[Bug 91202] Output to DVI-I (or DVI-D) is blank on Tonga (R9 285 and 380X) with multiple monitors

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

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

--- Comment #25 from Guido Winkelmann  ---
I tried upgrading to the newest commit in amd-staging-4.7 today
(680da8633ae17cdea8fddd1ede87253325c8ca25), and now it is broken now, but in a
different way, see: https://bugs.freedesktop.org/show_bug.cgi?id=98730

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

[Bug 98730] On kernel startup, all monitors will go blank and stay blank with newest amd-staging-4.7

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

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

Bug ID: 98730
   Summary: On kernel startup, all monitors will go blank and stay
blank with newest amd-staging-4.7
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: critical
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: guido-xorgbugs at unknownsite.de

When booting with the newest kernel from the amd-staging-4.7 branch from
https://cgit.freedesktop.org/~agd5f/linux/, all connected monitors will go
blank and stay blank indefinitely. The power indicator on the monitors will
start to blink as if there was no signal.

This is with commit 680da8633ae17cdea8fddd1ede87253325c8ca25. With an older
commit, d330e1e9c232895dbd0c183a647d41d54ecc0884, this branch still works.

DAL is enabled in the config in both cases.

The graphics card is a Sapphire Nitro Radeon R9 380X.

There are three monitors connected in total, one to the DVI-I port, one to the
DVI-D port and one to the DisplayPort.

I am using this particular branch as a workaround for the bug described in
https://bugs.freedesktop.org/show_bug.cgi?id=91202

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

[PATCH] drm/i2c/tda998x: fix spelling mistake

[Colin King]

From: Colin Ian King 

Trivial fix to spelling mistake "configutation" to "configuration"
in dev_err message

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/i2c/tda998x_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index af8683e..bebb619 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1260,7 +1260,7 @@ static int tda998x_audio_hw_params(struct device *dev, 
void *data,
}

if (audio.config == 0) {
-   dev_err(dev, "%s: No audio configutation found\n", __func__);
+   dev_err(dev, "%s: No audio configuration found\n", __func__);
return -EINVAL;
}

-- 
2.10.2

[PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"

[Sharma, Shashank]

On 11/14/2016 10:15 PM, Ville Syrjälä wrote:
> On Mon, Nov 14, 2016 at 10:12:04PM +0530, Sharma, Shashank wrote:
>> Regards
>>
>> Shashank
>>
>>
>> On 11/14/2016 9:50 PM, Ville Syrjälä wrote:
>>> On Mon, Nov 14, 2016 at 09:37:18PM +0530, Sharma, Shashank wrote:
 Regards

 Shashank


 On 11/14/2016 9:19 PM, Ville Syrjälä wrote:
> On Mon, Nov 14, 2016 at 08:14:34PM +0530, Sharma, Shashank wrote:
>> Regards
>> Shashank
>>> the revert:
>>>
>>>  HDMI2 connected 1920x1080+0+0 (normal left inverted right x axis y 
>>> axis) 700mm x 390mm
>>> -   1920x1080 60.00*+
>>> -   1920x1080i60.0050.00
>>> +   1920x1080 60.00*+  50.0059.9430.0025.0024.00
>>> 29.9723.98
>>> +   1920x1080i60.0050.0059.94
>>> 1600x1200 60.00
>>> 1680x1050 59.88
>>> 1280x1024 75.0260.02
>>> @@ -13,30 +13,29 @@
>>> 1360x768  60.02
>>> 1280x800  59.91
>>> 1152x864  75.00
>>> -   1280x720  60.0050.00
>>> +   1280x720  60.0050.0059.94
>>> 1024x768  75.0370.0760.00
>>> 832x624   74.55
>>> 800x600   72.1975.0060.32
>>> -   640x480   75.0072.8166.6759.94
>>> +   720x576   50.00
>>> +   720x480   60.0059.94
>>> +   640x480   75.0072.8166.6760.0059.94
>>> 720x400   70.08
>> None of these aspect ratios are new modes / new aspect ratios from HDMI
>> 2.0/CEA-861-F
>> These are the existing modes, and should be independent of reverted
>> patches.
> They're affected because your patches changed them by adding the aspect
> ratio flags to them.
 Yes, But they are independent of reverted patch, which adds aspect ratio
 for HDMI 2.0 ratios (64:27 and 256:135)
>>> The second patch had to be reverted so that the first patch would revert
>>> cleanly.
>>>
>>> This was with sna, which does this:
>>>  #define KNOWN_MODE_FLAGS ((1<<14)-1)
>>>  if (mode->status == MODE_OK && kmode->flags & ~KNOWN_MODE_FLAGS)
>>> mode->status = MODE_BAD; /* unknown flags => unhandled */
>>> so all the modes with an aspect ratio just vanished.
>>>
>>> -modesetting and -ati on the other hand just copy over the unknown
>>> bits into the xrandr mode structure, which sounds dubious at best:
>>>  mode->Flags = kmode->flags; //& FLAG_BITS;
>>> I've not checked what damage it can actually cause.
>>>
>>>
>>> It looks like a few modes disappeared from the kernel's mode list
>>> as well, presumably because some cea modes in the list originated from
>>> DTDs and whanot so they don't have an aspect ratio and that causes
>>> add_alternate_cea_modes() to ignore them. So not populating an aspect
>>> ratio for cea modes originating from a source other than
>>> edid_cea_modes[] looks like another bug to me as well.
>> I am writing a patch series to cap the aspect ratio implementation under
>> a drm_cap_hdmi2_aspect_ratios
>> This is how its going to work (inspired from the 2D/stereo series from
>> damien L)
>>
>> - Add a new capability hdmi2_ar
> It should be just a generic "expose aspect ratio flags to userspace?"
 Makes sense, in this way we can even revert the aspect_ratio property
 for HDMI connector, as discussed during
 the code review sessions of this patch series. In this way, when kernel
 will expose the aspect ratios, it will either
 do the aspect ratios as per EDID, or wont.
>> - by default parsing the new hdmi 2.0 aspect ratio will be disabled
>> under check of this cap
>> - during bootup time, while initializing the display, a userspace can
>> get_cap on the hdmi2_aspect_ratio
>> - If it wants HDMI 2.0 aspect ratio support, it will set the cap, and
>> kernel will expose these aspect ratios
>>> Another bug I think might be the ordering of the modes with aspect ratio
>>> specified. IIRC the spec says that the preferred aspect ratio should be
>>> listed first in the EDID, but I don't think we preserve that ordering
>>> in the final mode list. I guess we could fix that by somehow noting
>>> which aspect ratio is preferred and sort based on that, or we try to
>>> preserve the order from the EDID until we're ready to sort, and then do
>>> the sorting with a stable algorithm.
>> AFAIK The mode order and priority is decided and arranged in userspace,
>> based on various factors like
>> - preferred mode.
>> - previously applied mode in previous sessions (like for android tvs)
>> - Bigger h/w vs better refresh rate ?
>> - Xserver applies its own algorithms to decide which mode should be
>> shown first.
> Xorg does sort on its own. But since it 

[linux-sunxi] [PATCH v5 4/7] ASoC: sunxi: Add sun8i I2S driver

[Maxime Ripard]

On Tue, Nov 08, 2016 at 11:51:29AM +0100, Jean-Francois Moine wrote:
> On Mon, 7 Nov 2016 21:05:05 +0100
> Maxime Ripard  wrote:
> 
> > Hi,
> > 
> > On Sun, Nov 06, 2016 at 07:02:48PM +0100, Jean-Francois Moine wrote:
> > > On Sun, 23 Oct 2016 09:33:16 +0800
> > > Chen-Yu Tsai  wrote:
> > > 
> > > > On Fri, Oct 21, 2016 at 4:36 PM, Jean-Francois Moine  > > > free.fr> wrote:
> > > > > This patch adds I2S support to sun8i SoCs as the A83T and H3.
> > > > >
> > > > > Signed-off-by: Jean-Francois Moine 
> > > > > ---
> > > > > Note: This driver is closed to the sun4i-i2s except that:
> > > > > - it handles the H3
> > > > 
> > > > If it's close to sun4i-i2s, you should probably rework that one to 
> > > > support
> > > > the newer SoCs.
> > > 
> > > I started to add the H3 into the sun4i-i2s, but I am blocked with
> > > regmap.
> > > Many H3 registers are common with the A10, but some of them have more
> > > or less fields, the fields may be at different offsets. And, finally,
> > > some registers are completely different.
> > > This would not raise any problem, except with regmap which is really
> > > painful.
> > 
> > That's weird, because regmap's regmap_field should make that much
> > easier.
> 
> #define field_relaxed(addr, mask, val) \
>   writel_relaxed((readl_relaxed(addr) & mask) | val, addr)

I'm not sure what you mean here.

> > > As I may understood, regmap is used to simplify suspend/resume, but, is
> > > it useful to save the I2S register on suspend?
> > > Practically, I am streaming some tune on my device. I suspend it for
> > > any reason. The next morning, I resume it. Are you sure I want to
> > > continue to hear the end of the tune?
> > > 
> > > I better think that streaming should be simply stopped on suspend.
> > 
> > You're mistaken. The code in there is for *runtime* suspend, ie when
> > the device is no longer used, so that case shouldn't even happen at
> > all.
> > 
> > (And real suspend isn't supported anyway)
> 
> Is it time to remove this useless code?

Which useless code?

> > > Then, there is no need to save the playing registers, and, here I am,
> > > there is no need to use regmap.
> > > 
> > > May I go this way?
> > 
> > No, please don't. regmap is also providing very useful features, such
> > as access to all the registers through debugfs, or tracing. What
> > exactly feels painful to you?
> 
> When the I/O registers are in memory (that's the case), you may access
> them (read and write) thru /dev/mem.

For all the registers if you want to dump all of them. It needs
scripting, it needs root access, and it needs some tool (either devmem
or a custom one) to dump the values. And this is if you have the right
kernel configuration options (devmem enabled, with the protection
against mapped devices disabled).

It just works with debugfs.

> Also, is a register access trace really needed in this driver?

Yes.

> The pain is to define the regmap_config (which registers can be
> read/write/volatile and which can be the values the u-boot let us in
> the registers at startup time), and the lot of code which is run instead
> of simple load/store machine instructions.

This is only needed if you want to use caching, and caching is
optional.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161114/5cda6589/attachment.sig>

[PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"

[Sharma, Shashank]

Regards

Shashank


On 11/14/2016 9:50 PM, Ville Syrjälä wrote:
> On Mon, Nov 14, 2016 at 09:37:18PM +0530, Sharma, Shashank wrote:
>> Regards
>>
>> Shashank
>>
>>
>> On 11/14/2016 9:19 PM, Ville Syrjälä wrote:
>>> On Mon, Nov 14, 2016 at 08:14:34PM +0530, Sharma, Shashank wrote:
 Regards
 Shashank
> the revert:
>
> HDMI2 connected 1920x1080+0+0 (normal left inverted right x axis y 
> axis) 700mm x 390mm
> -   1920x1080 60.00*+
> -   1920x1080i60.0050.00
> +   1920x1080 60.00*+  50.0059.9430.0025.0024.00
> 29.9723.98
> +   1920x1080i60.0050.0059.94
>1600x1200 60.00
>1680x1050 59.88
>1280x1024 75.0260.02
> @@ -13,30 +13,29 @@
>1360x768  60.02
>1280x800  59.91
>1152x864  75.00
> -   1280x720  60.0050.00
> +   1280x720  60.0050.0059.94
>1024x768  75.0370.0760.00
>832x624   74.55
>800x600   72.1975.0060.32
> -   640x480   75.0072.8166.6759.94
> +   720x576   50.00
> +   720x480   60.0059.94
> +   640x480   75.0072.8166.6760.0059.94
>720x400   70.08
 None of these aspect ratios are new modes / new aspect ratios from HDMI
 2.0/CEA-861-F
 These are the existing modes, and should be independent of reverted
 patches.
>>> They're affected because your patches changed them by adding the aspect
>>> ratio flags to them.
>> Yes, But they are independent of reverted patch, which adds aspect ratio
>> for HDMI 2.0 ratios (64:27 and 256:135)
> The second patch had to be reverted so that the first patch would revert
> cleanly.
>
> This was with sna, which does this:
> #define KNOWN_MODE_FLAGS ((1<<14)-1)
> if (mode->status == MODE_OK && kmode->flags & ~KNOWN_MODE_FLAGS)
>   mode->status = MODE_BAD; /* unknown flags => unhandled */
> so all the modes with an aspect ratio just vanished.
>
> -modesetting and -ati on the other hand just copy over the unknown
> bits into the xrandr mode structure, which sounds dubious at best:
> mode->Flags = kmode->flags; //& FLAG_BITS;
> I've not checked what damage it can actually cause.
>
>
> It looks like a few modes disappeared from the kernel's mode list
> as well, presumably because some cea modes in the list originated from
> DTDs and whanot so they don't have an aspect ratio and that causes
> add_alternate_cea_modes() to ignore them. So not populating an aspect
> ratio for cea modes originating from a source other than
> edid_cea_modes[] looks like another bug to me as well.
 I am writing a patch series to cap the aspect ratio implementation under
 a drm_cap_hdmi2_aspect_ratios
 This is how its going to work (inspired from the 2D/stereo series from
 damien L)

 - Add a new capability hdmi2_ar
>>> It should be just a generic "expose aspect ratio flags to userspace?"
>> Makes sense, in this way we can even revert the aspect_ratio property
>> for HDMI connector, as discussed during
>> the code review sessions of this patch series. In this way, when kernel
>> will expose the aspect ratios, it will either
>> do the aspect ratios as per EDID, or wont.
 - by default parsing the new hdmi 2.0 aspect ratio will be disabled
 under check of this cap
 - during bootup time, while initializing the display, a userspace can
 get_cap on the hdmi2_aspect_ratio
 - If it wants HDMI 2.0 aspect ratio support, it will set the cap, and
 kernel will expose these aspect ratios
> Another bug I think might be the ordering of the modes with aspect ratio
> specified. IIRC the spec says that the preferred aspect ratio should be
> listed first in the EDID, but I don't think we preserve that ordering
> in the final mode list. I guess we could fix that by somehow noting
> which aspect ratio is preferred and sort based on that, or we try to
> preserve the order from the EDID until we're ready to sort, and then do
> the sorting with a stable algorithm.
 AFAIK The mode order and priority is decided and arranged in userspace,
 based on various factors like
 - preferred mode.
 - previously applied mode in previous sessions (like for android tvs)
 - Bigger h/w vs better refresh rate ?
 - Xserver applies its own algorithms to decide which mode should be
 shown first.
>>> Xorg does sort on its own. But since it doesn't know anything about
>>> aspect ratios and whatnot I wouldn't rely on that for anything. I
>>> also wouldn't expect eg. wayland compositors to do their own sorting.
>>> And yeah, looks like weston at least doesn't do any sorting whatsoever.
>>>
 I dont think kernel needs to bother about it.
>>> So I'm going to say that we in fact 

[PATCH v6 8/9] drm/hisilicon/hibmc: Add vblank interruput

[Rongrong Zou]

在 2016/11/11 9:49, Sean Paul 写道:
> On Fri, Oct 28, 2016 at 3:28 AM, Rongrong Zou  
> wrote:
>> Add vblank interrupt.
>>
>> Signed-off-by: Rongrong Zou 
>> ---
>>   drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 56 
>> -
>>   drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h |  1 +
>>   2 files changed, 56 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c 
>> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> index 4253603..b668e3e 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> @@ -40,16 +40,46 @@
>>
>>   static int hibmc_enable_vblank(struct drm_device *dev, unsigned int pipe)
>>   {
>> +   struct hibmc_drm_device *hidev =
>> +   (struct hibmc_drm_device *)dev->dev_private;
>> +
>> +   writel(HIBMC_RAW_INTERRUPT_EN_VBLANK(1),
>> +  hidev->mmio + HIBMC_RAW_INTERRUPT_EN);
>> +
>>  return 0;
>>   }
>>
>>   static void hibmc_disable_vblank(struct drm_device *dev, unsigned int pipe)
>>   {
>> +   struct hibmc_drm_device *hidev =
>> +   (struct hibmc_drm_device *)dev->dev_private;
>> +
>> +   writel(HIBMC_RAW_INTERRUPT_EN_VBLANK(0),
>> +  hidev->mmio + HIBMC_RAW_INTERRUPT_EN);
>> +}
>> +
>> +irqreturn_t hibmc_drm_interrupt(int irq, void *arg)
>> +{
>> +   struct drm_device *dev = (struct drm_device *)arg;
>> +   struct hibmc_drm_device *hidev =
>> +   (struct hibmc_drm_device *)dev->dev_private;
>> +   struct drm_crtc *crtc = >crtc;
>> +   u32 status;
>> +
>> +   status = readl(hidev->mmio + HIBMC_RAW_INTERRUPT);
>> +
>> +   if (status & HIBMC_RAW_INTERRUPT_VBLANK(1)) {
>> +   writel(HIBMC_RAW_INTERRUPT_VBLANK(1),
>> +  hidev->mmio + HIBMC_RAW_INTERRUPT);
>> +   drm_crtc_handle_vblank(crtc);
>> +   }
>> +
>> +   return IRQ_HANDLED;
>>   }
>>
>>   static struct drm_driver hibmc_driver = {
>>  .driver_features= DRIVER_GEM | DRIVER_MODESET |
>> - DRIVER_ATOMIC,
>> + DRIVER_ATOMIC | DRIVER_HAVE_IRQ,
>>  .fops   = _fops,
>>  .name   = "hibmc",
>>  .date   = "20160828",
>> @@ -63,6 +93,7 @@ static void hibmc_disable_vblank(struct drm_device *dev, 
>> unsigned int pipe)
>>  .dumb_create= hibmc_dumb_create,
>>  .dumb_map_offset= hibmc_dumb_mmap_offset,
>>  .dumb_destroy   = drm_gem_dumb_destroy,
>> +   .irq_handler= hibmc_drm_interrupt,
>>   };
>>
>>   static int hibmc_pm_suspend(struct device *dev)
>> @@ -242,6 +273,13 @@ static int hibmc_unload(struct drm_device *dev)
>>  struct hibmc_drm_device *hidev = dev->dev_private;
>>
>>  hibmc_fbdev_fini(hidev);
>> +
>> +   if (dev->irq_enabled)
>> +   drm_irq_uninstall(dev);
>> +   if (hidev->msi_enabled)
>> +   pci_disable_msi(dev->pdev);
>> +   drm_vblank_cleanup(dev);
>> +
>>  hibmc_kms_fini(hidev);
>>  hibmc_mm_fini(hidev);
>>  hibmc_hw_fini(hidev);
>> @@ -272,6 +310,22 @@ static int hibmc_load(struct drm_device *dev, unsigned 
>> long flags)
>>  if (ret)
>>  goto err;
>>
>> +   ret = drm_vblank_init(dev, dev->mode_config.num_crtc);
>> +   if (ret) {
>> +   DRM_ERROR("failed to initialize vblank.\n");
>> +   goto err;
>> +   }
>> +
>> +   hidev->msi_enabled = 0;
>> +   if (pci_enable_msi(dev->pdev)) {
>
> It would be useful to check and print the return value of this.

agreed, thanks.

>
>> +   DRM_ERROR("Enabling MSI failed!\n");
>> +   } else {
>> +   hidev->msi_enabled = 1;
>> +   ret = drm_irq_install(dev, dev->pdev->irq);
>> +   if (ret)
>> +   DRM_ERROR("install irq failed , ret = %d\n", ret);
>
> DRM_WARN might be more appropriate, given that this isn't considered fatal.

agreed, thanks.

>
>> +   }
>> +
>>  /* reset all the states of crtc/plane/encoder/connector */
>>  drm_mode_config_reset(dev);
>>
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h 
>> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> index 450247d..f1706fb 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> @@ -42,6 +42,7 @@ struct hibmc_drm_device {
>>  void __iomem   *fb_map;
>>  unsigned long  fb_base;
>>  unsigned long  fb_size;
>> +   int msi_enabled;
>
> Why not bool?

agreed, thanks.

Regards,
Rongrong.

>
>>
>>  /* drm */
>>  struct drm_device  *dev;
>> --
>> 1.9.1
>>
>>
>> ___
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> 

[PATCH v6 7/9] drm/hisilicon/hibmc: Add connector for VDAC

[Rongrong Zou]

在 2016/11/11 9:45, Sean Paul 写道:
> On Fri, Oct 28, 2016 at 3:28 AM, Rongrong Zou  
> wrote:
>> Add connector funcs and helper funcs for VDAC.
>>
>> Signed-off-by: Rongrong Zou 
>> ---
>>   drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c  |  8 +++
>>   drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h  |  2 +
>>   drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 76 
>> 
>>   3 files changed, 86 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c 
>> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> index ba191e1..4253603 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> @@ -131,6 +131,14 @@ static int hibmc_kms_init(struct hibmc_drm_device 
>> *hidev)
>>  return ret;
>>  }
>>
>> +   ret = hibmc_connector_init(hidev);
>> +   if (ret) {
>> +   DRM_ERROR("failed to init connector\n");
>> +   return ret;
>> +   }
>> +
>> +   drm_mode_connector_attach_encoder(>connector,
>> + >encoder);
>
> The connector should be initialized in the vdac driver with the
> encoder, not in the drv file (same as plane/crtc)

applied, thanks.

>
>>  return 0;
>>   }
>>
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h 
>> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> index 401cea4..450247d 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> @@ -48,6 +48,7 @@ struct hibmc_drm_device {
>>  struct drm_plane plane;
>>  struct drm_crtc crtc;
>>  struct drm_encoder encoder;
>> +   struct drm_connector connector;
>
> No need to keep track here

will allocate with devm_kzalloc(), thanks.

>
>>  bool mode_config_initialized;
>>
>>  /* ttm */
>> @@ -89,6 +90,7 @@ static inline struct hibmc_bo *gem_to_hibmc_bo(struct 
>> drm_gem_object *gem)
>>   int hibmc_plane_init(struct hibmc_drm_device *hidev);
>>   int hibmc_crtc_init(struct hibmc_drm_device *hidev);
>>   int hibmc_encoder_init(struct hibmc_drm_device *hidev);
>> +int hibmc_connector_init(struct hibmc_drm_device *hidev);
>>   int hibmc_fbdev_init(struct hibmc_drm_device *hidev);
>>   void hibmc_fbdev_fini(struct hibmc_drm_device *hidev);
>>
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c 
>> b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
>> index 953f659..ebefcd1 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c
>> @@ -87,3 +87,79 @@ int hibmc_encoder_init(struct hibmc_drm_device *hidev)
>>  drm_encoder_helper_add(encoder, _encoder_helper_funcs);
>>  return 0;
>>   }
>> +
>> +static int hibmc_connector_get_modes(struct drm_connector *connector)
>> +{
>> +   int count;
>> +
>> +   count = drm_add_modes_noedid(connector, 800, 600);
>> +   drm_set_preferred_mode(connector, defx, defy);
>
> So you have defx/defy as module parameters, but then hardcode the
> 800x600 mode. If defx/defy is anything other than 800/600, this won't
> work. I think you should just remove the defx/defy module params and
> rely on userspace adding modes as appropriate.

will remove them, thanks.

>
>> +   return count;
>> +}
>> +
>> +static int hibmc_connector_mode_valid(struct drm_connector *connector,
>> + struct drm_display_mode *mode)
>> +{
>> +   struct hibmc_drm_device *hiprivate =
>> +container_of(connector, struct hibmc_drm_device, connector);
>> +   unsigned long size = mode->hdisplay * mode->vdisplay * 4;
>
> Why * 4 here and why * 2 below? You support formats less than 32 bpp,
> so the * 4 isn't necessarily correct for all formats. Is the * 2 to
> account for front & back buffer?
>

it is from bochs, the original comments below:
/*
 * Make sure we can fit two framebuffers into video memory.
 * This allows up to 1600x1200 with 16 MB (default size).
 * If you want more try this:
 * 'qemu -vga std -global VGA.vgamem_mb=32 $otherargs'
 */
i think it is not necessary for hibmc, so will remove it and return
MODE_OK, thanks.

>
>> +
>> +   if (size * 2 > hiprivate->fb_size)
>> +   return MODE_BAD;
>> +
>> +   return MODE_OK;
>> +}
>> +
>> +static struct drm_encoder *
>> +hibmc_connector_best_encoder(struct drm_connector *connector)
>> +{
>> +   int enc_id = connector->encoder_ids[0];
>> +
>> +   /* pick the encoder ids */
>> +   if (enc_id)
>> +   return drm_encoder_find(connector->dev, enc_id);
>
> Can't you just do return drm_encoder_find(connector->dev,
> connector->encoder_ids[0]); ?
>
> ie: won't drm_encoder_find do the right thing if you pass in id == 0?

hibmc_connector_best_encoder(struct drm_connector *connector)
{
return 

[v17 2/2] drm/bridge: Add I2C based driver for ps8640 bridge

[Jitao Shi]

Dear Archit,

  Thanks a lot for your reviewing. 
  I have sent a new patchset for those review items.

On Fri, 2016-11-11 at 11:32 +0530, Archit Taneja wrote:
> Hi Jitao,
> 
> I couldn't locate the original mail, so posting on this thread instead.
> Some comments below.
> 
> On 11/10/2016 10:09 PM, Enric Balletbo Serra wrote:
> > Hi Jitao,
> >
> > 2016-08-27 8:44 GMT+02:00 Jitao Shi :
> >> This patch adds drm_bridge driver for parade DSI to eDP bridge chip.
> >>
> >> Signed-off-by: Jitao Shi 
> >> Reviewed-by: Daniel Kurtz 
> >> ---
> >> Changes since v16:
> >>  - Disable ps8640 DSI MCS Function.
> >>  - Rename gpios name more clearly.
> >>  - Tune the ps8640 power on sequence.
> >>
> >> Changes since v15:
> >>  - Drop drm_connector_(un)register calls from parade ps8640.
> >>The main DRM driver mtk_drm_drv now calls
> >>drm_connector_register_all() after drm_dev_register() in the
> >>mtk_drm_bind() function. That function should iterate over all
> >>connectors and call drm_connector_register() for each of them.
> >>So, remove drm_connector_(un)register calls from parade ps8640.
> >>
> >> Changes since v14:
> >>  - update copyright info.
> >>  - change bridge_to_ps8640 and connector_to_ps8640 to inline function.
> >>  - fix some coding style.
> >>  - use sizeof as array counter.
> >>  - use drm_get_edid when read edid.
> >>  - add mutex when firmware updating.
> >>
> >> Changes since v13:
> >>  - add const on data, ps8640_write_bytes(struct i2c_client *client, const 
> >> u8 *data, u16 data_len)
> >>  - fix PAGE2_SW_REST tyro.
> >>  - move the buf[3] init to entrance of the function.
> >>
> >> Changes since v12:
> >>  - fix hw_chip_id build warning
> >>
> >> Changes since v11:
> >>  - Remove depends on I2C, add DRM depends
> >>  - Reuse ps8640_write_bytes() in ps8640_write_byte()
> >>  - Use timer check for polling like the routines in 
> >>  - Fix no drm_connector_unregister/drm_connector_cleanup when 
> >> ps8640_bridge_attach fail
> >>  - Check the ps8640 hardware id in ps8640_validate_firmware
> >>  - Remove fw_version check
> >>  - Move ps8640_validate_firmware before ps8640_enter_bl
> >>  - Add ddc_i2c unregister when probe fail and ps8640_remove
> >> ---
> >>  drivers/gpu/drm/bridge/Kconfig |   12 +
> >>  drivers/gpu/drm/bridge/Makefile|1 +
> >>  drivers/gpu/drm/bridge/parade-ps8640.c | 1077 
> >> 
> >>  3 files changed, 1090 insertions(+)
> >>  create mode 100644 drivers/gpu/drm/bridge/parade-ps8640.c
> >>
> >> diff --git a/drivers/gpu/drm/bridge/Kconfig 
> >> b/drivers/gpu/drm/bridge/Kconfig
> >> index b590e67..c59d043 100644
> >> --- a/drivers/gpu/drm/bridge/Kconfig
> >> +++ b/drivers/gpu/drm/bridge/Kconfig
> >> @@ -50,6 +50,18 @@ config DRM_PARADE_PS8622
> >> ---help---
> >>   Parade eDP-LVDS bridge chip driver.
> >>
> >> +config DRM_PARADE_PS8640
> >> +   tristate "Parade PS8640 MIPI DSI to eDP Converter"
> >> +   depends on DRM
> >> +   depends on OF
> >> +   select DRM_KMS_HELPER
> >> +   select DRM_MIPI_DSI
> >> +   select DRM_PANEL
> >> +   ---help---
> >> + Choose this option if you have PS8640 for display
> >> + The PS8640 is a high-performance and low-power
> >> + MIPI DSI to eDP converter
> >> +
> >>  config DRM_SII902X
> >> tristate "Silicon Image sii902x RGB/HDMI bridge"
> >> depends on OF
> >> diff --git a/drivers/gpu/drm/bridge/Makefile 
> >> b/drivers/gpu/drm/bridge/Makefile
> >> index efdb07e..3360537 100644
> >> --- a/drivers/gpu/drm/bridge/Makefile
> >> +++ b/drivers/gpu/drm/bridge/Makefile
> >> @@ -5,6 +5,7 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
> >>  obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
> >>  obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
> >>  obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> >> +obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
> >>  obj-$(CONFIG_DRM_SII902X) += sii902x.o
> >>  obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
> >>  obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
> >> diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
> >> b/drivers/gpu/drm/bridge/parade-ps8640.c
> >> new file mode 100644
> >> index 000..7d67431
> >> --- /dev/null
> >> +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
> >> @@ -0,0 +1,1077 @@
> >> +/*
> >> + * Copyright (c) 2016 MediaTek Inc.
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify
> >> + * it under the terms of the GNU General Public License version 2 as
> >> + * published by the Free Software Foundation.
> >> + *
> >> + * This program is distributed in the hope that it will be useful,
> >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> >> + * GNU General Public License for more details.
> >> + */
> >> +
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> 
> Not needed.
> 
> >> +#include 
> >> 

[PATCH v18 2/2] drm/bridge: Add I2C based driver for ps8640 bridge

[Jitao Shi]

This patch adds drm_bridge driver for parade DSI to eDP bridge chip.

Signed-off-by: Jitao Shi 
Reviewed-by: Daniel Kurtz 
Reviewed-by: Enric Balletbo i Serra 
---
Changes since v17:
 - remove some unused head files.
 - add macros for ps8640 pages.
 - remove ddc_i2c client
 - add mipi_dsi_device_register_full
 - remove the manufacturer from the name and i2c_device_id

Changes since v16:
 - Disable ps8640 DSI MCS Function.
 - Rename gpios name more clearly.
 - Tune the ps8640 power on sequence.

Changes since v15:
 - Drop drm_connector_(un)register calls from parade ps8640.
   The main DRM driver mtk_drm_drv now calls
   drm_connector_register_all() after drm_dev_register() in the
   mtk_drm_bind() function. That function should iterate over all
   connectors and call drm_connector_register() for each of them.
   So, remove drm_connector_(un)register calls from parade ps8640.

Changes since v14:
 - update copyright info.
 - change bridge_to_ps8640 and connector_to_ps8640 to inline function.
 - fix some coding style.
 - use sizeof as array counter.
 - use drm_get_edid when read edid.
 - add mutex when firmware updating. 

Changes since v13:
 - add const on data, ps8640_write_bytes(struct i2c_client *client, const u8 
*data, u16 data_len)
 - fix PAGE2_SW_REST tyro.
 - move the buf[3] init to entrance of the function.

Changes since v12:
 - fix hw_chip_id build warning

Changes since v11:
 - Remove depends on I2C, add DRM depends
 - Reuse ps8640_write_bytes() in ps8640_write_byte()
 - Use timer check for polling like the routines in 
 - Fix no drm_connector_unregister/drm_connector_cleanup when 
ps8640_bridge_attach fail
 - Check the ps8640 hardware id in ps8640_validate_firmware
 - Remove fw_version check
 - Move ps8640_validate_firmware before ps8640_enter_bl
 - Add ddc_i2c unregister when probe fail and ps8640_remove
---
 drivers/gpu/drm/bridge/Kconfig |   12 +
 drivers/gpu/drm/bridge/Makefile|1 +
 drivers/gpu/drm/bridge/parade-ps8640.c | 1079 
 3 files changed, 1092 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/parade-ps8640.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 10e12e7..7f41bbc 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -57,6 +57,18 @@ config DRM_PARADE_PS8622
---help---
  Parade eDP-LVDS bridge chip driver.

+config DRM_PARADE_PS8640
+   tristate "Parade PS8640 MIPI DSI to eDP Converter"
+   depends on DRM
+   depends on OF
+   select DRM_KMS_HELPER
+   select DRM_MIPI_DSI
+   select DRM_PANEL
+   ---help---
+ Choose this option if you have PS8640 for display
+ The PS8640 is a high-performance and low-power
+ MIPI DSI to eDP converter
+
 config DRM_SII902X
tristate "Silicon Image sii902x RGB/HDMI bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index cdf3a3c..7d93d40 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
+obj-$(CONFIG_DRM_PARADE_PS8640) += parade-ps8640.o
 obj-$(CONFIG_DRM_SII902X) += sii902x.o
 obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
 obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c 
b/drivers/gpu/drm/bridge/parade-ps8640.c
new file mode 100644
index 000..2d9c337
--- /dev/null
+++ b/drivers/gpu/drm/bridge/parade-ps8640.c
@@ -0,0 +1,1079 @@
+/*
+ * Copyright (c) 2016 MediaTek Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PAGE1_VSTART   0x6b
+#define PAGE2_SPI_CFG3 0x82
+#define I2C_TO_SPI_RESET   0x20
+#define PAGE2_ROMADD_BYTE1 0x8e
+#define PAGE2_ROMADD_BYTE2 0x8f
+#define PAGE2_SWSPI_WDATA  0x90
+#define PAGE2_SWSPI_RDATA  0x91
+#define PAGE2_SWSPI_LEN0x92
+#define PAGE2_SWSPI_CTL0x93
+#define TRIGGER_NO_READBACK0x05
+#define TRIGGER_READBACK   0x01
+#define PAGE2_SPI_STATUS   0x9e
+#define SPI_READY  0x0c
+#define PAGE2_GPIO_L   0xa6
+#define PAGE2_GPIO_H   0xa7
+#define PS_GPIO9   BIT(1)
+#define 

[PATCH v18 1/2] Documentation: bridge: Add documentation for ps8640 DT properties

[Jitao Shi]

Add documentation for DT properties supported by
ps8640 DSI-eDP converter.

Signed-off-by: Jitao Shi 
Acked-by: Rob Herring 
Reviewed-by: Philipp Zabel 
---
Changes since v17:
 - No change.

Changes since v16:
 - No change.

Changes since v15:
 - No change.

Changes since v14:
 - change mode-sel-gpios as optional.
---
 .../devicetree/bindings/display/bridge/ps8640.txt  |   44 
 1 file changed, 44 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/display/bridge/ps8640.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/ps8640.txt 
b/Documentation/devicetree/bindings/display/bridge/ps8640.txt
new file mode 100644
index 000..7b13f92
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ps8640.txt
@@ -0,0 +1,44 @@
+ps8640-bridge bindings
+
+Required properties:
+   - compatible: "parade,ps8640"
+   - reg: first page address of the bridge.
+   - sleep-gpios: OF device-tree gpio specification for PD pin.
+   - reset-gpios: OF device-tree gpio specification for reset pin.
+   - vdd12-supply: OF device-tree regulator specification for 1.2V power.
+   - vdd33-supply: OF device-tree regulator specification for 3.3V power.
+   - ports: The device node can contain video interface port nodes per
+the video-interfaces bind[1]. For port at 0,set the reg = <0> 
as
+ps8640 dsi in and port at 1,set the reg = <1> as ps8640 eDP 
out.
+
+Optional properties:
+   - mode-sel-gpios: OF device-tree gpio specification for mode-sel pin.
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+   edp-bridge at 18 {
+   compatible = "parade,ps8640";
+   reg = <0x18>;
+   sleep-gpios = < 116 GPIO_ACTIVE_LOW>;
+   reset-gpios = < 115 GPIO_ACTIVE_LOW>;
+   mode-sel-gpios = < 92 GPIO_ACTIVE_HIGH>;
+   vdd12-supply = <_fixed_1v2>;
+   vdd33-supply = <_vgp2_reg>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   port at 0 {
+   reg = <0>;
+   ps8640_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   port at 1 {
+   reg = <1>;
+   ps8640_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
-- 
1.7.9.5

[PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"

[Sharma, Shashank]

Regards

Shashank


On 11/14/2016 9:19 PM, Ville Syrjälä wrote:
> On Mon, Nov 14, 2016 at 08:14:34PM +0530, Sharma, Shashank wrote:
>> Regards
>> Shashank
>>> the revert:
>>>
>>>HDMI2 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 
>>> 700mm x 390mm
>>> -   1920x1080 60.00*+
>>> -   1920x1080i60.0050.00
>>> +   1920x1080 60.00*+  50.0059.9430.0025.0024.00
>>> 29.9723.98
>>> +   1920x1080i60.0050.0059.94
>>>   1600x1200 60.00
>>>   1680x1050 59.88
>>>   1280x1024 75.0260.02
>>> @@ -13,30 +13,29 @@
>>>   1360x768  60.02
>>>   1280x800  59.91
>>>   1152x864  75.00
>>> -   1280x720  60.0050.00
>>> +   1280x720  60.0050.0059.94
>>>   1024x768  75.0370.0760.00
>>>   832x624   74.55
>>>   800x600   72.1975.0060.32
>>> -   640x480   75.0072.8166.6759.94
>>> +   720x576   50.00
>>> +   720x480   60.0059.94
>>> +   640x480   75.0072.8166.6760.0059.94
>>>   720x400   70.08
>> None of these aspect ratios are new modes / new aspect ratios from HDMI
>> 2.0/CEA-861-F
>> These are the existing modes, and should be independent of reverted
>> patches.
> They're affected because your patches changed them by adding the aspect
> ratio flags to them.
Yes, But they are independent of reverted patch, which adds aspect ratio 
for HDMI 2.0 ratios (64:27 and 256:135)
>>> This was with sna, which does this:
>>>#define KNOWN_MODE_FLAGS ((1<<14)-1)
>>>if (mode->status == MODE_OK && kmode->flags & ~KNOWN_MODE_FLAGS)
>>> mode->status = MODE_BAD; /* unknown flags => unhandled */
>>> so all the modes with an aspect ratio just vanished.
>>>
>>> -modesetting and -ati on the other hand just copy over the unknown
>>> bits into the xrandr mode structure, which sounds dubious at best:
>>>mode->Flags = kmode->flags; //& FLAG_BITS;
>>> I've not checked what damage it can actually cause.
>>>
>>>
>>> It looks like a few modes disappeared from the kernel's mode list
>>> as well, presumably because some cea modes in the list originated from
>>> DTDs and whanot so they don't have an aspect ratio and that causes
>>> add_alternate_cea_modes() to ignore them. So not populating an aspect
>>> ratio for cea modes originating from a source other than
>>> edid_cea_modes[] looks like another bug to me as well.
>> I am writing a patch series to cap the aspect ratio implementation under
>> a drm_cap_hdmi2_aspect_ratios
>> This is how its going to work (inspired from the 2D/stereo series from
>> damien L)
>>
>> - Add a new capability hdmi2_ar
> It should be just a generic "expose aspect ratio flags to userspace?"
Makes sense, in this way we can even revert the aspect_ratio property 
for HDMI connector, as discussed during
the code review sessions of this patch series. In this way, when kernel 
will expose the aspect ratios, it will either
do the aspect ratios as per EDID, or wont.
>
>> - by default parsing the new hdmi 2.0 aspect ratio will be disabled
>> under check of this cap
>> - during bootup time, while initializing the display, a userspace can
>> get_cap on the hdmi2_aspect_ratio
>> - If it wants HDMI 2.0 aspect ratio support, it will set the cap, and
>> kernel will expose these aspect ratios
>>> Another bug I think might be the ordering of the modes with aspect ratio
>>> specified. IIRC the spec says that the preferred aspect ratio should be
>>> listed first in the EDID, but I don't think we preserve that ordering
>>> in the final mode list. I guess we could fix that by somehow noting
>>> which aspect ratio is preferred and sort based on that, or we try to
>>> preserve the order from the EDID until we're ready to sort, and then do
>>> the sorting with a stable algorithm.
>> AFAIK The mode order and priority is decided and arranged in userspace,
>> based on various factors like
>> - preferred mode.
>> - previously applied mode in previous sessions (like for android tvs)
>> - Bigger h/w vs better refresh rate ?
>> - Xserver applies its own algorithms to decide which mode should be
>> shown first.
> Xorg does sort on its own. But since it doesn't know anything about
> aspect ratios and whatnot I wouldn't rely on that for anything. I
> also wouldn't expect eg. wayland compositors to do their own sorting.
> And yeah, looks like weston at least doesn't do any sorting whatsoever.
>
>> I dont think kernel needs to bother about it.
> So I'm going to say that we in fact do need to bother.
>
IMHO, making policies for UI is not a part of kernel design, a UI 
manager (Hardware composed, X or Wayland) should take care of it, as
they have access to much information (Like previously applied mode, user 
preference etc). When it comes to sorting of modes, the only general rule
across drivers like FB, V4L2, I have seen is the first mode in the list 
should be preferred mode, which we are still keeping. And after that 

[PATCH v10 3/3] drm/fence: add out-fences support

[Daniel Vetter]

On Mon, Nov 14, 2016 at 3:57 PM, Brian Starkey  wrote:
> I was just writing some internal docs, and it occurred to me that the
> out-fence implementation here doesn't seem to match what we discussed
> with Ville a few weeks back (which had completely slipped my mind).
>
> Did the idea of returning -1 fences for multiple commits within a
> frame get dropped? I didn't see any discussion further than that
> thread on v5 from October:
> http://lkml.iu.edu/hypermail/linux/kernel/1610.2/04727.html

Atm we only support a queue depth of 1, and not faster than vblank.
This was just discussions to make sure we're not drawing ourselves
into a corner with this uabi.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"

[Sharma, Shashank]

Regards
Shashank
> the revert:
>
>   HDMI2 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 
> 700mm x 390mm
> -   1920x1080 60.00*+
> -   1920x1080i60.0050.00
> +   1920x1080 60.00*+  50.0059.9430.0025.0024.0029.97 
>23.98
> +   1920x1080i60.0050.0059.94
>  1600x1200 60.00
>  1680x1050 59.88
>  1280x1024 75.0260.02
> @@ -13,30 +13,29 @@
>  1360x768  60.02
>  1280x800  59.91
>  1152x864  75.00
> -   1280x720  60.0050.00
> +   1280x720  60.0050.0059.94
>  1024x768  75.0370.0760.00
>  832x624   74.55
>  800x600   72.1975.0060.32
> -   640x480   75.0072.8166.6759.94
> +   720x576   50.00
> +   720x480   60.0059.94
> +   640x480   75.0072.8166.6760.0059.94
>  720x400   70.08
None of these aspect ratios are new modes / new aspect ratios from HDMI 
2.0/CEA-861-F
These are the existing modes, and should be independent of reverted 
patches.
> This was with sna, which does this:
>   #define KNOWN_MODE_FLAGS ((1<<14)-1)
>   if (mode->status == MODE_OK && kmode->flags & ~KNOWN_MODE_FLAGS)
>   mode->status = MODE_BAD; /* unknown flags => unhandled */
> so all the modes with an aspect ratio just vanished.
>
> -modesetting and -ati on the other hand just copy over the unknown
> bits into the xrandr mode structure, which sounds dubious at best:
>   mode->Flags = kmode->flags; //& FLAG_BITS;
> I've not checked what damage it can actually cause.
>
>
> It looks like a few modes disappeared from the kernel's mode list
> as well, presumably because some cea modes in the list originated from
> DTDs and whanot so they don't have an aspect ratio and that causes
> add_alternate_cea_modes() to ignore them. So not populating an aspect
> ratio for cea modes originating from a source other than
> edid_cea_modes[] looks like another bug to me as well.
I am writing a patch series to cap the aspect ratio implementation under 
a drm_cap_hdmi2_aspect_ratios
This is how its going to work (inspired from the 2D/stereo series from 
damien L)

- Add a new capability hdmi2_ar
- by default parsing the new hdmi 2.0 aspect ratio will be disabled 
under check of this cap
- during bootup time, while initializing the display, a userspace can 
get_cap on the hdmi2_aspect_ratio
- If it wants HDMI 2.0 aspect ratio support, it will set the cap, and 
kernel will expose these aspect ratios
> Another bug I think might be the ordering of the modes with aspect ratio
> specified. IIRC the spec says that the preferred aspect ratio should be
> listed first in the EDID, but I don't think we preserve that ordering
> in the final mode list. I guess we could fix that by somehow noting
> which aspect ratio is preferred and sort based on that, or we try to
> preserve the order from the EDID until we're ready to sort, and then do
> the sorting with a stable algorithm.
AFAIK The mode order and priority is decided and arranged in userspace, 
based on various factors like
- preferred mode.
- previously applied mode in previous sessions (like for android tvs)
- Bigger h/w vs better refresh rate ?
- Xserver applies its own algorithms to decide which mode should be 
shown first.

I dont think kernel needs to bother about it.

[Intel-gfx] [PATCH 0/5] Handle Link Training Failure during modeset

[Cheng, Tony]

Acked-by: Tony Cheng 

-Original Message-
From: Manasi Navare [mailto:manasi.d.nav...@intel.com] 
Sent: Monday, November 14, 2016 12:52 PM
To: Cheng, Tony 
Cc: Daniel Vetter ; intel-gfx at lists.freedesktop.org; 
Peres, Martin ; dri-devel at lists.freedesktop.org; 
Deucher, Alexander ; Wentland, Harry 

Subject: Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure during modeset

Yes driver can chose to have the pre train for kernel hiding unsupported mode, 
that is completely still possible for the amd driver and it would never use the 
link_status connector property and no interaction with userspace.
Could you please give your ACKs for the patches if you are okay with this 
porposal?

Regards
Manasi



On Mon, Nov 14, 2016 at 02:45:55PM +, Cheng, Tony wrote:
> I see.  As long as amd can still just have kernel hiding unsupported mode by 
> doing a pre-train I am okay with the proposal.  Just to caution you the link 
> training fallback we implemented on windows in old dal architecture is very 
> painful to get right.  Windows 7, 8.1 and 10 all behave differently.  Not all 
> apps handles mode change failure gracefully and worse case we get stuck in 
> infinite mode set.  This is why for future generations asic on windows we are 
> also going to just hide unsupported mode by doing pre-train.
> 
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of 
> Daniel Vetter
> Sent: Monday, November 14, 2016 3:04 AM
> To: Manasi Navare 
> Cc: Cheng, Tony ; intel-gfx at lists.freedesktop.org; 
> Peres, Martin ; 
> dri-devel at lists.freedesktop.org; Deucher, Alexander 
> ; Wentland, Harry 
> Subject: Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure 
> during modeset
> 
> On Sun, Nov 13, 2016 at 11:43:01PM -0800, Manasi Navare wrote:
> > On Fri, Nov 11, 2016 at 07:42:16PM +, Cheng, Tony wrote:
> > > In case of link training failure and requiring user space to set a lower 
> > > mode, would full mode set address it?  How do we make user mode select 
> > > lower resolution?
> > > 
> > > For example 4k at 60Hz monitor, and link training at 4 lane HBR2 fails 
> > > and fallback to 4 lanes HBR, 4k at 60 is no longer doable.  I would think 
> > > preventing user mode from seeing 4K at 60Hz from the start is a easier 
> > > and more robust solution and requiring user mode to have logic to decide 
> > > how to fallback.
> > >
> > 
> > Hi Tony,
> > 
> > So in case of link training failure, we first call mode_valid that 
> > will use the lower link rate/lane count values based on the link 
> > training fallback to validate the modes and prune the modes that are 
> > higher than the available link. After this is done, then we send the uevent 
> > to userspace indicating that link status is BAD and it will redo a probe 
> > and trigger a modeset for next possible lower resolution.
> 
> Just in case it's not clear: This entire discussion here is only about the 
> userspace-visible abi changes. And I think for the worst-case we need 
> something like this (and Harry at least said on irc that on other os you do 
> something similar already). It of course does not preclude at all that you do 
> additional link-training/probe on initial hotplug. That part is entirely up 
> to drivers (and we might get there on some platforms, but on others it's a 
> real pain to get a link up unfortunately for training, since we need 
> to steal a crtc and do a full modeset).
> -Daniel
> 
> > 
> > Manasi
> > 
> >  
> > > -Original Message-
> > > From: Ville Syrjälä [mailto:ville.syrjala at linux.intel.com]
> > > Sent: Friday, November 11, 2016 11:44 AM
> > > To: Cheng, Tony 
> > > Cc: Deucher, Alexander ; 'Jani Nikula' 
> > > ; Manasi Navare 
> > > ; dri-devel at lists.freedesktop.org; 
> > > intel-gfx at lists.freedesktop.org; Wentland, Harry 
> > > ; Peres, Martin 
> > > Subject: Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure 
> > > during modeset
> > > 
> > > On Fri, Nov 11, 2016 at 04:21:58PM +, Cheng, Tony wrote:
> > > > For HDMI, you can yank the cable, plug back in, HDMI will light up 
> > > > without user mode or kernel mode doing anything.
> > > > 
> > > > For DP this is not possible, someone will have to retrain the link when 
> > > > plugging back in or DP will not light up.  We see that on Ubuntu if 
> > > > someone unplug display and plug it back into same connector, we do not 
> > > > get KMS so in this case.  It appears there is some optimizations 
> > > > somewhere in user mode stack which I am not familiar with yet.  dal 
> > > > added workaround to retrain the link to light it back up (after the 
> > > > test training at end of detection).
> > > 
> > > The link should get retrained as the driver should check the link state 
> > > on HPD and retrain if it's not good. At least that's what we do in i915. 
> > > Of course if it's not the same display that got plugged back, the 
> > > retraining might fail. The new property can help with that 

[PATCH 0/5] Handle Link Training Failure during modeset

[Harry Wentland]

Overall this patch set makes sense but I think it would be good to move 
some stuff to common code instead of leaving it in i915. I'm thinking 
about patch 2 (setting the link status property) in particular but also 
tend to agree with Ville and Daniel about their comments for patch 5.

That said, should another driver need it it shouldn't be hard to pull 
that out.

Patch 1: Reviewed-by: Harry Wentland 

Patch 2-5: Acked-by: Harry Wentland 

Harry


On 2016-11-09 11:42 PM, Manasi Navare wrote:
> Link training failure is handled by lowering the link rate first
> until it reaches the minimum and keeping the lane count maximum
> and then lowering the lane count until it reaches minimim. These
> fallback values are saved and hotplug uevent is sent to the userspace
> after setting the connector link status property to BAD. Userspace
> should triiger another modeset on a uevent and if link status property
> is BAD. This will retrain the link at fallback values.
> This is repeated until the link is successfully trained.
>
> This has been validated to pass DP compliance.
>
> Manasi Navare (5):
>drm: Add a new connector property for link status
>drm/i915: Set link status property for DP connector
>drm/i915: Update CRTC state if connector link status property changed
>drm/i915: Find fallback link rate/lane count
>drm/i915: Implement Link Rate fallback on Link training failure
>
>   drivers/gpu/drm/drm_atomic_helper.c   |   7 ++
>   drivers/gpu/drm/drm_connector.c   |  17 
>   drivers/gpu/drm/i915/intel_ddi.c  |  21 +++-
>   drivers/gpu/drm/i915/intel_dp.c   | 138 
> +-
>   drivers/gpu/drm/i915/intel_dp_link_training.c |  12 ++-
>   drivers/gpu/drm/i915/intel_drv.h  |  12 ++-
>   include/drm/drm_connector.h   |   7 +-
>   include/drm/drm_crtc.h|   5 +
>   include/uapi/drm/drm_mode.h   |   4 +
>   9 files changed, 214 insertions(+), 9 deletions(-)
>

[ANNOUNCE] libdrm 2.4.73

[Emil Velikov]

Emil Velikov (3):
  headers: Add README file
  xd86drm: read more than 128 bytes of uevent in drmParsePciBusInfo
  Bump version for release

git tag: libdrm-2.4.73

https://dri.freedesktop.org/libdrm/libdrm-2.4.73.tar.bz2
MD5:  bc1cee09cde72ffe3b952e8f50ccdaa8  libdrm-2.4.73.tar.bz2
SHA1: 7abe64965ac4aa77d51746e70d6f2a38f100483d  libdrm-2.4.73.tar.bz2
SHA256: 96bfd39242fe168017d95f22e141645a35591f5902a7d98c2fa4ca8c31df5e4d
 libdrm-2.4.73.tar.bz2
PGP:  https://dri.freedesktop.org/libdrm/libdrm-2.4.73.tar.bz2.sig

https://dri.freedesktop.org/libdrm/libdrm-2.4.73.tar.gz
MD5:  595a17e209f27602d3b1198e9a03e2d0  libdrm-2.4.73.tar.gz
SHA1: dd2e4993c8ee56b8f363e667e00e8aef1a7a733b  libdrm-2.4.73.tar.gz
SHA256: 047d3073e3ecdf06e5419f74f8de8543e59f83d451c37519db4b6c8393620bfe
 libdrm-2.4.73.tar.gz
PGP:  https://dri.freedesktop.org/libdrm/libdrm-2.4.73.tar.gz.sig

[PATCH 1/2] devicetree/bindings: display: Add bindings for LVDS panels

[Rob Herring]

On Mon, Oct 17, 2016 at 7:42 AM, Laurent Pinchart
 wrote:
> Hi Rob,
>
> On Friday 14 Oct 2016 07:40:14 Rob Herring wrote:
>> On Sun, Oct 9, 2016 at 11:33 AM, Laurent Pinchart wrote:
>> > On Saturday 08 Oct 2016 20:29:39 Rob Herring wrote:
>> >> On Tue, Oct 04, 2016 at 07:23:29PM +0300, Laurent Pinchart wrote:
>> >>> LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A.
>> >>> Multiple incompatible data link layers have been used over time to
>> >>> transmit image data to LVDS panels. This binding supports display
>> >>> panels compatible with the JEIDA-59-1999, Open-LDI and VESA SWPG
>> >>> specifications.
>> >>>
>> >>> Signed-off-by: Laurent Pinchart
>> >>> 
>> >>> ---
>> >>>
>> >>>  .../bindings/display/panel/panel-lvds.txt  | 119 ++
>> >>>  1 file changed, 119 insertions(+)
>> >>>  create mode 100644
>> >>>  Documentation/devicetree/bindings/display/panel/panel-lvds.txt>
>> >>>
>> >>> diff --git
>> >>> a/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
>> >>> b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
>> >>> new file mode 100644
>> >>> index ..250861f2673e
>> >>> --- /dev/null
>> >>> +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.txt
>> >>> @@ -0,0 +1,119 @@
>> >>> +Generic LVDS Panel
>> >>> +==
>> >>> +
>> >>> +LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A.
>> >>> Multiple
>> >>> +incompatible data link layers have been used over time to transmit
>> >>> image data
>> >>> +to LVDS panels. This bindings supports display panels compatible with
>> >>> the
>> >>> +following specifications.
>> >>> +
>> >>> +[JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999,
>> >>> February
>> >>> +1999 (Version 1.0), Japan Electronic Industry Development Association
>> >>> (JEIDA)
>> >>> +[LDI] "Open LVDS Display Interface", May 1999 (Version 0.95), National
>> >>> +Semiconductor
>> >>> +[VESA] "VESA Notebook Panel Standard", October 2007 (Version 1.0),
>> >>> Video
>> >>> +Electronics Standards Association (VESA)
>> >>> +
>> >>> +Device compatible with those specifications have been marketed under
>> >>> the
>> >>> +FPD-Link and FlatLink brands.
>> >>> +
>> >>> +
>> >>> +Required properties:
>> >>> +- compatible: shall contain "panel-lvds"
>> >>
>> >> Maybe as a fallback, but on its own, no way.
>> >
>> > Which brings an interesting question: when designing generic DT bindings,
>> > what's the rule regarding
>
> Looks like I forgot part of the question. I meant to ask what is the rule
> regarding usage of more precise compatible strings ?

When in doubt, always have one. If there's any chance at all that s/w
will need to know or care, then we should have one.

> For instance (but perhaps not the best example), the input/rotary-encoder.txt
> bindings define a "rotary-encoder" compatible string, with no other bindings
> defining more precise compatible strings for the exact rotary encoder model.
> When it comes to panels I believe it makes sense to define model-specific
> compatible strings even if they're unused by drivers. I'm however wondering
> what the rule is there, and where those device-specific compatible strings
> should be defined. I'd like to avoid using one file per panel model as done
> today for the simple-panel bindings.

There's a few exceptions like this where there is not any sort of
model to base a compatible on. For example, a GPIO connected LED is
truly generic. The only way to have a more specific compatible would
be something with the board name in it.

Your case here is in the middle. It seems like it's generic and
passive, but perhaps power control is not. Rather than trying to
decide, we can just cover our ass and put both a generic and specific
compatible in.

>> Call it "simple" so I can easily NAK it. :)
>>
>> Define a generic structure, not a single binding trying to serve all.
>>
>> >> > +- width-mm: panel display width in millimeters
>> >> > +- height-mm: panel display height in millimeters
>> >>
>> >> This is already documented for all panels IIRC.
>> >
>> > Note that this DT binding has nothing to do with the simple-panel binding.
>> > It is instead similar to the panel-dpi and panel-dsi-cm bindings (which
>> > currently don't but should specify the panel size in DT). The LVDS panel
>> > driver will *not* include any panel-specific information such as size or
>> > timings, these are specified in DT.
>>
>> The panel bindings aren't really different. The biggest difference was
>> location in the tree, but we now generally allow panels to be either a
>> child of the LCD controller or connected with OF graph. We probably
>> need to work on restructuring the panel bindings a bit. We should have
>> an inheritance with a base panel binding of things like size, label,
>> graph, backlight, etc, then perhaps an interface specific bindings for
>> LVDS, DSI, and parallel, then a panel specific binding. 

[PATCH v3] PCI: create revision file in sysfs

[Daniel Vetter]

On Fri, Nov 11, 2016 at 02:37:23PM +, Emil Velikov wrote:
> From: Emil Velikov 
> 
> Currently the revision isn't available via sysfs/libudev thus if one
> wants to know the value they need to read through the config file.
> 
> This in itself wakes/powers up the device, causing unwanted delay
> since it can be quite costly.
> 
> There are at least two userspace components which could make use the new
> file libpciaccess and libdrm. The former [used in various places] wakes
> up _every_ PCI device, which can be observed via glxinfo [when using
> Mesa 10.0+ drivers]. While the latter [in association with Mesa 13.0]
> can lead to 2-3 second delays while starting firefox, thunderbird or
> chromium.
> 
> Expose the revision as a separate file, just like we do for the device,
> vendor, their subsystem version and class.
> 
> Cc: Bjorn Helgaas 
> Cc: linux-pci at vger.kernel.org
> Cc: Greg KH 
> Link: https://bugs.freedesktop.org/show_bug.cgi?id=98502
> Tested-by: Mauro Santos 
> Reviewed-by: Alex Deucher 
> Signed-off-by: Emil Velikov 

Given that waking a gpu can take somewhere between ages and forever, and
that we read the pci revisions everytime we launch a new gl app I think
this is the correct approach. Of course we could just patch libdrm and
everyone to not look at the pci revision, but that just leads to every
pci-based driver having a driver-private ioctl/getparam thing to expose
it. Which also doesn't make much sense.

Reviewed-by: Daniel Vetter 

Björn, if you're all ok with this we'd like to start landing at least
libdrm patches before this patch hits a released kernel, just to shorten
the pain window for users waiting for upgrades.

Thanks, Daniel

> ---
> v2: Add r-b/t-b tags, slim down CC list, add note about userspace.
> 
> v3: Add Documentation/ bits (Greg KH)
> 
> Gents, please keep me in the CC list.
> 
> Thanks
> Emil
> ---
>  Documentation/ABI/testing/sysfs-bus-pci | 7 +++
>  Documentation/filesystems/sysfs-pci.txt | 2 ++
>  drivers/pci/pci-sysfs.c | 2 ++
>  3 files changed, 11 insertions(+)
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-pci 
> b/Documentation/ABI/testing/sysfs-bus-pci
> index b3bc50f..5a1732b 100644
> --- a/Documentation/ABI/testing/sysfs-bus-pci
> +++ b/Documentation/ABI/testing/sysfs-bus-pci
> @@ -294,3 +294,10 @@ Description:
>   a firmware bug to the system vendor.  Writing to this file
>   taints the kernel with TAINT_FIRMWARE_WORKAROUND, which
>   reduces the supportability of your system.
> +
> +What:/sys/bus/pci/devices/.../revision
> +Date:November 2016
> +Contact: Emil Velikov 
> +Description:
> + This file contains the revision field of the the PCI device.
> + The value comes from device config space. The file is read only.
> diff --git a/Documentation/filesystems/sysfs-pci.txt 
> b/Documentation/filesystems/sysfs-pci.txt
> index 74eaac2..6ea1ced 100644
> --- a/Documentation/filesystems/sysfs-pci.txt
> +++ b/Documentation/filesystems/sysfs-pci.txt
> @@ -17,6 +17,7 @@ that support it.  For example, a given bus might look like 
> this:
>   |   |-- resource0
>   |   |-- resource1
>   |   |-- resource2
> + |   |-- revision
>   |   |-- rom
>   |   |-- subsystem_device
>   |   |-- subsystem_vendor
> @@ -41,6 +42,7 @@ files, each with their own function.
> resource PCI resource host addresses (ascii, ro)
> resource0..N PCI resource N, if present (binary, mmap, rw[1])
> resource0_wc..N_wc  PCI WC map resource N, if prefetchable (binary, 
> mmap)
> +   revision PCI revision (ascii, ro)
> rom  PCI ROM resource, if present (binary, ro)
> subsystem_device PCI subsystem device (ascii, ro)
> subsystem_vendor PCI subsystem vendor (ascii, ro)
> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> index bcd10c7..0666287 100644
> --- a/drivers/pci/pci-sysfs.c
> +++ b/drivers/pci/pci-sysfs.c
> @@ -50,6 +50,7 @@ pci_config_attr(vendor, "0x%04x\n");
>  pci_config_attr(device, "0x%04x\n");
>  pci_config_attr(subsystem_vendor, "0x%04x\n");
>  pci_config_attr(subsystem_device, "0x%04x\n");
> +pci_config_attr(revision, "0x%02x\n");
>  pci_config_attr(class, "0x%06x\n");
>  pci_config_attr(irq, "%u\n");
>  
> @@ -568,6 +569,7 @@ static struct attribute *pci_dev_attrs[] = {
>   _attr_device.attr,
>   _attr_subsystem_vendor.attr,
>   _attr_subsystem_device.attr,
> + _attr_revision.attr,
>   _attr_class.attr,
>   _attr_irq.attr,
>   _attr_local_cpus.attr,
> -- 
> 2.9.3
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[PATCH 2/5] drm: Set DRM connector link status property

[Manasi Navare]

None of the other functions that set the connector property hold the 
mode config locks while setting the connector property, I am following
the same convention.
Also we dont need to grab and release the locks in i915_modeset_work_func
that first validates the modes and then sets this link status property.

Manasi

On Mon, Nov 14, 2016 at 07:13:20PM -0800, Manasi Navare wrote:
> In the usual working scenarios, this property is "Good".
> If something fails during modeset, the DRM driver can
> set the link status to "Bad", prune the mode list based on the
> link rate/lane count fallback values and send  hotplug uevent
> so that userspace that is aware of this property can take an
> appropriate action by reprobing connectors and re triggering
> a modeset to improve user experience and avoid black screens.
> In case of userspace that is not aware of this link status
> property, the user experience will be unchanged.
> 
> The reason for adding the property is to handle link training failures,
> but it is not limited to DP or link training. For example, if we
> implement asynchronous setcrtc, we can use this to report any failures
> in that.
> 
> Cc: dri-devel at lists.freedesktop.org
> Cc: Jani Nikula 
> Cc: Daniel Vetter 
> Cc: Ville Syrjala 
> Signed-off-by: Manasi Navare 
> ---
>  drivers/gpu/drm/drm_connector.c | 38 ++
>  include/drm/drm_connector.h |  2 ++
>  2 files changed, 40 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index d4e852f..09f4093 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -968,6 +968,44 @@ int drm_mode_connector_update_edid_property(struct 
> drm_connector *connector,
>  }
>  EXPORT_SYMBOL(drm_mode_connector_update_edid_property);
>  
> +/**
> + * drm_mode_connector_set_link_status_property - Set the link status 
> property of
> + * a connector to indicate status of link as a result of link training.
> + * @connector: drm connector
> + * @link_status: new value of link status property (0: Good, 1: Bad)
> + *
> + * In usual working scenario, this link status property will always be set to
> + * "GOOD".
> + * If something fails during or after a mode set, the kernel driver can set 
> this
> + * link status to "BAD", prune the mode list based on new information and 
> send a
> + * hotplug uevent for userspace to have it re-check the valid modes through
> + * Get_connector and try again.
> + *
> + * If userspace is not aware of this property, the user experience is the 
> same
> + * as it currently is. If the userspace is aware of the property, it has a 
> chance
> + * to improve user experience by handling link training failures, avoiding 
> black
> + * screens. The DRM driver can chose to not modify property and keep link 
> status
> + * as "GOOD" always to keep the user experience same as it currently is.
> + *
> + * The reason for adding this property is to handle link training failures, 
> but
> + * it is not limited to DP or link training. For example, if we implement
> + * asynchronous setcrtc, this property can be used to reportany failures in 
> that.
> + *
> + * This function must be called from asynchronous work item.
> + * Returns zero on success and negative errrno on failure.
> + */
> +int drm_mode_connector_set_link_status_property(struct drm_connector 
> *connector,
> + uint64_t link_status)
> +{
> + struct drm_device *dev = connector->dev;
> +
> + connector->link_status = link_status;
> + return drm_object_property_set_value(>base,
> +  
> dev->mode_config.link_status_property,
> +  link_status);
> +}
> +EXPORT_SYMBOL(drm_mode_connector_set_link_status_property);
> +
>  int drm_mode_connector_set_obj_prop(struct drm_mode_object *obj,
>   struct drm_property *property,
>   uint64_t value)
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index ad5c8b0..ac76469 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -778,6 +778,8 @@ int drm_mode_connector_set_path_property(struct 
> drm_connector *connector,
>  int drm_mode_connector_set_tile_property(struct drm_connector *connector);
>  int drm_mode_connector_update_edid_property(struct drm_connector *connector,
>   const struct edid *edid);
> +int drm_mode_connector_set_link_status_property(struct drm_connector 
> *connector,
> + uint64_t link_status);
>  
>  /**
>   * drm_for_each_connector - iterate over all connectors
> -- 
> 1.9.1
> 

[PATCH 5/5] drm/i915: Implement Link Rate fallback on Link training failure

[Manasi Navare]

If link training at a link rate optimal for a particular
mode fails during modeset's atomic commit phase, then we
let the modeset complete and then retry. We save the link rate
value at which link training failed, update the link status property
to "BAD" and use a lower link rate to prune the modes. It will redo
the modeset on the current mode at lower link rate or if the current
mode gets pruned due to lower link constraints then, it will send a
hotplug uevent for userspace to handle it.

This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4,
4.3.1.6.

v5:
* Move set link status to drm core (Daniel Vetter, Jani Nikula)
v4:
* Add fallback support for non DDI platforms too
* Set connector->link status inside set_link_status function
(Jani Nikula)
v3:
* Set link status property to BAd unconditionally (Jani Nikula)
* Dont use two separate variables link_train_failed and link_status
to indicate same thing (Jani Nikula)
v2:
* Squashed a few patches (Jani Nikula)

Acked-by: Tony Cheng 
Acked-by: Harry Wentland 
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_ddi.c  |  21 +-
 drivers/gpu/drm/i915/intel_dp.c   | 102 +-
 drivers/gpu/drm/i915/intel_dp_link_training.c |  12 ++-
 drivers/gpu/drm/i915/intel_drv.h  |   6 +-
 4 files changed, 131 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 0ad4e16..57b7ee9 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1684,6 +1684,8 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder 
*encoder,
struct intel_dp *intel_dp = enc_to_intel_dp(>base);
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
enum port port = intel_ddi_get_encoder_port(encoder);
+   struct intel_connector *intel_connector = intel_dp->attached_connector;
+   struct drm_connector *connector = _connector->base;

intel_dp_set_link_params(intel_dp, link_rate, lane_count,
 link_mst);
@@ -1694,7 +1696,24 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder 
*encoder,
intel_prepare_dp_ddi_buffers(encoder);
intel_ddi_init_dp_buf_reg(encoder);
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
-   intel_dp_start_link_train(intel_dp);
+   if (!intel_dp_start_link_train(intel_dp)) {
+   DRM_DEBUG_KMS("Link Training failed at link rate = %d, lane 
count = %d",
+ link_rate, lane_count);
+   if (!intel_dp_get_link_train_fallback_values(intel_dp,
+link_rate,
+lane_count))
+   /* Schedule a Hotplug Uevent to userspace to start 
modeset */
+   schedule_work(_connector->modeset_retry_work);
+   } else {
+   DRM_DEBUG_KMS("Link Training Passed at Link Rate = %d, Lane 
count = %d",
+ link_rate, lane_count);
+   intel_dp->fallback_link_rate_index = -1;
+   intel_dp->fallback_link_rate = 0;
+   intel_dp->fallback_lane_count = 0;
+   drm_mode_connector_set_link_status_property(connector,
+   
DRM_MODE_LINK_STATUS_GOOD);
+   }
+
if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
intel_dp_stop_link_train(intel_dp);
 }
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index e87b451..af2f8b2 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -353,8 +353,14 @@ int intel_dp_get_link_train_fallback_values(struct 
intel_dp *intel_dp,
target_clock = fixed_mode->clock;
}

-   max_link_clock = intel_dp_max_link_rate(intel_dp);
-   max_lanes = intel_dp_max_lane_count(intel_dp);
+   /* Prune the modes using the fallback link rate/lane count */
+   if (connector->link_status == DRM_MODE_LINK_STATUS_BAD) {
+   max_link_clock = intel_dp->fallback_link_rate;
+   max_lanes = intel_dp->fallback_lane_count;
+   } else {
+   max_link_clock = intel_dp_max_link_rate(intel_dp);
+   max_lanes = intel_dp_max_lane_count(intel_dp);
+   }

max_rate = intel_dp_max_data_rate(max_link_clock, max_lanes);
mode_rate = intel_dp_link_required(target_clock, 18);
@@ -1591,6 +1597,7 @@ static int intel_dp_compute_bpp(struct intel_dp *intel_dp,
enum port port = dp_to_dig_port(intel_dp)->port;
struct intel_crtc *intel_crtc = to_intel_crtc(pipe_config->base.crtc);
struct intel_connector *intel_connector = intel_dp->attached_connector;
+   struct drm_connector *connector = _connector->base;
int lane_count, clock;
   

[PATCH 4/5] drm/i915: Find fallback link rate/lane count

[Manasi Navare]

If link training fails, then we need to fallback to lower
link rate first and if link training fails at RBR, then
fallback to lower lane count.
This function finds the next lower link rate/lane count
value after link training failure.

v2:
Squash the patch that returns the link rate index (Jani Nikula)

Acked-by: Tony Cheng 
Acked-by: Harry Wentland 
Cc: Ville Syrjala 
Cc: Jani Nikula 
Cc: Daniel Vetter 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_dp.c  | 42 
 drivers/gpu/drm/i915/intel_drv.h |  6 ++
 2 files changed, 48 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index a1b0181..e87b451 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -288,6 +288,48 @@ static int intel_dp_common_rates(struct intel_dp *intel_dp,
   common_rates);
 }

+static int intel_dp_link_rate_index(struct intel_dp *intel_dp,
+   int *common_rates, int link_rate)
+{
+   int common_len;
+   int index;
+
+   common_len = intel_dp_common_rates(intel_dp, common_rates);
+   for (index = 0; index < common_len; index++) {
+   if (link_rate == common_rates[common_len - index - 1])
+   return common_len - index - 1;
+   }
+
+   return -1;
+}
+
+int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
+   int link_rate, uint8_t lane_count)
+{
+   int common_rates[DP_MAX_SUPPORTED_RATES] = {};
+   int common_len;
+   int link_rate_index = -1;
+
+   common_len = intel_dp_common_rates(intel_dp, common_rates);
+   link_rate_index = intel_dp_link_rate_index(intel_dp,
+  common_rates,
+  link_rate);
+   if (link_rate_index > 0) {
+   intel_dp->fallback_link_rate_index = link_rate_index - 1;
+   intel_dp->fallback_link_rate = 
common_rates[intel_dp->fallback_link_rate_index];
+   intel_dp->fallback_lane_count = 
intel_dp_max_lane_count(intel_dp);
+   } else if (lane_count > 1) {
+   intel_dp->fallback_link_rate_index = common_len - 1;
+   intel_dp->fallback_link_rate = 
common_rates[intel_dp->fallback_link_rate_index];
+   intel_dp->fallback_lane_count = lane_count >> 1;
+   } else {
+   DRM_ERROR("Link Training Unsuccessful\n");
+   return -1;
+   }
+
+   return 0;
+}
+
 static enum drm_mode_status
 intel_dp_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 75252ec..55ceb44 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -887,6 +887,10 @@ struct intel_dp {
uint32_t DP;
int link_rate;
uint8_t lane_count;
+   int fallback_link_rate;
+   uint8_t fallback_lane_count;
+   int fallback_link_rate_index;
+   bool link_train_failed;
uint8_t sink_count;
bool link_mst;
bool has_audio;
@@ -1383,6 +1387,8 @@ bool intel_dp_init_connector(struct intel_digital_port 
*intel_dig_port,
 void intel_dp_set_link_params(struct intel_dp *intel_dp,
  int link_rate, uint8_t lane_count,
  bool link_mst);
+int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
+   int link_rate, uint8_t lane_count);
 void intel_dp_start_link_train(struct intel_dp *intel_dp);
 void intel_dp_stop_link_train(struct intel_dp *intel_dp);
 void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode);
-- 
1.9.1

[PATCH 3/5] drm/i915: Update CRTC state if connector link status property changed

[Manasi Navare]

CRTC state connector_changed needs to be set to true
if connector link status property has changed. This will tell the
driver to do a complete modeset due to change in connector property.

Acked-by: Harry Wentland 
Acked-by: Tony Cheng 
Cc: dri-devel at lists.freedesktop.org
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/drm_atomic_helper.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 5007796..aeecf2f 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -519,6 +519,13 @@ static int handle_conflicting_encoders(struct 
drm_atomic_state *state,
   connector_state);
if (ret)
return ret;
+
+   if (connector->state->crtc) {
+   crtc_state = drm_atomic_get_existing_crtc_state(state,
+   
connector->state->crtc);
+   if (connector->link_status == DRM_MODE_LINK_STATUS_BAD)
+   crtc_state->connectors_changed = true;
+   }
}

/*
-- 
1.9.1

[PATCH 2/5] drm: Set DRM connector link status property

[Manasi Navare]

In the usual working scenarios, this property is "Good".
If something fails during modeset, the DRM driver can
set the link status to "Bad", prune the mode list based on the
link rate/lane count fallback values and send  hotplug uevent
so that userspace that is aware of this property can take an
appropriate action by reprobing connectors and re triggering
a modeset to improve user experience and avoid black screens.
In case of userspace that is not aware of this link status
property, the user experience will be unchanged.

The reason for adding the property is to handle link training failures,
but it is not limited to DP or link training. For example, if we
implement asynchronous setcrtc, we can use this to report any failures
in that.

Cc: dri-devel at lists.freedesktop.org
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/drm_connector.c | 38 ++
 include/drm/drm_connector.h |  2 ++
 2 files changed, 40 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index d4e852f..09f4093 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -968,6 +968,44 @@ int drm_mode_connector_update_edid_property(struct 
drm_connector *connector,
 }
 EXPORT_SYMBOL(drm_mode_connector_update_edid_property);

+/**
+ * drm_mode_connector_set_link_status_property - Set the link status property 
of
+ * a connector to indicate status of link as a result of link training.
+ * @connector: drm connector
+ * @link_status: new value of link status property (0: Good, 1: Bad)
+ *
+ * In usual working scenario, this link status property will always be set to
+ * "GOOD".
+ * If something fails during or after a mode set, the kernel driver can set 
this
+ * link status to "BAD", prune the mode list based on new information and send 
a
+ * hotplug uevent for userspace to have it re-check the valid modes through
+ * Get_connector and try again.
+ *
+ * If userspace is not aware of this property, the user experience is the same
+ * as it currently is. If the userspace is aware of the property, it has a 
chance
+ * to improve user experience by handling link training failures, avoiding 
black
+ * screens. The DRM driver can chose to not modify property and keep link 
status
+ * as "GOOD" always to keep the user experience same as it currently is.
+ *
+ * The reason for adding this property is to handle link training failures, but
+ * it is not limited to DP or link training. For example, if we implement
+ * asynchronous setcrtc, this property can be used to reportany failures in 
that.
+ *
+ * This function must be called from asynchronous work item.
+ * Returns zero on success and negative errrno on failure.
+ */
+int drm_mode_connector_set_link_status_property(struct drm_connector 
*connector,
+   uint64_t link_status)
+{
+   struct drm_device *dev = connector->dev;
+
+   connector->link_status = link_status;
+   return drm_object_property_set_value(>base,
+
dev->mode_config.link_status_property,
+link_status);
+}
+EXPORT_SYMBOL(drm_mode_connector_set_link_status_property);
+
 int drm_mode_connector_set_obj_prop(struct drm_mode_object *obj,
struct drm_property *property,
uint64_t value)
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index ad5c8b0..ac76469 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -778,6 +778,8 @@ int drm_mode_connector_set_path_property(struct 
drm_connector *connector,
 int drm_mode_connector_set_tile_property(struct drm_connector *connector);
 int drm_mode_connector_update_edid_property(struct drm_connector *connector,
const struct edid *edid);
+int drm_mode_connector_set_link_status_property(struct drm_connector 
*connector,
+   uint64_t link_status);

 /**
  * drm_for_each_connector - iterate over all connectors
-- 
1.9.1

[PATCH 1/5] drm: Add a new connector property for link status

[Manasi Navare]

A new default connector property is added for keeping
track of whether the link is good (link training passed) or
link is bad (link training  failed). If the link status property
is not good, then userspace should fire off a new modeset at the current
mode even if there have not been any changes in the mode list
or connector status.
Also add link status connector member corersponding to the
decoded value of link status property.

v3:
* Drop "link training" from description since this is
not specific to DP (Jani Nikula)
* Add link status member to store property value locally
(Ville Syrjala)
v2:
* Make this a default connector property (Daniel Vetter)

Reviewed-by: Harry Wentland 
Cc: dri-devel at lists.freedesktop.org
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Cc: Chris Wilson 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/drm_connector.c | 17 +
 include/drm/drm_connector.h |  7 ++-
 include/drm/drm_crtc.h  |  5 +
 include/uapi/drm/drm_mode.h |  4 
 4 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 2db7fb5..d4e852f 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -243,6 +243,10 @@ int drm_connector_init(struct drm_device *dev,
drm_object_attach_property(>base,
  config->dpms_property, 0);

+   drm_object_attach_property(>base,
+  config->link_status_property,
+  0);
+
if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
drm_object_attach_property(>base, 
config->prop_crtc_id, 0);
}
@@ -506,6 +510,12 @@ const char *drm_get_subpixel_order_name(enum 
subpixel_order order)
 };
 DRM_ENUM_NAME_FN(drm_get_dpms_name, drm_dpms_enum_list)

+static const struct drm_prop_enum_list drm_link_status_enum_list[] = {
+   { DRM_MODE_LINK_STATUS_GOOD, "Good" },
+   { DRM_MODE_LINK_STATUS_BAD, "Bad" },
+};
+DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
+
 /**
  * drm_display_info_set_bus_formats - set the supported bus formats
  * @info: display info to store bus formats in
@@ -622,6 +632,13 @@ int drm_connector_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.tile_property = prop;

+   prop = drm_property_create_enum(dev, 0, "link-status",
+   drm_link_status_enum_list,
+   ARRAY_SIZE(drm_link_status_enum_list));
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.link_status_property = prop;
+
return 0;
 }

diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 3e97272..ad5c8b0 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -695,6 +695,12 @@ struct drm_connector {
uint8_t num_h_tile, num_v_tile;
uint8_t tile_h_loc, tile_v_loc;
uint16_t tile_h_size, tile_v_size;
+
+   /* Connector Link status
+* 0: If the link is Good
+* 1: If the link is Bad
+*/
+   int link_status;
 };

 #define obj_to_connector(x) container_of(x, struct drm_connector, base)
@@ -767,7 +773,6 @@ int drm_mode_create_tv_properties(struct drm_device *dev,
 int drm_mode_create_scaling_mode_property(struct drm_device *dev);
 int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
 int drm_mode_create_suggested_offset_properties(struct drm_device *dev);
-
 int drm_mode_connector_set_path_property(struct drm_connector *connector,
 const char *path);
 int drm_mode_connector_set_tile_property(struct drm_connector *connector);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 8cca2a8..a93148b 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1164,6 +1164,11 @@ struct drm_mode_config {
 */
struct drm_property *tile_property;
/**
+* @link_status_property: Default connector property for link status
+* of a connector
+*/
+   struct drm_property *link_status_property;
+   /**
 * @plane_type_property: Default plane property to differentiate
 * CURSOR, PRIMARY and OVERLAY legacy uses of planes.
 */
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 01000c9..66b145b 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -129,6 +129,10 @@
 #define DRM_MODE_DIRTY_ON   1
 #define DRM_MODE_DIRTY_ANNOTATE 2

+/* Link Status options */
+#define DRM_MODE_LINK_STATUS_GOOD  0
+#define DRM_MODE_LINK_STATUS_BAD   1
+
 struct drm_mode_modeinfo {
__u32 clock;
__u16 hdisplay;
-- 
1.9.1

[PATCH 0/5] Handle link training failure during modeset

[Manasi Navare]

Submitting new series that adds proper commit messages/cover letter
and kernel documentation. It also moved the set_link_status function
to drm core so other kernel drivers can make use of it.

The idea presented in these patches is to address link training failure
in a way that:
a) changes the current happy day scenario as little as possible, to avoid
regressions, b) can be implemented the same way by all drm drivers, c)
is still opt-in for the drivers and userspace, and opting out doesn't
regress the user experience, d) doesn't prevent drivers from
implementing better or alternate approaches, possibly without userspace
involvement. And, of course, handles all the issues presented.

The solution is to add a "link status" connector property. In the usual
happy day scenario, this is always "good". If something fails during or
after a mode set, the kernel driver can set the link status to "bad",
prune the mode list based on new information as necessary, and send a
hotplug uevent for userspace to have it re-check the valid modes through
getconnector, and try again. If the theoretical capabilities of the link
can't be reached, the mode list is trimmed based on that.

If the userspace is not aware of the property, the user experience is
the same as it currently is. If the userspace is aware of the property,
it has a chance to improve user experience. If a drm driver does not
modify the property (it stays "good"), the user experience is the same
as it currently is. A drm driver can also choose to try to handle more
of the failures in kernel, hardware not limiting, or it can choose to
involve userspace more. Up to the drivers.

The reason for adding the property is to handle link training failures,
but it is not limited to DP or link training. For example, if we
implement asynchronous setcrtc, we can use this to report any failures
in that.

Finally, while DP CTS compliance is advertized (which is great, and
could be made to work similarly for all drm drivers), this can be used
for the more important goal of improving user experience on link
training failures, by avoiding black screens.

Acked-by: Tony Cheng 
Acked-by: Harry Wentland 

Manasi Navare (5):
  drm: Add a new connector property for link status
  drm: Set DRM connector link status property
  drm/i915: Update CRTC state if connector link status property changed
  drm/i915: Find fallback link rate/lane count
  drm/i915: Implement Link Rate fallback on Link training failure

 drivers/gpu/drm/drm_atomic_helper.c   |   7 ++
 drivers/gpu/drm/drm_connector.c   |  55 ++
 drivers/gpu/drm/i915/intel_ddi.c  |  21 +++-
 drivers/gpu/drm/i915/intel_dp.c   | 144 +-
 drivers/gpu/drm/i915/intel_dp_link_training.c |  12 ++-
 drivers/gpu/drm/i915/intel_drv.h  |  10 +-
 include/drm/drm_connector.h   |   9 +-
 include/drm/drm_crtc.h|   5 +
 include/uapi/drm/drm_mode.h   |   4 +
 9 files changed, 257 insertions(+), 10 deletions(-)

-- 
1.9.1

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

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

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

--- Comment #60 from Rosco P. Coltrane  ---
Some people are reporting that they can reproduce the bug on windows 7. 

https://github.com/ValveSoftware/Source-1-Games/issues/1943#issuecomment-260154700

Are we absolutely sure that it is not a hardware problem?

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

[PATCH 12/12] tests/kms_atomic_transition: set out_fence for all crtcs

[Gustavo Padovan]

From: Gustavo Padovan 

Signed-off-by: Gustavo Padovan 
---
 tests/kms_atomic_transition.c | 22 +-
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/tests/kms_atomic_transition.c b/tests/kms_atomic_transition.c
index 54fc9da..3022e04 100644
--- a/tests/kms_atomic_transition.c
+++ b/tests/kms_atomic_transition.c
@@ -486,7 +486,7 @@ static void collect_crcs_mask(igt_pipe_crc_t **pipe_crcs, 
unsigned mask, igt_crc
}
 }

-static void run_modeset_tests(igt_display_t *display, int howmany, bool 
nonblocking)
+static void run_modeset_tests(igt_display_t *display, int howmany, bool 
nonblocking, bool fencing)
 {
struct igt_fb fbs[2];
int i, j;
@@ -495,6 +495,7 @@ static void run_modeset_tests(igt_display_t *display, int 
howmany, bool nonblock
igt_output_t *output;
unsigned width = 0, height = 0;
bool skip_test = false;
+   int out_fence[I915_MAX_PIPES];

for_each_connected_output(display, output) {
drmModeModeInfo *mode = igt_output_get_mode(output);
@@ -532,6 +533,11 @@ static void run_modeset_tests(igt_display_t *display, int 
howmany, bool nonblock
igt_plane_set_size(plane, mode->hdisplay, 
mode->vdisplay);
} else
igt_plane_set_fb(plane, NULL);
+
+   if(fencing)
+   igt_pipe_set_out_fence_ptr(>pipes[i],
+  _fence[i]);
+
}

/*
@@ -619,7 +625,7 @@ cleanup:

 }

-static void run_modeset_transition(igt_display_t *display, int 
requested_outputs, bool nonblocking)
+static void run_modeset_transition(igt_display_t *display, int 
requested_outputs, bool nonblocking, bool fencing)
 {
igt_output_t *outputs[I915_MAX_PIPES] = {};
int num_outputs = 0;
@@ -647,7 +653,7 @@ static void run_modeset_transition(igt_display_t *display, 
int requested_outputs
  "Should have at least %i outputs, found %i\n",
  requested_outputs, num_outputs);

-   run_modeset_tests(display, requested_outputs, nonblocking);
+   run_modeset_tests(display, requested_outputs, nonblocking, fencing);
 }

 igt_main
@@ -706,10 +712,16 @@ igt_main

for (i = 1; i <= I915_MAX_PIPES; i++) {
igt_subtest_f("%ix-modeset-transitions", i)
-   run_modeset_transition(, i, false);
+   run_modeset_transition(, i, false, false);

igt_subtest_f("%ix-modeset-transitions-nonblocking", i)
-   run_modeset_transition(, i, true);
+   run_modeset_transition(, i, true, false);
+
+   igt_subtest_f("%ix-modeset-transitions-fencing", i)
+   run_modeset_transition(, i, false, true);
+
+   igt_subtest_f("%ix-modeset-transitions-nonblocking-fencing", i)
+   run_modeset_transition(, i, true, true);
}

igt_fixture {
-- 
2.5.5

[PATCH 11/12] tests/kms_atomic_transition: add in_fences tests

[Gustavo Padovan]

From: Gustavo Padovan 

Signed-off-by: Gustavo Padovan 
---
 tests/kms_atomic_transition.c | 92 ++-
 1 file changed, 82 insertions(+), 10 deletions(-)

diff --git a/tests/kms_atomic_transition.c b/tests/kms_atomic_transition.c
index 507f526..54fc9da 100644
--- a/tests/kms_atomic_transition.c
+++ b/tests/kms_atomic_transition.c
@@ -23,7 +23,9 @@

 #include "igt.h"
 #include "drmtest.h"
+#include "sw_sync.h"
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -111,6 +113,78 @@ enum transition_type {
TRANSITION_MODESET_DISABLE,
 };

+int timeline[IGT_MAX_PLANES];
+pthread_t thread[IGT_MAX_PLANES];
+int seqno[IGT_MAX_PLANES];
+
+static void prepare_fencing(igt_display_t *display, enum pipe pipe)
+{
+   igt_plane_t *plane;
+
+   for_each_plane_on_pipe(display, pipe, plane)
+   timeline[plane->index] = sw_sync_timeline_create();
+}
+
+static void unprepare_fencing(igt_display_t *display, enum pipe pipe)
+{
+   igt_plane_t *plane;
+
+   for_each_plane_on_pipe(display, pipe, plane)
+   close(timeline[plane->index]);
+}
+
+static void *fence_inc_thread(void *arg)
+{
+   int t = *((int *) arg);
+
+   pthread_detach(pthread_self());
+
+   usleep(5000);
+   sw_sync_timeline_inc(t, 1);
+   return NULL;
+}
+
+static void configure_fencing(igt_display_t *display, enum pipe pipe)
+{
+   igt_plane_t *plane;
+   int i, fd, ret;
+
+   for_each_plane_on_pipe(display, pipe, plane) {
+
+   if (!plane->fb)
+   continue;
+
+   i = plane->index;
+
+   seqno[i]++;
+   fd = sw_sync_fence_create(timeline[i], seqno[i]);
+   igt_plane_set_fence_fd(plane, fd);
+   ret = pthread_create([i], NULL, fence_inc_thread, 
[i]);
+   igt_assert_eq(ret, 0);
+   }
+}
+
+static void clear_fencing(igt_display_t *display, enum pipe pipe)
+{
+   igt_plane_t *plane;
+
+   for_each_plane_on_pipe(display, pipe, plane)
+   igt_plane_set_fence_fd(plane, -1);
+}
+
+static void atomic_commit(igt_display_t *display, enum pipe pipe, unsigned int 
flags, void *data, bool fencing, int *out_fence)
+{
+   if (fencing) {
+   configure_fencing(display, pipe);
+   igt_pipe_set_out_fence_ptr(>pipes[pipe], out_fence);
+   }
+
+   igt_display_commit_atomic(display, flags, data);
+
+   if (fencing)
+   clear_fencing(display, pipe);
+}
+
 /*
  * 1. Set primary plane to a known fb.
  * 2. Make sure getcrtc returns the correct fb id.
@@ -134,6 +208,9 @@ run_transition_test(igt_display_t *display, enum pipe pipe, 
igt_output_t *output
unsigned flags = DRM_MODE_PAGE_FLIP_EVENT;
int out_fence, ret;

+   if (fencing)
+   prepare_fencing(display, pipe);
+
if (nonblocking)
flags |= DRM_MODE_ATOMIC_NONBLOCK;

@@ -233,10 +310,8 @@ run_transition_test(igt_display_t *display, enum pipe 
pipe, igt_output_t *output

wm_setup_plane(display, pipe, i, parms);

-   if (fencing)
-   igt_pipe_set_out_fence_ptr(>pipes[pipe], 
_fence);
+   atomic_commit(display, pipe, flags, (void *)(unsigned long)i, 
fencing, _fence);

-   igt_display_commit_atomic(display, flags, (void *)(unsigned 
long)i);
drmHandleEvent(display->drm_fd, _events);

if (type == TRANSITION_MODESET_DISABLE) {
@@ -260,19 +335,14 @@ run_transition_test(igt_display_t *display, enum pipe 
pipe, igt_output_t *output
if (type == TRANSITION_MODESET)
igt_output_override_mode(output, 
_mode);

-   if (fencing)
-   
igt_pipe_set_out_fence_ptr(>pipes[pipe], _fence);
-
-   igt_display_commit_atomic(display, flags, (void 
*)(unsigned long)j);
+   atomic_commit(display, pipe, flags, (void 
*)(unsigned long)i, fencing, _fence);
drmHandleEvent(display->drm_fd, _events);

wm_setup_plane(display, pipe, i, parms);
if (type == TRANSITION_MODESET)
igt_output_override_mode(output, NULL);

-   if (fencing)
-   
igt_pipe_set_out_fence_ptr(>pipes[pipe], _fence);
-
+   atomic_commit(display, pipe, flags, (void 
*)(unsigned long)i, fencing, _fence);
igt_display_commit_atomic(display, flags, (void 
*)(unsigned long)i);
drmHandleEvent(display->drm_fd, _events);
}
@@ -280,6 +350,8 @@ run_transition_test(igt_display_t *display, enum pipe pipe, 
igt_output_t *output
 

[PATCH 10/12] tests/kms_atomic_transition: add out_fences tests

[Gustavo Padovan]

From: Gustavo Padovan 

Signed-off-by: Gustavo Padovan 
---
 lib/igt_kms.c | 22 ++
 tests/kms_atomic_transition.c | 30 --
 2 files changed, 50 insertions(+), 2 deletions(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index f25e1eb..9271ab4 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -49,6 +49,7 @@
 #include "intel_chipset.h"
 #include "igt_debugfs.h"
 #include "igt_sysfs.h"
+#include "sw_sync.h"

 /**
  * SECTION:igt_kms
@@ -2183,6 +2184,27 @@ static int igt_atomic_commit(igt_display_t *display, 
uint32_t flags, void *user_
}

ret = drmModeAtomicCommit(display->drm_fd, req, flags, user_data);
+   if (!ret) {
+   uint64_t *fence_ptr;
+
+   for_each_pipe(display, pipe) {
+   igt_pipe_t *pipe_obj = >pipes[pipe];
+
+   fence_ptr = (uint64_t *)pipe_obj->out_fence_ptr;
+   if (!fence_ptr)
+   continue;
+
+   if (flags & DRM_MODE_ATOMIC_TEST_ONLY) {
+   igt_assert(*fence_ptr == -1);
+   } else {
+   igt_assert(*fence_ptr >= 0);
+   ret = sw_sync_wait(*fence_ptr, 1000);
+   igt_assert(ret == 0);
+   close(*fence_ptr);
+   }
+   }
+   }
+
drmModeAtomicFree(req);
return ret;

diff --git a/tests/kms_atomic_transition.c b/tests/kms_atomic_transition.c
index 8bef85d..507f526 100644
--- a/tests/kms_atomic_transition.c
+++ b/tests/kms_atomic_transition.c
@@ -132,6 +132,7 @@ run_transition_test(igt_display_t *display, enum pipe pipe, 
igt_output_t *output
struct plane_parms parms[IGT_MAX_PLANES];
bool skip_test = false;
unsigned flags = DRM_MODE_PAGE_FLIP_EVENT;
+   int out_fence, ret;

if (nonblocking)
flags |= DRM_MODE_ATOMIC_NONBLOCK;
@@ -198,9 +199,10 @@ run_transition_test(igt_display_t *display, enum pipe 
pipe, igt_output_t *output
 * planes to fix this
 */
while (1) {
-   int ret;
-
wm_setup_plane(display, pipe, iter_max - 1, parms);
+
+   if (fencing)
+   igt_pipe_set_out_fence_ptr(>pipes[pipe], 
_fence);
ret = igt_display_try_commit_atomic(display, 
DRM_MODE_ATOMIC_TEST_ONLY | DRM_MODE_ATOMIC_ALLOW_MODESET, NULL);

if (ret != -EINVAL || n_planes < 3)
@@ -231,6 +233,9 @@ run_transition_test(igt_display_t *display, enum pipe pipe, 
igt_output_t *output

wm_setup_plane(display, pipe, i, parms);

+   if (fencing)
+   igt_pipe_set_out_fence_ptr(>pipes[pipe], 
_fence);
+
igt_display_commit_atomic(display, flags, (void *)(unsigned 
long)i);
drmHandleEvent(display->drm_fd, _events);

@@ -239,6 +244,9 @@ run_transition_test(igt_display_t *display, enum pipe pipe, 
igt_output_t *output

wm_setup_plane(display, pipe, 0, parms);

+   if (fencing)
+   
igt_pipe_set_out_fence_ptr(>pipes[pipe], _fence);
+
igt_display_commit_atomic(display, flags, (void *)0UL);

drmHandleEvent(display->drm_fd, _events);
@@ -252,6 +260,9 @@ run_transition_test(igt_display_t *display, enum pipe pipe, 
igt_output_t *output
if (type == TRANSITION_MODESET)
igt_output_override_mode(output, 
_mode);

+   if (fencing)
+   
igt_pipe_set_out_fence_ptr(>pipes[pipe], _fence);
+
igt_display_commit_atomic(display, flags, (void 
*)(unsigned long)j);
drmHandleEvent(display->drm_fd, _events);

@@ -259,6 +270,9 @@ run_transition_test(igt_display_t *display, enum pipe pipe, 
igt_output_t *output
if (type == TRANSITION_MODESET)
igt_output_override_mode(output, NULL);

+   if (fencing)
+   
igt_pipe_set_out_fence_ptr(>pipes[pipe], _fence);
+
igt_display_commit_atomic(display, flags, (void 
*)(unsigned long)i);
drmHandleEvent(display->drm_fd, _events);
}
@@ -594,14 +608,26 @@ igt_main
for_each_pipe_with_valid_output(, pipe, output)
run_transition_test(, pipe, output, 
TRANSITION_PLANES, false, false);

+   igt_subtest("plane-all-transition-fencing")
+   for_each_pipe_with_valid_output(, pipe, output)
+   run_transition_test(, pipe, output, 

[PATCH 09/12] tests/kms_atomic_transition: add fencing parameter to run_transition_tests

[Gustavo Padovan]

From: Gustavo Padovan 

Signed-off-by: Gustavo Padovan 
---
 tests/kms_atomic_transition.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/tests/kms_atomic_transition.c b/tests/kms_atomic_transition.c
index 8b26b53..8bef85d 100644
--- a/tests/kms_atomic_transition.c
+++ b/tests/kms_atomic_transition.c
@@ -121,7 +121,7 @@ enum transition_type {
  * so test this and make sure it works.
  */
 static void
-run_transition_test(igt_display_t *display, enum pipe pipe, igt_output_t 
*output, enum transition_type type, bool nonblocking)
+run_transition_test(igt_display_t *display, enum pipe pipe, igt_output_t 
*output, enum transition_type type, bool nonblocking, bool fencing)
 {
struct igt_fb fb, argb_fb;
drmModeModeInfo *mode, override_mode;
@@ -592,19 +592,19 @@ igt_main

igt_subtest("plane-all-transition")
for_each_pipe_with_valid_output(, pipe, output)
-   run_transition_test(, pipe, output, 
TRANSITION_PLANES, false);
+   run_transition_test(, pipe, output, 
TRANSITION_PLANES, false, false);

igt_subtest("plane-all-transition-nonblocking")
for_each_pipe_with_valid_output(, pipe, output)
-   run_transition_test(, pipe, output, 
TRANSITION_PLANES, true);
+   run_transition_test(, pipe, output, 
TRANSITION_PLANES, true, false);

igt_subtest("plane-all-modeset-transition")
for_each_pipe_with_valid_output(, pipe, output)
-   run_transition_test(, pipe, output, 
TRANSITION_MODESET, false);
+   run_transition_test(, pipe, output, 
TRANSITION_MODESET, false, false);

igt_subtest("plane-toggle-modeset-transition")
for_each_pipe_with_valid_output(, pipe, output)
-   run_transition_test(, pipe, output, 
TRANSITION_MODESET_DISABLE, false);
+   run_transition_test(, pipe, output, 
TRANSITION_MODESET_DISABLE, false, false);

for (i = 1; i <= I915_MAX_PIPES; i++) {
igt_subtest_f("%ix-modeset-transitions", i)
-- 
2.5.5

[PATCH 08/12] tests/kms_atomic: stress possible fence settings

[Gustavo Padovan]

From: Gustavo Padovan 

Signed-off-by: Gustavo Padovan 
---
 tests/kms_atomic.c | 124 +
 1 file changed, 115 insertions(+), 9 deletions(-)

diff --git a/tests/kms_atomic.c b/tests/kms_atomic.c
index 8b648eb..58fc0dd 100644
--- a/tests/kms_atomic.c
+++ b/tests/kms_atomic.c
@@ -44,6 +44,7 @@
 #include "drmtest.h"
 #include "igt.h"
 #include "igt_aux.h"
+#include "sw_sync.h"

 #ifndef DRM_CLIENT_CAP_ATOMIC
 #define DRM_CLIENT_CAP_ATOMIC 3
@@ -126,6 +127,7 @@ struct kms_atomic_plane_state {
uint32_t fb_id; /* 0 to disable */
uint32_t src_x, src_y, src_w, src_h; /* 16.16 fixed-point */
uint32_t crtc_x, crtc_y, crtc_w, crtc_h; /* normal integers */
+   int32_t fence_fd;
 };

 struct kms_atomic_crtc_state {
@@ -133,6 +135,7 @@ struct kms_atomic_crtc_state {
uint32_t obj;
int idx;
bool active;
+   uint64_t out_fence_ptr;
struct kms_atomic_blob mode;
 };

@@ -190,11 +193,13 @@ static uint32_t blob_duplicate(int fd, uint32_t id_orig)
crtc_populate_req(crtc, req); \
plane_populate_req(plane, req); \
do_atomic_commit((crtc)->state->desc->fd, req, flags); \
-   crtc_check_current_state(crtc, plane, relax); \
-   plane_check_current_state(plane, relax); \
+   if (!(flags & DRM_MODE_ATOMIC_TEST_ONLY)) { \
+   crtc_check_current_state(crtc, plane, relax); \
+   plane_check_current_state(plane, relax); \
+   } \
 }

-#define crtc_commit_atomic_err(crtc, plane, crtc_old, plane_old, req, relax, 
e) { \
+#define crtc_commit_atomic_err(crtc, plane, crtc_old, plane_old, req, flags, 
relax, e) { \
drmModeAtomicSetCursor(req, 0); \
crtc_populate_req(crtc, req); \
plane_populate_req(plane, req); \
@@ -299,6 +304,9 @@ find_connector(struct kms_atomic_state *state,
 static void plane_populate_req(struct kms_atomic_plane_state *plane,
   drmModeAtomicReq *req)
 {
+   if (plane->fence_fd)
+   plane_set_prop(req, plane, IGT_PLANE_IN_FENCE_FD, 
plane->fence_fd);
+
plane_set_prop(req, plane, IGT_PLANE_CRTC_ID, plane->crtc_id);
plane_set_prop(req, plane, IGT_PLANE_FB_ID, plane->fb_id);
plane_set_prop(req, plane, IGT_PLANE_SRC_X, plane->src_x);
@@ -424,6 +432,10 @@ find_plane(struct kms_atomic_state *state, enum plane_type 
type,
 static void crtc_populate_req(struct kms_atomic_crtc_state *crtc,
  drmModeAtomicReq *req)
 {
+   if (crtc->out_fence_ptr)
+   crtc_set_prop(req, crtc, IGT_CRTC_OUT_FENCE_PTR,
+ crtc->out_fence_ptr);
+
crtc_set_prop(req, crtc, IGT_CRTC_MODE_ID, crtc->mode.id);
crtc_set_prop(req, crtc, IGT_CRTC_ACTIVE, crtc->active);
 }
@@ -986,6 +998,7 @@ static void plane_invalid_params(struct 
kms_atomic_crtc_state *crtc,
uint32_t format = plane_get_igt_format();
drmModeAtomicReq *req = drmModeAtomicAlloc();
struct igt_fb fb;
+   int timeline, fence_fd;

/* Pass a series of invalid object IDs for the FB ID. */
plane.fb_id = plane.obj;
@@ -1024,6 +1037,23 @@ static void plane_invalid_params(struct 
kms_atomic_crtc_state *crtc,
plane_commit_atomic_err(, plane_old, req,
ATOMIC_RELAX_NONE, EINVAL);

+   /* invalid fence fd */
+   plane.fence_fd = plane.state->desc->fd;
+   plane.crtc_id = plane_old->crtc_id;
+   plane_commit_atomic_err(, plane_old, req,
+   ATOMIC_RELAX_NONE, EINVAL);
+
+   /* Valid fence_fd but invalid CRTC */
+   timeline = sw_sync_timeline_create();
+   fence_fd =  sw_sync_fence_create(timeline, 1);
+   plane.fence_fd = fence_fd;
+   plane.crtc_id = ~0U;
+   plane_commit_atomic_err(, plane_old, req,
+   ATOMIC_RELAX_NONE, EINVAL);
+   close(fence_fd);
+   close(timeline);
+
+   plane.fence_fd = -1;
plane.crtc_id = plane_old->crtc_id;
plane_commit_atomic(, req, ATOMIC_RELAX_NONE);

@@ -1058,27 +1088,98 @@ static void crtc_invalid_params(struct 
kms_atomic_crtc_state *crtc_old,
 {
struct kms_atomic_crtc_state crtc = *crtc_old;
drmModeAtomicReq *req = drmModeAtomicAlloc();
+   int timeline, fence_fd, *out_fence;

igt_assert(req);

/* Pass a series of invalid object IDs for the mode ID. */
crtc.mode.id = plane->obj;
-   crtc_commit_atomic_err(, plane, crtc_old, plane, req,
+   crtc_commit_atomic_err(, plane, crtc_old, plane, req, 0,
   ATOMIC_RELAX_NONE, EINVAL);

crtc.mode.id = crtc.obj;
-   crtc_commit_atomic_err(, plane, crtc_old, plane, req,
+   crtc_commit_atomic_err(, plane, crtc_old, plane, req, 0,
   ATOMIC_RELAX_NONE, EINVAL);

crtc.mode.id = conn->obj;
-   crtc_commit_atomic_err(, 

[PATCH 07/12] lib/igt_kms: Add support for the OUT_FENCE_PTR property

[Gustavo Padovan]

From: Gustavo Padovan 

Add support for the OUT_FENCE_PTR property to enable setting out fences for
atomic commits.

Signed-off-by: Gustavo Padovan 
---
 lib/igt_kms.c | 20 +++-
 lib/igt_kms.h |  3 +++
 2 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 4748c0a..f25e1eb 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -175,7 +175,8 @@ const char *igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = {
"DEGAMMA_LUT",
"GAMMA_LUT",
"MODE_ID",
-   "ACTIVE"
+   "ACTIVE",
+   "OUT_FENCE_PTR"
 };

 const char *igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = {
@@ -2103,6 +2104,9 @@ static void igt_atomic_prepare_crtc_commit(igt_pipe_t 
*pipe_obj, drmModeAtomicRe
igt_atomic_populate_crtc_req(req, pipe_obj, IGT_CRTC_ACTIVE, 
!!output);
}

+   if (pipe_obj->out_fence_ptr)
+   igt_atomic_populate_crtc_req(req, pipe_obj, 
IGT_CRTC_OUT_FENCE_PTR, pipe_obj->out_fence_ptr);
+
/*
 *  TODO: Add all crtc level properties here
 */
@@ -2683,6 +2687,20 @@ igt_pipe_set_gamma_lut(igt_pipe_t *pipe, void *ptr, 
size_t length)
 }

 /**
+ * igt_pipe_set_out_fence_ptr:
+ * @pipe: pipe pointer to which background color to be set
+ * @fence_ptr: out fence pointer
+ *
+ * Sets the out fence pointer that will be passed to the kernel in
+ * the atomic ioctl. When the kernel returns the out fence pointer
+ * will contain the fd number of the out fence created by KMS.
+ */
+void igt_pipe_set_out_fence_ptr(igt_pipe_t *pipe, int *fence_ptr)
+{
+   pipe->out_fence_ptr = (uint64_t) fence_ptr;
+}
+
+/**
  * igt_crtc_set_background:
  * @pipe: pipe pointer to which background color to be set
  * @background: background color value in BGR 16bpc
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 344f931..02d7bd1 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -110,6 +110,7 @@ enum igt_atomic_crtc_properties {
IGT_CRTC_GAMMA_LUT,
IGT_CRTC_MODE_ID,
IGT_CRTC_ACTIVE,
+   IGT_CRTC_OUT_FENCE_PTR,
IGT_NUM_CRTC_PROPS
 };

@@ -298,6 +299,7 @@ struct igt_pipe {

uint64_t mode_blob;
bool mode_changed;
+   uint64_t out_fence_ptr;
 };

 typedef struct {
@@ -351,6 +353,7 @@ static inline bool igt_plane_supports_rotation(igt_plane_t 
*plane)
 void igt_pipe_set_degamma_lut(igt_pipe_t *pipe, void *ptr, size_t length);
 void igt_pipe_set_ctm_matrix(igt_pipe_t *pipe, void *ptr, size_t length);
 void igt_pipe_set_gamma_lut(igt_pipe_t *pipe, void *ptr, size_t length);
+void igt_pipe_set_out_fence_ptr(igt_pipe_t *pipe, int *fence_ptr);

 void igt_plane_set_fb(igt_plane_t *plane, struct igt_fb *fb);
 void igt_plane_set_fence_fd(igt_plane_t *plane, uint32_t fence_fd);
-- 
2.5.5

[PATCH 06/12] lib/igt_kms: Add support for the IN_FENCE_FD property

[Gustavo Padovan]

From: Robert Foss 

Add support dor the IN_FENCE_FD property to enable setting in fences for atomic
commits.

Signed-off-by: Robert Foss 
---
 lib/igt_kms.c | 20 
 lib/igt_kms.h |  5 +
 2 files changed, 25 insertions(+)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 8aaff5b..4748c0a 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -164,6 +164,7 @@ const char *igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = {
"CRTC_H",
"FB_ID",
"CRTC_ID",
+   "IN_FENCE_FD",
"type",
"rotation"
 };
@@ -1426,6 +1427,7 @@ void igt_display_init(igt_display_t *display, int drm_fd)
n_planes++;
plane->pipe = pipe;
plane->drm_plane = drm_plane;
+   plane->fence_fd = -1;

if (is_atomic == 0) {
display->is_atomic = 1;
@@ -1712,6 +1714,11 @@ igt_atomic_prepare_plane_commit(igt_plane_t *plane, 
igt_pipe_t *pipe,
plane->index,
fb_id);

+   if (plane->fence_fd >= 0) {
+   uint32_t fence_fd = plane->fence_fd;
+   igt_atomic_populate_plane_req(req, plane, 
IGT_PLANE_IN_FENCE_FD, fence_fd);
+   }
+
if (plane->fb_changed) {
igt_atomic_populate_plane_req(req, plane, IGT_PLANE_CRTC_ID, 
fb_id ? crtc_id : 0);
igt_atomic_populate_plane_req(req, plane, IGT_PLANE_FB_ID, 
fb_id);
@@ -2522,6 +2529,19 @@ void igt_plane_set_fb(igt_plane_t *plane, struct igt_fb 
*fb)
plane->size_changed = true;
 }

+/**
+ * igt_plane_set_fence_fd:
+ * @plane: plane
+ * @fence_fd: fence fd, disable fence_fd by setting it to 0
+ *
+ * This function sets a fence fd to enable a commit to wait for some event to
+ * occur before completing.
+ */
+void igt_plane_set_fence_fd(igt_plane_t *plane, uint32_t fence_fd)
+{
+   plane->fence_fd = fence_fd;
+}
+
 void igt_plane_set_position(igt_plane_t *plane, int x, int y)
 {
igt_pipe_t *pipe = plane->pipe;
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index ae2b505..344f931 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -213,6 +213,7 @@ enum igt_atomic_plane_properties {

IGT_PLANE_FB_ID,
IGT_PLANE_CRTC_ID,
+   IGT_PLANE_IN_FENCE_FD,
IGT_PLANE_TYPE,
IGT_PLANE_ROTATION,
IGT_NUM_PLANE_PROPS
@@ -266,6 +267,9 @@ typedef struct {
uint32_t src_h;

igt_rotation_t rotation;
+
+   /* in fence fd */
+   int32_t fence_fd;
uint32_t atomic_props_plane[IGT_NUM_PLANE_PROPS];
 } igt_plane_t;

@@ -349,6 +353,7 @@ void igt_pipe_set_ctm_matrix(igt_pipe_t *pipe, void *ptr, 
size_t length);
 void igt_pipe_set_gamma_lut(igt_pipe_t *pipe, void *ptr, size_t length);

 void igt_plane_set_fb(igt_plane_t *plane, struct igt_fb *fb);
+void igt_plane_set_fence_fd(igt_plane_t *plane, uint32_t fence_fd);
 void igt_plane_set_position(igt_plane_t *plane, int x, int y);
 void igt_plane_set_size(igt_plane_t *plane, int w, int h);
 void igt_plane_set_rotation(igt_plane_t *plane, igt_rotation_t rotation);
-- 
2.5.5

[PATCH 05/12] tests/kms_atomic: use global atomic properties definitions

[Gustavo Padovan]

From: Gustavo Padovan 

Signed-off-by: Gustavo Padovan 
---
 tests/kms_atomic.c | 123 -
 1 file changed, 37 insertions(+), 86 deletions(-)

diff --git a/tests/kms_atomic.c b/tests/kms_atomic.c
index 1441fdf..8b648eb 100644
--- a/tests/kms_atomic.c
+++ b/tests/kms_atomic.c
@@ -105,55 +105,6 @@ static const char 
*plane_type_prop_names[NUM_PLANE_TYPE_PROPS] = {
"Cursor"
 };

-enum plane_properties {
-   PLANE_SRC_X = 0,
-   PLANE_SRC_Y,
-   PLANE_SRC_W,
-   PLANE_SRC_H,
-   PLANE_CRTC_X,
-   PLANE_CRTC_Y,
-   PLANE_CRTC_W,
-   PLANE_CRTC_H,
-   PLANE_FB_ID,
-   PLANE_CRTC_ID,
-   PLANE_TYPE,
-   NUM_PLANE_PROPS
-};
-
-static const char *plane_prop_names[NUM_PLANE_PROPS] = {
-   "SRC_X",
-   "SRC_Y",
-   "SRC_W",
-   "SRC_H",
-   "CRTC_X",
-   "CRTC_Y",
-   "CRTC_W",
-   "CRTC_H",
-   "FB_ID",
-   "CRTC_ID",
-   "type"
-};
-
-enum crtc_properties {
-   CRTC_MODE_ID = 0,
-   CRTC_ACTIVE,
-   NUM_CRTC_PROPS
-};
-
-static const char *crtc_prop_names[NUM_CRTC_PROPS] = {
-   "MODE_ID",
-   "ACTIVE"
-};
-
-enum connector_properties {
-   CONNECTOR_CRTC_ID = 0,
-   NUM_CONNECTOR_PROPS
-};
-
-static const char *connector_prop_names[NUM_CONNECTOR_PROPS] = {
-   "CRTC_ID"
-};
-
 struct kms_atomic_blob {
uint32_t id; /* 0 if not already allocated */
size_t len;
@@ -197,9 +148,9 @@ struct kms_atomic_state {

 struct kms_atomic_desc {
int fd;
-   uint32_t props_connector[NUM_CONNECTOR_PROPS];
-   uint32_t props_crtc[NUM_CRTC_PROPS];
-   uint32_t props_plane[NUM_PLANE_PROPS];
+   uint32_t props_connector[IGT_NUM_CONNECTOR_PROPS];
+   uint32_t props_crtc[IGT_NUM_CRTC_PROPS];
+   uint32_t props_plane[IGT_NUM_PLANE_PROPS];
uint64_t props_plane_type[NUM_PLANE_TYPE_PROPS];
 };

@@ -280,7 +231,7 @@ connector_get_current_state(struct 
kms_atomic_connector_state *connector)
for (i = 0; i < props->count_props; i++) {
uint32_t *prop_ids = connector->state->desc->props_connector;

-   if (props->props[i] == prop_ids[CONNECTOR_CRTC_ID])
+   if (props->props[i] == prop_ids[IGT_CONNECTOR_CRTC_ID])
connector->crtc_id = props->prop_values[i];
}
drmModeFreeObjectProperties(props);
@@ -348,16 +299,16 @@ find_connector(struct kms_atomic_state *state,
 static void plane_populate_req(struct kms_atomic_plane_state *plane,
   drmModeAtomicReq *req)
 {
-   plane_set_prop(req, plane, PLANE_CRTC_ID, plane->crtc_id);
-   plane_set_prop(req, plane, PLANE_FB_ID, plane->fb_id);
-   plane_set_prop(req, plane, PLANE_SRC_X, plane->src_x);
-   plane_set_prop(req, plane, PLANE_SRC_Y, plane->src_y);
-   plane_set_prop(req, plane, PLANE_SRC_W, plane->src_w);
-   plane_set_prop(req, plane, PLANE_SRC_H, plane->src_h);
-   plane_set_prop(req, plane, PLANE_CRTC_X, plane->crtc_x);
-   plane_set_prop(req, plane, PLANE_CRTC_Y, plane->crtc_y);
-   plane_set_prop(req, plane, PLANE_CRTC_W, plane->crtc_w);
-   plane_set_prop(req, plane, PLANE_CRTC_H, plane->crtc_h);
+   plane_set_prop(req, plane, IGT_PLANE_CRTC_ID, plane->crtc_id);
+   plane_set_prop(req, plane, IGT_PLANE_FB_ID, plane->fb_id);
+   plane_set_prop(req, plane, IGT_PLANE_SRC_X, plane->src_x);
+   plane_set_prop(req, plane, IGT_PLANE_SRC_Y, plane->src_y);
+   plane_set_prop(req, plane, IGT_PLANE_SRC_W, plane->src_w);
+   plane_set_prop(req, plane, IGT_PLANE_SRC_H, plane->src_h);
+   plane_set_prop(req, plane, IGT_PLANE_CRTC_X, plane->crtc_x);
+   plane_set_prop(req, plane, IGT_PLANE_CRTC_Y, plane->crtc_y);
+   plane_set_prop(req, plane, IGT_PLANE_CRTC_W, plane->crtc_w);
+   plane_set_prop(req, plane, IGT_PLANE_CRTC_H, plane->crtc_h);
 }

 static void plane_get_current_state(struct kms_atomic_plane_state *plane)
@@ -373,27 +324,27 @@ static void plane_get_current_state(struct 
kms_atomic_plane_state *plane)
for (i = 0; i < props->count_props; i++) {
uint32_t *prop_ids = desc->props_plane;

-   if (props->props[i] == prop_ids[PLANE_CRTC_ID])
+   if (props->props[i] == prop_ids[IGT_PLANE_CRTC_ID])
plane->crtc_id = props->prop_values[i];
-   else if (props->props[i] == prop_ids[PLANE_FB_ID])
+   else if (props->props[i] == prop_ids[IGT_PLANE_FB_ID])
plane->fb_id = props->prop_values[i];
-   else if (props->props[i] == prop_ids[PLANE_CRTC_X])
+   else if (props->props[i] == prop_ids[IGT_PLANE_CRTC_X])
plane->crtc_x = props->prop_values[i];
-   else if (props->props[i] == prop_ids[PLANE_CRTC_Y])
+   else if (props->props[i] == prop_ids[IGT_PLANE_CRTC_Y])
   

[PATCH 04/12] lib/igt_kms: export properties names

[Gustavo Padovan]

From: Gustavo Padovan 

Signed-off-by: Gustavo Padovan 
---
 lib/igt_kms.c | 6 +++---
 lib/igt_kms.h | 5 +
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index aa9fd16..8aaff5b 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -153,7 +153,7 @@ const unsigned char* igt_kms_get_base_edid(void)
 #define EDID_NAME alt_edid
 #include "igt_edid_template.h"

-static const char *igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = {
+const char *igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = {
"SRC_X",
"SRC_Y",
"SRC_W",
@@ -168,7 +168,7 @@ static const char 
*igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = {
"rotation"
 };

-static const char *igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = {
+const char *igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = {
"background_color",
"CTM",
"DEGAMMA_LUT",
@@ -177,7 +177,7 @@ static const char *igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] 
= {
"ACTIVE"
 };

-static const char *igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = {
+const char *igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = {
"scaling mode",
"CRTC_ID"
 };
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 6422adc..ae2b505 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -113,12 +113,16 @@ enum igt_atomic_crtc_properties {
IGT_NUM_CRTC_PROPS
 };

+extern const char *igt_crtc_prop_names[];
+
 enum igt_atomic_connector_properties {
IGT_CONNECTOR_SCALING_MODE = 0,
IGT_CONNECTOR_CRTC_ID,
IGT_NUM_CONNECTOR_PROPS
 };

+extern const char *igt_connector_prop_names[];
+
 struct kmstest_connector_config {
drmModeCrtc *crtc;
drmModeConnector *connector;
@@ -214,6 +218,7 @@ enum igt_atomic_plane_properties {
IGT_NUM_PLANE_PROPS
 };

+extern const char *igt_plane_prop_names[];

 typedef struct igt_display igt_display_t;
 typedef struct igt_pipe igt_pipe_t;
-- 
2.5.5

[PATCH 03/12] lib/igt_kms: move igt_kms_get_alt_edid() to the right place

[Gustavo Padovan]

From: Gustavo Padovan 

Signed-off-by: Gustavo Padovan 
---
 lib/igt_kms.c | 34 +-
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index 989704e..aa9fd16 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -153,23 +153,6 @@ const unsigned char* igt_kms_get_base_edid(void)
 #define EDID_NAME alt_edid
 #include "igt_edid_template.h"

-/**
- * igt_kms_get_alt_edid:
- *
- * Get an alternate edid block, which includes the following modes:
- *
- *  - 1400x1050 60Hz
- *  - 1920x1080 60Hz
- *  - 1280x720 60Hz
- *  - 1024x768 60Hz
- *  - 800x600 60Hz
- *  - 640x480 60Hz
- *
- * This can be extended with further features using functions such as
- * #kmstest_edid_add_3d.
- *
- * Returns: an alternate edid block
- */
 static const char *igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = {
"SRC_X",
"SRC_Y",
@@ -297,6 +280,23 @@ igt_atomic_fill_pipe_props(igt_display_t *display, 
igt_pipe_t *pipe,
drmModeFreeObjectProperties(props);
 }

+/**
+ * igt_kms_get_alt_edid:
+ *
+ * Get an alternate edid block, which includes the following modes:
+ *
+ *  - 1400x1050 60Hz
+ *  - 1920x1080 60Hz
+ *  - 1280x720 60Hz
+ *  - 1024x768 60Hz
+ *  - 800x600 60Hz
+ *  - 640x480 60Hz
+ *
+ * This can be extended with further features using functions such as
+ * #kmstest_edid_add_3d.
+ *
+ * Returns: an alternate edid block
+ */
 const unsigned char* igt_kms_get_alt_edid(void)
 {
update_edid_csum(alt_edid);
-- 
2.5.5

[PATCH 02/12] tests/kms_atomic_transition: don't assume max pipes

[Gustavo Padovan]

From: Gustavo Padovan 

Signed-off-by: Gustavo Padovan 
---
 tests/kms_atomic_transition.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/kms_atomic_transition.c b/tests/kms_atomic_transition.c
index e693c88..8b26b53 100644
--- a/tests/kms_atomic_transition.c
+++ b/tests/kms_atomic_transition.c
@@ -404,7 +404,7 @@ static void run_modeset_tests(igt_display_t *display, int 
howmany, bool nonblock
 {
struct igt_fb fbs[2];
int i, j;
-   unsigned iter_max = 1 << I915_MAX_PIPES;
+   unsigned iter_max = 1 << display->n_pipes;
igt_pipe_crc_t *pipe_crcs[I915_MAX_PIPES];
igt_output_t *output;
unsigned width = 0, height = 0;
-- 
2.5.5

[PATCH i-g-t 2/2] lib/drmtest: add virtio_gpu support

[Gustavo Padovan]

From: Gustavo Padovan 

Support the virtio GPU on drmtest.

Signed-off-by: Gustavo Padovan 
---
 lib/drmtest.c | 9 +
 lib/drmtest.h | 1 +
 2 files changed, 10 insertions(+)

diff --git a/lib/drmtest.c b/lib/drmtest.c
index 9f3ac7f..b374006 100644
--- a/lib/drmtest.c
+++ b/lib/drmtest.c
@@ -115,6 +115,11 @@ static bool is_vgem_device(int fd)
return __is_device(fd, "vgem");
 }

+static bool is_virtio_device(int fd)
+{
+   return __is_device(fd, "virt");
+}
+
 static bool has_known_intel_chipset(int fd)
 {
struct drm_i915_getparam gp;
@@ -260,6 +265,10 @@ int __drm_open_driver(int chipset)
is_vgem_device(fd))
return fd;

+   if (chipset & DRIVER_VIRTIO &&
+   is_virtio_device(fd))
+   return fd;
+
close(fd);
}

diff --git a/lib/drmtest.h b/lib/drmtest.h
index 8ce32a6..19d4bd1 100644
--- a/lib/drmtest.h
+++ b/lib/drmtest.h
@@ -41,6 +41,7 @@
 #define DRIVER_INTEL   (1 << 0)
 #define DRIVER_VC4 (1 << 1)
 #define DRIVER_VGEM(1 << 2)
+#define DRIVER_VIRTIO  (1 << 3)
 #define DRIVER_ANY ~(DRIVER_VGEM)

 #ifdef ANDROID
-- 
2.5.5

[PATCH 01/12] tests/kms_atomic_transition: use select + read instead of blocking read

[Gustavo Padovan]

From: Gustavo Padovan 

If the event never arrives we can timeout with select and end the test.

Signed-off-by: Gustavo Padovan 
---
 tests/kms_atomic_transition.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/tests/kms_atomic_transition.c b/tests/kms_atomic_transition.c
index 1977993..e693c88 100644
--- a/tests/kms_atomic_transition.c
+++ b/tests/kms_atomic_transition.c
@@ -296,6 +296,14 @@ static void commit_display(igt_display_t *display, 
unsigned event_mask, bool non
struct drm_event *e = (void *)buf;
struct drm_event_vblank *vblank = (void *)buf;
uint32_t crtc_id, pipe = I915_MAX_PIPES;
+   struct timeval timeout = { .tv_sec = 3, .tv_usec = 0 };
+   fd_set fds;
+
+   FD_ZERO();
+   FD_SET(0, );
+   FD_SET(display->drm_fd, );
+   ret = select(display->drm_fd + 1, , NULL, NULL, );
+   igt_assert(ret > 0);

ret = read(display->drm_fd, buf, sizeof(buf));
if (ret < 0 && (errno == EINTR || errno == EAGAIN))
-- 
2.5.5

[PATCH i-g-t 1/2] lib/drmtest: Fix igt_skip message

[Gustavo Padovan]

From: Gustavo Padovan 

Now other gpus are supported too.

Signed-off-by: Gustavo Padovan 
---
 lib/drmtest.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/drmtest.c b/lib/drmtest.c
index 884fe7c..9f3ac7f 100644
--- a/lib/drmtest.c
+++ b/lib/drmtest.c
@@ -263,7 +263,7 @@ int __drm_open_driver(int chipset)
close(fd);
}

-   igt_skip("No intel gpu found\n");
+   igt_skip("No known gpu found\n");
return -1;
 }

-- 
2.5.5

[PATCH 00/12] kms tests for the DRM fences interfaces

[Gustavo Padovan]

From: Gustavo Padovan 

Hi,

That is the first version of the igt tests for DRM fences[1]. The
first four patches are just fix/improvements on the kms_atomic
infrastructure.

These patches depends on Robert Foss tests for sw_sync and a branch
with those tests included can be seen here:

https://git.collabora.com/cgit/user/padovan/intel-gpu-tools.git/log/

Gustavo

---
[1] https://lkml.org/lkml/2016/11/13/324

Gustavo Padovan (11):
  tests/kms_atomic_transition: use select + read instead of blocking
read
  tests/kms_atomic_transition: don't assume max pipes
  lib/igt_kms: move igt_kms_get_alt_edid() to the right place
  lib/igt_kms: export properties names
  tests/kms_atomic: use global atomic properties definitions
  lib/igt_kms: Add support for the OUT_FENCE_PTR property
  tests/kms_atomic: stress possible fence settings
  tests/kms_atomic_transition: add fencing parameter to
run_transition_tests
  tests/kms_atomic_transition: add out_fences tests
  tests/kms_atomic_transition: add in_fences tests
  tests/kms_atomic_transition: set out_fence for all crtcs

Robert Foss (1):
  lib/igt_kms: Add support for the IN_FENCE_FD property

 lib/igt_kms.c | 102 +
 lib/igt_kms.h |  13 +++
 tests/kms_atomic.c| 247 ++
 tests/kms_atomic_transition.c | 148 ++---
 4 files changed, 379 insertions(+), 131 deletions(-)

-- 
2.5.5

[PATCH libdrm v2] xf86drm: Parse the separate files to retrieve the vendor, ... info

[Michel Dänzer]

On 10/11/16 10:38 PM, Emil Velikov wrote:
> On 10 November 2016 at 12:40, Nicolai Hähnle  wrote:
>> On 09.11.2016 19:08, Emil Velikov wrote:
>>>
>>> From: Emil Velikov 
>>>
>>> Parsing config sysfs file wakes up the device. The latter of which may
>>> be slow and isn't required to begin with.
>>>
>>> Reading through config is/was required since the revision is not
>>> available by other means, although with a kernel patch in the way that
>>> is about to change.
>>>
>>> Since returning 0 when one might expect a valid value is a no-go add a
>>> workaround drmDeviceUseRevisionFile() which one can use to say "I don't
>>> care if the revision file returns 0."
>>>
>>> v2: Complete rework - add new API to control the method, instead of
>>> changing it underneat the users' feet.
>>>
>>> Cc: Michel Dänzer 
>>> Cc: Mauro Santos 
>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98502
>>> Signed-off-by: Emil Velikov 
>>> ---
>>> I don't have a strong preference for/against this or v1.
>>>
>>> With this Mesa will require a 2 line patch. With v1 things will get
>>> fixed magically, when rebuilt against newer libdrm.
>>>
>>> Mauro I'll send the mesa patch in a second. Feel free to give it a spin.
>>>
>>> Thanks
>>> ---
>>>  xf86drm.c | 70
>>> ---
>>>  xf86drm.h | 11 ++
>>>  2 files changed, 78 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/xf86drm.c b/xf86drm.c
>>> index 52add5e..676effc 100644
>>> --- a/xf86drm.c
>>> +++ b/xf86drm.c
>>> @@ -113,6 +113,13 @@ void drmSetServerInfo(drmServerInfoPtr info)
>>>  drm_server_info = info;
>>>  }
>>>
>>> +static bool use_revision_file;
>>> +
>>> +void drmDeviceUseRevisionFile(void)
>>> +{
>>> +use_revision_file = true;
>>> +}
>>
>>
>> I think this API of setting a magic hidden global variable is really nasty.
>>
>> Can we add new drmGetDevice[s] entry points with a flags parameter and a
>> flag (per Michel's suggestion) which says "I don't care about the revision
>> ID"? It kind of sucks because they'll have to get a silly name like
>> drmGetDevice[s]2, but I think that's still better than magic global state.
>>
> AFACS Michel suggested (in his latest reply) to have
> parse_separate_sysfs_files always and make the lack of revision file
> fatal - falling back to ./config. Not a separate API [+ flags] ?

You're mixing up two separate issues. Sorry if I was unclear before, let
me try again:

My first comment was about the "drmDeviceUseRevisionFile" name being
misleading and not reflecting the intent. For this issue, I think
Nicolai's suggestion is even better than just fixing the name.

My other comment was that parse_separate_sysfs_files should be tried
first even if the revision information is needed, and should only bail
in that case if the separate revision sysfs files are missing, in which
case parse_config_sysfs_file can be used as a fallback.


> P.S. /me is dreaming of the day when [wh]e'll get to drop 90% of
> libdrm and it's hacks - viva la libdrm3 !

Given the issues with bumping SONAME, I'm afraid you'll have to continue
dreaming for a long time. :)


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

[PATCH v2 3/3] drm/tilcdc: Add drm bridge support for attaching drm bridge drivers

[Jyri Sarha]

Adds drm bride support for attaching drm bridge drivers to tilcdc. The
decision whether a video port leads to an external encoder or bridge
is made simply based on remote device's compatible string. The code
has been tested with BeagleBone-Black with and without BeagleBone
DVI-D Cape Rev A3 using ti-tfp410 driver.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/tilcdc/tilcdc_drv.c  |   7 +-
 drivers/gpu/drm/tilcdc/tilcdc_drv.h  |   2 +
 drivers/gpu/drm/tilcdc/tilcdc_external.c | 140 +++
 drivers/gpu/drm/tilcdc/tilcdc_external.h |   1 +
 4 files changed, 131 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index dcc9621..ec22576 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -384,9 +384,14 @@ static int tilcdc_init(struct drm_driver *ddrv, struct 
device *dev)
ret = tilcdc_add_external_encoders(ddev);
if (ret < 0)
goto init_failed;
+   } else {
+   ret = tilcdc_attach_remote_device(ddev);
+   if (ret)
+   goto init_failed;
}

-   if ((priv->num_encoders == 0) || (priv->num_connectors == 0)) {
+   if (!priv->remote_encoder &&
+   ((priv->num_encoders == 0) || (priv->num_connectors == 0))) {
dev_err(dev, "no encoders/connectors found\n");
ret = -ENXIO;
goto init_failed;
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
index d31fe5d..283ff28 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
@@ -90,6 +90,8 @@ struct tilcdc_drm_private {
struct drm_connector *connectors[8];
const struct drm_connector_helper_funcs *connector_funcs[8];

+   struct drm_encoder *remote_encoder;
+
bool is_registered;
bool is_componentized;
 };
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_external.c 
b/drivers/gpu/drm/tilcdc/tilcdc_external.c
index 06a4c58..e1576ba 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_external.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_external.c
@@ -28,6 +28,18 @@
.raster_order   = 0,
 };

+static const struct tilcdc_panel_info panel_info_default = {
+   .ac_bias= 255,
+   .ac_bias_intrpt = 0,
+   .dma_burst_sz   = 16,
+   .bpp= 16,
+   .fdd= 0x80,
+   .tft_alt_mode   = 0,
+   .sync_edge  = 0,
+   .sync_ctrl  = 1,
+   .raster_order   = 0,
+};
+
 static int tilcdc_external_mode_valid(struct drm_connector *connector,
  struct drm_display_mode *mode)
 {
@@ -130,6 +142,101 @@ void tilcdc_remove_external_encoders(struct drm_device 
*dev)
 priv->connector_funcs[i]);
 }

+static const struct drm_encoder_funcs tilcdc_remote_encoder_funcs = {
+   .destroy= drm_encoder_cleanup,
+};
+
+static
+int tilcdc_attach_bridge(struct drm_device *ddev, struct drm_bridge *bridge)
+{
+   struct tilcdc_drm_private *priv = ddev->dev_private;
+   int ret;
+
+   priv->remote_encoder->possible_crtcs = BIT(0);
+   priv->remote_encoder->bridge = bridge;
+   bridge->encoder = priv->remote_encoder;
+
+   ret = drm_bridge_attach(ddev, bridge);
+   if (ret) {
+   dev_err(ddev->dev, "drm_bridge_attach() failed %d\n", ret);
+   return ret;
+   }
+
+   tilcdc_crtc_set_panel_info(priv->crtc, _info_default);
+
+   return 0;
+}
+
+static int tilcdc_node_has_port(struct device_node *dev_node)
+{
+   struct device_node *node;
+
+   node = of_get_child_by_name(dev_node, "ports");
+   if (!node)
+   node = of_get_child_by_name(dev_node, "port");
+   if (!node)
+   return 0;
+   of_node_put(node);
+
+   return 1;
+}
+
+static
+struct device_node *tilcdc_get_remote_node(struct device_node *node)
+{
+   struct device_node *ep;
+   struct device_node *parent;
+
+   if (!tilcdc_node_has_port(node))
+   return NULL;
+
+   ep = of_graph_get_next_endpoint(node, NULL);
+   if (!ep)
+   return NULL;
+
+   parent = of_graph_get_remote_port_parent(ep);
+   of_node_put(ep);
+
+   return parent;
+}
+
+int tilcdc_attach_remote_device(struct drm_device *ddev)
+{
+   struct tilcdc_drm_private *priv = ddev->dev_private;
+   struct device_node *remote_node;
+   struct drm_bridge *bridge;
+   int ret;
+
+   remote_node = tilcdc_get_remote_node(ddev->dev->of_node);
+   if (!remote_node)
+   return 0;
+
+   bridge = of_drm_find_bridge(remote_node);
+   of_node_put(remote_node);
+   if (!bridge)
+   

[PATCH v2 2/3] drm/bridge: Add ti-tfp410 DVI transmitter driver

[Jyri Sarha]

Add very basic ti-ftp410 DVI transmitter driver. The only feature
separating this from a completely dummy bridge is the EDID read
support trough DDC I2C. Even that functionality should be in a
separate generic connector driver. However, because of missing DRM
infrastructure support the connector is implemented within the bridge
driver. Some tfp410 HW specific features may be added later if needed,
because there is a set of registers behind i2c if it is connected.

This implementations is tested against my new tilcdc bridge support
and it works with BeagleBone DVI-D Cape Rev A3. A DT binding document
is also added.

Signed-off-by: Jyri Sarha 
---
 .../bindings/display/bridge/ti,tfp410.txt  |  41 
 drivers/gpu/drm/bridge/Kconfig |   7 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/ti-tfp410.c | 223 +
 4 files changed, 272 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
 create mode 100644 drivers/gpu/drm/bridge/ti-tfp410.c

diff --git a/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt 
b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
new file mode 100644
index 000..7446b2b
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
@@ -0,0 +1,41 @@
+TFP410 DVI bridge bindings
+
+Required properties:
+   - compatible: "ti,tfp410"
+
+Optional properties
+   - reg: I2C address. If and only if present the driver node
+ should be placed into the i2c controller node where the
+ tfp410 i2c is connected to (the current implementation does
+ not yet support this).
+
+Required subnodes:
+   - port at 0: Video input port node to connect the bridge to a
+ display controller output [1].
+   - port at 1: Video output port node to connect the bridge to a
+ connector input [1].
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+
+Example:
+   hdmi-bridge {
+   compatible = "ti,tfp410";
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port at 0 {
+   reg = <0>;
+   bridge_in: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+
+   port at 1 {
+   reg = <1>;
+   bridge_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+   };
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index bd6acc8..a424e03 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -81,6 +81,13 @@ config DRM_TOSHIBA_TC358767
---help---
  Toshiba TC358767 eDP bridge chip driver.

+config DRM_TI_TFP410
+   tristate "TI TFP410 DVI/HDMI bridge"
+   depends on OF
+   select DRM_KMS_HELPER
+   ---help---
+ Texas Instruments TFP410 DVI/HDMI Transmitter driver
+
 source "drivers/gpu/drm/bridge/analogix/Kconfig"

 source "drivers/gpu/drm/bridge/adv7511/Kconfig"
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 97ed1a5..8b065d9 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -11,3 +11,4 @@ obj-$(CONFIG_DRM_SII902X) += sii902x.o
 obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
 obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
 obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
+obj-$(CONFIG_DRM_TI_TFP410) += ti-tfp410.o
diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c 
b/drivers/gpu/drm/bridge/ti-tfp410.c
new file mode 100644
index 000..a806cd6
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ti-tfp410.c
@@ -0,0 +1,223 @@
+/*
+ * Copyright (C) 2016 Texas Instruments
+ * Author: Jyri Sarha 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ */
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+struct tfp410 {
+   struct drm_bridge   bridge;
+   struct drm_connectorconnector;
+
+   struct i2c_adapter  *ddc;
+
+   struct device *dev;
+};
+
+static inline struct tfp410 *
+drm_bridge_to_tfp410(struct drm_bridge *bridge)
+{
+   return container_of(bridge, struct tfp410, bridge);
+}
+
+static inline struct tfp410 *
+drm_connector_to_tfp410(struct drm_connector *connector)
+{
+   return container_of(connector, struct tfp410, connector);
+}
+
+static int tfp410_get_modes(struct drm_connector *connector)
+{
+   struct tfp410 *dvi = drm_connector_to_tfp410(connector);
+   struct edid *edid;
+   

[PATCH v2 1/3] drm/tilcdc: Recover from sync lost error flood by resetting the LCDC

[Jyri Sarha]

Recover from sync lost error flood by resetting the LCDC instead of
turning off the SYNC_LOST error IRQ. When LCDC starves on limited
memory bandwidth it may sometimes result an error situation when the
picture may have shifted couple of pixels to right and SYNC_LOST
interrupt is generated on every frame. LCDC main reset recovers from
this situation and causes a brief blanking on the screen.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
index 0d09acc..c787349 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
@@ -55,6 +55,7 @@ struct tilcdc_crtc {

int sync_lost_count;
bool frame_intact;
+   struct work_struct recover_work;
 };
 #define to_tilcdc_crtc(x) container_of(x, struct tilcdc_crtc, base)

@@ -252,6 +253,25 @@ static bool tilcdc_crtc_is_on(struct drm_crtc *crtc)
return crtc->state && crtc->state->enable && crtc->state->active;
 }

+static void tilcdc_crtc_recover_work(struct work_struct *work)
+{
+   struct tilcdc_crtc *tilcdc_crtc =
+   container_of(work, struct tilcdc_crtc, recover_work);
+   struct drm_crtc *crtc = _crtc->base;
+
+   dev_info(crtc->dev->dev, "%s: Reset CRTC", __func__);
+
+   drm_modeset_lock_crtc(crtc, NULL);
+
+   if (!tilcdc_crtc_is_on(crtc))
+   goto out;
+
+   tilcdc_crtc_disable(crtc);
+   tilcdc_crtc_enable(crtc);
+out:
+   drm_modeset_unlock_crtc(crtc);
+}
+
 static void tilcdc_crtc_destroy(struct drm_crtc *crtc)
 {
struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
@@ -838,9 +858,12 @@ irqreturn_t tilcdc_crtc_irq(struct drm_crtc *crtc)
tilcdc_crtc->frame_intact = false;
if (tilcdc_crtc->sync_lost_count++ >
SYNC_LOST_COUNT_LIMIT) {
-   dev_err(dev->dev, "%s(0x%08x): Sync lost flood 
detected, disabling the interrupt", __func__, stat);
+   dev_err(dev->dev, "%s(0x%08x): Sync lost flood 
detected, recovering", __func__, stat);
+   queue_work(system_wq,
+  _crtc->recover_work);
tilcdc_write(dev, LCDC_INT_ENABLE_CLR_REG,
 LCDC_SYNC_LOST);
+   tilcdc_crtc->sync_lost_count = 0;
}
}

@@ -880,6 +903,7 @@ struct drm_crtc *tilcdc_crtc_create(struct drm_device *dev)
"unref", unref_worker);

spin_lock_init(_crtc->irq_lock);
+   INIT_WORK(_crtc->recover_work, tilcdc_crtc_recover_work);

ret = drm_crtc_init_with_planes(dev, crtc,
_crtc->primary,
-- 
1.9.1

[PATCH v2 0/3] drm/tilcdc: Add bridge support and sync-lost flood recovery

[Jyri Sarha]

Changes since first version of the series:
- "drm/tilcdc: Recover from sync lost error flood by resetting the LCDC"
  - no change
- "drm/bridge: Add ti-tfp410 DVI transmitter driver"
  - HDMI -> DVI
  - DT Binding document
- Prepare for tfp410 connected trough i2c by optional reg property
- Require two port nodes
  - Implementation
- Implement connector node functionality with in tfp410 bridge
  drive, but follow generic connector binding by pulling the
  ddc-i2c-bus property from the connector node.
- "drm/tilcdc: Add drm bridge support for attaching drm bridge drivers"
  - Remove earlier change in TD binding document. There is no need to
mention DRM implementation details, like bridge support, in DT
binding.

The first patch is an independent on and I've been testing it for
quite a while now.

The tfp410 bridge driver and the tilcdc bridge support are tested with
BeagleBone DVI-D Cape Rev A3. The tfp410 bridge driver is missing a
lot of features, because the DVI-D cape does not have too many wires
connected. The missing features can be added later when they are
needed.

Jyri Sarha (3):
  drm/tilcdc: Recover from sync lost error flood by resetting the LCDC
  drm/bridge: Add ti-tfp410 DVI transmitter driver
  drm/tilcdc: Add drm bridge support for attaching drm bridge drivers

 .../bindings/display/bridge/ti,tfp410.txt  |  41 
 drivers/gpu/drm/bridge/Kconfig |   7 +
 drivers/gpu/drm/bridge/Makefile|   1 +
 drivers/gpu/drm/bridge/ti-tfp410.c | 223 +
 drivers/gpu/drm/tilcdc/tilcdc_crtc.c   |  26 ++-
 drivers/gpu/drm/tilcdc/tilcdc_drv.c|   7 +-
 drivers/gpu/drm/tilcdc/tilcdc_drv.h|   2 +
 drivers/gpu/drm/tilcdc/tilcdc_external.c   | 140 +++--
 drivers/gpu/drm/tilcdc/tilcdc_external.h   |   1 +
 9 files changed, 428 insertions(+), 20 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
 create mode 100644 drivers/gpu/drm/bridge/ti-tfp410.c

-- 
1.9.1

[PATCH 4/6] drm/irq: Unexport drm_vblank_count

[Philipp Zabel]

Am Montag, den 14.11.2016, 10:02 +0100 schrieb Daniel Vetter:
> No one outside of drm_irq.c should ever need this. The correct way to
> implement get_vblank_count for hw lacking a vblank counter is
> drm_vblank_no_hw_counter. Fix this up in mtk, which is the only
> offender left over.
> 
> Cc: CK Hu 
> Cc: Philipp Zabel 
> Signed-off-by: Daniel Vetter 

Acked-by: Philipp Zabel 

regards
Philipp

> ---
>  drivers/gpu/drm/drm_irq.c  | 37 
> +-
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c |  2 +-
>  2 files changed, 11 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 2fb5861b04b7..1681e919b866 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -234,6 +234,16 @@ static void drm_update_vblank_count(struct drm_device 
> *dev, unsigned int pipe,
>   store_vblank(dev, pipe, diff, _vblank, cur_vblank);
>  }
>  
> +static u32 drm_vblank_count(struct drm_device *dev, unsigned int pipe)
> +{
> + struct drm_vblank_crtc *vblank = >vblank[pipe];
> +
> + if (WARN_ON(pipe >= dev->num_crtcs))
> + return 0;
> +
> + return vblank->count;
> +}
> +
>  /**
>   * drm_accurate_vblank_count - retrieve the master vblank counter
>   * @crtc: which counter to retrieve
> @@ -888,31 +898,6 @@ drm_get_last_vbltimestamp(struct drm_device *dev, 
> unsigned int pipe,
>  }
>  
>  /**
> - * drm_vblank_count - retrieve "cooked" vblank counter value
> - * @dev: DRM device
> - * @pipe: index of CRTC for which to retrieve the counter
> - *
> - * Fetches the "cooked" vblank count value that represents the number of
> - * vblank events since the system was booted, including lost events due to
> - * modesetting activity.
> - *
> - * This is the legacy version of drm_crtc_vblank_count().
> - *
> - * Returns:
> - * The software vblank counter.
> - */
> -u32 drm_vblank_count(struct drm_device *dev, unsigned int pipe)
> -{
> - struct drm_vblank_crtc *vblank = >vblank[pipe];
> -
> - if (WARN_ON(pipe >= dev->num_crtcs))
> - return 0;
> -
> - return vblank->count;
> -}
> -EXPORT_SYMBOL(drm_vblank_count);
> -
> -/**
>   * drm_crtc_vblank_count - retrieve "cooked" vblank counter value
>   * @crtc: which counter to retrieve
>   *
> @@ -920,8 +905,6 @@ EXPORT_SYMBOL(drm_vblank_count);
>   * vblank events since the system was booted, including lost events due to
>   * modesetting activity.
>   *
> - * This is the native KMS version of drm_vblank_count().
> - *
>   * Returns:
>   * The software vblank counter.
>   */
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index d90152e85ed0..4b7fe7eaec01 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -256,7 +256,7 @@ static struct drm_driver mtk_drm_driver = {
>   .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME |
>  DRIVER_ATOMIC,
>  
> - .get_vblank_counter = drm_vblank_count,
> + .get_vblank_counter = drm_vblank_no_hw_counter,
>   .enable_vblank = mtk_drm_crtc_enable_vblank,
>   .disable_vblank = mtk_drm_crtc_disable_vblank,
>  

[PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"

[Ville Syrjälä]

On Mon, Nov 14, 2016 at 10:12:04PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 11/14/2016 9:50 PM, Ville Syrjälä wrote:
> > On Mon, Nov 14, 2016 at 09:37:18PM +0530, Sharma, Shashank wrote:
> >> Regards
> >>
> >> Shashank
> >>
> >>
> >> On 11/14/2016 9:19 PM, Ville Syrjälä wrote:
> >>> On Mon, Nov 14, 2016 at 08:14:34PM +0530, Sharma, Shashank wrote:
>  Regards
>  Shashank
> > the revert:
> >
> > HDMI2 connected 1920x1080+0+0 (normal left inverted right x axis y 
> > axis) 700mm x 390mm
> > -   1920x1080 60.00*+
> > -   1920x1080i60.0050.00
> > +   1920x1080 60.00*+  50.0059.9430.0025.0024.00
> > 29.9723.98
> > +   1920x1080i60.0050.0059.94
> >1600x1200 60.00
> >1680x1050 59.88
> >1280x1024 75.0260.02
> > @@ -13,30 +13,29 @@
> >1360x768  60.02
> >1280x800  59.91
> >1152x864  75.00
> > -   1280x720  60.0050.00
> > +   1280x720  60.0050.0059.94
> >1024x768  75.0370.0760.00
> >832x624   74.55
> >800x600   72.1975.0060.32
> > -   640x480   75.0072.8166.6759.94
> > +   720x576   50.00
> > +   720x480   60.0059.94
> > +   640x480   75.0072.8166.6760.0059.94
> >720x400   70.08
>  None of these aspect ratios are new modes / new aspect ratios from HDMI
>  2.0/CEA-861-F
>  These are the existing modes, and should be independent of reverted
>  patches.
> >>> They're affected because your patches changed them by adding the aspect
> >>> ratio flags to them.
> >> Yes, But they are independent of reverted patch, which adds aspect ratio
> >> for HDMI 2.0 ratios (64:27 and 256:135)
> > The second patch had to be reverted so that the first patch would revert
> > cleanly.
> >
> > This was with sna, which does this:
> > #define KNOWN_MODE_FLAGS ((1<<14)-1)
> > if (mode->status == MODE_OK && kmode->flags & ~KNOWN_MODE_FLAGS)
> > mode->status = MODE_BAD; /* unknown flags => unhandled */
> > so all the modes with an aspect ratio just vanished.
> >
> > -modesetting and -ati on the other hand just copy over the unknown
> > bits into the xrandr mode structure, which sounds dubious at best:
> > mode->Flags = kmode->flags; //& FLAG_BITS;
> > I've not checked what damage it can actually cause.
> >
> >
> > It looks like a few modes disappeared from the kernel's mode list
> > as well, presumably because some cea modes in the list originated from
> > DTDs and whanot so they don't have an aspect ratio and that causes
> > add_alternate_cea_modes() to ignore them. So not populating an aspect
> > ratio for cea modes originating from a source other than
> > edid_cea_modes[] looks like another bug to me as well.
>  I am writing a patch series to cap the aspect ratio implementation under
>  a drm_cap_hdmi2_aspect_ratios
>  This is how its going to work (inspired from the 2D/stereo series from
>  damien L)
> 
>  - Add a new capability hdmi2_ar
> >>> It should be just a generic "expose aspect ratio flags to userspace?"
> >> Makes sense, in this way we can even revert the aspect_ratio property
> >> for HDMI connector, as discussed during
> >> the code review sessions of this patch series. In this way, when kernel
> >> will expose the aspect ratios, it will either
> >> do the aspect ratios as per EDID, or wont.
>  - by default parsing the new hdmi 2.0 aspect ratio will be disabled
>  under check of this cap
>  - during bootup time, while initializing the display, a userspace can
>  get_cap on the hdmi2_aspect_ratio
>  - If it wants HDMI 2.0 aspect ratio support, it will set the cap, and
>  kernel will expose these aspect ratios
> > Another bug I think might be the ordering of the modes with aspect ratio
> > specified. IIRC the spec says that the preferred aspect ratio should be
> > listed first in the EDID, but I don't think we preserve that ordering
> > in the final mode list. I guess we could fix that by somehow noting
> > which aspect ratio is preferred and sort based on that, or we try to
> > preserve the order from the EDID until we're ready to sort, and then do
> > the sorting with a stable algorithm.
>  AFAIK The mode order and priority is decided and arranged in userspace,
>  based on various factors like
>  - preferred mode.
>  - previously applied mode in previous sessions (like for android tvs)
>  - Bigger h/w vs better refresh rate ?
>  - Xserver applies its own algorithms to decide which mode should be
>  shown first.
> >>> Xorg does sort on its own. But since it doesn't know anything about
> >>> aspect ratios and whatnot I wouldn't 

[PATCH 4/4] drm: rcar-du: Fix LVDS start sequence on Gen3

[Laurent Pinchart]

From: Koji Matsuoka 

According to the latest revision of the datasheet, the LVDS I/O pins
must be enabled before starting the PLL. Fix it.

Signed-off-by: Koji Matsuoka 
Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
index b74105a80a6e..e3a4985f6f3f 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
@@ -104,7 +104,14 @@ static void rcar_du_lvdsenc_start_gen3(struct 
rcar_du_lvdsenc *lvds,

rcar_lvds_write(lvds, LVDPLLCR, pllcr);

-   /* Turn the PLL on, set it to LVDS normal mode, wait for the startup
+   /* Turn all the channels on. */
+   rcar_lvds_write(lvds, LVDCR1,
+   LVDCR1_CHSTBY_GEN3(3) | LVDCR1_CHSTBY_GEN3(2) |
+   LVDCR1_CHSTBY_GEN3(1) | LVDCR1_CHSTBY_GEN3(0) |
+   LVDCR1_CLKSTBY_GEN3);
+
+   /*
+* Turn the PLL on, set it to LVDS normal mode, wait for the startup
 * delay and turn the output on.
 */
lvdcr0 = LVDCR0_PLLON;
@@ -117,12 +124,6 @@ static void rcar_du_lvdsenc_start_gen3(struct 
rcar_du_lvdsenc *lvds,

lvdcr0 |= LVDCR0_LVRES;
rcar_lvds_write(lvds, LVDCR0, lvdcr0);
-
-   /* Turn all the channels on. */
-   rcar_lvds_write(lvds, LVDCR1,
-   LVDCR1_CHSTBY_GEN3(3) | LVDCR1_CHSTBY_GEN3(2) |
-   LVDCR1_CHSTBY_GEN3(1) | LVDCR1_CHSTBY_GEN3(0) |
-   LVDCR1_CLKSTBY_GEN3);
 }

 static int rcar_du_lvdsenc_start(struct rcar_du_lvdsenc *lvds,
-- 
Regards,

Laurent Pinchart

[PATCH 3/4] drm: rcar-du: Fix H/V sync signal polarity configuration

[Laurent Pinchart]

From: Koji Matsuoka 

The VSL and HSL bits in the DSMR register set the corresponding
horizontal and vertical sync signal polarity to active high. The code
got it the wrong way around, fix it.

Signed-off-by: Koji Matsuoka 
Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index aca26eed93b1..a2ec6d8796a0 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -149,8 +149,8 @@ static void rcar_du_crtc_set_display_timing(struct 
rcar_du_crtc *rcrtc)
rcar_du_group_write(rcrtc->group, rcrtc->index % 2 ? OTAR2 : OTAR, 0);

/* Signal polarities */
-   value = ((mode->flags & DRM_MODE_FLAG_PVSYNC) ? 0 : DSMR_VSL)
- | ((mode->flags & DRM_MODE_FLAG_PHSYNC) ? 0 : DSMR_HSL)
+   value = ((mode->flags & DRM_MODE_FLAG_PVSYNC) ? DSMR_VSL : 0)
+ | ((mode->flags & DRM_MODE_FLAG_PHSYNC) ? DSMR_HSL : 0)
  | DSMR_DIPM_DISP | DSMR_CSPM;
rcar_du_crtc_write(rcrtc, DSMR, value);

-- 
Regards,

Laurent Pinchart

[PATCH 2/4] drm: rcar-du: Fix display timing controller parameter

[Laurent Pinchart]

From: Koji Matsuoka 

There is a bug in the setting of the DES (Display Enable Signal)
register. This current setting occurs 1 dot left shift. The DES
register should be set minus one value about the specifying value
with H/W specification. This patch corrects it.

Signed-off-by: Koji Matsuoka 
Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 7316fc7fa0bd..aca26eed93b1 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -172,7 +172,7 @@ static void rcar_du_crtc_set_display_timing(struct 
rcar_du_crtc *rcrtc)
mode->crtc_vsync_start - 1);
rcar_du_crtc_write(rcrtc, VCR,  mode->crtc_vtotal - 1);

-   rcar_du_crtc_write(rcrtc, DESR,  mode->htotal - mode->hsync_start);
+   rcar_du_crtc_write(rcrtc, DESR,  mode->htotal - mode->hsync_start - 1);
rcar_du_crtc_write(rcrtc, DEWR,  mode->hdisplay);
 }

-- 
Regards,

Laurent Pinchart

[PATCH 1/4] drm: rcar-du: Fix dot clock routing configuration

[Laurent Pinchart]

Dot clock routing is setup through different registers depending on the
DU generation. The code has been designed for Gen2 and hasn't been
updated since. This works thanks to good reset default value, but isn't
very safe. Fix it.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_group.c | 22 +-
 1 file changed, 13 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_group.c 
b/drivers/gpu/drm/rcar-du/rcar_du_group.c
index 33b2fc53da3e..64738fca96d0 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_group.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_group.c
@@ -105,16 +105,20 @@ static void rcar_du_group_setup(struct rcar_du_group 
*rgrp)
if (rcar_du_has(rgrp->dev, RCAR_DU_FEATURE_EXT_CTRL_REGS)) {
rcar_du_group_setup_defr8(rgrp);

-   /* Configure input dot clock routing. We currently hardcode the
-* configuration to routing DOTCLKINn to DUn.
+   /*
+* Configure input dot clock routing. We currently hardcode the
+* configuration to routing DOTCLKINn to DUn. Register fields
+* depend on the DU generation, but the resulting value is 0 in
+* all cases.
+*
+* On Gen2 a single register in the first group controls dot
+* clock selection for all channels, while on Gen3 dot clocks
+* are setup through per-group registers, only available when
+* the group has two channels.
 */
-   rcar_du_group_write(rgrp, DIDSR, DIDSR_CODE |
-   DIDSR_LCDS_DCLKIN(2) |
-   DIDSR_LCDS_DCLKIN(1) |
-   DIDSR_LCDS_DCLKIN(0) |
-   DIDSR_PDCS_CLK(2, 0) |
-   DIDSR_PDCS_CLK(1, 0) |
-   DIDSR_PDCS_CLK(0, 0));
+   if ((rcdu->info->gen < 3 && rgrp->index == 0) ||
+   (rcdu->info->gen == 3 &&  rgrp->num_crtcs > 1))
+   rcar_du_group_write(rgrp, DIDSR, DIDSR_CODE);
}

if (rcdu->info->gen >= 3)
-- 
Regards,

Laurent Pinchart

[PATCH 0/4] Renesas R-Car DU fixes

[Laurent Pinchart]

Hello,

This series contains four fixes for the R-Car DU driver, all backported or
inspired by the R-Car Gen3 BSP.

Please see individual patches for details.

Koji Matsuoka (3):
  drm: rcar-du: Fix display timing controller parameter
  drm: rcar-du: Fix H/V sync signal polarity configuration
  drm: rcar-du: Fix LVDS start sequence on Gen3

Laurent Pinchart (1):
  drm: rcar-du: Fix dot clock routing configuration

 drivers/gpu/drm/rcar-du/rcar_du_crtc.c|  6 +++---
 drivers/gpu/drm/rcar-du/rcar_du_group.c   | 22 +-
 drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 15 ---
 3 files changed, 24 insertions(+), 19 deletions(-)

-- 
Regards,

Laurent Pinchart

[PATCH 2/2] ARM: davinci_all_defconfig: enable the mstpri and ddrctl drivers

[Bartosz Golaszewski]

With the da8xx memory controller and master peripheral priority
drivers merged and corresponding device tree changes in place we can
now enable appropriate options by default.

Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/configs/davinci_all_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/davinci_all_defconfig 
b/arch/arm/configs/davinci_all_defconfig
index b5e978f..f814f01 100644
--- a/arch/arm/configs/davinci_all_defconfig
+++ b/arch/arm/configs/davinci_all_defconfig
@@ -56,6 +56,7 @@ CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
 # CONFIG_FW_LOADER is not set
+CONFIG_DA8XX_MSTPRI=y
 CONFIG_MTD=m
 CONFIG_MTD_BLOCK=m
 CONFIG_MTD_CFI=m
@@ -187,6 +188,7 @@ CONFIG_DMADEVICES=y
 CONFIG_TI_EDMA=y
 CONFIG_MEMORY=y
 CONFIG_TI_AEMIF=m
+CONFIG_DA8XX_DDRCTL=y
 CONFIG_EXT2_FS=y
 CONFIG_EXT3_FS=y
 CONFIG_XFS_FS=m
-- 
2.9.3

[PATCH 1/2] ARM: dts: da850: add the mstpri and ddrctl nodes

[Bartosz Golaszewski]

Add the nodes for the MSTPRI configuration and DDR2/mDDR memory
controller drivers to da850.dtsi.

Signed-off-by: Bartosz Golaszewski 
---
 arch/arm/boot/dts/da850.dtsi | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 1bb1f6d..1635218 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -440,6 +440,11 @@
interrupts = <52>;
status = "disabled";
};
+
+   mstpri: mstpri at 14110 {
+   compatible = "ti,da850-mstpri";
+   reg = <0x14110 0x0c>;
+   };
};
aemif: aemif at 6800 {
compatible = "ti,da850-aemif";
@@ -451,4 +456,8 @@
  1 0 0x6800 0x8000>;
status = "disabled";
};
+   ddrctl: ddrctl at b000 {
+   compatible = "ti,da850-ddr-controller";
+   reg = <0xb000 0xe8>;
+   };
 };
-- 
2.9.3

[PATCH 0/2] ARM: da850: enable the MSTPRI and DDR2/mDDR drivers

[Bartosz Golaszewski]

This is a follow-up for my previous series:

  ARM: da850: new drivers for better LCDC support

from which the new drivers were merged, while the patch adding the
panel node was nacked and has been dropped.

The first patch in this series enables the new drivers in da850.dtsi.
It has been changed since the last iteration to not disable the added
nodes. Also: the patch enabling the nodes in da850-lcdk.dts has been
dropped too.

The second patch updates the davinci defconfig.

Bartosz Golaszewski (2):
  ARM: dts: da850: add the mstpri and ddrctl nodes
  ARM: davinci_all_defconfig: enable the mstpri and ddrctl drivers

 arch/arm/boot/dts/da850.dtsi   | 9 +
 arch/arm/configs/davinci_all_defconfig | 2 ++
 2 files changed, 11 insertions(+)

-- 
2.9.3

[PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"

[Ville Syrjälä]

On Mon, Nov 14, 2016 at 09:37:18PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 11/14/2016 9:19 PM, Ville Syrjälä wrote:
> > On Mon, Nov 14, 2016 at 08:14:34PM +0530, Sharma, Shashank wrote:
> >> Regards
> >> Shashank
> >>> the revert:
> >>>
> >>>HDMI2 connected 1920x1080+0+0 (normal left inverted right x axis y 
> >>> axis) 700mm x 390mm
> >>> -   1920x1080 60.00*+
> >>> -   1920x1080i60.0050.00
> >>> +   1920x1080 60.00*+  50.0059.9430.0025.0024.00
> >>> 29.9723.98
> >>> +   1920x1080i60.0050.0059.94
> >>>   1600x1200 60.00
> >>>   1680x1050 59.88
> >>>   1280x1024 75.0260.02
> >>> @@ -13,30 +13,29 @@
> >>>   1360x768  60.02
> >>>   1280x800  59.91
> >>>   1152x864  75.00
> >>> -   1280x720  60.0050.00
> >>> +   1280x720  60.0050.0059.94
> >>>   1024x768  75.0370.0760.00
> >>>   832x624   74.55
> >>>   800x600   72.1975.0060.32
> >>> -   640x480   75.0072.8166.6759.94
> >>> +   720x576   50.00
> >>> +   720x480   60.0059.94
> >>> +   640x480   75.0072.8166.6760.0059.94
> >>>   720x400   70.08
> >> None of these aspect ratios are new modes / new aspect ratios from HDMI
> >> 2.0/CEA-861-F
> >> These are the existing modes, and should be independent of reverted
> >> patches.
> > They're affected because your patches changed them by adding the aspect
> > ratio flags to them.
> Yes, But they are independent of reverted patch, which adds aspect ratio 
> for HDMI 2.0 ratios (64:27 and 256:135)

The second patch had to be reverted so that the first patch would revert
cleanly.

> >>> This was with sna, which does this:
> >>>#define KNOWN_MODE_FLAGS ((1<<14)-1)
> >>>if (mode->status == MODE_OK && kmode->flags & ~KNOWN_MODE_FLAGS)
> >>>   mode->status = MODE_BAD; /* unknown flags => unhandled */
> >>> so all the modes with an aspect ratio just vanished.
> >>>
> >>> -modesetting and -ati on the other hand just copy over the unknown
> >>> bits into the xrandr mode structure, which sounds dubious at best:
> >>>mode->Flags = kmode->flags; //& FLAG_BITS;
> >>> I've not checked what damage it can actually cause.
> >>>
> >>>
> >>> It looks like a few modes disappeared from the kernel's mode list
> >>> as well, presumably because some cea modes in the list originated from
> >>> DTDs and whanot so they don't have an aspect ratio and that causes
> >>> add_alternate_cea_modes() to ignore them. So not populating an aspect
> >>> ratio for cea modes originating from a source other than
> >>> edid_cea_modes[] looks like another bug to me as well.
> >> I am writing a patch series to cap the aspect ratio implementation under
> >> a drm_cap_hdmi2_aspect_ratios
> >> This is how its going to work (inspired from the 2D/stereo series from
> >> damien L)
> >>
> >> - Add a new capability hdmi2_ar
> > It should be just a generic "expose aspect ratio flags to userspace?"
> Makes sense, in this way we can even revert the aspect_ratio property 
> for HDMI connector, as discussed during
> the code review sessions of this patch series. In this way, when kernel 
> will expose the aspect ratios, it will either
> do the aspect ratios as per EDID, or wont.
> >
> >> - by default parsing the new hdmi 2.0 aspect ratio will be disabled
> >> under check of this cap
> >> - during bootup time, while initializing the display, a userspace can
> >> get_cap on the hdmi2_aspect_ratio
> >> - If it wants HDMI 2.0 aspect ratio support, it will set the cap, and
> >> kernel will expose these aspect ratios
> >>> Another bug I think might be the ordering of the modes with aspect ratio
> >>> specified. IIRC the spec says that the preferred aspect ratio should be
> >>> listed first in the EDID, but I don't think we preserve that ordering
> >>> in the final mode list. I guess we could fix that by somehow noting
> >>> which aspect ratio is preferred and sort based on that, or we try to
> >>> preserve the order from the EDID until we're ready to sort, and then do
> >>> the sorting with a stable algorithm.
> >> AFAIK The mode order and priority is decided and arranged in userspace,
> >> based on various factors like
> >> - preferred mode.
> >> - previously applied mode in previous sessions (like for android tvs)
> >> - Bigger h/w vs better refresh rate ?
> >> - Xserver applies its own algorithms to decide which mode should be
> >> shown first.
> > Xorg does sort on its own. But since it doesn't know anything about
> > aspect ratios and whatnot I wouldn't rely on that for anything. I
> > also wouldn't expect eg. wayland compositors to do their own sorting.
> > And yeah, looks like weston at least doesn't do any sorting whatsoever.
> >
> >> I dont think kernel needs to bother about it.
> > So I'm going to say that we in fact do need to bother.
> >
> IMHO, making policies for UI is not a part of kernel design, a 

[GIT PULL] drm/arcpgu: Accommodate adv7511 switch to DRM bridge

[Алексей Бродкин]

Hi Dave,

2016-11-11 4:52 GMT+03:00 Алексей Бродкин :
> Hi Dave,
>
> Please pull that change for ARC PGU that fixes driver instantiation on
> AXS 10x boards.
> The patch was published for review here:
> https://lists.freedesktop.org/archives/dri-devel/2016-October/121245.html
>
> It is based on today's "drm-next" branch.

I erroneously used "drm-next" instead of "drm-fixes" branch.

I may resend a pull request if you want but that only patch in question gets
applied to "drm-fixes" perfectly fine without any changes.

Regards,
Alexey

[PATCH 1/2] Revert "drm: Add and handle new aspect ratios in DRM layer"

[Ville Syrjälä]

On Mon, Nov 14, 2016 at 08:14:34PM +0530, Sharma, Shashank wrote:
> Regards
> Shashank
> > the revert:
> >
> >   HDMI2 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 
> > 700mm x 390mm
> > -   1920x1080 60.00*+
> > -   1920x1080i60.0050.00
> > +   1920x1080 60.00*+  50.0059.9430.0025.0024.00
> > 29.9723.98
> > +   1920x1080i60.0050.0059.94
> >  1600x1200 60.00
> >  1680x1050 59.88
> >  1280x1024 75.0260.02
> > @@ -13,30 +13,29 @@
> >  1360x768  60.02
> >  1280x800  59.91
> >  1152x864  75.00
> > -   1280x720  60.0050.00
> > +   1280x720  60.0050.0059.94
> >  1024x768  75.0370.0760.00
> >  832x624   74.55
> >  800x600   72.1975.0060.32
> > -   640x480   75.0072.8166.6759.94
> > +   720x576   50.00
> > +   720x480   60.0059.94
> > +   640x480   75.0072.8166.6760.0059.94
> >  720x400   70.08
> None of these aspect ratios are new modes / new aspect ratios from HDMI 
> 2.0/CEA-861-F
> These are the existing modes, and should be independent of reverted 
> patches.

They're affected because your patches changed them by adding the aspect
ratio flags to them.

> > This was with sna, which does this:
> >   #define KNOWN_MODE_FLAGS ((1<<14)-1)
> >   if (mode->status == MODE_OK && kmode->flags & ~KNOWN_MODE_FLAGS)
> > mode->status = MODE_BAD; /* unknown flags => unhandled */
> > so all the modes with an aspect ratio just vanished.
> >
> > -modesetting and -ati on the other hand just copy over the unknown
> > bits into the xrandr mode structure, which sounds dubious at best:
> >   mode->Flags = kmode->flags; //& FLAG_BITS;
> > I've not checked what damage it can actually cause.
> >
> >
> > It looks like a few modes disappeared from the kernel's mode list
> > as well, presumably because some cea modes in the list originated from
> > DTDs and whanot so they don't have an aspect ratio and that causes
> > add_alternate_cea_modes() to ignore them. So not populating an aspect
> > ratio for cea modes originating from a source other than
> > edid_cea_modes[] looks like another bug to me as well.
> I am writing a patch series to cap the aspect ratio implementation under 
> a drm_cap_hdmi2_aspect_ratios
> This is how its going to work (inspired from the 2D/stereo series from 
> damien L)
> 
> - Add a new capability hdmi2_ar

It should be just a generic "expose aspect ratio flags to userspace?"

> - by default parsing the new hdmi 2.0 aspect ratio will be disabled 
> under check of this cap
> - during bootup time, while initializing the display, a userspace can 
> get_cap on the hdmi2_aspect_ratio
> - If it wants HDMI 2.0 aspect ratio support, it will set the cap, and 
> kernel will expose these aspect ratios
> > Another bug I think might be the ordering of the modes with aspect ratio
> > specified. IIRC the spec says that the preferred aspect ratio should be
> > listed first in the EDID, but I don't think we preserve that ordering
> > in the final mode list. I guess we could fix that by somehow noting
> > which aspect ratio is preferred and sort based on that, or we try to
> > preserve the order from the EDID until we're ready to sort, and then do
> > the sorting with a stable algorithm.
> AFAIK The mode order and priority is decided and arranged in userspace, 
> based on various factors like
> - preferred mode.
> - previously applied mode in previous sessions (like for android tvs)
> - Bigger h/w vs better refresh rate ?
> - Xserver applies its own algorithms to decide which mode should be 
> shown first.

Xorg does sort on its own. But since it doesn't know anything about
aspect ratios and whatnot I wouldn't rely on that for anything. I
also wouldn't expect eg. wayland compositors to do their own sorting.
And yeah, looks like weston at least doesn't do any sorting whatsoever.

> 
> I dont think kernel needs to bother about it.

So I'm going to say that we in fact do need to bother.

-- 
Ville Syrjälä
Intel OTC

[Bug 98724] garbled output using glDrawElementsIndirect

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

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

Bug ID: 98724
   Summary: garbled output using glDrawElementsIndirect
   Product: Mesa
   Version: git
  Hardware: Other
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: logan at bacoosta.com
QA Contact: dri-devel at lists.freedesktop.org

I work on an N64 emulator (GLupeN64). I received a report from a user that they
had garbled output from the application. They tried it with llvmpipe and it
worked.

The issue report is here:
https://github.com/loganmc10/GLupeN64/issues/102

It includes and apitrace and a screenshot.

I had him disable indirect drawing, and in that mode the application will use
glDrawElementsBaseVertex instead of glDrawElementsIndirect. He said that that
fixed the issue, but it was very slow.

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

[PATCH] drm: don't let crtc_ww_class leak out

[Rob Clark]

kbuild spotted this error, with drm/msm patches that add a new
modeset-lock in the driver and driver built as a module:

  ERROR: "crtc_ww_class" [drivers/gpu/drm/msm/msm.ko] undefined!

Really the only reason for crtc_ww_class not being internal to
drm_modeset_lock.c is that drm_modeset_lock_init() was static-inline
(for no particularly good reason).

Fix that, and move crtc_ww_class into drm_modeset_lock.c.

Signed-off-by: Rob Clark 
---
This is an alternative to the "drm: export crtc_ww_class" patch.

 drivers/gpu/drm/drm_crtc.c |  2 --
 drivers/gpu/drm/drm_modeset_lock.c | 13 +
 include/drm/drm_modeset_lock.h | 12 +---
 3 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index cf2423d..5d994cc 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -102,8 +102,6 @@ int drm_crtc_force_disable_all(struct drm_device *dev)
 }
 EXPORT_SYMBOL(drm_crtc_force_disable_all);

-DEFINE_WW_CLASS(crtc_ww_class);
-
 static unsigned int drm_num_crtcs(struct drm_device *dev)
 {
unsigned int num = 0;
diff --git a/drivers/gpu/drm/drm_modeset_lock.c 
b/drivers/gpu/drm/drm_modeset_lock.c
index 61146f5..9059fe3 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -60,6 +60,8 @@
  *  lists and lookup data structures.
  */

+static DEFINE_WW_CLASS(crtc_ww_class);
+
 /**
  * drm_modeset_lock_all - take all modeset locks
  * @dev: DRM device
@@ -398,6 +400,17 @@ int drm_modeset_backoff_interruptible(struct 
drm_modeset_acquire_ctx *ctx)
 EXPORT_SYMBOL(drm_modeset_backoff_interruptible);

 /**
+ * drm_modeset_lock_init - initialize lock
+ * @lock: lock to init
+ */
+void drm_modeset_lock_init(struct drm_modeset_lock *lock)
+{
+   ww_mutex_init(>mutex, _ww_class);
+   INIT_LIST_HEAD(>head);
+}
+EXPORT_SYMBOL(drm_modeset_lock_init);
+
+/**
  * drm_modeset_lock - take modeset lock
  * @lock: lock to take
  * @ctx: acquire ctx
diff --git a/include/drm/drm_modeset_lock.h b/include/drm/drm_modeset_lock.h
index c5576fb..d918ce4 100644
--- a/include/drm/drm_modeset_lock.h
+++ b/include/drm/drm_modeset_lock.h
@@ -82,8 +82,6 @@ struct drm_modeset_lock {
struct list_head head;
 };

-extern struct ww_class crtc_ww_class;
-
 void drm_modeset_acquire_init(struct drm_modeset_acquire_ctx *ctx,
uint32_t flags);
 void drm_modeset_acquire_fini(struct drm_modeset_acquire_ctx *ctx);
@@ -91,15 +89,7 @@ void drm_modeset_drop_locks(struct drm_modeset_acquire_ctx 
*ctx);
 void drm_modeset_backoff(struct drm_modeset_acquire_ctx *ctx);
 int drm_modeset_backoff_interruptible(struct drm_modeset_acquire_ctx *ctx);

-/**
- * drm_modeset_lock_init - initialize lock
- * @lock: lock to init
- */
-static inline void drm_modeset_lock_init(struct drm_modeset_lock *lock)
-{
-   ww_mutex_init(>mutex, _ww_class);
-   INIT_LIST_HEAD(>head);
-}
+void drm_modeset_lock_init(struct drm_modeset_lock *lock);

 /**
  * drm_modeset_lock_fini - cleanup lock
-- 
2.7.4

[Intel-gfx] [PATCH] dma-buf: Replace reservation shared fence array with a compressed radix tree

[kbuild test robot]

Hi Chris,

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

url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/dma-buf-Replace-reservation-shared-fence-array-with-a-compressed-radix-tree/20161114-163437
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: x86_64-randconfig-x008-201646 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/qxl/qxl_debugfs.c: In function 'qxl_debugfs_buffers_info':
>> drivers/gpu/drm/qxl/qxl_debugfs.c:70:49: warning: format '%d' expects 
>> argument of type 'int', but argument 5 has type 'long unsigned int' 
>> [-Wformat=]
  seq_printf(m, "size %ld, pc %d, num releases %d\n",
^

vim +70 drivers/gpu/drm/qxl/qxl_debugfs.c

f64122c1 Dave Airlie   2013-02-25  54  qxl_debugfs_buffers_info(struct 
seq_file *m, void *data)
f64122c1 Dave Airlie   2013-02-25  55  {
f64122c1 Dave Airlie   2013-02-25  56   struct drm_info_node *node = 
(struct drm_info_node *) m->private;
f64122c1 Dave Airlie   2013-02-25  57   struct qxl_device *qdev = 
node->minor->dev->dev_private;
f64122c1 Dave Airlie   2013-02-25  58   struct qxl_bo *bo;
f64122c1 Dave Airlie   2013-02-25  59  
f64122c1 Dave Airlie   2013-02-25  60   list_for_each_entry(bo, 
>gem.objects, list) {
3c911823 Chris Wilson  2016-11-14  61   struct 
reservation_shared_iter iter;
3c911823 Chris Wilson  2016-11-14  62   unsigned long rel;
2f453ed4 Maarten Lankhorst 2014-04-02  63  
3c911823 Chris Wilson  2016-11-14  64   rel = 0;
2f453ed4 Maarten Lankhorst 2014-04-02  65   rcu_read_lock();
3c911823 Chris Wilson  2016-11-14  66   
reservation_object_for_each_shared(bo->tbo.resv, iter)
3c911823 Chris Wilson  2016-11-14  67   rel++;
2f453ed4 Maarten Lankhorst 2014-04-02  68   rcu_read_unlock();
2f453ed4 Maarten Lankhorst 2014-04-02  69  
f2c24b83 Maarten Lankhorst 2014-04-02 @70   seq_printf(m, "size 
%ld, pc %d, num releases %d\n",
f2c24b83 Maarten Lankhorst 2014-04-02  71  (unsigned 
long)bo->gem_base.size,
f2c24b83 Maarten Lankhorst 2014-04-02  72  
bo->pin_count, rel);
f64122c1 Dave Airlie   2013-02-25  73   }
f64122c1 Dave Airlie   2013-02-25  74   return 0;
f64122c1 Dave Airlie   2013-02-25  75  }
f64122c1 Dave Airlie   2013-02-25  76  
f64122c1 Dave Airlie   2013-02-25  77  static struct drm_info_list 
qxl_debugfs_list[] = {
f64122c1 Dave Airlie   2013-02-25  78   { "irq_received", 
qxl_debugfs_irq_received, 0, NULL },

:: The code at line 70 was first introduced by commit
:: f2c24b83ae90292d315aa7ac029c6ce7929e01aa drm/ttm: flip the switch, and 
convert to dma_fence

:: TO: Maarten Lankhorst 
:: CC: Maarten Lankhorst 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 26798 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161114/218b8e15/attachment-0001.gz>

[PATCH 0/5] Handle Link Training Failure during modeset

[Manasi Navare]

On Mon, Nov 14, 2016 at 08:07:39PM -0500, Harry Wentland wrote:
> Overall this patch set makes sense but I think it would be good to
> move some stuff to common code instead of leaving it in i915. I'm
> thinking about patch 2 (setting the link status property) in
> particular but also tend to agree with Ville and Daniel about their
> comments for patch 5.
> 
> That said, should another driver need it it shouldn't be hard to
> pull that out.
> 
> Patch 1: Reviewed-by: Harry Wentland 
> 
> Patch 2-5: Acked-by: Harry Wentland 
> 
> Harry
> 
>

Thanks for the review.
I am already moving Patch 2 set_link_status to the drm core as
per Daniel and Ville's suggestion. I will make those changes
and submit the new patches by EOD today.

Regards
Manasi

> On 2016-11-09 11:42 PM, Manasi Navare wrote:
> >Link training failure is handled by lowering the link rate first
> >until it reaches the minimum and keeping the lane count maximum
> >and then lowering the lane count until it reaches minimim. These
> >fallback values are saved and hotplug uevent is sent to the userspace
> >after setting the connector link status property to BAD. Userspace
> >should triiger another modeset on a uevent and if link status property
> >is BAD. This will retrain the link at fallback values.
> >This is repeated until the link is successfully trained.
> >
> >This has been validated to pass DP compliance.
> >
> >Manasi Navare (5):
> >   drm: Add a new connector property for link status
> >   drm/i915: Set link status property for DP connector
> >   drm/i915: Update CRTC state if connector link status property changed
> >   drm/i915: Find fallback link rate/lane count
> >   drm/i915: Implement Link Rate fallback on Link training failure
> >
> >  drivers/gpu/drm/drm_atomic_helper.c   |   7 ++
> >  drivers/gpu/drm/drm_connector.c   |  17 
> >  drivers/gpu/drm/i915/intel_ddi.c  |  21 +++-
> >  drivers/gpu/drm/i915/intel_dp.c   | 138 
> > +-
> >  drivers/gpu/drm/i915/intel_dp_link_training.c |  12 ++-
> >  drivers/gpu/drm/i915/intel_drv.h  |  12 ++-
> >  include/drm/drm_connector.h   |   7 +-
> >  include/drm/drm_crtc.h|   5 +
> >  include/uapi/drm/drm_mode.h   |   4 +
> >  9 files changed, 214 insertions(+), 9 deletions(-)
> >
> 

[Intel-gfx] [PATCH] dma-buf: Replace reservation shared fence array with a compressed radix tree

[kbuild test robot]

Hi Chris,

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

url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/dma-buf-Replace-reservation-shared-fence-array-with-a-compressed-radix-tree/20161114-163437
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: x86_64-randconfig-x009-201646 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All error/warnings (new ones prefixed by >>):

   drivers/gpu/drm/radeon/radeon_sync.c: In function 'radeon_sync_resv':
>> drivers/gpu/drm/radeon/radeon_sync.c:110:2: error: implicit declaration of 
>> function 'resevation_object_for_each_shared' 
>> [-Werror=implicit-function-declaration]
 resevation_object_for_each_shared(resv, iter) {
 ^
>> drivers/gpu/drm/radeon/radeon_sync.c:110:48: error: expected ';' before '{' 
>> token
 resevation_object_for_each_shared(resv, iter) {
   ^
>> drivers/gpu/drm/radeon/radeon_sync.c:121:1: warning: control reaches end of 
>> non-void function [-Wreturn-type]
}
^
   cc1: some warnings being treated as errors

vim +/resevation_object_for_each_shared +110 
drivers/gpu/drm/radeon/radeon_sync.c

   104  else if (f)
   105  r = dma_fence_wait(f, true);
   106  
   107  if (shared || !reservation_object_has_shared(resv) || r)
   108  return r;
   109  
 > 110  resevation_object_for_each_shared(resv, iter) {
   111  fence = to_radeon_fence(iter.fence);
   112  if (fence && fence->rdev == rdev)
   113  radeon_sync_fence(sync, fence);
   114  else
   115  r = dma_fence_wait(f, true);
   116  
   117  if (r)
   118  break;
   119  }
   120  return r;
 > 121  }
   122  
   123  /**
   124   * radeon_sync_rings - sync ring to all registered fences

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
-- next part --
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 30158 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161114/4119caa2/attachment-0001.gz>

[RFCv2 PATCH 2/5] drm/bridge: dw_hdmi: remove CEC engine register definitions

[Hans Verkuil]

You're CC-ed for all, so if you don't receive it in the next 15 minutes
let me know and I'll forward it to you. But my guess is that the mails were
delayed for some reason and that they simply haven't arrived yet.

Hans

On 11/14/2016 04:39 PM, Russell King - ARM Linux wrote:
> I can't comment on these, you've not included me in patch 1 nor the
> covering message.
> 
> On Mon, Nov 14, 2016 at 04:22:45PM +0100, Hans Verkuil wrote:
>> From: Russell King 
>>
>> We don't need the CEC engine register definitions, so let's remove them.
>>
>> Signed-off-by: Russell King 
>> ---
>>  drivers/gpu/drm/bridge/dw-hdmi.h | 45 
>> 
>>  1 file changed, 45 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.h 
>> b/drivers/gpu/drm/bridge/dw-hdmi.h
>> index fc9a560..26d6845 100644
>> --- a/drivers/gpu/drm/bridge/dw-hdmi.h
>> +++ b/drivers/gpu/drm/bridge/dw-hdmi.h
>> @@ -478,51 +478,6 @@
>>  #define HDMI_A_PRESETUP 0x501A
>>  #define HDMI_A_SRM_BASE 0x5020
>>  
>> -/* CEC Engine Registers */
>> -#define HDMI_CEC_CTRL   0x7D00
>> -#define HDMI_CEC_STAT   0x7D01
>> -#define HDMI_CEC_MASK   0x7D02
>> -#define HDMI_CEC_POLARITY   0x7D03
>> -#define HDMI_CEC_INT0x7D04
>> -#define HDMI_CEC_ADDR_L 0x7D05
>> -#define HDMI_CEC_ADDR_H 0x7D06
>> -#define HDMI_CEC_TX_CNT 0x7D07
>> -#define HDMI_CEC_RX_CNT 0x7D08
>> -#define HDMI_CEC_TX_DATA0   0x7D10
>> -#define HDMI_CEC_TX_DATA1   0x7D11
>> -#define HDMI_CEC_TX_DATA2   0x7D12
>> -#define HDMI_CEC_TX_DATA3   0x7D13
>> -#define HDMI_CEC_TX_DATA4   0x7D14
>> -#define HDMI_CEC_TX_DATA5   0x7D15
>> -#define HDMI_CEC_TX_DATA6   0x7D16
>> -#define HDMI_CEC_TX_DATA7   0x7D17
>> -#define HDMI_CEC_TX_DATA8   0x7D18
>> -#define HDMI_CEC_TX_DATA9   0x7D19
>> -#define HDMI_CEC_TX_DATA10  0x7D1a
>> -#define HDMI_CEC_TX_DATA11  0x7D1b
>> -#define HDMI_CEC_TX_DATA12  0x7D1c
>> -#define HDMI_CEC_TX_DATA13  0x7D1d
>> -#define HDMI_CEC_TX_DATA14  0x7D1e
>> -#define HDMI_CEC_TX_DATA15  0x7D1f
>> -#define HDMI_CEC_RX_DATA0   0x7D20
>> -#define HDMI_CEC_RX_DATA1   0x7D21
>> -#define HDMI_CEC_RX_DATA2   0x7D22
>> -#define HDMI_CEC_RX_DATA3   0x7D23
>> -#define HDMI_CEC_RX_DATA4   0x7D24
>> -#define HDMI_CEC_RX_DATA5   0x7D25
>> -#define HDMI_CEC_RX_DATA6   0x7D26
>> -#define HDMI_CEC_RX_DATA7   0x7D27
>> -#define HDMI_CEC_RX_DATA8   0x7D28
>> -#define HDMI_CEC_RX_DATA9   0x7D29
>> -#define HDMI_CEC_RX_DATA10  0x7D2a
>> -#define HDMI_CEC_RX_DATA11  0x7D2b
>> -#define HDMI_CEC_RX_DATA12  0x7D2c
>> -#define HDMI_CEC_RX_DATA13  0x7D2d
>> -#define HDMI_CEC_RX_DATA14  0x7D2e
>> -#define HDMI_CEC_RX_DATA15  0x7D2f
>> -#define HDMI_CEC_LOCK   0x7D30
>> -#define HDMI_CEC_WKUPCTRL   0x7D31
>> -
>>  /* I2C Master Registers (E-DDC) */
>>  #define HDMI_I2CM_SLAVE 0x7E00
>>  #define HDMI_I2CM_ADDRESS   0x7E01
>> -- 
>> 2.8.1
>>
>>
>> ___
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

[PATCH] dma-buf: Use fence_get_rcu_safe() for retrieving the exclusive fence

[Christian König]

Am 14.11.2016 um 12:55 schrieb Chris Wilson:
> The current code is subject to a race where we may try to acquire a
> reference on a stale fence:
>
> [13703.335118] WARNING: CPU: 1 PID: 14975 at ./include/linux/kref.h:46 
> i915_gem_object_wait+0x1a3/0x1c0
> [13703.335184] Modules linked in:
> [13703.335202] CPU: 1 PID: 14975 Comm: gem_concurrent_ Not tainted 4.9.0-rc4+ 
> #26
> [13703.335216] Hardware name:  /, BIOS 
> PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015
> [13703.335233]  c90002f5bcc8 812807de  
> 
> [13703.335257]  c90002f5bd08 81073811 002e8000 
> 88026bf7c780
> [13703.335279]  7fff 0001 88027045a550 
> 88026bf7c780
> [13703.335301] Call Trace:
> [13703.335316]  [] dump_stack+0x4d/0x6f
> [13703.335331]  [] __warn+0xc1/0xe0
> [13703.335343]  [] warn_slowpath_null+0x18/0x20
> [13703.335355]  [] i915_gem_object_wait+0x1a3/0x1c0
> [13703.335367]  [] i915_gem_set_domain_ioctl+0xcc/0x330
> [13703.335386]  [] drm_ioctl+0x1cb/0x410
> [13703.335400]  [] ? 
> i915_gem_obj_prepare_shmem_write+0x1d0/0x1d0
> [13703.335416]  [] ? drm_ioctl+0x2bb/0x410
> [13703.335429]  [] do_vfs_ioctl+0x8f/0x5c0
> [13703.335442]  [] SyS_ioctl+0x3c/0x70
> [13703.335456]  [] entry_SYSCALL_64_fastpath+0x17/0x98
> [13703.335558] ---[ end trace fd24176416ba6981 ]---
> [13703.382778] general protection fault:  [#1] SMP
> [13703.382802] Modules linked in:
> [13703.382816] CPU: 1 PID: 14967 Comm: gem_concurrent_ Tainted: GW
>4.9.0-rc4+ #26
> [13703.382828] Hardware name:  /, BIOS 
> PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015
> [13703.382841] task: 880275458000 task.stack: c90002f18000
> [13703.382849] RIP: 0010:[]  [] 
> i915_gem_request_retire+0x2b4/0x320
> [13703.382870] RSP: 0018:c90002f1bbc8  EFLAGS: 00010293
> [13703.382878] RAX: dead0200 RBX: 88026bf7dce8 RCX: 
> dead0100
> [13703.382887] RDX: dead0100 RSI: 88026bf7c930 RDI: 
> 88026bf7dd00
> [13703.382897] RBP: c90002f1bbf8 R08:  R09: 
> 88026b89a000
> [13703.382905] R10: 0001 R11: 88026bbe8fe0 R12: 
> 88026bf7c000
> [13703.382913] R13: 880275af8000 R14: 88026bf7c180 R15: 
> dead0200
> [13703.382922] FS:  7f89e787d740() GS:88027fd0() 
> knlGS:
> [13703.382934] CS:  0010 DS:  ES:  CR0: 80050033
> [13703.382942] CR2: 7f9053d2e000 CR3: 00026d414000 CR4: 
> 001006e0
> [13703.382951] Stack:
> [13703.382958]  880275413000 c90002f1bde8 880275af8000 
> 880274e8a600
> [13703.382976]  880276a06000 c90002f1bde8 c90002f1bc38 
> 813b48c5
> [13703.382995]  c90002f1bc00 c90002f1bde8 88026972a440 
> 
> [13703.383021] Call Trace:
> [13703.383032]  [] i915_gem_request_alloc+0xa5/0x350
> [13703.383043]  [] 
> i915_gem_do_execbuffer.isra.41+0x7b3/0x18b0
> [13703.383055]  [] ? i915_gem_object_get_sg+0x25c/0x2b0
> [13703.383065]  [] ? i915_gem_object_get_page+0x1d/0x50
> [13703.383076]  [] ? i915_gem_pwrite_ioctl+0x66c/0x6d0
> [13703.383086]  [] i915_gem_execbuffer2+0x95/0x1e0
> [13703.383096]  [] drm_ioctl+0x1cb/0x410
> [13703.383105]  [] ? i915_gem_execbuffer+0x2d0/0x2d0
> [13703.383117]  [] ? hrtimer_start_range_ns+0x1a0/0x310
> [13703.383128]  [] do_vfs_ioctl+0x8f/0x5c0
> [13703.383140]  [] ? SyS_timer_settime+0x118/0x1a0
> [13703.383150]  [] SyS_ioctl+0x3c/0x70
> [13703.383162]  [] entry_SYSCALL_64_fastpath+0x17/0x98
> [13703.383172] Code: 49 39 c6 48 8d 70 e8 48 8d 5f e8 75 16 eb 47 48 8d 43 18 
> 48 8b 53 18 48 89 de 49 39 c6 48 8d 5a e8 74 33 48 8b 56 08 48 8b 46 10 <48> 
> 89 42 08 48 89 10 f6 46 38 01 48 89 4e 08 4c 89 7e 10 74 cf
> [13703.383557] RIP  [] i915_gem_request_retire+0x2b4/0x320
> [13703.383570]  RSP 
> [13703.383586] ---[ end trace fd24176416ba6982 ]---
>
> This is fixed by using the kref_get_unless_zero() as a full memory
> barrier to validate the fence is still the current exclusive fence before
> returning it back to the caller. (Note the fix only requires using
> dma_fence_get_rcu() and correct handling, but we may as well use the
> helper rather than inline equivalent code.)
>
> Signed-off-by: Chris Wilson 
> Cc: Sumit Semwal .

> ---
>   include/linux/reservation.h | 15 ++-
>   1 file changed, 6 insertions(+), 9 deletions(-)
>
> diff --git a/include/linux/reservation.h b/include/linux/reservation.h
> index 2e313cca08f0..d9706a6f5ae2 100644
> --- a/include/linux/reservation.h
> +++ b/include/linux/reservation.h
> @@ -177,17 +177,14 @@ static inline struct dma_fence *
>   reservation_object_get_excl_rcu(struct reservation_object *obj)
>   {
>   struct dma_fence *fence;
> - unsigned seq;
> -retry:
> - seq = read_seqcount_begin(>seq);
> +
> + if (!rcu_access_pointer(obj->fence_excl))
> + return NULL;
> +
>   rcu_read_lock();
> -  

[RFCv2 PATCH 5/5] drm/i2c: add tda998x/tda9950 CEC driver

[Hans Verkuil]

From: Russell King 

Add a CEC driver for the TDA9950, which is a stand-alone I2C CEC device.
The TDA9950 contains a command processor which handles retransmissions
and the low level bus protocol.  The driver just has to read and write
the messages, and handle error conditions.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/i2c/Kconfig   |   5 +
 drivers/gpu/drm/i2c/Makefile  |   1 +
 drivers/gpu/drm/i2c/tda9950.c | 516 ++
 include/linux/platform_data/tda9950.h |  15 +
 4 files changed, 537 insertions(+)
 create mode 100644 drivers/gpu/drm/i2c/tda9950.c
 create mode 100644 include/linux/platform_data/tda9950.h

diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
index a6c92be..b30ea3b 100644
--- a/drivers/gpu/drm/i2c/Kconfig
+++ b/drivers/gpu/drm/i2c/Kconfig
@@ -26,4 +26,9 @@ config DRM_I2C_NXP_TDA998X
help
  Support for NXP Semiconductors TDA998X HDMI encoders.

+config DRM_I2C_NXP_TDA9950
+   tristate "NXP Semiconductors TDA9950/TDA998X HDMI CEC"
+   depends on MEDIA_CEC_SUPPORT
+   select HDMI_NOTIFIERS
+
 endmenu
diff --git a/drivers/gpu/drm/i2c/Makefile b/drivers/gpu/drm/i2c/Makefile
index 43aa33b..8a6e13e 100644
--- a/drivers/gpu/drm/i2c/Makefile
+++ b/drivers/gpu/drm/i2c/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_DRM_I2C_SIL164) += sil164.o

 tda998x-y := tda998x_drv.o
 obj-$(CONFIG_DRM_I2C_NXP_TDA998X) += tda998x.o
+obj-$(CONFIG_DRM_I2C_NXP_TDA9950) += tda9950.o
diff --git a/drivers/gpu/drm/i2c/tda9950.c b/drivers/gpu/drm/i2c/tda9950.c
new file mode 100644
index 000..601da7c
--- /dev/null
+++ b/drivers/gpu/drm/i2c/tda9950.c
@@ -0,0 +1,516 @@
+/*
+ *  TDA9950 Consumer Electronics Control driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * The NXP TDA9950 implements the HDMI Consumer Electronics Control
+ * interface.  The host interface is similar to a mailbox: the data
+ * registers starting at REG_CDR0 are written to send a command to the
+ * internal CPU, and replies are read from these registers.
+ *
+ * As the data registers represent a mailbox, they must be accessed
+ * as a single I2C transaction.  See the TDA9950 data sheet for details.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+enum {
+   REG_CSR = 0x00,
+   CSR_BUSY = BIT(7),
+   CSR_INT  = BIT(6),
+   CSR_ERR  = BIT(5),
+
+   REG_CER = 0x01,
+
+   REG_CVR = 0x02,
+
+   REG_CCR = 0x03,
+   CCR_RESET = BIT(7),
+   CCR_ON= BIT(6),
+
+   REG_ACKH = 0x04,
+   REG_ACKL = 0x05,
+
+   REG_CCONR = 0x06,
+   CCONR_ENABLE_ERROR = BIT(4),
+
+   REG_CDR0 = 0x07,
+
+   CDR1_REQ = 0x00,
+   CDR1_CNF = 0x01,
+   CDR1_IND = 0x81,
+   CDR1_ERR = 0x82,
+   CDR1_IER = 0x83,
+
+   CDR2_CNF_SUCCESS= 0x00,
+   CDR2_CNF_OFF_STATE  = 0x80,
+   CDR2_CNF_BAD_REQ= 0x81,
+   CDR2_CNF_CEC_ACCESS = 0x82,
+   CDR2_CNF_ARB_ERROR  = 0x83,
+   CDR2_CNF_BAD_TIMING = 0x84,
+   CDR2_CNF_NACK_ADDR  = 0x85,
+   CDR2_CNF_NACK_DATA  = 0x86,
+};
+
+struct tda9950_priv {
+   struct i2c_client *client;
+   struct device *hdmi;
+   struct cec_adapter *adap;
+   struct tda9950_glue *glue;
+   u16 addresses;
+   struct cec_msg rx_msg;
+   struct hdmi_notifier *n;
+   struct notifier_block nb;
+   bool open;
+};
+
+static int tda9950_write_range(struct i2c_client *client, u8 addr, u8 *p, int 
cnt)
+{
+   struct i2c_msg msg;
+   u8 buf[cnt + 1];
+   int ret;
+
+   buf[0] = addr;
+   memcpy(buf + 1, p, cnt);
+
+   msg.addr = client->addr;
+   msg.flags = 0;
+   msg.len = cnt + 1;
+   msg.buf = buf;
+
+   dev_dbg(>dev, "wr 0x%02x: %*ph\n", addr, cnt, p);
+
+   ret = i2c_transfer(client->adapter, , 1);
+   if (ret < 0)
+   dev_err(>dev, "Error %d writing to cec:0x%x\n", ret, 
addr);
+   return ret < 0 ? ret : 0;
+}
+
+static void tda9950_write(struct i2c_client *client, u8 addr, u8 val)
+{
+   tda9950_write_range(client, addr, , 1);
+}
+
+static int tda9950_read_range(struct i2c_client *client, u8 addr, u8 *p, int 
cnt)
+{
+   struct i2c_msg msg[2];
+   int ret;
+
+   msg[0].addr = client->addr;
+   msg[0].flags = 0;
+   msg[0].len = 1;
+   msg[0].buf = 
+   msg[1].addr = client->addr;
+   msg[1].flags = I2C_M_RD;
+   msg[1].len = cnt;
+   msg[1].buf = p;
+
+   ret = i2c_transfer(client->adapter, msg, 2);
+   if (ret < 0)
+   dev_err(>dev, "Error %d reading from cec:0x%x\n", ret, 
addr);
+
+   dev_dbg(>dev, "rd 0x%02x: %*ph\n", addr, cnt, p);
+
+   return ret;
+}
+
+static u8 tda9950_read(struct i2c_client 

[RFCv2 PATCH 4/5] drm/bridge: add dw-hdmi cec driver using Hans Verkuil's CEC code

[Hans Verkuil]

From: Russell King 

Add a CEC driver for the dw-hdmi hardware using Hans Verkuil's CEC
implementation.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/bridge/Kconfig|   7 +
 drivers/gpu/drm/bridge/Makefile   |   1 +
 drivers/gpu/drm/bridge/dw-hdmi-cec.c  | 346 ++
 drivers/gpu/drm/bridge/dw-hdmi.c  |  64 +-
 include/linux/platform_data/dw_hdmi-cec.h |  16 ++
 5 files changed, 423 insertions(+), 11 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/dw-hdmi-cec.c
 create mode 100644 include/linux/platform_data/dw_hdmi-cec.h

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 5f4ebe9..4ab137e 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -40,6 +40,13 @@ config DRM_DW_HDMI_AHB_AUDIO
  Designware HDMI block.  This is used in conjunction with
  the i.MX6 HDMI driver.

+config DRM_DW_HDMI_CEC
+   tristate "Synopsis Designware CEC interface"
+   depends on DRM_DW_HDMI && MEDIA_CEC_SUPPORT
+   help
+ Support the CE interface which is part of the Synopsis
+ Designware HDMI block.
+
 config DRM_NXP_PTN3460
tristate "NXP PTN3460 DP/LVDS bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index cdf3a3c..6bdd8b9 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
 obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
 obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
+obj-$(CONFIG_DRM_DW_HDMI_CEC) += dw-hdmi-cec.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
 obj-$(CONFIG_DRM_SII902X) += sii902x.o
diff --git a/drivers/gpu/drm/bridge/dw-hdmi-cec.c 
b/drivers/gpu/drm/bridge/dw-hdmi-cec.c
new file mode 100644
index 000..e7e12b5
--- /dev/null
+++ b/drivers/gpu/drm/bridge/dw-hdmi-cec.c
@@ -0,0 +1,346 @@
+/* http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/
+ * tree/drivers/mxc/hdmi-cec/mxc_hdmi-cec.c?h=imx_3.0.35_4.1.0 */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+
+#define DEV_NAME "mxc_hdmi_cec"
+
+enum {
+   HDMI_IH_CEC_STAT0   = 0x0106,
+   HDMI_IH_MUTE_CEC_STAT0  = 0x0186,
+
+   HDMI_CEC_CTRL   = 0x7d00,
+   CEC_CTRL_START  = BIT(0),
+   CEC_CTRL_NORMAL = 1 << 1,
+
+   HDMI_CEC_STAT   = 0x7d01,
+   CEC_STAT_DONE   = BIT(0),
+   CEC_STAT_EOM= BIT(1),
+   CEC_STAT_NACK   = BIT(2),
+   CEC_STAT_ARBLOST= BIT(3),
+   CEC_STAT_ERROR_INIT = BIT(4),
+   CEC_STAT_ERROR_FOLL = BIT(5),
+   CEC_STAT_WAKEUP = BIT(6),
+
+   HDMI_CEC_MASK   = 0x7d02,
+   HDMI_CEC_POLARITY   = 0x7d03,
+   HDMI_CEC_INT= 0x7d04,
+   HDMI_CEC_ADDR_L = 0x7d05,
+   HDMI_CEC_ADDR_H = 0x7d06,
+   HDMI_CEC_TX_CNT = 0x7d07,
+   HDMI_CEC_RX_CNT = 0x7d08,
+   HDMI_CEC_TX_DATA0   = 0x7d10,
+   HDMI_CEC_RX_DATA0   = 0x7d20,
+   HDMI_CEC_LOCK   = 0x7d30,
+   HDMI_CEC_WKUPCTRL   = 0x7d31,
+};
+
+struct dw_hdmi_cec {
+   void __iomem *base;
+   u32 addresses;
+   struct cec_adapter *adap;
+   struct cec_msg rx_msg;
+   unsigned int tx_status;
+   bool tx_done;
+   bool rx_done;
+   const struct dw_hdmi_cec_ops *ops;
+   void *ops_data;
+   int retries;
+   int irq;
+   struct hdmi_notifier *n;
+   struct notifier_block nb;
+};
+
+static int dw_hdmi_cec_log_addr(struct cec_adapter *adap, u8 logical_addr)
+{
+   struct dw_hdmi_cec *cec = adap->priv;
+   u32 addresses;
+
+   if (logical_addr == CEC_LOG_ADDR_INVALID)
+   addresses = cec->addresses = BIT(15);
+   else
+   addresses = cec->addresses |= BIT(logical_addr);
+
+   writeb_relaxed(addresses & 255, cec->base + HDMI_CEC_ADDR_L);
+   writeb_relaxed(addresses >> 8, cec->base + HDMI_CEC_ADDR_H);
+
+   return 0;
+}
+
+static int dw_hdmi_cec_transmit(struct cec_adapter *adap, u8 attempts,
+   u32 signal_free_time, struct cec_msg *msg)
+{
+   struct dw_hdmi_cec *cec = adap->priv;
+   unsigned i;
+
+   cec->retries = attempts;
+
+   for (i = 0; i < msg->len; i++)
+   writeb_relaxed(msg->msg[i], cec->base + HDMI_CEC_TX_DATA0 + i);
+
+   writeb_relaxed(msg->len, cec->base + HDMI_CEC_TX_CNT);
+   writeb_relaxed(CEC_CTRL_NORMAL | CEC_CTRL_START, cec->base + 
HDMI_CEC_CTRL);
+
+   return 0;
+}
+
+static irqreturn_t dw_hdmi_cec_hardirq(int irq, void *data)
+{
+   struct cec_adapter *adap 

[RFCv2 PATCH 3/5] drm/bridge: dw_hdmi: add HDMI notifier support

[Hans Verkuil]

From: Russell King 

Add HDMI notifiers to the HDMI bridge driver.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/bridge/Kconfig   |  1 +
 drivers/gpu/drm/bridge/dw-hdmi.c | 25 -
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 10e12e7..5f4ebe9 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -27,6 +27,7 @@ config DRM_DUMB_VGA_DAC
 config DRM_DW_HDMI
tristate
select DRM_KMS_HELPER
+   select HDMI_NOTIFIERS

 config DRM_DW_HDMI_AHB_AUDIO
tristate "Synopsis Designware AHB Audio interface"
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index ab7023e..bd02da5 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -114,6 +115,7 @@ struct dw_hdmi {

struct hdmi_data_info hdmi_data;
const struct dw_hdmi_plat_data *plat_data;
+   struct hdmi_notifier *n;

int vic;

@@ -1448,9 +1450,11 @@ static int dw_hdmi_connector_get_modes(struct 
drm_connector *connector)
hdmi->sink_is_hdmi = drm_detect_hdmi_monitor(edid);
hdmi->sink_has_audio = drm_detect_monitor_audio(edid);
drm_mode_connector_update_edid_property(connector, edid);
+   hdmi_event_new_edid(hdmi->n, edid, 0);
ret = drm_add_edid_modes(connector, edid);
/* Store the ELD */
drm_edid_to_eld(connector, edid);
+   hdmi_event_new_eld(hdmi->n, connector->eld);
kfree(edid);
} else {
dev_dbg(hdmi->dev, "failed to get edid\n");
@@ -1579,6 +1583,12 @@ static irqreturn_t dw_hdmi_irq(int irq, void *dev_id)
dw_hdmi_update_phy_mask(hdmi);
}
mutex_unlock(>mutex);
+
+   if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) == 0)
+   hdmi_event_disconnect(hdmi->n);
+   else if ((phy_stat & (HDMI_PHY_RX_SENSE | HDMI_PHY_HPD)) ==
+(HDMI_IH_PHY_STAT0_RX_SENSE | HDMI_PHY_HPD))
+   hdmi_event_connect(hdmi->n);
}

if (intr_stat & HDMI_IH_PHY_STAT0_HPD) {
@@ -1732,11 +1742,17 @@ int dw_hdmi_bind(struct device *dev, struct device 
*master,

initialize_hdmi_ih_mutes(hdmi);

+   hdmi->n = hdmi_notifier_get(dev);
+   if (!hdmi->n) {
+   ret = -ENOMEM;
+   goto err_iahb;
+   }
+
ret = devm_request_threaded_irq(dev, irq, dw_hdmi_hardirq,
dw_hdmi_irq, IRQF_SHARED,
dev_name(dev), hdmi);
if (ret)
-   goto err_iahb;
+   goto err_hdmi_not;

/*
 * To prevent overflows in HDMI_IH_FC_STAT2, set the clk regenerator
@@ -1788,6 +1804,8 @@ int dw_hdmi_bind(struct device *dev, struct device 
*master,

return 0;

+err_hdmi_not:
+   hdmi_notifier_put(hdmi->n);
 err_iahb:
clk_disable_unprepare(hdmi->iahb_clk);
 err_isfr:
@@ -1804,6 +1822,11 @@ void dw_hdmi_unbind(struct device *dev, struct device 
*master, void *data)
if (hdmi->audio && !IS_ERR(hdmi->audio))
platform_device_unregister(hdmi->audio);

+   hdmi_notifier_put(hdmi->n);
+
+   if (!IS_ERR(hdmi->cec))
+   platform_device_unregister(hdmi->cec);
+
/* Disable all interrupts */
hdmi_writeb(hdmi, ~0, HDMI_IH_MUTE_PHY_STAT0);

-- 
2.8.1

[RFCv2 PATCH 2/5] drm/bridge: dw_hdmi: remove CEC engine register definitions

[Hans Verkuil]

From: Russell King 

We don't need the CEC engine register definitions, so let's remove them.

Signed-off-by: Russell King 
---
 drivers/gpu/drm/bridge/dw-hdmi.h | 45 
 1 file changed, 45 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.h b/drivers/gpu/drm/bridge/dw-hdmi.h
index fc9a560..26d6845 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.h
+++ b/drivers/gpu/drm/bridge/dw-hdmi.h
@@ -478,51 +478,6 @@
 #define HDMI_A_PRESETUP 0x501A
 #define HDMI_A_SRM_BASE 0x5020

-/* CEC Engine Registers */
-#define HDMI_CEC_CTRL   0x7D00
-#define HDMI_CEC_STAT   0x7D01
-#define HDMI_CEC_MASK   0x7D02
-#define HDMI_CEC_POLARITY   0x7D03
-#define HDMI_CEC_INT0x7D04
-#define HDMI_CEC_ADDR_L 0x7D05
-#define HDMI_CEC_ADDR_H 0x7D06
-#define HDMI_CEC_TX_CNT 0x7D07
-#define HDMI_CEC_RX_CNT 0x7D08
-#define HDMI_CEC_TX_DATA0   0x7D10
-#define HDMI_CEC_TX_DATA1   0x7D11
-#define HDMI_CEC_TX_DATA2   0x7D12
-#define HDMI_CEC_TX_DATA3   0x7D13
-#define HDMI_CEC_TX_DATA4   0x7D14
-#define HDMI_CEC_TX_DATA5   0x7D15
-#define HDMI_CEC_TX_DATA6   0x7D16
-#define HDMI_CEC_TX_DATA7   0x7D17
-#define HDMI_CEC_TX_DATA8   0x7D18
-#define HDMI_CEC_TX_DATA9   0x7D19
-#define HDMI_CEC_TX_DATA10  0x7D1a
-#define HDMI_CEC_TX_DATA11  0x7D1b
-#define HDMI_CEC_TX_DATA12  0x7D1c
-#define HDMI_CEC_TX_DATA13  0x7D1d
-#define HDMI_CEC_TX_DATA14  0x7D1e
-#define HDMI_CEC_TX_DATA15  0x7D1f
-#define HDMI_CEC_RX_DATA0   0x7D20
-#define HDMI_CEC_RX_DATA1   0x7D21
-#define HDMI_CEC_RX_DATA2   0x7D22
-#define HDMI_CEC_RX_DATA3   0x7D23
-#define HDMI_CEC_RX_DATA4   0x7D24
-#define HDMI_CEC_RX_DATA5   0x7D25
-#define HDMI_CEC_RX_DATA6   0x7D26
-#define HDMI_CEC_RX_DATA7   0x7D27
-#define HDMI_CEC_RX_DATA8   0x7D28
-#define HDMI_CEC_RX_DATA9   0x7D29
-#define HDMI_CEC_RX_DATA10  0x7D2a
-#define HDMI_CEC_RX_DATA11  0x7D2b
-#define HDMI_CEC_RX_DATA12  0x7D2c
-#define HDMI_CEC_RX_DATA13  0x7D2d
-#define HDMI_CEC_RX_DATA14  0x7D2e
-#define HDMI_CEC_RX_DATA15  0x7D2f
-#define HDMI_CEC_LOCK   0x7D30
-#define HDMI_CEC_WKUPCTRL   0x7D31
-
 /* I2C Master Registers (E-DDC) */
 #define HDMI_I2CM_SLAVE 0x7E00
 #define HDMI_I2CM_ADDRESS   0x7E01
-- 
2.8.1

[RFCv2 PATCH 1/5] video: add HDMI state notifier support

[Hans Verkuil]

From: Hans Verkuil 

Add support for HDMI hotplug and EDID notifiers, which is used to convey
information from HDMI drivers to their CEC and audio counterparts.

Based on an earlier version from Russell King:

https://patchwork.kernel.org/patch/9277043/

The hdmi_notifier is a reference counted object containing the HDMI state
of an HDMI device.

When a new notifier is registered the current state will be reported to
that notifier at registration time.

Signed-off-by: Hans Verkuil 
---
 drivers/video/Kconfig |   3 +
 drivers/video/Makefile|   1 +
 drivers/video/hdmi-notifier.c | 136 ++
 include/linux/hdmi-notifier.h |  43 +
 4 files changed, 183 insertions(+)
 create mode 100644 drivers/video/hdmi-notifier.c
 create mode 100644 include/linux/hdmi-notifier.h

diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index 3c20af9..1ee7b9f 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -36,6 +36,9 @@ config VIDEOMODE_HELPERS
 config HDMI
bool

+config HDMI_NOTIFIERS
+   bool
+
 if VT
source "drivers/video/console/Kconfig"
 endif
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 9ad3c17..65f5649 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -1,5 +1,6 @@
 obj-$(CONFIG_VGASTATE)+= vgastate.o
 obj-$(CONFIG_HDMI)+= hdmi.o
+obj-$(CONFIG_HDMI_NOTIFIERS)  += hdmi-notifier.o

 obj-$(CONFIG_VT) += console/
 obj-$(CONFIG_LOGO)   += logo/
diff --git a/drivers/video/hdmi-notifier.c b/drivers/video/hdmi-notifier.c
new file mode 100644
index 000..c2a4f1b
--- /dev/null
+++ b/drivers/video/hdmi-notifier.c
@@ -0,0 +1,136 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct hdmi_notifiers {
+   struct list_head head;
+   struct device *dev;
+   struct hdmi_notifier *n;
+};
+
+static LIST_HEAD(hdmi_notifiers);
+static DEFINE_MUTEX(hdmi_notifiers_lock);
+
+struct hdmi_notifier *hdmi_notifier_get(struct device *dev)
+{
+   struct hdmi_notifier *n;
+
+   mutex_lock(_notifiers_lock);
+   list_for_each_entry(n, _notifiers, head) {
+   if (n->dev == dev) {
+   mutex_unlock(_notifiers_lock);
+   kref_get(>kref);
+   return n;
+   }
+   }
+   n = kzalloc(sizeof(*n), GFP_KERNEL);
+   if (!n)
+   goto unlock;
+   mutex_init(>lock);
+   BLOCKING_INIT_NOTIFIER_HEAD(>notifiers);
+   kref_init(>kref);
+   list_add_tail(>head, _notifiers);
+unlock:
+   mutex_unlock(_notifiers_lock);
+   return n;
+}
+EXPORT_SYMBOL_GPL(hdmi_notifier_get);
+
+static void hdmi_notifier_release(struct kref *kref)
+{
+   struct hdmi_notifier *n =
+   container_of(kref, struct hdmi_notifier, kref);
+
+   kfree(n->edid);
+   kfree(n);
+}
+
+void hdmi_notifier_put(struct hdmi_notifier *n)
+{
+   kref_put(>kref, hdmi_notifier_release);
+}
+EXPORT_SYMBOL_GPL(hdmi_notifier_put);
+
+int hdmi_notifier_register(struct hdmi_notifier *n, struct notifier_block *nb)
+{
+   int ret = blocking_notifier_chain_register(>notifiers, nb);
+
+   if (ret)
+   return ret;
+   kref_get(>kref);
+   mutex_lock(>lock);
+   if (n->connected) {
+   blocking_notifier_call_chain(>notifiers, HDMI_CONNECTED, n);
+   if (n->edid_size)
+   blocking_notifier_call_chain(>notifiers, 
HDMI_NEW_EDID, n);
+   if (n->has_eld)
+   blocking_notifier_call_chain(>notifiers, 
HDMI_NEW_ELD, n);
+   }
+   mutex_unlock(>lock);
+   return 0;
+}
+EXPORT_SYMBOL_GPL(hdmi_notifier_register);
+
+int hdmi_notifier_unregister(struct hdmi_notifier *n, struct notifier_block 
*nb)
+{
+   int ret = blocking_notifier_chain_unregister(>notifiers, nb);
+
+   if (ret == 0)
+   hdmi_notifier_put(n);
+   return ret;
+}
+EXPORT_SYMBOL_GPL(hdmi_notifier_unregister);
+
+void hdmi_event_connect(struct hdmi_notifier *n)
+{
+   mutex_lock(>lock);
+   n->connected = true;
+   blocking_notifier_call_chain(>notifiers, HDMI_CONNECTED, n);
+   mutex_unlock(>lock);
+}
+EXPORT_SYMBOL_GPL(hdmi_event_connect);
+
+void hdmi_event_disconnect(struct hdmi_notifier *n)
+{
+   mutex_lock(>lock);
+   n->connected = false;
+   n->has_eld = false;
+   n->edid_size = 0;
+   blocking_notifier_call_chain(>notifiers, HDMI_DISCONNECTED, n);
+   mutex_unlock(>lock);
+}
+EXPORT_SYMBOL_GPL(hdmi_event_disconnect);
+
+int hdmi_event_new_edid(struct hdmi_notifier *n, const void *edid, size_t size)
+{
+   mutex_lock(>lock);
+   if (n->edid_allocated_size < size) {
+   void *p = kmalloc(size, GFP_KERNEL);
+
+   if (p == NULL) {
+   mutex_unlock(>lock);
+   return -ENOMEM;
+   }

[RFCv2 PATCH 0/5] CEC drivers for iMX6 and TDA9950

[Hans Verkuil]

From: Hans Verkuil 

This patch series is an update to this RFC series from Russell:

https://lists.freedesktop.org/archives/dri-devel/2016-August/115733.html

I have not seen any updates to this, so I hope that that series is still
the latest version.

The main problem with that original series was that the notifier didn't
store the state, so if a CEC driver registered with the notifier, then
it wouldn't be informed of the current state.

The hdmi-notifier code has been changed to a per-HDMI-device and refcounted
block_notifier that stores the state and will report the current state
upon registration.

The other four patches have been adapted to the new notifier code, but
no other changes were made.

It has *only* been compile-tested. I might be able to verify it next week
with an actual i.MX6 device, but it will take time to set that up.

If someone has a ready-to-test setup, then I would very much appreciate
it if this series can be tested.

The patches are also available in my branch:

https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=cec-notifiers

It is on top of my patch series that moves CEC out of staging. This
is planned for 4.10.

Regards,

Hans

Hans Verkuil (1):
  video: add HDMI state notifier support

Russell King (4):
  drm/bridge: dw_hdmi: remove CEC engine register definitions
  drm/bridge: dw_hdmi: add HDMI notifier support
  drm/bridge: add dw-hdmi cec driver using Hans Verkuil's CEC code
  drm/i2c: add tda998x/tda9950 CEC driver

 drivers/gpu/drm/bridge/Kconfig|   8 +
 drivers/gpu/drm/bridge/Makefile   |   1 +
 drivers/gpu/drm/bridge/dw-hdmi-cec.c  | 346 
 drivers/gpu/drm/bridge/dw-hdmi.c  |  89 +-
 drivers/gpu/drm/bridge/dw-hdmi.h  |  45 ---
 drivers/gpu/drm/i2c/Kconfig   |   5 +
 drivers/gpu/drm/i2c/Makefile  |   1 +
 drivers/gpu/drm/i2c/tda9950.c | 516 ++
 drivers/video/Kconfig |   3 +
 drivers/video/Makefile|   1 +
 drivers/video/hdmi-notifier.c | 136 
 include/linux/hdmi-notifier.h |  43 +++
 include/linux/platform_data/dw_hdmi-cec.h |  16 +
 include/linux/platform_data/tda9950.h |  15 +
 14 files changed, 1168 insertions(+), 57 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/dw-hdmi-cec.c
 create mode 100644 drivers/gpu/drm/i2c/tda9950.c
 create mode 100644 drivers/video/hdmi-notifier.c
 create mode 100644 include/linux/hdmi-notifier.h
 create mode 100644 include/linux/platform_data/dw_hdmi-cec.h
 create mode 100644 include/linux/platform_data/tda9950.h

-- 
2.8.1

[PATCH 00/10] Renesas R8A7795/Salvator-X HDMI output

[Ulrich Hecht]

On Mon, Nov 14, 2016 at 11:16 AM, Geert Uytterhoeven
 wrote:
> Hi Uli,
>
> On Fri, Nov 11, 2016 at 6:07 PM, Ulrich Hecht
>  wrote:
>> This implements HDMI output support for the Renesas R8A7795 (H3) SoC and
>> Salvator-X board.  It is based on mainline v4.9-rc4 and depends on Geert's
>> "[PATCH v2 0/7] soc: renesas: Identify SoC and register with the SoC bus"
>> series.
[...]
> Is this safe to add to next renesas-drivers release?

I think it is.

CU
Uli

[Bug 98170] [vdpau] Error when calling vdp_output_surface_create

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

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

--- Comment #8 from Branko  ---
FIXED In mesa-13.0.1.

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

[Bug 98170] [vdpau] Error when calling vdp_output_surface_create

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

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

Branko  changed:

   What|Removed |Added

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

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

[PATCH v9 00/10] MT2701 DRM support

[Bibby Hsieh]

Hi, YT

On Fri, 2016-11-11 at 19:55 +0800, YT Shen wrote:
> This is MT2701 DRM support PATCH v9, based on 4.9-rc1.
> We add DSI interrupt control, transfer function for MIPI DSI panel support.
> Most codes are the same, except some register changed.
> 
> For example:
>  - DISP_OVL address offset changed, color format definition changed.
>  - DISP_RDMA fifo size changed.
>  - DISP_COLOR offset changed.
>  - MIPI_TX setting changed.
> 
> We add a new component DDP_COMPONENT_BLS, and the connections are updated.
> OVL -> RDMA -> COLOR -> BLS -> DSI
> RDMA -> DPI
> And we have shadow register support in MT2701.
> 
> We remove dts patch from the patch series, which depends on MT2701 CCF and 
> scpsys.
> 

I test this series on MT8173 platform, it looks pretty good to me,
thanks for your patches.

Tested-by: Bibby Hsieh 

> Changes since v8:
> - enable 3 DSI interrupts only
> - move mtk_dsi_wait_for_irq_done() to the patch of irq control
> - use the name BLS in DRM driver part
> - move BLS declaration to a separate patch
> - update mtk_dsi_switch_to_cmd_mode()
> - update mtk_output_dsi_enable() and mtk_output_dsi_disable()
> 
> Changes since v7:
> - Remove redundant codes
> - Move the definition of DDP_COMPONENT_BLS to patch of "drm/mediatek: update 
> display module connections"
> - Move _dsi_irq_wait_queue into platform driver data
> - Move mtk_dsi_irq_data_clear() to patch of "drm/mediatek: add dsi interrupt 
> control"
> - Add more descriptions in the commit messages
> 
> Changes since v6:
> - Change data type of irq_data to u32
> - Rewrite mtk_dsi_host_transfer() for simplify
> - Move some MIPI_TX config to patch of "drm/mediatek: add *driver_data for 
> different hardware settings".
> - Remove device tree from this patch series
> 
> Changes since v5:
> - Remove DPI device tree and compatible string
> - Use one wait queue to handle interrupt status
> - Update the interrupt check flow and DSI_INT_ALL_BITS
> - Use same function for host read/write command
> - various fixes
> 
> Changes since v4:
> - Add messages when timeout in mtk_disp_mutex_acquire()
> - Add descriptions for DISP_REG_MUTEX registers
> - Move connection settings for display modules to a separate patch
> - Remove 'mt2701-disp-wdma' because it is unused
> - Move cleaning up and renaming to a separate patch
> - Use wait_event_interruptible_timeout() to replace polling
> - Remove irq_num from mtk_dsi structure
> - Remove redundant and debug codes
> 
> Changes since v3:
> - Add DSI support for MIPI DSI panels
> - Update BLS binding to PWM nodes
> - Remove ufoe device nodes
> - Remove redundant parentheses
> - Remove global variable initialization
> 
> Changes since v2:
> - Rename mtk_ddp_mux_sel to mtk_ddp_sout_sel
> - Update mt2701_mtk_ddp_ext components
> - Changed to prefix naming
> - Reorder the patch series
> - Use of_device_get_match_data() to get driver private data
> - Use iopoll macros to implement mtk_disp_mutex_acquire()
> - Removed empty device tree nodes
> 
> Changes since v1:
> - Removed BLS bindings and codes, which belong to pwm driver
> - Moved mtk_disp_mutex_acquire() just before mtk_crtc_ddp_config()
> - Split patch into smaller parts
> - Added const keyword to constant structure
> - Removed codes for special memory align
> 
> Thanks,
> yt.shen
> 
> YT Shen (8):
>   drm/mediatek: rename macros, add chip prefix
>   drm/mediatek: add *driver_data for different hardware settings
>   drm/mediatek: add shadow register support
>   drm/mediatek: add BLS component
>   drm/mediatek: update display module connections
>   drm/mediatek: cleaning up and refine
>   drm/mediatek: update DSI sub driver flow for sending commands to panel
>   drm/mediatek: add support for Mediatek SoC MT2701
> 
> shaoming chen (2):
>   drm/mediatek: add dsi interrupt control
>   drm/mediatek: add dsi transfer function
> 
>  drivers/gpu/drm/mediatek/mtk_disp_ovl.c |  33 ++-
>  drivers/gpu/drm/mediatek/mtk_disp_rdma.c|  17 +-
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c |  76 +++--
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.c  | 138 ++---
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.h  |   2 +
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |  38 ++-
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |  15 +
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c  |  54 +++-
>  drivers/gpu/drm/mediatek/mtk_drm_drv.h  |   9 +
>  drivers/gpu/drm/mediatek/mtk_dsi.c  | 429 
> 
>  drivers/gpu/drm/mediatek/mtk_mipi_tx.c  |  70 +++--
>  11 files changed, 715 insertions(+), 166 deletions(-)
> 

-- 
Bibby

[RFCv2 PATCH 2/5] drm/bridge: dw_hdmi: remove CEC engine register definitions

[Russell King - ARM Linux]

I can't comment on these, you've not included me in patch 1 nor the
covering message.

On Mon, Nov 14, 2016 at 04:22:45PM +0100, Hans Verkuil wrote:
> From: Russell King 
> 
> We don't need the CEC engine register definitions, so let's remove them.
> 
> Signed-off-by: Russell King 
> ---
>  drivers/gpu/drm/bridge/dw-hdmi.h | 45 
> 
>  1 file changed, 45 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/dw-hdmi.h 
> b/drivers/gpu/drm/bridge/dw-hdmi.h
> index fc9a560..26d6845 100644
> --- a/drivers/gpu/drm/bridge/dw-hdmi.h
> +++ b/drivers/gpu/drm/bridge/dw-hdmi.h
> @@ -478,51 +478,6 @@
>  #define HDMI_A_PRESETUP 0x501A
>  #define HDMI_A_SRM_BASE 0x5020
>  
> -/* CEC Engine Registers */
> -#define HDMI_CEC_CTRL   0x7D00
> -#define HDMI_CEC_STAT   0x7D01
> -#define HDMI_CEC_MASK   0x7D02
> -#define HDMI_CEC_POLARITY   0x7D03
> -#define HDMI_CEC_INT0x7D04
> -#define HDMI_CEC_ADDR_L 0x7D05
> -#define HDMI_CEC_ADDR_H 0x7D06
> -#define HDMI_CEC_TX_CNT 0x7D07
> -#define HDMI_CEC_RX_CNT 0x7D08
> -#define HDMI_CEC_TX_DATA0   0x7D10
> -#define HDMI_CEC_TX_DATA1   0x7D11
> -#define HDMI_CEC_TX_DATA2   0x7D12
> -#define HDMI_CEC_TX_DATA3   0x7D13
> -#define HDMI_CEC_TX_DATA4   0x7D14
> -#define HDMI_CEC_TX_DATA5   0x7D15
> -#define HDMI_CEC_TX_DATA6   0x7D16
> -#define HDMI_CEC_TX_DATA7   0x7D17
> -#define HDMI_CEC_TX_DATA8   0x7D18
> -#define HDMI_CEC_TX_DATA9   0x7D19
> -#define HDMI_CEC_TX_DATA10  0x7D1a
> -#define HDMI_CEC_TX_DATA11  0x7D1b
> -#define HDMI_CEC_TX_DATA12  0x7D1c
> -#define HDMI_CEC_TX_DATA13  0x7D1d
> -#define HDMI_CEC_TX_DATA14  0x7D1e
> -#define HDMI_CEC_TX_DATA15  0x7D1f
> -#define HDMI_CEC_RX_DATA0   0x7D20
> -#define HDMI_CEC_RX_DATA1   0x7D21
> -#define HDMI_CEC_RX_DATA2   0x7D22
> -#define HDMI_CEC_RX_DATA3   0x7D23
> -#define HDMI_CEC_RX_DATA4   0x7D24
> -#define HDMI_CEC_RX_DATA5   0x7D25
> -#define HDMI_CEC_RX_DATA6   0x7D26
> -#define HDMI_CEC_RX_DATA7   0x7D27
> -#define HDMI_CEC_RX_DATA8   0x7D28
> -#define HDMI_CEC_RX_DATA9   0x7D29
> -#define HDMI_CEC_RX_DATA10  0x7D2a
> -#define HDMI_CEC_RX_DATA11  0x7D2b
> -#define HDMI_CEC_RX_DATA12  0x7D2c
> -#define HDMI_CEC_RX_DATA13  0x7D2d
> -#define HDMI_CEC_RX_DATA14  0x7D2e
> -#define HDMI_CEC_RX_DATA15  0x7D2f
> -#define HDMI_CEC_LOCK   0x7D30
> -#define HDMI_CEC_WKUPCTRL   0x7D31
> -
>  /* I2C Master Registers (E-DDC) */
>  #define HDMI_I2CM_SLAVE 0x7E00
>  #define HDMI_I2CM_ADDRESS   0x7E01
> -- 
> 2.8.1
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Bug 97403] AMDGPU/Iceland Strange warnings on drm-next-4.9-wip

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

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

--- Comment #4 from Armin K  ---
It says "Adapter not found."

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

[Bug 141741] drm:radeon_get_bios [radeon]] *ERROR* Unable to locate a BIOS ROM

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

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

--- Comment #21 from Tero Roponen  ---
(In reply to Lukas P from comment #19)
> I did a bisect and it reported the following commit as the first bad one:
> 30b5b8808c12bcd947dd474980482561b69c1bcb
> 
> diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
> index a1f37db..209292e 100644
> --- a/drivers/pci/Kconfig
> +++ b/drivers/pci/Kconfig
> @@ -128,4 +128,5 @@ config PCI_HYPERV
>The PCI device frontend driver allows the kernel to import
> arbitrary
>PCI devices from a PCI backend to support PCI driver domains.
>  
> +source "drivers/pci/hotplug/Kconfig"
>  source "drivers/pci/host/Kconfig"
> 
> If I remove the changed line in the source of v4.6 everything works normally.

I'm not an expert, but removing the inclusion of drivers/pci/hotplug/Kconfig
equals to disabling all the HOTPLUG_PCI_* options in the config ("Support for
PCI Hotplug" in menuconfig). You could try disabling those one by one to see
which one causes the problem.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are watching the assignee of the bug.

[PATCH v9 00/10] MT2701 DRM support

[CK Hu]

Hi, YT:

On Fri, 2016-11-11 at 19:55 +0800, YT Shen wrote:
> This is MT2701 DRM support PATCH v9, based on 4.9-rc1.
> We add DSI interrupt control, transfer function for MIPI DSI panel support.
> Most codes are the same, except some register changed.
> 
> For example:
>  - DISP_OVL address offset changed, color format definition changed.
>  - DISP_RDMA fifo size changed.
>  - DISP_COLOR offset changed.
>  - MIPI_TX setting changed.
> 
> We add a new component DDP_COMPONENT_BLS, and the connections are updated.
> OVL -> RDMA -> COLOR -> BLS -> DSI
> RDMA -> DPI
> And we have shadow register support in MT2701.
> 
> We remove dts patch from the patch series, which depends on MT2701 CCF and 
> scpsys.

For this series, it looks good to me.
Acked-by: CK Hu 

> 
> Changes since v8:
> - enable 3 DSI interrupts only
> - move mtk_dsi_wait_for_irq_done() to the patch of irq control
> - use the name BLS in DRM driver part
> - move BLS declaration to a separate patch
> - update mtk_dsi_switch_to_cmd_mode()
> - update mtk_output_dsi_enable() and mtk_output_dsi_disable()
> 
> Changes since v7:
> - Remove redundant codes
> - Move the definition of DDP_COMPONENT_BLS to patch of "drm/mediatek: update 
> display module connections"
> - Move _dsi_irq_wait_queue into platform driver data
> - Move mtk_dsi_irq_data_clear() to patch of "drm/mediatek: add dsi interrupt 
> control"
> - Add more descriptions in the commit messages
> 
> Changes since v6:
> - Change data type of irq_data to u32
> - Rewrite mtk_dsi_host_transfer() for simplify
> - Move some MIPI_TX config to patch of "drm/mediatek: add *driver_data for 
> different hardware settings".
> - Remove device tree from this patch series
> 
> Changes since v5:
> - Remove DPI device tree and compatible string
> - Use one wait queue to handle interrupt status
> - Update the interrupt check flow and DSI_INT_ALL_BITS
> - Use same function for host read/write command
> - various fixes
> 
> Changes since v4:
> - Add messages when timeout in mtk_disp_mutex_acquire()
> - Add descriptions for DISP_REG_MUTEX registers
> - Move connection settings for display modules to a separate patch
> - Remove 'mt2701-disp-wdma' because it is unused
> - Move cleaning up and renaming to a separate patch
> - Use wait_event_interruptible_timeout() to replace polling
> - Remove irq_num from mtk_dsi structure
> - Remove redundant and debug codes
> 
> Changes since v3:
> - Add DSI support for MIPI DSI panels
> - Update BLS binding to PWM nodes
> - Remove ufoe device nodes
> - Remove redundant parentheses
> - Remove global variable initialization
> 
> Changes since v2:
> - Rename mtk_ddp_mux_sel to mtk_ddp_sout_sel
> - Update mt2701_mtk_ddp_ext components
> - Changed to prefix naming
> - Reorder the patch series
> - Use of_device_get_match_data() to get driver private data
> - Use iopoll macros to implement mtk_disp_mutex_acquire()
> - Removed empty device tree nodes
> 
> Changes since v1:
> - Removed BLS bindings and codes, which belong to pwm driver
> - Moved mtk_disp_mutex_acquire() just before mtk_crtc_ddp_config()
> - Split patch into smaller parts
> - Added const keyword to constant structure
> - Removed codes for special memory align
> 
> Thanks,
> yt.shen
> 
> YT Shen (8):
>   drm/mediatek: rename macros, add chip prefix
>   drm/mediatek: add *driver_data for different hardware settings
>   drm/mediatek: add shadow register support
>   drm/mediatek: add BLS component
>   drm/mediatek: update display module connections
>   drm/mediatek: cleaning up and refine
>   drm/mediatek: update DSI sub driver flow for sending commands to panel
>   drm/mediatek: add support for Mediatek SoC MT2701
> 
> shaoming chen (2):
>   drm/mediatek: add dsi interrupt control
>   drm/mediatek: add dsi transfer function
> 
>  drivers/gpu/drm/mediatek/mtk_disp_ovl.c |  33 ++-
>  drivers/gpu/drm/mediatek/mtk_disp_rdma.c|  17 +-
>  drivers/gpu/drm/mediatek/mtk_drm_crtc.c |  76 +++--
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.c  | 138 ++---
>  drivers/gpu/drm/mediatek/mtk_drm_ddp.h  |   2 +
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c |  38 ++-
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |  15 +
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c  |  54 +++-
>  drivers/gpu/drm/mediatek/mtk_drm_drv.h  |   9 +
>  drivers/gpu/drm/mediatek/mtk_dsi.c  | 429 
> 
>  drivers/gpu/drm/mediatek/mtk_mipi_tx.c  |  70 +++--
>  11 files changed, 715 insertions(+), 166 deletions(-)
> 

[Bug 98505] [radeon, amdgpu] Regression introduced in 4.8-rc3

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

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

--- Comment #29 from Alex Deucher  ---
(In reply to Peter Wu from comment #23)
> Alex, I don't think that the minimum date should change in 4.8 (and 4.9?)
> due to the risk of breakage since it is not just limited to amdgpu/radeon.
> Another concern is that while the year seems a good heuristic, it does not
> match the checks that Windows 8 performs (which may or may not be an issue):
> https://msdn.microsoft.com/en-us/windows/hardware/drivers/bringup/firmware-
> requirements-for-d3cold

I agree that using the date is probably not a good idea, but it's what we have
now.  Adjusting the date seems lower impact than changing the policy for these
kernels.

> 
> I'll bring this up with linux-pci developers after the weekend. Should I
> proceed with proposing workaround amdgpu/radeon patches?

Sounds good.  I generally don't like hacking around this in the driver, but I
guess it's better than nothing at this point.  Thanks for your help with this.

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

[PATCH v10 3/3] drm/fence: add out-fences support

[Brian Starkey]

Hi Gustavo,

I was just writing some internal docs, and it occurred to me that the
out-fence implementation here doesn't seem to match what we discussed
with Ville a few weeks back (which had completely slipped my mind).

Did the idea of returning -1 fences for multiple commits within a
frame get dropped? I didn't see any discussion further than that
thread on v5 from October:
http://lkml.iu.edu/hypermail/linux/kernel/1610.2/04727.html

Cheers,
Brian

On Mon, Nov 14, 2016 at 10:59:56AM +0900, Gustavo Padovan wrote:
>From: Gustavo Padovan 
>
>Support DRM out-fences by creating a sync_file with a fence for each CRTC
>that sets the OUT_FENCE_PTR property.
>
>We use the out_fence pointer received in the OUT_FENCE_PTR prop to send
>the sync_file fd back to userspace.
>
>The sync_file and fd are allocated/created before commit, but the
>fd_install operation only happens after we know that commit succeed.
>
>v2: Comment by Rob Clark:
>   - Squash commit that adds DRM_MODE_ATOMIC_OUT_FENCE flag here.
>
>Comment by Daniel Vetter:
>   - Add clean up code for out_fences
>
>v3: Comments by Daniel Vetter:
>   - create DRM_MODE_ATOMIC_EVENT_MASK
>   - userspace should fill out_fences_ptr with the crtc_ids for which
>   it wants fences back.
>
>v4: Create OUT_FENCE_PTR properties and remove old approach.
>
>v5: Comments by Brian Starkey:
>   - Remove extra fence_get() in atomic_ioctl()
>   - Check ret before iterating on the crtc_state
>   - check ret before fd_install
>   - set fence_state to NULL at the beginning
>   - check fence_state->out_fence_ptr before put_user()
>   - change order of fput() and put_unused_fd() on failure
>
> - Add access_ok() check to the out_fence_ptr received
> - Rebase after fence -> dma_fence rename
> - Store out_fence_ptr in the drm_atomic_state
> - Split crtc_setup_out_fence()
> - return -1 as out_fence with TEST_ONLY flag
>
>v6: Comments by Daniel Vetter
>   - Add prepare/unprepare_crtc_signaling()
>   - move struct drm_out_fence_state to drm_atomic.c
>   - mark get_crtc_fence() as static
>
>Comments by Brian Starkey
>   - proper set fence_ptr fence_state array
>   - isolate fence_idx increment
>
>- improve error handling
>
>v7: Comments by Daniel Vetter
>   - remove prefix from internal functions
>   - make out_fence_ptr an s64 pointer
>   - degrade DRM_INFO to DRM_DEBUG_ATOMIC when put_user fail
>   - fix doc issues
>   - filter out OUT_FENCE_PTR == NULL and do not fail in this case
>   - add complete_crtc_signalling()
>   - krealloc fence_state on demand
>
>Comment by Brian Starkey
>   - remove unused crtc_state arg from get_out_fence()
>
>v8: Comment by Brian Starkey
>   - cancel events before check for !fence_state
>   - convert a few lefovers u64 types for out_fence_ptr
>   - fix memleak by assign fence_state earlier after realloc
>   - proper accout num_fences in case of error
>
>v9: Comment by Brian Starkey
>   - memset last position of fence_state after krealloc
>Comments by Sean Paul
>   - pass install_fds in complete_crtc_signaling() instead of ret
>
> - put_user(-1, fence_ptr) when decoding props
>
>Signed-off-by: Gustavo Padovan 
>---
> drivers/gpu/drm/drm_atomic.c | 241 +++
> drivers/gpu/drm/drm_crtc.c   |   8 ++
> include/drm/drm_atomic.h |   1 +
> include/drm/drm_crtc.h   |   6 ++
> 4 files changed, 211 insertions(+), 45 deletions(-)
>
>diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>index 3ad780a..27e5c0a 100644
>--- a/drivers/gpu/drm/drm_atomic.c
>+++ b/drivers/gpu/drm/drm_atomic.c
>@@ -290,6 +290,23 @@ drm_atomic_get_crtc_state(struct drm_atomic_state *state,
> }
> EXPORT_SYMBOL(drm_atomic_get_crtc_state);
>
>+static void set_out_fence_for_crtc(struct drm_atomic_state *state,
>+ struct drm_crtc *crtc, s64 __user *fence_ptr)
>+{
>+  state->crtcs[drm_crtc_index(crtc)].out_fence_ptr = fence_ptr;
>+}
>+
>+static s64 __user * get_out_fence_for_crtc(struct drm_atomic_state *state,
>+ struct drm_crtc *crtc)
>+{
>+  s64 __user *fence_ptr;
>+
>+  fence_ptr = state->crtcs[drm_crtc_index(crtc)].out_fence_ptr;
>+  state->crtcs[drm_crtc_index(crtc)].out_fence_ptr = NULL;
>+
>+  return fence_ptr;
>+}
>+
> /**
>  * drm_atomic_set_mode_for_crtc - set mode for CRTC
>  * @state: the CRTC whose incoming state to update
>@@ -494,6 +511,16 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
>   );
>   state->color_mgmt_changed |= replaced;
>   return ret;
>+  } else if (property == config->prop_out_fence_ptr) {
>+  s64 __user *fence_ptr = u64_to_user_ptr(val);
>+
>+  if (!fence_ptr)
>+  return 0;
>+
>+  if (put_user(-1, fence_ptr))
>+

[Intel-gfx] [PATCH 0/5] Handle Link Training Failure during modeset

[Cheng, Tony]

I see.  As long as amd can still just have kernel hiding unsupported mode by 
doing a pre-train I am okay with the proposal.  Just to caution you the link 
training fallback we implemented on windows in old dal architecture is very 
painful to get right.  Windows 7, 8.1 and 10 all behave differently.  Not all 
apps handles mode change failure gracefully and worse case we get stuck in 
infinite mode set.  This is why for future generations asic on windows we are 
also going to just hide unsupported mode by doing pre-train.

-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Monday, November 14, 2016 3:04 AM
To: Manasi Navare 
Cc: Cheng, Tony ; intel-gfx at lists.freedesktop.org; 
Peres, Martin ; dri-devel at lists.freedesktop.org; 
Deucher, Alexander ; Wentland, Harry 

Subject: Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure during modeset

On Sun, Nov 13, 2016 at 11:43:01PM -0800, Manasi Navare wrote:
> On Fri, Nov 11, 2016 at 07:42:16PM +, Cheng, Tony wrote:
> > In case of link training failure and requiring user space to set a lower 
> > mode, would full mode set address it?  How do we make user mode select 
> > lower resolution?
> > 
> > For example 4k at 60Hz monitor, and link training at 4 lane HBR2 fails and 
> > fallback to 4 lanes HBR, 4k at 60 is no longer doable.  I would think 
> > preventing user mode from seeing 4K at 60Hz from the start is a easier and 
> > more robust solution and requiring user mode to have logic to decide how to 
> > fallback.
> >
> 
> Hi Tony,
> 
> So in case of link training failure, we first call mode_valid that 
> will use the lower link rate/lane count values based on the link 
> training fallback to validate the modes and prune the modes that are 
> higher than the available link. After this is done, then we send the uevent 
> to userspace indicating that link status is BAD and it will redo a probe and 
> trigger a modeset for next possible lower resolution.

Just in case it's not clear: This entire discussion here is only about the 
userspace-visible abi changes. And I think for the worst-case we need something 
like this (and Harry at least said on irc that on other os you do something 
similar already). It of course does not preclude at all that you do additional 
link-training/probe on initial hotplug. That part is entirely up to drivers 
(and we might get there on some platforms, but on others it's a real pain to 
get a link up unfortunately for training, since we need to steal a crtc 
and do a full modeset).
-Daniel

> 
> Manasi
> 
>  
> > -Original Message-
> > From: Ville Syrjälä [mailto:ville.syrjala at linux.intel.com]
> > Sent: Friday, November 11, 2016 11:44 AM
> > To: Cheng, Tony 
> > Cc: Deucher, Alexander ; 'Jani Nikula' 
> > ; Manasi Navare 
> > ; dri-devel at lists.freedesktop.org; 
> > intel-gfx at lists.freedesktop.org; Wentland, Harry 
> > ; Peres, Martin 
> > Subject: Re: [Intel-gfx] [PATCH 0/5] Handle Link Training Failure 
> > during modeset
> > 
> > On Fri, Nov 11, 2016 at 04:21:58PM +, Cheng, Tony wrote:
> > > For HDMI, you can yank the cable, plug back in, HDMI will light up 
> > > without user mode or kernel mode doing anything.
> > > 
> > > For DP this is not possible, someone will have to retrain the link when 
> > > plugging back in or DP will not light up.  We see that on Ubuntu if 
> > > someone unplug display and plug it back into same connector, we do not 
> > > get KMS so in this case.  It appears there is some optimizations 
> > > somewhere in user mode stack which I am not familiar with yet.  dal added 
> > > workaround to retrain the link to light it back up (after the test 
> > > training at end of detection).
> > 
> > The link should get retrained as the driver should check the link state on 
> > HPD and retrain if it's not good. At least that's what we do in i915. Of 
> > course if it's not the same display that got plugged back, the retraining 
> > might fail. The new property can help with that case as userspace would 
> > then attempt a full modeset after the failed link training.
> > 
> > > 
> > > >From user mode perspective I think it make sense to keep CRTC running, 
> > > >so vblank is still going so UMD isn't impacted.   As regard to connector 
> > > >and encoder does it matter if kernel mode change state without user mode 
> > > >knowing?  It seems to me those are more informational to UMD as UMD 
> > > >doesn't act on them.
> > > 
> > > windows does not know link state and all link management is hidden behind 
> > > kernel driver.   
> > 
> > If the user visible state doesn't change in any way, then the kernel could 
> > try to manage it all internally.
> > 
> > > 
> > > -Original Message-
> > > From: Ville Syrjälä [mailto:ville.syrjala at linux.intel.com]
> > > Sent: Friday, November 11, 2016 9:05 AM
> > > To: Cheng, Tony 
> > > Cc: Deucher, Alexander ; 'Jani Nikula' 
> > > ; Manasi Navare 
> > > ; dri-devel at 

[PATCH libdrm] libkms/exynos: fix memory leak in error path

[Seung-Woo Kim]

This patch fixes memory leak in error path of exynos_bo_create().

Signed-off-by: Seung-Woo Kim 
---
 libkms/exynos.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/libkms/exynos.c b/libkms/exynos.c
index 5de2e5a..0e97fb5 100644
--- a/libkms/exynos.c
+++ b/libkms/exynos.c
@@ -88,7 +88,8 @@ exynos_bo_create(struct kms_driver *kms,
pitch = (pitch + 512 - 1) & ~(512 - 1);
size = pitch * ((height + 4 - 1) & ~(4 - 1));
} else {
-   return -EINVAL;
+   ret = -EINVAL;
+   goto err_free;
}

memset(, 0, sizeof(arg));
-- 
1.7.4.1

[PATCH RESEND] drm/ast: free correct pointer in astfb_create() error paths

[Andrew Donnellan]

In the err_free_vram and err_release_fbi error paths in astfb_create(), we
attempt to free afbdev->sysram. The only jumps to these error paths occur
before we assign afbdev->sysram = sysram. Free sysram instead.

Signed-off-by: Andrew Donnellan 

---

Found by Coverity Scan. Compile tested only.
---
 drivers/gpu/drm/ast/ast_fb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
index 7a86e24..d6f5ec6 100644
--- a/drivers/gpu/drm/ast/ast_fb.c
+++ b/drivers/gpu/drm/ast/ast_fb.c
@@ -253,7 +253,7 @@ static int astfb_create(struct drm_fb_helper *helper,
 err_release_fbi:
drm_fb_helper_release_fbi(helper);
 err_free_vram:
-   vfree(afbdev->sysram);
+   vfree(sysram);
return ret;
 }

-- 
Andrew Donnellan  OzLabs, ADL Canberra
andrew.donnellan at au1.ibm.com  IBM Australia Limited

[PATCH v2 00/18] Introduce DRM_FB_HELPER_DEFAULT_OPS for struct fb_ops

[Stefan Christ]

Hi Christian,

On Mon, Nov 14, 2016 at 10:43:10AM +0100, Christian König wrote:
> Am 14.11.2016 um 00:03 schrieb Stefan Christ:
> > Hi,
> >
> > this is the second version of the refactoring work suggested by Daniel 
> > Vetter
> > in the email:
> >
> > https://lists.freedesktop.org/archives/dri-devel/2016-July/113237.html
> >
> > The define DRM_FB_HELPER_DEFAULT_OPS provides the drm_fb_helper default
> > implementations for functions in struct fb_ops. A drm driver can use it 
> > like:
> >
> >  static struct fb_ops drm_fbdev_cma_ops = {
> >  .owner  = THIS_MODULE,
> >  DRM_FB_HELPER_DEFAULT_OPS,
> >  /* driver specific implementations */
> >  };
> 
> Looks good to me in general, but I've got one question. Why didn't you 
> put the owner field into the macro as well?
> 
> I have strong doubts that anybody would set anything else than 
> THIS_MODULE here.
> 

In the initial suggestion by Daniel Vetter he also mentioned this
possibility. See email and response:

https://lists.freedesktop.org/archives/dri-devel/2016-July/114136.html

But I decided against it, since it hides even more magic behind the
helper define.

Mit freundlichen Grüßen / Kind regards,
Stefan Christ

[PATCH 2/3] drm/bridge: Add ti-ftp410 HDMI transmitter driver

[Laurent Pinchart]

Hi Tomi,

On Monday 14 Nov 2016 13:16:49 Tomi Valkeinen wrote:
> On 14/11/16 13:10, Laurent Pinchart wrote:
> > On Monday 14 Nov 2016 10:49:43 Jyri Sarha wrote:
> >> On 11/03/16 19:46, Laurent Pinchart wrote:
>  +Required properties:
> > +   - compatible: "ti,tfp410"
> >>> 
> >>> The device is an I2C slave, it should have a reg property. Given that
> >>> the chip can be used without being controlled through I2C, the reg
> >>> property should be optional. You should document this clearly, and
> >>> explain how the DT node can be instantiated as a child of an I2C
> >>> controller when the I2C interface is used, or in other parts of the
> >>> device tree otherwise.
> >> 
> >> Shouldn't I have two different compatible strings if want to make both
> >> platform driver probe and i2c client probe to work?
> > 
> > I don't think so, it's still the same chip.
> > 
> >> Or can it be done with single compatible string? Would you know of an
> >> example of such a driver?
> > 
> > You will need to register both a i2c_driver and a platform_driver in the
> > tfp410 driver. Both will advertise the same compatible string. As you'll
> > have two probe functions, it should be easy to handle the differences
> > between the
>
> If you have the same compatible string, won't both probes trigger? If
> so, how does, e.g., the platform driver know this is actually i2c case,
> and bail out? And if both probes don't trigger, why not? How does the
> device probing machinery know that this DT node is actually an i2c node,
> not a platform device node?

The driver for the bus on which the device is sitting is responsible for 
instantiating a struct device corresponding to the bus type, and for binding 
the corresponding bus drivers. This will be a struct i2c_client for I2C buses, 
and a struct platform_device for platform buses. Only the corresponding driver 
type will be probed.

-- 
Regards,

Laurent Pinchart

[PATCH 2/3] drm/bridge: Add ti-ftp410 HDMI transmitter driver

[Tomi Valkeinen]

On 14/11/16 13:10, Laurent Pinchart wrote:
> Hi Jyri,
> 
> On Monday 14 Nov 2016 10:49:43 Jyri Sarha wrote:
>> On 11/03/16 19:46, Laurent Pinchart wrote:
>>>> +Required properties:
>>>>> + - compatible: "ti,tfp410"
>>>
>>> The device is an I2C slave, it should have a reg property. Given that the
>>> chip can be used without being controlled through I2C, the reg property
>>> should be optional. You should document this clearly, and explain how the
>>> DT node can be instantiated as a child of an I2C controller when the I2C
>>> interface is used, or in other parts of the device tree otherwise.
>>
>> Shouldn't I have two different compatible strings if want to make both
>> platform driver probe and i2c client probe to work?
> 
> I don't think so, it's still the same chip.
> 
>> Or can it be done with single compatible string? Would you know of an
>> example of such a driver?
> 
> You will need to register both a i2c_driver and a platform_driver in the 
> tfp410 driver. Both will advertise the same compatible string. As you'll have 
> two probe functions, it should be easy to handle the differences between the 

If you have the same compatible string, won't both probes trigger? If
so, how does, e.g., the platform driver know this is actually i2c case,
and bail out? And if both probes don't trigger, why not? How does the
device probing machinery know that this DT node is actually an i2c node,
not a platform device node?

 Tomi

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161114/c17b4689/attachment-0001.sig>

[PATCH 2/3] drm/bridge: Add ti-ftp410 HDMI transmitter driver

[Laurent Pinchart]

Hi Jyri,

On Monday 14 Nov 2016 10:49:43 Jyri Sarha wrote:
> On 11/03/16 19:46, Laurent Pinchart wrote:
> >> +Required properties:
> >> > +- compatible: "ti,tfp410"
> > 
> > The device is an I2C slave, it should have a reg property. Given that the
> > chip can be used without being controlled through I2C, the reg property
> > should be optional. You should document this clearly, and explain how the
> > DT node can be instantiated as a child of an I2C controller when the I2C
> > interface is used, or in other parts of the device tree otherwise.
> 
> Shouldn't I have two different compatible strings if want to make both
> platform driver probe and i2c client probe to work?

I don't think so, it's still the same chip.

> Or can it be done with single compatible string? Would you know of an
> example of such a driver?

You will need to register both a i2c_driver and a platform_driver in the 
tfp410 driver. Both will advertise the same compatible string. As you'll have 
two probe functions, it should be easy to handle the differences between the 
two situations there, with common code shared in common functions. A quick 
grep points to at least drivers/power/bq27x00_battery.c as an example (albeit 
without DT support).

-- 
Regards,

Laurent Pinchart

[Nouveau] [PATCH v3 1/2] nouveau/bl: Assign different names to interfaces

[Pierre Moreau]

gt; -   if (IS_ERR(bd))
> > +
> > +   if (IS_ERR(bd)) {
> > +   if (bl_connector.id > 0)
> > +   ida_simple_remove(_ida, bl_connector.id);
> > return PTR_ERR(bd);
> > +   }
> > +   list_add(_connector.head, >bl_connectors);
> > drm->backlight = bd;
> > bd->props.brightness = nv40_get_intensity(bd);
> > backlight_update_status(bd);
> > @@ -182,6 +211,8 @@ nv50_backlight_init(struct drm_connector *connector)
> > struct backlight_properties props;
> > struct backlight_device *bd;
> > const struct backlight_ops *ops;
> > +   struct backlight_connector bl_connector;
> > +   char backlight_name[BL_NAME_SIZE];
> >  
> > nv_encoder = find_encoder(connector, DCB_OUTPUT_LVDS);
> > if (!nv_encoder) {
> > @@ -203,11 +234,17 @@ nv50_backlight_init(struct drm_connector *connector)
> > memset(, 0, sizeof(struct backlight_properties));
> > props.type = BACKLIGHT_RAW;
> > props.max_brightness = 100;
> > -   bd = backlight_device_register("nv_backlight", connector->kdev,
> > +   nouveau_get_backlight_name(backlight_name, _connector);
> > +   bd = backlight_device_register(backlight_name , connector->kdev,
> >nv_encoder, ops, );
> > -   if (IS_ERR(bd))
> > +
> > +   if (IS_ERR(bd)) {
> > +   if (bl_connector.id > 0)
> > +   ida_simple_remove(_ida, bl_connector.id);
> > return PTR_ERR(bd);
> > +   }
> >  
> > +   list_add(_connector.head, >bl_connectors);
> > drm->backlight = bd;
> > bd->props.brightness = bd->ops->get_brightness(bd);
> > backlight_update_status(bd);
> > @@ -221,6 +258,8 @@ nouveau_backlight_init(struct drm_device *dev)
> > struct nvif_device *device = >device;
> > struct drm_connector *connector;
> >  
> > +   INIT_LIST_HEAD(>bl_connectors);
> > +
> > list_for_each_entry(connector, >mode_config.connector_list, head) {
> > if (connector->connector_type != DRM_MODE_CONNECTOR_LVDS &&
> > connector->connector_type != DRM_MODE_CONNECTOR_eDP)
> > @@ -247,9 +286,27 @@ void
> >  nouveau_backlight_exit(struct drm_device *dev)
> >  {
> > struct nouveau_drm *drm = nouveau_drm(dev);
> > +   struct backlight_connector *connector;
> > +
> > +   list_for_each_entry(connector, >bl_connectors, head) {
> > +   if (connector->id >= 0)
> > +   ida_simple_remove(_ida, connector->id);
> > +   }
> >  
> > if (drm->backlight) {
> > backlight_device_unregister(drm->backlight);
> > drm->backlight = NULL;
> > }
> >  }
> > +
> > +void
> > +nouveau_backlight_ctor(void)
> > +{
> > +   ida_init(_ida);
> > +}
> > +
> > +void
> > +nouveau_backlight_dtor(void)
> > +{
> > +   ida_destroy(_ida);
> > +}
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_display.h 
> > b/drivers/gpu/drm/nouveau/nouveau_display.h
> > index 330fe0f..4a75df0 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_display.h
> > +++ b/drivers/gpu/drm/nouveau/nouveau_display.h
> > @@ -91,6 +91,8 @@ int nouveau_crtc_set_config(struct drm_mode_set *set);
> >  #ifdef CONFIG_DRM_NOUVEAU_BACKLIGHT
> >  extern int nouveau_backlight_init(struct drm_device *);
> >  extern void nouveau_backlight_exit(struct drm_device *);
> > +extern void nouveau_backlight_ctor(void);
> > +extern void nouveau_backlight_dtor(void);
> >  #else
> >  static inline int
> >  nouveau_backlight_init(struct drm_device *dev)
> > @@ -101,6 +103,14 @@ nouveau_backlight_init(struct drm_device *dev)
> >  static inline void
> >  nouveau_backlight_exit(struct drm_device *dev) {
> >  }
> > +
> > +static inline void
> > +nouveau_backlight_ctor(void) {
> > +}
> > +
> > +static inline void
> > +nouveau_backlight_dtor(void) {
> > +}
> >  #endif
> >  
> >  struct drm_framebuffer *
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
> > b/drivers/gpu/drm/nouveau/nouveau_drm.c
> > index 9876e6f..2b93b55 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> > +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> > @@ -1113,6 +1113,7 @@ nouveau_drm_init(void)
> >  #endif
> >  
> > nouveau_register_dsm_handler();
> > +   nouveau_backlight_ctor();
> > return drm_pci_init(_pci, _drm_pci_driver);
> >  }
> >  
> > @@ -1123,6 +1124,7 @@ nouveau_drm_exit(void)
> > return;
> >  
> > drm_pci_exit(_pci, _drm_pci_driver);
> > +   nouveau_backlight_dtor();
> > nouveau_unregister_dsm_handler();
> >  
> >  #ifdef CONFIG_NOUVEAU_PLATFORM_DRIVER
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h 
> > b/drivers/gpu/drm/nouveau/nouveau_drv.h
> > index 4cd47ba..923dbce 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_drv.h
> > +++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
> > @@ -161,6 +161,7 @@ struct nouveau_drm {
> > struct nvbios vbios;
> > struct nouveau_display *display;
> > struct backlight_device *backlight;
> > +   struct list_head bl_connectors;
> >  
> > /* power management */
> > struct nouveau_hwmon *hwmon;
> > -- 
> > 2.10.2
> > 
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> Nouveau mailing list
> Nouveau at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161114/f4e158d5/attachment.sig>

[PATCH 10/10] drm: Drop externs from drm_crtc.h

[Daniel Vetter]

Just noise.

Signed-off-by: Daniel Vetter 
---
 include/drm/drm_crtc.h | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index cf96b393091a..bcc1a4d1d1a6 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -762,14 +762,14 @@ struct drm_mode_set {

 #define obj_to_crtc(x) container_of(x, struct drm_crtc, base)

-extern __printf(6, 7)
+__printf(6, 7)
 int drm_crtc_init_with_planes(struct drm_device *dev,
  struct drm_crtc *crtc,
  struct drm_plane *primary,
  struct drm_plane *cursor,
  const struct drm_crtc_funcs *funcs,
  const char *name, ...);
-extern void drm_crtc_cleanup(struct drm_crtc *crtc);
+void drm_crtc_cleanup(struct drm_crtc *crtc);

 /**
  * drm_crtc_index - find the index of a registered CRTC
@@ -795,12 +795,12 @@ static inline uint32_t drm_crtc_mask(const struct 
drm_crtc *crtc)
return 1 << drm_crtc_index(crtc);
 }

-extern void drm_crtc_get_hv_timing(const struct drm_display_mode *mode,
-  int *hdisplay, int *vdisplay);
-extern int drm_crtc_force_disable(struct drm_crtc *crtc);
-extern int drm_crtc_force_disable_all(struct drm_device *dev);
+void drm_crtc_get_hv_timing(const struct drm_display_mode *mode,
+   int *hdisplay, int *vdisplay);
+int drm_crtc_force_disable(struct drm_crtc *crtc);
+int drm_crtc_force_disable_all(struct drm_device *dev);

-extern int drm_mode_set_config_internal(struct drm_mode_set *set);
+int drm_mode_set_config_internal(struct drm_mode_set *set);

 /* Helpers */
 static inline struct drm_crtc *drm_crtc_find(struct drm_device *dev,
-- 
2.10.2

[PATCH 09/10] drm: Move tile group code into drm_connector.c

[Daniel Vetter]

And also put the overview section into the KMS Properties part of the
docs, instead of randomly-placed within the helpers - this is part of
the uabi.

With this patch I think drm_crtc.[hc] is cleaned up and entirely
documented.

Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/drm-kms-helpers.rst |   8 ---
 Documentation/gpu/drm-kms.rst |   6 ++
 drivers/gpu/drm/drm_connector.c   | 104 ++
 drivers/gpu/drm/drm_crtc.c|  99 
 include/drm/drm_connector.h   |  24 
 include/drm/drm_crtc.h|  15 -
 6 files changed, 134 insertions(+), 122 deletions(-)

diff --git a/Documentation/gpu/drm-kms-helpers.rst 
b/Documentation/gpu/drm-kms-helpers.rst
index bb4254d19cbb..4ca77f675967 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -261,14 +261,6 @@ Plane Helper Reference
 .. kernel-doc:: drivers/gpu/drm/drm_plane_helper.c
:export:

-Tile group
-==
-
-# FIXME: This should probably be moved into a property documentation section
-
-.. kernel-doc:: drivers/gpu/drm/drm_crtc.c
-   :doc: Tile group
-
 Auxiliary Modeset Helpers
 =

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index a8ff2c87c0e9..568f3c2b6e46 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -281,6 +281,12 @@ Color Management Properties
 .. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
:export:

+Tile Group Property
+---
+
+.. kernel-doc:: drivers/gpu/drm/drm_connector.c
+   :doc: Tile group
+
 Existing KMS Properties
 ---

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 0b89577aa9f8..f370663b49f2 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1126,3 +1126,107 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
return ret;
 }

+
+/**
+ * DOC: Tile group
+ *
+ * Tile groups are used to represent tiled monitors with a unique integer
+ * identifier. Tiled monitors using DisplayID v1.3 have a unique 8-byte handle,
+ * we store this in a tile group, so we have a common identifier for all tiles
+ * in a monitor group. The property is called "TILE". Drivers can manage tile
+ * groups using drm_mode_create_tile_group(), drm_mode_put_tile_group() and
+ * drm_mode_get_tile_group(). But this is only needed for internal panels where
+ * the tile group information is exposed through a non-standard way.
+ */
+
+static void drm_tile_group_free(struct kref *kref)
+{
+   struct drm_tile_group *tg = container_of(kref, struct drm_tile_group, 
refcount);
+   struct drm_device *dev = tg->dev;
+   mutex_lock(>mode_config.idr_mutex);
+   idr_remove(>mode_config.tile_idr, tg->id);
+   mutex_unlock(>mode_config.idr_mutex);
+   kfree(tg);
+}
+
+/**
+ * drm_mode_put_tile_group - drop a reference to a tile group.
+ * @dev: DRM device
+ * @tg: tile group to drop reference to.
+ *
+ * drop reference to tile group and free if 0.
+ */
+void drm_mode_put_tile_group(struct drm_device *dev,
+struct drm_tile_group *tg)
+{
+   kref_put(>refcount, drm_tile_group_free);
+}
+EXPORT_SYMBOL(drm_mode_put_tile_group);
+
+/**
+ * drm_mode_get_tile_group - get a reference to an existing tile group
+ * @dev: DRM device
+ * @topology: 8-bytes unique per monitor.
+ *
+ * Use the unique bytes to get a reference to an existing tile group.
+ *
+ * RETURNS:
+ * tile group or NULL if not found.
+ */
+struct drm_tile_group *drm_mode_get_tile_group(struct drm_device *dev,
+  char topology[8])
+{
+   struct drm_tile_group *tg;
+   int id;
+   mutex_lock(>mode_config.idr_mutex);
+   idr_for_each_entry(>mode_config.tile_idr, tg, id) {
+   if (!memcmp(tg->group_data, topology, 8)) {
+   if (!kref_get_unless_zero(>refcount))
+   tg = NULL;
+   mutex_unlock(>mode_config.idr_mutex);
+   return tg;
+   }
+   }
+   mutex_unlock(>mode_config.idr_mutex);
+   return NULL;
+}
+EXPORT_SYMBOL(drm_mode_get_tile_group);
+
+/**
+ * drm_mode_create_tile_group - create a tile group from a displayid 
description
+ * @dev: DRM device
+ * @topology: 8-bytes unique per monitor.
+ *
+ * Create a tile group for the unique monitor, and get a unique
+ * identifier for the tile group.
+ *
+ * RETURNS:
+ * new tile group or error.
+ */
+struct drm_tile_group *drm_mode_create_tile_group(struct drm_device *dev,
+ char topology[8])
+{
+   struct drm_tile_group *tg;
+   int ret;
+
+   tg = kzalloc(sizeof(*tg), GFP_KERNEL);
+   if (!tg)
+   return ERR_PTR(-ENOMEM);
+
+   kref_init(>refcount);
+   memcpy(tg->group_data, topology, 

[PATCH 08/10] drm: Extract drm_mode_config.[hc]

[Daniel Vetter]

And shuffle the kernel-doc structure a bit since drm_crtc.[hc] now
only contains CRTC-related functions and structures.

Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/drm-kms.rst   |  32 +-
 drivers/gpu/drm/Makefile|   2 +-
 drivers/gpu/drm/drm_crtc.c  | 379 +
 drivers/gpu/drm/drm_crtc_internal.h |  20 +-
 drivers/gpu/drm/drm_mode_config.c   | 399 ++
 include/drm/drm_crtc.h  | 622 +-
 include/drm/drm_mode_config.h   | 658 
 7 files changed, 1094 insertions(+), 1018 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_mode_config.c
 create mode 100644 include/drm/drm_mode_config.h

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 4edfb6d91250..a8ff2c87c0e9 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -15,25 +15,24 @@ be setup by initializing the following fields.
 -  struct drm_mode_config_funcs \*funcs;
Mode setting functions.

-Modeset Base Object Abstraction
-===
+Mode Configuration

-.. kernel-doc:: include/drm/drm_mode_object.h
-   :internal:
+KMS Core Structures and Functions
+=

-.. kernel-doc:: drivers/gpu/drm/drm_mode_object.c
+.. kernel-doc:: drivers/gpu/drm/drm_mode_config.c
:export:

-KMS Data Structures
-===
-
-.. kernel-doc:: include/drm/drm_crtc.h
+.. kernel-doc:: include/drm/drm_mode_config.h
:internal:

-KMS API Functions
-=
+Modeset Base Object Abstraction
+===

-.. kernel-doc:: drivers/gpu/drm/drm_crtc.c
+.. kernel-doc:: include/drm/drm_mode_object.h
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_mode_object.c
:export:

 Atomic Mode Setting Function Reference
@@ -45,6 +44,15 @@ Atomic Mode Setting Function Reference
 .. kernel-doc:: include/drm/drm_atomic.h
:internal:

+CRTC Abstraction
+
+
+.. kernel-doc:: drivers/gpu/drm/drm_crtc.c
+   :export:
+
+.. kernel-doc:: include/drm/drm_crtc.h
+   :internal:
+
 Frame Buffer Abstraction
 

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index adcfc8f922e3..883f3e75cfbc 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -16,7 +16,7 @@ drm-y   :=drm_auth.o drm_bufs.o drm_cache.o \
drm_framebuffer.o drm_connector.o drm_blend.o \
drm_encoder.o drm_mode_object.o drm_property.o \
drm_plane.o drm_color_mgmt.o drm_print.o \
-   drm_dumb_buffers.o
+   drm_dumb_buffers.o drm_mode_config.o

 drm-$(CONFIG_COMPAT) += drm_ioc32.o
 drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 0ece33cc0dc6..6e7d376d809c 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -45,18 +45,6 @@
 #include "drm_crtc_internal.h"
 #include "drm_internal.h"

-/*
- * Global properties
- */
-static const struct drm_prop_enum_list drm_plane_type_enum_list[] = {
-   { DRM_PLANE_TYPE_OVERLAY, "Overlay" },
-   { DRM_PLANE_TYPE_PRIMARY, "Primary" },
-   { DRM_PLANE_TYPE_CURSOR, "Cursor" },
-};
-
-/*
- * Optional properties
- */
 /**
  * drm_crtc_force_disable - Forcibly turn off a CRTC
  * @crtc: CRTC to turn off
@@ -116,7 +104,7 @@ static unsigned int drm_num_crtcs(struct drm_device *dev)
return num;
 }

-static int drm_crtc_register_all(struct drm_device *dev)
+int drm_crtc_register_all(struct drm_device *dev)
 {
struct drm_crtc *crtc;
int ret = 0;
@@ -135,7 +123,7 @@ static int drm_crtc_register_all(struct drm_device *dev)
return 0;
 }

-static void drm_crtc_unregister_all(struct drm_device *dev)
+void drm_crtc_unregister_all(struct drm_device *dev)
 {
struct drm_crtc *crtc;

@@ -287,290 +275,6 @@ void drm_crtc_cleanup(struct drm_crtc *crtc)
 }
 EXPORT_SYMBOL(drm_crtc_cleanup);

-int drm_modeset_register_all(struct drm_device *dev)
-{
-   int ret;
-
-   ret = drm_plane_register_all(dev);
-   if (ret)
-   goto err_plane;
-
-   ret = drm_crtc_register_all(dev);
-   if  (ret)
-   goto err_crtc;
-
-   ret = drm_encoder_register_all(dev);
-   if (ret)
-   goto err_encoder;
-
-   ret = drm_connector_register_all(dev);
-   if (ret)
-   goto err_connector;
-
-   return 0;
-
-err_connector:
-   drm_encoder_unregister_all(dev);
-err_encoder:
-   drm_crtc_unregister_all(dev);
-err_crtc:
-   drm_plane_unregister_all(dev);
-err_plane:
-   return ret;
-}
-
-void drm_modeset_unregister_all(struct drm_device *dev)
-{
-   drm_connector_unregister_all(dev);
-   drm_encoder_unregister_all(dev);
-   drm_crtc_unregister_all(dev);
-   drm_plane_unregister_all(dev);
-}
-
-static int 

[PATCH 07/10] drm/print: Move kerneldoc next to definition

[Daniel Vetter]

kerneldoc expects the comment next to definitions, otherwise it can't
pick up exported vs. internal stuff.

This fixes a warning from the doc build done with:

$ make DOCBOOKS="" htmldocs

Fixes: d8187177b0b1 ("drm: add helper for printing to log or seq_file")
Cc: Rob Clark 
Cc: Sean Paul 
Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/drm-internals.rst | 2 +-
 drivers/gpu/drm/drm_print.c | 5 +
 include/drm/drm_print.h | 5 -
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/Documentation/gpu/drm-internals.rst 
b/Documentation/gpu/drm-internals.rst
index a54ac97510b3..e35920db1f4c 100644
--- a/Documentation/gpu/drm-internals.rst
+++ b/Documentation/gpu/drm-internals.rst
@@ -366,7 +366,7 @@ Printer
 .. kernel-doc:: include/drm/drm_print.h
:internal:

-.. kernel-doc:: include/drm/drm_print.h
+.. kernel-doc:: drivers/gpu/drm/drm_print.c
:export:


diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 34eb85618b76..ad3caaa1f48b 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -40,6 +40,11 @@ void __drm_printfn_info(struct drm_printer *p, struct 
va_format *vaf)
 }
 EXPORT_SYMBOL(__drm_printfn_info);

+/**
+ * drm_printf - print to a _printer stream
+ * @p: the _printer
+ * @f: format string
+ */
 void drm_printf(struct drm_printer *p, const char *f, ...)
 {
struct va_format vaf;
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index 475ffe3730e9..1adf84aea622 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -74,11 +74,6 @@ struct drm_printer {
 void __drm_printfn_seq_file(struct drm_printer *p, struct va_format *vaf);
 void __drm_printfn_info(struct drm_printer *p, struct va_format *vaf);

-/**
- * drm_printf - print to a _printer stream
- * @p: the _printer
- * @f: format string
- */
 void drm_printf(struct drm_printer *p, const char *f, ...);


-- 
2.10.2

[PATCH 06/10] drm: Consolidate dumb buffer docs

[Daniel Vetter]

Put the callback docs into struct drm_driver, and the small overview
into a DOC comment.

Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/drm-kms.rst  | 42 ++---
 drivers/gpu/drm/drm_dumb_buffers.c | 46 ++--
 include/drm/drm_drv.h  | 48 +-
 3 files changed, 67 insertions(+), 69 deletions(-)

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index cb0d3537b705..4edfb6d91250 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -72,46 +72,8 @@ DRM Format Handling
 Dumb Buffer Objects
 ===

-The KMS API doesn't standardize backing storage object creation and
-leaves it to driver-specific ioctls. Furthermore actually creating a
-buffer object even for GEM-based drivers is done through a
-driver-specific ioctl - GEM only has a common userspace interface for
-sharing and destroying objects. While not an issue for full-fledged
-graphics stacks that include device-specific userspace components (in
-libdrm for instance), this limit makes DRM-based early boot graphics
-unnecessarily complex.
-
-Dumb objects partly alleviate the problem by providing a standard API to
-create dumb buffers suitable for scanout, which can then be used to
-create KMS frame buffers.
-
-To support dumb objects drivers must implement the dumb_create,
-dumb_destroy and dumb_map_offset operations.
-
--  int (\*dumb_create)(struct drm_file \*file_priv, struct
-   drm_device \*dev, struct drm_mode_create_dumb \*args);
-   The dumb_create operation creates a driver object (GEM or TTM
-   handle) suitable for scanout based on the width, height and depth
-   from the struct :c:type:`struct drm_mode_create_dumb
-   ` argument. It fills the argument's
-   handle, pitch and size fields with a handle for the newly created
-   object and its line pitch and size in bytes.
-
--  int (\*dumb_destroy)(struct drm_file \*file_priv, struct
-   drm_device \*dev, uint32_t handle);
-   The dumb_destroy operation destroys a dumb object created by
-   dumb_create.
-
--  int (\*dumb_map_offset)(struct drm_file \*file_priv, struct
-   drm_device \*dev, uint32_t handle, uint64_t \*offset);
-   The dumb_map_offset operation associates an mmap fake offset with
-   the object given by the handle and returns it. Drivers must use the
-   :c:func:`drm_gem_create_mmap_offset()` function to associate
-   the fake offset as described in ?.
-
-Note that dumb objects may not be used for gpu acceleration, as has been
-attempted on some ARM embedded platforms. Such drivers really must have
-a hardware-specific ioctl to allocate suitable buffer objects.
+.. kernel-doc:: drivers/gpu/drm/drm_dumb_buffers.c
+   :doc: overview

 Plane Abstraction
 =
diff --git a/drivers/gpu/drm/drm_dumb_buffers.c 
b/drivers/gpu/drm/drm_dumb_buffers.c
index 4b4364b61c8d..139b40164206 100644
--- a/drivers/gpu/drm/drm_dumb_buffers.c
+++ b/drivers/gpu/drm/drm_dumb_buffers.c
@@ -25,24 +25,29 @@
 #include "drm_crtc_internal.h"

 /**
- * drm_mode_create_dumb_ioctl - create a dumb backing storage buffer
- * @dev: DRM device
- * @data: ioctl data
- * @file_priv: DRM file info
+ * DOC: overview
  *
- * This creates a new dumb buffer in the driver's backing storage manager (GEM,
- * TTM or something else entirely) and returns the resulting buffer handle. 
This
- * handle can then be wrapped up into a framebuffer modeset object.
+ * The KMS API doesn't standardize backing storage object creation and leaves 
it
+ * to driver-specific ioctls. Furthermore actually creating a buffer object 
even
+ * for GEM-based drivers is done through a driver-specific ioctl - GEM only has
+ * a common userspace interface for sharing and destroying objects. While not 
an
+ * issue for full-fledged graphics stacks that include device-specific 
userspace
+ * components (in libdrm for instance), this limit makes DRM-based early boot
+ * graphics unnecessarily complex.
  *
- * Note that userspace is not allowed to use such objects for render
- * acceleration - drivers must create their own private ioctls for such a use
- * case.
+ * Dumb objects partly alleviate the problem by providing a standard API to
+ * create dumb buffers suitable for scanout, which can then be used to create
+ * KMS frame buffers.
  *
- * Called by the user via ioctl.
+ * To support dumb objects drivers must implement the dumb_create,
+ * dumb_destroy and dumb_map_offset operations from struct _driver. See
+ * there for further details.
  *
- * Returns:
- * Zero on success, negative errno on failure.
+ * Note that dumb objects may not be used for gpu acceleration, as has been
+ * attempted on some ARM embedded platforms. Such drivers really must have
+ * a hardware-specific ioctl to allocate suitable buffer objects.
  */
+
 int drm_mode_create_dumb_ioctl(struct drm_device *dev,
   void *data, struct drm_file *file_priv)
 {
@@ -107,21 

[PATCH 05/10] drm: Clean up kerneldoc for struct drm_driver

[Daniel Vetter]

Just cleans up what's there, still plenty missing.

Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/drm-internals.rst |   3 +
 include/drm/drm_drv.h   | 168 +++-
 2 files changed, 109 insertions(+), 62 deletions(-)

diff --git a/Documentation/gpu/drm-internals.rst 
b/Documentation/gpu/drm-internals.rst
index 25ee92c5df65..a54ac97510b3 100644
--- a/Documentation/gpu/drm-internals.rst
+++ b/Documentation/gpu/drm-internals.rst
@@ -143,6 +143,9 @@ Device Instance and Driver Handling
 .. kernel-doc:: drivers/gpu/drm/drm_drv.c
:export:

+.. kernel-doc:: include/drm/drm_drv.h
+   :internal:
+
 Driver Load
 ---

diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 98f930a76e6d..4a0d3d941d5c 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -74,92 +74,110 @@ struct drm_driver {
int (*set_busid)(struct drm_device *dev, struct drm_master *master);

/**
-* get_vblank_counter - get raw hardware vblank counter
-* @dev: DRM device
-* @pipe: counter to fetch
+* @get_vblank_counter:
 *
-* Driver callback for fetching a raw hardware vblank counter for @crtc.
-* If a device doesn't have a hardware counter, the driver can simply
-* use drm_vblank_no_hw_counter() function. The DRM core will account 
for
+* Driver callback for fetching a raw hardware vblank counter for the
+* CRTC specified with the pipe argument.  If a device doesn't have a
+* hardware counter, the driver can simply use
+* drm_vblank_no_hw_counter() function. The DRM core will account for
 * missed vblank events while interrupts where disabled based on system
 * timestamps.
 *
 * Wraparound handling and loss of events due to modesetting is dealt
-* with in the DRM core code.
+* with in the DRM core code, as long as drivers call
+* drm_crtc_vblank_off() and drm_crtc_vblank_on() when disabling or
+* enabling a CRTC.
+*
+* Returns:
 *
-* RETURNS
 * Raw vblank counter value.
 */
u32 (*get_vblank_counter) (struct drm_device *dev, unsigned int pipe);

/**
-* enable_vblank - enable vblank interrupt events
-* @dev: DRM device
-* @pipe: which irq to enable
+* @enable_vblank:
+*
+* Enable vblank interrupts for the CRTC specified with the pipe
+* argument.
 *
-* Enable vblank interrupts for @crtc.  If the device doesn't have
-* a hardware vblank counter, the driver should use the
-* drm_vblank_no_hw_counter() function that keeps a virtual counter.
+* Returns:
 *
-* RETURNS
 * Zero on success, appropriate errno if the given @crtc's vblank
 * interrupt cannot be enabled.
 */
int (*enable_vblank) (struct drm_device *dev, unsigned int pipe);

/**
-* disable_vblank - disable vblank interrupt events
-* @dev: DRM device
-* @pipe: which irq to enable
+* @disable_vblank:
 *
-* Disable vblank interrupts for @crtc.  If the device doesn't have
-* a hardware vblank counter, the driver should use the
-* drm_vblank_no_hw_counter() function that keeps a virtual counter.
+* Disable vblank interrupts for the CRTC specified with the pipe
+* argument.
 */
void (*disable_vblank) (struct drm_device *dev, unsigned int pipe);

/**
-* Called by \c drm_device_is_agp.  Typically used to determine if a
-* card is really attached to AGP or not.
+* @device_is_agp:
+*
+* Called by drm_device_is_agp().  Typically used to determine if a card
+* is really attached to AGP or not.
 *
-* \param dev  DRM device handle
+* Returns:
 *
-* \returns
 * One of three values is returned depending on whether or not the
-* card is absolutely \b not AGP (return of 0), absolutely \b is AGP
+* card is absolutely not AGP (return of 0), absolutely is AGP
 * (return of 1), or may or may not be AGP (return of 2).
 */
int (*device_is_agp) (struct drm_device *dev);

/**
+* @get_scanout_position:
+*
 * Called by vblank timestamping code.
 *
-* Return the current display scanout position from a crtc, and an
-* optional accurate ktime_get timestamp of when position was measured.
+* Returns the current display scanout position from a crtc, and an
+* optional accurate ktime_get() timestamp of when position was
+* measured. Note that this is a helper callback which is only used if a
+* driver uses drm_calc_vbltimestamp_from_scanoutpos() for the
+* @get_vblank_timestamp callback.
+*
+* Parameters:
 *
-   

[PATCH 04/10] drm: Extract drm_drv.h

[Daniel Vetter]

I want to move dumb buffer documentation into the right vfuncs, and
for that I first need to be able to pull that into kerneldoc without
having to clean up all of drmP.h. Also, header-splitting is nice.

While at it shuffle all the function declarations for drm_drv.c into
the right spots, and drop the kerneldoc for drm_minor_acquire/release
since it's only used internally.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_drv.c  |  18 +--
 drivers/gpu/drm/drm_internal.h |   4 +
 include/drm/drmP.h | 299 +---
 include/drm/drm_drv.h  | 337 +
 4 files changed, 346 insertions(+), 312 deletions(-)
 create mode 100644 include/drm/drm_drv.h

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 98a083d4b81e..cc6c2530764b 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -32,7 +32,10 @@
 #include 
 #include 
 #include 
+
+#include 
 #include 
+
 #include "drm_crtc_internal.h"
 #include "drm_legacy.h"
 #include "drm_internal.h"
@@ -257,10 +260,7 @@ static void drm_minor_unregister(struct drm_device *dev, 
unsigned int type)
drm_debugfs_cleanup(minor);
 }

-/**
- * drm_minor_acquire - Acquire a DRM minor
- * @minor_id: Minor ID of the DRM-minor
- *
+/*
  * Looks up the given minor-ID and returns the respective DRM-minor object. The
  * refence-count of the underlying device is increased so you must release this
  * object with drm_minor_release().
@@ -268,10 +268,6 @@ static void drm_minor_unregister(struct drm_device *dev, 
unsigned int type)
  * As long as you hold this minor, it is guaranteed that the object and the
  * minor->dev pointer will stay valid! However, the device may get unplugged 
and
  * unregistered while you hold the minor.
- *
- * Returns:
- * Pointer to minor-object with increased device-refcount, or PTR_ERR on
- * failure.
  */
 struct drm_minor *drm_minor_acquire(unsigned int minor_id)
 {
@@ -294,12 +290,6 @@ struct drm_minor *drm_minor_acquire(unsigned int minor_id)
return minor;
 }

-/**
- * drm_minor_release - Release DRM minor
- * @minor: Pointer to DRM minor object
- *
- * Release a minor that was previously acquired via drm_minor_acquire().
- */
 void drm_minor_release(struct drm_minor *minor)
 {
drm_dev_unref(minor->dev);
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 1e29cbc556d5..db80ec860e33 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -43,6 +43,10 @@ void drm_prime_destroy_file_private(struct 
drm_prime_file_private *prime_fpriv);
 void drm_prime_remove_buf_handle_locked(struct drm_prime_file_private 
*prime_fpriv,
struct dma_buf *dma_buf);

+/* drm_drv.c */
+struct drm_minor *drm_minor_acquire(unsigned int minor_id);
+void drm_minor_release(struct drm_minor *minor);
+
 /* drm_info.c */
 int drm_name_info(struct seq_file *m, void *data);
 int drm_clients_info(struct seq_file *m, void* data);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index cfa4b80f0628..b352a7b812e6 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -76,6 +76,7 @@
 #include 
 #include 
 #include 
+#include 

 struct module;

@@ -137,34 +138,10 @@ struct dma_buf_attachment;
 #define DRM_UT_VBL 0x20
 #define DRM_UT_STATE   0x40

-extern __printf(6, 7)
-void drm_dev_printk(const struct device *dev, const char *level,
-   unsigned int category, const char *function_name,
-   const char *prefix, const char *format, ...);
-
-extern __printf(3, 4)
-void drm_printk(const char *level, unsigned int category,
-   const char *format, ...);
-
 /***/
 /** \name DRM template customization defaults */
 /*@{*/

-/* driver capabilities and requirements mask */
-#define DRIVER_USE_AGP 0x1
-#define DRIVER_LEGACY  0x2
-#define DRIVER_PCI_DMA 0x8
-#define DRIVER_SG  0x10
-#define DRIVER_HAVE_DMA0x20
-#define DRIVER_HAVE_IRQ0x40
-#define DRIVER_IRQ_SHARED  0x80
-#define DRIVER_GEM 0x1000
-#define DRIVER_MODESET 0x2000
-#define DRIVER_PRIME   0x4000
-#define DRIVER_RENDER  0x8000
-#define DRIVER_ATOMIC  0x1
-#define DRIVER_KMS_LEGACY_CONTEXT  0x2
-
 /***/
 /** \name Macros to make printk easier */
 /*@{*/
@@ -480,263 +457,6 @@ struct drm_lock_data {
 #define DRM_SCANOUTPOS_IN_VBLANK(1 << 1)
 #define DRM_SCANOUTPOS_ACCURATE (1 << 2)

-/**
- * DRM driver structure. This structure represent the common code for
- * a family of cards. There will one drm_device for each card present
- * in this family
- */
-struct 

[PATCH 03/10] doc/dma-buf: Fix up include directives

[Daniel Vetter]

Would be great if everony could add

$ make DOCBOOKS="" htmldocs

to their build scripts to catch these. 0day should also report them,
not sure why it failed to spot this.

Fixes: f54d1867005c ("dma-buf: Rename struct fence to dma_fence")
Cc: Chris Wilson 
Cc: Gustavo Padovan 
Cc: Sumit Semwal 
Cc: Christian König 
Signed-off-by: Daniel Vetter 
---
 Documentation/driver-api/infrastructure.rst | 8 
 include/linux/dma-fence.h   | 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/driver-api/infrastructure.rst 
b/Documentation/driver-api/infrastructure.rst
index 5d50d6733db3..a0d65eb49055 100644
--- a/Documentation/driver-api/infrastructure.rst
+++ b/Documentation/driver-api/infrastructure.rst
@@ -86,10 +86,10 @@ reservation
 fence
 ~

-.. kernel-doc:: drivers/dma-buf/fence.c
+.. kernel-doc:: drivers/dma-buf/dma-fence.c
:export:

-.. kernel-doc:: include/linux/fence.h
+.. kernel-doc:: include/linux/dma-fence.h
:internal:

 .. kernel-doc:: drivers/dma-buf/seqno-fence.c
@@ -98,10 +98,10 @@ fence
 .. kernel-doc:: include/linux/seqno-fence.h
:internal:

-.. kernel-doc:: drivers/dma-buf/fence-array.c
+.. kernel-doc:: drivers/dma-buf/dma-fence-array.c
:export:

-.. kernel-doc:: include/linux/fence-array.h
+.. kernel-doc:: include/linux/dma-fence-array.h
:internal:

 .. kernel-doc:: drivers/dma-buf/reservation.c
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index fcf4b1971eba..d51a7d23c358 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -225,7 +225,7 @@ static inline struct dma_fence *dma_fence_get_rcu(struct 
dma_fence *fence)

 /**
  * dma_fence_get_rcu_safe  - acquire a reference to an RCU tracked fence
- * @fence: [in]pointer to fence to increase refcount of
+ * @fencep:[in]pointer to fence to increase refcount of
  *
  * Function returns NULL if no refcount could be obtained, or the fence.
  * This function handles acquiring a reference to a fence that may be
-- 
2.10.2

[PATCH 02/10] drm/i915: Fixup kerneldoc includes

[Daniel Vetter]

Would be great if everony could add

$ make DOCBOOKS="" htmldocs

to their build scripts to catch these. 0day should also report them,
not sure why it failed to spot this.

Fixes: b42fe9ca0a1e ("drm/i915: Split out i915_vma.c")
Cc: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Signed-off-by: Daniel Vetter 
---
 Documentation/gpu/i915.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index ba83b7d88f1f..117d2ab7a5f7 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -258,19 +258,19 @@ Global GTT views
 GTT Fences and Swizzling
 

-.. kernel-doc:: drivers/gpu/drm/i915/i915_gem_fence.c
+.. kernel-doc:: drivers/gpu/drm/i915/i915_gem_fence_reg.c
:internal:

 Global GTT Fence Handling
 ~

-.. kernel-doc:: drivers/gpu/drm/i915/i915_gem_fence.c
+.. kernel-doc:: drivers/gpu/drm/i915/i915_gem_fence_reg.c
:doc: fence register handling

 Hardware Tiling and Swizzling Details
 ~

-.. kernel-doc:: drivers/gpu/drm/i915/i915_gem_fence.c
+.. kernel-doc:: drivers/gpu/drm/i915/i915_gem_fence_reg.c
:doc: tiling swizzling details

 Object Tiling IOCTLs
-- 
2.10.2