Re: [Intel-gfx] [PATCH 2/5] drm/edid: Introduce drm_default_rgb_quant_range()

[Daniel Vetter]

On Wed, Jan 11, 2017 at 06:31:52PM +0200, Ville Syrjälä wrote:
> On Wed, Jan 11, 2017 at 05:16:54PM +0100, Daniel Vetter wrote:
> > On Wed, Jan 11, 2017 at 02:57:22PM +0200, ville.syrj...@linux.intel.com 
> > wrote:
> > > From: Ville Syrjälä 
> > > 
> > > Make the code selecting the RGB quantization range a little less magicy
> > > by wrapping it up in a small helper.
> > > 
> > > Signed-off-by: Ville Syrjälä 
> > 
> > Needs cc: for driver maintainers, Eric for vc4 here.
> 
> Eric was cc:d. I was just too lazy to add the cc:s to all the commit
> messages, and so i just used --cc on the whole lot.

Hm, he's not on the cc: list over here (on the mails, not in the patch
body).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 2/5] drm/edid: Introduce drm_default_rgb_quant_range()

[Michel Dänzer]

On 12/01/17 05:00 PM, Daniel Vetter wrote:
> On Wed, Jan 11, 2017 at 06:31:52PM +0200, Ville Syrjälä wrote:
>> On Wed, Jan 11, 2017 at 05:16:54PM +0100, Daniel Vetter wrote:
>>> On Wed, Jan 11, 2017 at 02:57:22PM +0200, ville.syrj...@linux.intel.com 
>>> wrote:
 From: Ville Syrjälä 

 Make the code selecting the RGB quantization range a little less magicy
 by wrapping it up in a small helper.

 Signed-off-by: Ville Syrjälä 
>>>
>>> Needs cc: for driver maintainers, Eric for vc4 here.
>>
>> Eric was cc:d. I was just too lazy to add the cc:s to all the commit
>> messages, and so i just used --cc on the whole lot.
> 
> Hm, he's not on the cc: list over here (on the mails, not in the patch
> body).

That could be because he has "Avoid duplicate copies of messages?"
enabled in his mailman subscription options.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/5] drm/exynos: Stop using drm_framebuffer_unregister_private

[Inki Dae]

Applied.

Thanks.

2016년 12월 27일 19:49에 Daniel Vetter 이(가) 쓴 글:
> This is the deprecated function for when you embedded the framebuffer
> somewhere else (which breaks refcounting). But exynos is using
> drm_framebuffer_remove and a free-standing fb, so this is rendundant.
> 
> Cc: Inki Dae 
> Cc: Joonyoung Shim 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> index d8808158d418..a7884bea42eb 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> @@ -270,10 +270,8 @@ static void exynos_drm_fbdev_destroy(struct drm_device 
> *dev,
>   /* release drm framebuffer and real buffer */
>   if (fb_helper->fb && fb_helper->fb->funcs) {
>   fb = fb_helper->fb;
> - if (fb) {
> - drm_framebuffer_unregister_private(fb);
> + if (fb)
>   drm_framebuffer_remove(fb);
> - }
>   }
>  
>   drm_fb_helper_unregister_fbi(fb_helper);
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/atomic: Add target_vblank support in atomic helpers (v2)

[Michel Dänzer]

On 12/01/17 12:48 AM, Grodzovsky, Andrey wrote:
>> From: Michel Dänzer [mailto:mic...@daenzer.net]
>> On 09/01/17 06:59 PM, Daniel Vetter wrote:
>>> On Fri, Jan 06, 2017 at 03:39:40PM -0500, Andrey Grodzovsky wrote:
 Allows usage of the new page_flip_target hook for drivers
 implementing the atomic path.
 Provides default atomic helper for the new hook.

 v2:
 Update code sharing logic between exsiting and the new flip hooks.
 Improve kerneldoc.

 Signed-off-by: Andrey Grodzovsky 
>>>
>>> Looks all reasonable, I think an ack from Alex that the amd side is in
>>> shape too, and I'll pull this into drm-misc.
>>
>> Andrey, is there an updated patch 2 adapted to current patch 1? Other than
>> that and some questionable indentation of parameters in function
>> signatures, looks good to me FWIW.
> 
> We are unable to use the atomic helpers both for page_flip and 
> page_flip_target
> At their current form mostly due to DRM_MODE_PAGE_FLIP_ASYNC flag rejection 
> they do. 
> I discussed this with Daniel Vetter on IRC and suggested 
> to remove the rejection but he said the precise semantics of 
> atomic async flip is not clear yet and it's better to leave that out for now 
> until there is a  userspace asking for it.
> So I tested it by just hacking  the helper to remove the rejection.
> Until that settled the original change [PATCH 2/2] drm/amd/dal: Switch to 
> page_flip_target hook in DAL
> Is what we plan to use in DAL

IIRC Daniel suggested (on IRC?) to use the helper for non-async flips
and the current DC code for async flips. Is that feasible?


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/nouveau: Handle fbcon suspend/resume in seperate worker

[Hans de Goede]

Hi,

Good catch (both the previous patch as well as this one).
I've one small comment inline:

On 12-01-17 03:25, Lyude wrote:

Resuming from RPM can happen while already holding
dev->mode_config.mutex. This means we can't actually handle fbcon in
any RPM resume workers, since restoring fbcon requires grabbing
dev->mode_config.mutex again. So move the fbcon suspend/resume code into
it's own worker, and rely on that instead to avoid deadlocking.

This fixes more deadlocks for runtime suspending the GPU on the ThinkPad
W541. Reproduction recipe:

 - Get a machine with both optimus and a nvidia card with connectors
   attached to it
 - Wait for the nvidia GPU to suspend
 - Attempt to manually reprobe any of the connectors on the nvidia GPU
   using sysfs
 - *deadlock*

Signed-off-by: Lyude 
Cc: Hans de Goede 
Cc: Kilian Singer 
Cc: Lukas Wunner 
Cc: David Airlie 
---
 drivers/gpu/drm/nouveau/nouveau_drv.h   |  2 ++
 drivers/gpu/drm/nouveau/nouveau_fbcon.c | 43 ++---
 2 files changed, 36 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h 
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index 8d5ed5b..42c1fa5 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -165,6 +165,8 @@ struct nouveau_drm {
struct backlight_device *backlight;
struct list_head bl_connectors;
struct work_struct hpd_work;
+   struct work_struct fbcon_work;
+   int fbcon_new_state;
 #ifdef CONFIG_ACPI
struct notifier_block acpi_nb;
 #endif
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index 2f2a3dc..87cd30b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -470,19 +470,43 @@ static const struct drm_fb_helper_funcs 
nouveau_fbcon_helper_funcs = {
.fb_probe = nouveau_fbcon_create,
 };

+static void
+nouveau_fbcon_set_suspend_work(struct work_struct *work)
+{
+   struct nouveau_drm *drm = container_of(work, typeof(*drm), fbcon_work);
+   int state = drm->fbcon_new_state;


The compiler may decide to optimize away this variable
and simply use drm->fbcon_new_state in the if-s below,
which is racy. I would fix this by making
drm->fbcon_new_state an atomic_t and using

atomic_read(&drm->fbcon_new_state) here.
(and atomic_set below).

Regards,

Hans




+
+   if (state == FBINFO_STATE_RUNNING)
+   pm_runtime_get_sync(drm->dev->dev);
+
+   console_lock();
+   if (state == FBINFO_STATE_RUNNING)
+   nouveau_fbcon_accel_restore(drm->dev);
+   drm_fb_helper_set_suspend(&drm->fbcon->helper, state);
+   if (state != FBINFO_STATE_RUNNING)
+   nouveau_fbcon_accel_save_disable(drm->dev);
+   console_unlock();
+
+   if (state == FBINFO_STATE_RUNNING) {
+   pm_runtime_mark_last_busy(drm->dev->dev);
+   pm_runtime_put_sync(drm->dev->dev);
+   }
+}
+
 void
 nouveau_fbcon_set_suspend(struct drm_device *dev, int state)
 {
struct nouveau_drm *drm = nouveau_drm(dev);
-   if (drm->fbcon) {
-   console_lock();
-   if (state == FBINFO_STATE_RUNNING)
-   nouveau_fbcon_accel_restore(dev);
-   drm_fb_helper_set_suspend(&drm->fbcon->helper, state);
-   if (state != FBINFO_STATE_RUNNING)
-   nouveau_fbcon_accel_save_disable(dev);
-   console_unlock();
-   }
+
+   if (!drm->fbcon)
+   return;
+
+   drm->fbcon_new_state = state;
+   /* Since runtime resume can happen as a result of a sysfs operation,
+* it's possible we already have the console locked. So handle fbcon
+* init/deinit from a seperate work thread
+*/
+   schedule_work(&drm->fbcon_work);
 }

 int
@@ -502,6 +526,7 @@ nouveau_fbcon_init(struct drm_device *dev)
return -ENOMEM;

drm->fbcon = fbcon;
+   INIT_WORK(&drm->fbcon_work, nouveau_fbcon_set_suspend_work);

drm_fb_helper_prepare(dev, &fbcon->helper, &nouveau_fbcon_helper_funcs);



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

Re: [PATCH] drm/atomic: Add target_vblank support in atomic helpers (v2)

[Daniel Vetter]

On Thu, Jan 12, 2017 at 9:28 AM, Michel Dänzer  wrote:
> On 12/01/17 12:48 AM, Grodzovsky, Andrey wrote:
>>> From: Michel Dänzer [mailto:mic...@daenzer.net]
>>> On 09/01/17 06:59 PM, Daniel Vetter wrote:
 On Fri, Jan 06, 2017 at 03:39:40PM -0500, Andrey Grodzovsky wrote:
> Allows usage of the new page_flip_target hook for drivers
> implementing the atomic path.
> Provides default atomic helper for the new hook.
>
> v2:
> Update code sharing logic between exsiting and the new flip hooks.
> Improve kerneldoc.
>
> Signed-off-by: Andrey Grodzovsky 

 Looks all reasonable, I think an ack from Alex that the amd side is in
 shape too, and I'll pull this into drm-misc.
>>>
>>> Andrey, is there an updated patch 2 adapted to current patch 1? Other than
>>> that and some questionable indentation of parameters in function
>>> signatures, looks good to me FWIW.
>>
>> We are unable to use the atomic helpers both for page_flip and 
>> page_flip_target
>> At their current form mostly due to DRM_MODE_PAGE_FLIP_ASYNC flag rejection 
>> they do.
>> I discussed this with Daniel Vetter on IRC and suggested
>> to remove the rejection but he said the precise semantics of
>> atomic async flip is not clear yet and it's better to leave that out for now
>> until there is a  userspace asking for it.
>> So I tested it by just hacking  the helper to remove the rejection.
>> Until that settled the original change [PATCH 2/2] drm/amd/dal: Switch to 
>> page_flip_target hook in DAL
>> Is what we plan to use in DAL
>
> IIRC Daniel suggested (on IRC?) to use the helper for non-async flips
> and the current DC code for async flips. Is that feasible?

We do have some async flip flag reserved for atomic, so we could route
it through. But since atm there's no one asking for async flips on the
atomic ioctl I'm a bit wary for fear of ending up with ill-defined
semantics. But I guess if we do this for legacy pageflips only, and
make sure we do still reject async flips submitted through the atomic
ioctl that should be all fine. And it should allow amdgpu to entirely
get rid of the legacy flip path, which would be nice.

Once we have that we could even use it for cursor plane updates
(through the legacy ioctl, for drivers with universal planes), for
those drivers that support it.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: fix MMU dependencies

[Benjamin Gaignard]

DRM_VM and DRM_LEGACY shouldn't be selected if MMU isn't set.

Fixes: 62a0d98a188c ("drm: allow to use mmuless SoC")
Signed-off-by: Benjamin Gaignard 
Cc: Arnd Bergmann 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 6f3f9e6..90bc65d 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -138,7 +138,7 @@ config DRM_KMS_CMA_HELPER
 
 config DRM_VM
bool
-   depends on DRM
+   depends on DRM && MMU
 
 source "drivers/gpu/drm/i2c/Kconfig"
 
@@ -267,7 +267,7 @@ source "drivers/gpu/drm/meson/Kconfig"
 
 menuconfig DRM_LEGACY
bool "Enable legacy drivers (DANGEROUS)"
-   depends on DRM
+   depends on DRM && MMU
select DRM_VM
help
  Enable legacy DRI1 drivers. Those drivers expose unsafe and dangerous
-- 
1.9.1

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

[PATCH v5 1/4] drm/bridge: analogix_dp: set connector to drm_dp_aux

[Tomeu Vizoso]

Set the backpointer so that the DP helpers are able to access the
connector that the drm_dp_aux is associated with.

Signed-off-by: Tomeu Vizoso 
---

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index e7cd1056ff2d..44c2b74bf771 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1403,26 +1403,28 @@ int analogix_dp_bind(struct device *dev, struct 
drm_device *drm_dev,
dp->drm_dev = drm_dev;
dp->encoder = dp->plat_data->encoder;
 
+   ret = analogix_dp_create_bridge(drm_dev, dp);
+   if (ret) {
+   DRM_ERROR("failed to create bridge (%d)\n", ret);
+   goto err_encoder_cleanup;
+   }
+
dp->aux.name = "DP-AUX";
dp->aux.transfer = analogix_dpaux_transfer;
dp->aux.dev = &pdev->dev;
+   dp->aux.connector = &dp->connector;
 
ret = drm_dp_aux_register(&dp->aux);
if (ret)
-   goto err_disable_pm_runtime;
-
-   ret = analogix_dp_create_bridge(drm_dev, dp);
-   if (ret) {
-   DRM_ERROR("failed to create bridge (%d)\n", ret);
-   drm_encoder_cleanup(dp->encoder);
-   goto err_disable_pm_runtime;
-   }
+   goto err_encoder_cleanup;
 
phy_power_off(dp->phy);
pm_runtime_put(dev);
 
return 0;
 
+err_encoder_cleanup:
+   drm_encoder_cleanup(dp->encoder);
 err_disable_pm_runtime:
 
phy_power_off(dp->phy);
-- 
2.9.3

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

[PATCH v5 0/4] drm/dp: Implement CRC debugfs API

[Tomeu Vizoso]

Hi,

this series builds up on the API for exposing captured CRCs through
debugfs.

It adds new DP helpers for starting and stopping CRC capture and gets
the Rockchip driver to use it.

Also had to add a connector backpointer to the drm_dp_aux struct so we could
wait for the right vblank and store the CRCs afterwards, I will be glad
to hear about better alternatives.

With these patches, tests in IGT such as kms_pipe_crc_basic and
kms_plane do pass on RK3288.

In this v5, "drm/dp: add helpers for capture of frame CRCs" has gone
back to the more explicit way of just retrying once.

Also, I have left the connector back pointer in the AUX structure, as on
IRC nor danvet nor me could find a good reason to change it.

Thanks,

Tomeu


Tomeu Vizoso (4):
  drm/bridge: analogix_dp: set connector to drm_dp_aux
  drm/dp: add helpers for capture of frame CRCs
  drm/bridge: analogix_dp: add helpers for capture of frame CRCs
  drm/rockchip: Implement CRC debugfs API

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  34 --
 drivers/gpu/drm/drm_dp_helper.c| 124 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c|  42 +++
 include/drm/bridge/analogix_dp.h   |   3 +
 include/drm/drm_dp_helper.h|   7 ++
 5 files changed, 202 insertions(+), 8 deletions(-)

-- 
2.9.3

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

[PATCH v5 3/4] drm/bridge: analogix_dp: add helpers for capture of frame CRCs

[Tomeu Vizoso]

Add two simple functions that just take the drm_dp_aux from our struct
and calls the corresponding DP helpers with it.

Signed-off-by: Tomeu Vizoso 
---

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 16 
 include/drm/bridge/analogix_dp.h   |  3 +++
 2 files changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 44c2b74bf771..f5e0379d9abe 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1490,6 +1490,22 @@ int analogix_dp_resume(struct device *dev)
 EXPORT_SYMBOL_GPL(analogix_dp_resume);
 #endif
 
+int analogix_dp_start_crc(struct drm_connector *connector)
+{
+   struct analogix_dp_device *dp = to_dp(connector);
+
+   return drm_dp_start_crc(&dp->aux);
+}
+EXPORT_SYMBOL_GPL(analogix_dp_start_crc);
+
+int analogix_dp_stop_crc(struct drm_connector *connector)
+{
+   struct analogix_dp_device *dp = to_dp(connector);
+
+   return drm_dp_stop_crc(&dp->aux);
+}
+EXPORT_SYMBOL_GPL(analogix_dp_stop_crc);
+
 MODULE_AUTHOR("Jingoo Han ");
 MODULE_DESCRIPTION("Analogix DP Core Driver");
 MODULE_LICENSE("GPL v2");
diff --git a/include/drm/bridge/analogix_dp.h b/include/drm/bridge/analogix_dp.h
index f6f0c062205c..c99d6eaef1ac 100644
--- a/include/drm/bridge/analogix_dp.h
+++ b/include/drm/bridge/analogix_dp.h
@@ -49,4 +49,7 @@ int analogix_dp_bind(struct device *dev, struct drm_device 
*drm_dev,
 struct analogix_dp_plat_data *plat_data);
 void analogix_dp_unbind(struct device *dev, struct device *master, void *data);
 
+int analogix_dp_start_crc(struct drm_connector *connector);
+int analogix_dp_stop_crc(struct drm_connector *connector);
+
 #endif /* _ANALOGIX_DP_H_ */
-- 
2.9.3

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

[PATCH v5 2/4] drm/dp: add helpers for capture of frame CRCs

[Tomeu Vizoso]

Adds helpers for starting and stopping capture of frame CRCs through the
DPCD. When capture is on, a worker waits for vblanks and retrieves the
frame CRC to put it in the queue on the CRTC that is using the
eDP connector, so it's passed to userspace.

v2: Reuse drm_crtc_wait_one_vblank
Update locking, as drm_crtc_add_crc_entry now takes the lock

v3: Don't call wake_up_interruptible directly, that's now done in
drm_crtc_add_crc_entry.

v4: Style fixes (Sean Paul)
Reworked retry of CRC reads (Sean Paul)
Flush worker after stopping CRC generationa (Sean Paul)

v5: Move back to make the retry explicitly once

Signed-off-by: Tomeu Vizoso 
---

 drivers/gpu/drm/drm_dp_helper.c | 124 
 include/drm/drm_dp_helper.h |   7 +++
 2 files changed, 131 insertions(+)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 3e6fe82c6d64..6dd550c7a8bd 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -981,6 +981,78 @@ static const struct i2c_lock_operations 
drm_dp_i2c_lock_ops = {
.unlock_bus = unlock_bus,
 };
 
+static int drm_dp_aux_get_crc(struct drm_dp_aux *aux, u8 *crc)
+{
+   u8 buf, count;
+   int ret;
+
+   ret = drm_dp_dpcd_readb(aux, DP_TEST_SINK, &buf);
+   if (ret < 0)
+   return ret;
+
+   WARN_ON(!(buf & DP_TEST_SINK_START));
+
+   ret = drm_dp_dpcd_readb(aux, DP_TEST_SINK_MISC, &buf);
+   if (ret < 0)
+   return ret;
+
+   count = buf & DP_TEST_COUNT_MASK;
+   if (count == aux->crc_count)
+   return -EAGAIN; /* No CRC yet */
+
+   aux->crc_count = count;
+
+   /*
+* At DP_TEST_CRC_R_CR, there's 6 bytes containing CRC data, 2 bytes
+* per component (RGB or CrYCb).
+*/
+   ret = drm_dp_dpcd_read(aux, DP_TEST_CRC_R_CR, crc, 6);
+   if (ret < 0)
+   return ret;
+
+   return 0;
+}
+
+static void drm_dp_aux_crc_work(struct work_struct *work)
+{
+   struct drm_dp_aux *aux = container_of(work, struct drm_dp_aux,
+ crc_work);
+   struct drm_crtc *crtc;
+   u8 crc_bytes[6];
+   uint32_t crcs[3];
+   int ret;
+
+   if (WARN_ON(!aux->connector))
+   return;
+
+   crtc = aux->connector->state->crtc;
+   while (crtc->crc.opened) {
+   drm_crtc_wait_one_vblank(crtc);
+   if (!crtc->crc.opened)
+   break;
+
+   ret = drm_dp_aux_get_crc(aux, crc_bytes);
+   if (ret == -EAGAIN) {
+   usleep_range(1000, 2000);
+   ret = drm_dp_aux_get_crc(aux, crc_bytes);
+   }
+
+   if (ret == -EAGAIN) {
+   DRM_DEBUG_KMS("Get CRC failed after retrying: %d\n",
+ ret);
+   continue;
+   } else if (ret) {
+   DRM_DEBUG_KMS("Failed to get a CRC: %d\n", ret);
+   continue;
+   }
+
+   crcs[0] = crc_bytes[0] | crc_bytes[1] << 8;
+   crcs[1] = crc_bytes[2] | crc_bytes[3] << 8;
+   crcs[2] = crc_bytes[4] | crc_bytes[5] << 8;
+   drm_crtc_add_crc_entry(crtc, false, 0, crcs);
+   }
+}
+
 /**
  * drm_dp_aux_init() - minimally initialise an aux channel
  * @aux: DisplayPort AUX channel
@@ -993,6 +1065,7 @@ static const struct i2c_lock_operations 
drm_dp_i2c_lock_ops = {
 void drm_dp_aux_init(struct drm_dp_aux *aux)
 {
mutex_init(&aux->hw_mutex);
+   INIT_WORK(&aux->crc_work, drm_dp_aux_crc_work);
 
aux->ddc.algo = &drm_dp_i2c_algo;
aux->ddc.algo_data = aux;
@@ -1081,3 +1154,54 @@ int drm_dp_psr_setup_time(const u8 
psr_cap[EDP_PSR_RECEIVER_CAP_SIZE])
 EXPORT_SYMBOL(drm_dp_psr_setup_time);
 
 #undef PSR_SETUP_TIME
+
+/**
+ * drm_dp_start_crc() - start capture of frame CRCs
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int drm_dp_start_crc(struct drm_dp_aux *aux)
+{
+   u8 buf;
+   int ret;
+
+   ret = drm_dp_dpcd_readb(aux, DP_TEST_SINK, &buf);
+   if (ret < 0)
+   return ret;
+
+   ret = drm_dp_dpcd_writeb(aux, DP_TEST_SINK, buf | DP_TEST_SINK_START);
+   if (ret < 0)
+   return ret;
+
+   aux->crc_count = 0;
+   schedule_work(&aux->crc_work);
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_dp_start_crc);
+
+/**
+ * drm_dp_stop_crc() - stop capture of frame CRCs
+ * @aux: DisplayPort AUX channel
+ *
+ * Returns 0 on success or a negative error code on failure.
+ */
+int drm_dp_stop_crc(struct drm_dp_aux *aux)
+{
+   u8 buf;
+   int ret;
+
+   ret = drm_dp_dpcd_readb(aux, DP_TEST_SINK, &buf);
+   if (ret < 0)
+   return ret;
+
+   ret = drm_dp_dpcd_writeb(aux, DP_TEST_SINK, buf & ~DP_TEST_SINK_START);
+   if (ret < 0)
+   

[PATCH v5 4/4] drm/rockchip: Implement CRC debugfs API

[Tomeu Vizoso]

Implement the .set_crc_source() callback and call the DP helpers
accordingly to start and stop CRC capture.

This is only done if this CRTC is currently using the eDP connector.

v3: Remove superfluous check on rockchip_crtc_state->output_type

Signed-off-by: Tomeu Vizoso 
---

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 42 +
 1 file changed, 42 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index fb5f001f51c3..6e5eb1aa182a 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1105,6 +1106,46 @@ static void vop_crtc_destroy_state(struct drm_crtc *crtc,
kfree(s);
 }
 
+static struct drm_connector *vop_get_edp_connector(struct vop *vop)
+{
+   struct drm_crtc *crtc = &vop->crtc;
+   struct drm_connector *connector;
+
+   mutex_lock(&crtc->dev->mode_config.mutex);
+   drm_for_each_connector(connector, crtc->dev)
+   if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) {
+   mutex_unlock(&crtc->dev->mode_config.mutex);
+   return connector;
+   }
+   mutex_unlock(&crtc->dev->mode_config.mutex);
+
+   return NULL;
+}
+
+static int vop_crtc_set_crc_source(struct drm_crtc *crtc,
+  const char *source_name, size_t *values_cnt)
+{
+   struct vop *vop = to_vop(crtc);
+   struct rockchip_crtc_state *s = to_rockchip_crtc_state(crtc->state);
+   struct drm_connector *connector;
+   int ret;
+
+   connector = vop_get_edp_connector(vop);
+   if (!connector)
+   return -EINVAL;
+
+   *values_cnt = 3;
+
+   if (source_name && strcmp(source_name, "auto") == 0)
+   ret = analogix_dp_start_crc(connector);
+   else if (!source_name)
+   ret = analogix_dp_stop_crc(connector);
+   else
+   ret = -EINVAL;
+
+   return ret;
+}
+
 static const struct drm_crtc_funcs vop_crtc_funcs = {
.set_config = drm_atomic_helper_set_config,
.page_flip = drm_atomic_helper_page_flip,
@@ -1112,6 +1153,7 @@ static const struct drm_crtc_funcs vop_crtc_funcs = {
.reset = vop_crtc_reset,
.atomic_duplicate_state = vop_crtc_duplicate_state,
.atomic_destroy_state = vop_crtc_destroy_state,
+   .set_crc_source = vop_crtc_set_crc_source,
 };
 
 static void vop_fb_unref_worker(struct drm_flip_work *work, void *val)
-- 
2.9.3

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

Re: [Intel-gfx] GPU hang with kernel 4.10rc3

[Chris Wilson]

On Thu, Jan 12, 2017 at 07:03:25AM +0100, Juergen Gross wrote:
> On 11/01/17 18:08, Chris Wilson wrote:
> > On Wed, Jan 11, 2017 at 05:33:34PM +0100, Juergen Gross wrote:
> >> With kernel 4.10rc3 running as Xen dm0 I get at each boot:
> >>
> >> [   49.213697] [drm] GPU HANG: ecode 7:0:0x3d1d3d3d, in gnome-shell
> >> [1431], reason: Hang on render ring, action: reset
> >> [   49.213699] [drm] GPU hangs can indicate a bug anywhere in the entire
> >> gfx stack, including userspace.
> >> [   49.213700] [drm] Please file a _new_ bug report on
> >> bugs.freedesktop.org against DRI -> DRM/Intel
> >> [   49.213700] [drm] drm/i915 developers can then reassign to the right
> >> component if it's not a kernel issue.
> >> [   49.213700] [drm] The gpu crash dump is required to analyze gpu
> >> hangs, so please always attach it.
> >> [   49.213701] [drm] GPU crash dump saved to /sys/class/drm/card0/error
> >> [   49.213755] drm/i915: Resetting chip after gpu hang
> >> [   60.213769] drm/i915: Resetting chip after gpu hang
> >> [   71.189737] drm/i915: Resetting chip after gpu hang
> >> [   82.165747] drm/i915: Resetting chip after gpu hang
> >> [   93.205727] drm/i915: Resetting chip after gpu hang
> >>
> >> The dump is attached.
> > 
> > That's a nasty one. The first couple of pages of the batchbuffer appear
> > to be overwritten. (Full of 0xc2c2c2c2, i.e. probably pixel data.) That
> > may be a concurrent write by either the GPU or CPU, or we may have
> > incorrected mapped a set of pages. That it doesn't recovered suggests
> > that the corruption occurs frequently, probably on every request/batch.
> 
> I hoped someone would have an idea already.

Sorry, first report of something like this in a long time (that I can
remember at least). And the problem is that it can be anything from a
coherency to a concurrency issue, so no one patch springs to mind.
Thankfully it appears to be kernel related.
-Chris

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

Re: [Intel-gfx] [PATCH 1/5] drm/edid: Have drm_edid.h include hdmi.h

[Jani Nikula]

On Wed, 11 Jan 2017, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
>
> drm_edid.h depends on hdmi.h on account of enum hdmi_picture_aspect,
> so let's just include hdmi.h and drop some useless struct declarations.
>
> Signed-off-by: Ville Syrjälä 

Reviewed-by: Jani Nikula 


> ---
>  include/drm/drm_edid.h | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 38eabf65f19d..838eaf2b42e9 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -24,6 +24,7 @@
>  #define __DRM_EDID_H__
>  
>  #include 
> +#include 
>  
>  struct drm_device;
>  struct i2c_adapter;
> @@ -322,8 +323,6 @@ struct cea_sad {
>  struct drm_encoder;
>  struct drm_connector;
>  struct drm_display_mode;
> -struct hdmi_avi_infoframe;
> -struct hdmi_vendor_infoframe;
>  
>  void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid);
>  int drm_edid_to_sad(struct edid *edid, struct cea_sad **sads);

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

Re: [PATCH] drm/exynos/decon5433: update shadow registers iff there are active windows

[Inki Dae]

Applied.

Thanks.

2017년 01월 09일 23:33에 Andrzej Hajda 이(가) 쓴 글:
> Improper usage of DECON_UPDATE register leads to subtle errors.
> If it set in decon_commit when there are no active windows it results
> in slow registry updates - all subsequent shadow registry updates takes more
> than full vblank. On the other side if it is not set when there are
> active windows it results in garbage on the screen after suspend/resume of
> FB console.
> 
> The patch hopefully fixes it.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> index ca75fe1..f15d9b1 100644
> --- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
> @@ -209,8 +209,6 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
>  
>   /* enable output and display signal */
>   decon_set_bits(ctx, DECON_VIDCON0, VIDCON0_ENVID | VIDCON0_ENVID_F, ~0);
> -
> - decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
>  }
>  
>  static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int win,
> @@ -361,8 +359,9 @@ static void decon_atomic_flush(struct exynos_drm_crtc 
> *crtc)
>   for (i = ctx->first_win; i < WINDOWS_NR; i++)
>   decon_shadow_protect_win(ctx, i, false);
>  
> - /* standalone update */
> - decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
> + /* update iff there are active windows */
> + if (crtc->base.state->plane_mask)
> + decon_set_bits(ctx, DECON_UPDATE, STANDALONE_UPDATE_F, ~0);
>  
>   if (ctx->out_type & IFTYPE_I80)
>   set_bit(BIT_WIN_UPDATED, &ctx->flags);
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2.1 6/7] drm/atomic: Convert get_existing_state callers to get_old/new_state, v2.

[Maarten Lankhorst]

This is a straightforward conversion that converts all the users of
get_existing_state in atomic core to use get_old_state or get_new_state

Changes since v1:
- Fix using the wrong state in drm_atomic_helper_update_legacy_modeset_state.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_atomic.c|  6 +++---
 drivers/gpu/drm/drm_atomic_helper.c | 39 +
 drivers/gpu/drm/drm_blend.c |  3 +--
 3 files changed, 22 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 7b61e0da9ace..6428e9469607 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1362,8 +1362,8 @@ drm_atomic_set_crtc_for_connector(struct 
drm_connector_state *conn_state,
return 0;
 
if (conn_state->crtc) {
-   crtc_state = 
drm_atomic_get_existing_crtc_state(conn_state->state,
-   
conn_state->crtc);
+   crtc_state = drm_atomic_get_new_crtc_state(conn_state->state,
+  conn_state->crtc);
 
crtc_state->connector_mask &=
~(1 << drm_connector_index(conn_state->connector));
@@ -1480,7 +1480,7 @@ drm_atomic_add_affected_planes(struct drm_atomic_state 
*state,
 {
struct drm_plane *plane;
 
-   WARN_ON(!drm_atomic_get_existing_crtc_state(state, crtc));
+   WARN_ON(!drm_atomic_get_new_crtc_state(state, crtc));
 
drm_for_each_plane_mask(plane, state->dev, crtc->state->plane_mask) {
struct drm_plane_state *plane_state =
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index d2d4e7eefa1a..2e117d0acf2f 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -70,8 +70,7 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state 
*state,
struct drm_crtc_state *crtc_state;
 
if (old_plane_state->crtc) {
-   crtc_state = drm_atomic_get_existing_crtc_state(state,
-   
old_plane_state->crtc);
+   crtc_state = drm_atomic_get_new_crtc_state(state, 
old_plane_state->crtc);
 
if (WARN_ON(!crtc_state))
return;
@@ -80,8 +79,7 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state 
*state,
}
 
if (plane_state->crtc) {
-   crtc_state = drm_atomic_get_existing_crtc_state(state,
-   
plane_state->crtc);
+   crtc_state = drm_atomic_get_new_crtc_state(state, 
plane_state->crtc);
 
if (WARN_ON(!crtc_state))
return;
@@ -150,7 +148,7 @@ static int handle_conflicting_encoders(struct 
drm_atomic_state *state,
drm_for_each_connector_iter(connector, &conn_iter) {
struct drm_crtc_state *crtc_state;
 
-   if (drm_atomic_get_existing_connector_state(state, connector))
+   if (drm_atomic_get_new_connector_state(state, connector))
continue;
 
encoder = connector->state->best_encoder;
@@ -178,7 +176,7 @@ static int handle_conflicting_encoders(struct 
drm_atomic_state *state,
 conn_state->crtc->base.id, 
conn_state->crtc->name,
 connector->base.id, connector->name);
 
-   crtc_state = drm_atomic_get_existing_crtc_state(state, 
conn_state->crtc);
+   crtc_state = drm_atomic_get_new_crtc_state(state, 
conn_state->crtc);
 
ret = drm_atomic_set_crtc_for_connector(conn_state, NULL);
if (ret)
@@ -219,7 +217,7 @@ set_best_encoder(struct drm_atomic_state *state,
 */
WARN_ON(!crtc && encoder != conn_state->best_encoder);
if (crtc) {
-   crtc_state = drm_atomic_get_existing_crtc_state(state, 
crtc);
+   crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
 
crtc_state->encoder_mask &=
~(1 << 
drm_encoder_index(conn_state->best_encoder));
@@ -230,7 +228,7 @@ set_best_encoder(struct drm_atomic_state *state,
crtc = conn_state->crtc;
WARN_ON(!crtc);
if (crtc) {
-   crtc_state = drm_atomic_get_existing_crtc_state(state, 
crtc);
+   crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
 
crtc_state->encoder_mask |=
1 << drm_encoder_index(encoder);
@@ -263,7 +261,7 @@ steal_encoder(struct drm_atomic_state *state,
 
set_best_encoder(state, new_connector_state, NULL);
 
-   crtc_state = drm_atomic_get_existing_crtc_state(state, 
encoder_crtc);
+

Re: [Intel-gfx] [PATCH v2 2/5] drm/edid: Introduce drm_default_rgb_quant_range()

[Jani Nikula]

On Wed, 11 Jan 2017, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
>
> Make the code selecting the RGB quantization range a little less magicy
> by wrapping it up in a small helper.
>
> v2: s/adjusted_mode/mode in vc4 to make it actually compile
>
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_edid.c| 18 ++
>  drivers/gpu/drm/i915/intel_dp.c   |  4 +++-
>  drivers/gpu/drm/i915/intel_hdmi.c |  3 ++-
>  drivers/gpu/drm/vc4/vc4_hdmi.c|  4 +++-
>  include/drm/drm_edid.h|  2 ++
>  5 files changed, 28 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 4ff04aa84dd0..304c583b8000 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3768,6 +3768,24 @@ bool drm_rgb_quant_range_selectable(struct edid *edid)
>  }
>  EXPORT_SYMBOL(drm_rgb_quant_range_selectable);
>  
> +/**
> + * drm_default_rgb_quant_range - default RGB quantization range
> + * @mode: display mode
> + *
> + * Determine the default RGB quantization range for the mode,
> + * as specified in CEA-861.
> + *
> + * Return: The default RGB quantization range for the mode
> + */
> +enum hdmi_quantization_range
> +drm_default_rgb_quant_range(const struct drm_display_mode *mode)
> +{
> + return drm_match_cea_mode(mode) > 1 ?
> + HDMI_QUANTIZATION_RANGE_LIMITED :
> + HDMI_QUANTIZATION_RANGE_FULL;
> +}
> +EXPORT_SYMBOL(drm_default_rgb_quant_range);

Or just bool drm_default_to_limited_range() or similar?

*shrug*

Reviewed-by: Jani Nikula 



> +
>  static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
>  const u8 *hdmi)
>  {
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 343e1d9fa761..d4befbbe834a 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1713,7 +1713,9 @@ intel_dp_compute_config(struct intel_encoder *encoder,
>* VESA DisplayPort Ver.1.2a - 5.1.1.1 Video Colorimetry
>*/
>   pipe_config->limited_color_range =
> - bpp != 18 && drm_match_cea_mode(adjusted_mode) > 1;
> + bpp != 18 &&
> + drm_default_rgb_quant_range(adjusted_mode) ==
> + HDMI_QUANTIZATION_RANGE_LIMITED;
>   } else {
>   pipe_config->limited_color_range =
>   intel_dp->limited_color_range;
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 0bcfead14571..19bd13f53729 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1330,7 +1330,8 @@ bool intel_hdmi_compute_config(struct intel_encoder 
> *encoder,
>   /* See CEA-861-E - 5.1 Default Encoding Parameters */
>   pipe_config->limited_color_range =
>   pipe_config->has_hdmi_sink &&
> - drm_match_cea_mode(adjusted_mode) > 1;
> + drm_default_rgb_quant_range(adjusted_mode) ==
> + HDMI_QUANTIZATION_RANGE_LIMITED;
>   } else {
>   pipe_config->limited_color_range =
>   intel_hdmi->limited_color_range;
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index c4cb2e26de32..5d49bf948162 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -463,7 +463,9 @@ static void vc4_hdmi_encoder_mode_set(struct drm_encoder 
> *encoder,
>   csc_ctl = VC4_SET_FIELD(VC4_HD_CSC_CTL_ORDER_BGR,
>   VC4_HD_CSC_CTL_ORDER);
>  
> - if (vc4_encoder->hdmi_monitor && drm_match_cea_mode(mode) > 1) {
> + if (vc4_encoder->hdmi_monitor &&
> + drm_default_rgb_quant_range(mode) ==
> + HDMI_QUANTIZATION_RANGE_LIMITED) {
>   /* CEA VICs other than #1 requre limited range RGB
>* output unless overridden by an AVI infoframe.
>* Apply a colorspace conversion to squash 0-255 down
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 838eaf2b42e9..25cdf5f7a0d8 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -441,6 +441,8 @@ enum hdmi_picture_aspect drm_get_cea_aspect_ratio(const 
> u8 video_code);
>  bool drm_detect_hdmi_monitor(struct edid *edid);
>  bool drm_detect_monitor_audio(struct edid *edid);
>  bool drm_rgb_quant_range_selectable(struct edid *edid);
> +enum hdmi_quantization_range
> +drm_default_rgb_quant_range(const struct drm_display_mode *mode);
>  int drm_add_modes_noedid(struct drm_connector *connector,
>int hdisplay, int vdisplay);
>  void drm_set_preferred_mode(struct drm_connector *connector,

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freede

Re: [PATCH 3/5] drm/edid: Introduce drm_hdmi_avi_infoframe_quant_range()

[Jani Nikula]

On Wed, 11 Jan 2017, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
>
> Pull the logic to populate the quantization range information
> in the AVI infoframe into a small helper. We'll be adding a bit
> more logic to it, and having it in a central place seems like a
> good idea since it's based on the CEA-861 spec.
>
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_edid.c| 26 ++
>  drivers/gpu/drm/i915/intel_hdmi.c | 13 +
>  drivers/gpu/drm/vc4/vc4_hdmi.c| 14 +-
>  include/drm/drm_edid.h|  4 
>  4 files changed, 40 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 304c583b8000..548c20250b95 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4291,6 +4291,32 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
> hdmi_avi_infoframe *frame,
>  }
>  EXPORT_SYMBOL(drm_hdmi_avi_infoframe_from_display_mode);
>  
> +/**
> + * drm_hdmi_avi_infoframe_quant_range() - fill the HDMI AVI infoframe
> + *quantization range information

I'm a fan of having a verb in the function name for functions that do
stuff. Would be nice to have "set" in there somewhere, although the name
is growing a bit unwieldy. (Btw, same for drm_default_rgb_quant_range()
in the previous patch, "get" would be nice.)

Up to you.

Reviewed-by: Jani Nikula 


> + * @frame: HDMI AVI infoframe
> + * @rgb_quant_range: RGB quantization range (Q)
> + * @rgb_quant_range_selectable: Sink support selectable RGB quantization 
> range (QS)
> + */
> +void
> +drm_hdmi_avi_infoframe_quant_range(struct hdmi_avi_infoframe *frame,
> +enum hdmi_quantization_range rgb_quant_range,
> +bool rgb_quant_range_selectable)
> +{
> + /*
> +  * CEA-861:
> +  * "A Source shall not send a non-zero Q value that does not correspond
> +  *  to the default RGB Quantization Range for the transmitted Picture
> +  *  unless the Sink indicates support for the Q bit in a Video
> +  *  Capabilities Data Block."
> +  */
> + if (rgb_quant_range_selectable)
> + frame->quantization_range = rgb_quant_range;
> + else
> + frame->quantization_range = HDMI_QUANTIZATION_RANGE_DEFAULT;
> +}
> +EXPORT_SYMBOL(drm_hdmi_avi_infoframe_quant_range);
> +
>  static enum hdmi_3d_structure
>  s3d_structure_from_display_mode(const struct drm_display_mode *mode)
>  {
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 19bd13f53729..351f837b09a0 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -465,14 +465,11 @@ static void intel_hdmi_set_avi_infoframe(struct 
> drm_encoder *encoder,
>   return;
>   }
>  
> - if (intel_hdmi->rgb_quant_range_selectable) {
> - if (crtc_state->limited_color_range)
> - frame.avi.quantization_range =
> - HDMI_QUANTIZATION_RANGE_LIMITED;
> - else
> - frame.avi.quantization_range =
> - HDMI_QUANTIZATION_RANGE_FULL;
> - }
> + drm_hdmi_avi_infoframe_quant_range(&frame.avi,
> +crtc_state->limited_color_range ?
> +HDMI_QUANTIZATION_RANGE_LIMITED :
> +HDMI_QUANTIZATION_RANGE_FULL,
> +
> intel_hdmi->rgb_quant_range_selectable);
>  
>   intel_write_infoframe(encoder, crtc_state, &frame);
>  }
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index d79466a42690..a588156b5410 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -356,15 +356,11 @@ static void vc4_hdmi_set_avi_infoframe(struct 
> drm_encoder *encoder)
>   return;
>   }
>  
> - if (vc4_encoder->rgb_range_selectable) {
> - if (vc4_encoder->limited_rgb_range) {
> - frame.avi.quantization_range =
> - HDMI_QUANTIZATION_RANGE_LIMITED;
> - } else {
> - frame.avi.quantization_range =
> - HDMI_QUANTIZATION_RANGE_FULL;
> - }
> - }
> + drm_hdmi_avi_infoframe_quant_range(&frame.avi,
> +vc4_encoder->limited_rgb_range ?
> +HDMI_QUANTIZATION_RANGE_LIMITED :
> +HDMI_QUANTIZATION_RANGE_FULL,
> +vc4_encoder->rgb_range_selectable);
>  
>   vc4_hdmi_write_infoframe(encoder, &frame);
>  }
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index 25cdf5f7a0d8..cfad4d89589f 100644
> --- a/include/drm/drm_edid.h

Re: [Intel-gfx] [PATCH 1/3] drm: Add new DRM_IOCTL_MODE_GETPLANE2

[Ville Syrjälä]

On Wed, Jan 11, 2017 at 08:43:16PM -0500, Rob Clark wrote:
> On Wed, Jan 11, 2017 at 7:51 PM, Ben Widawsky  wrote:
> >
> > +struct drm_format_modifier {
> > +   /* Bitmask of formats in get_plane format list this info
> > +* applies to. */
> > +   uint64_t formats;
> 
> re: the uabi, I'd suggest to at least make this 'u32 offset; u32
> formats'.. we can keep the existing implementation in this patch and
> always set 'offset' to zero, and let the first one to hit more than 32
> formats deal with the implementation.  (Maybe a strategically placed
> WARN_ON() if you go that route..)

Isn't an implicit offset enough? As in first mask for a specific
modifier is for format indexes 0-63, second mask for the same modifier
is for 64-127, and so on.

The bigger issue is the userspace side I think. If we don't add the
userspace side code to handle this case from the get go, it's going to
be hard to actually start doing it from the kernel side.

> 
> Otherwise I guess it is just a couple years until getplane3 ;-)
> 
> BR,
> -R
> 
> > +
> > +   /* This modifier can be used with the format for this plane. */
> > +   uint64_t modifier;
> > +};
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

Re: [Intel-gfx] [PATCH 4/5] drm/edid: Set AVI infoframe Q even when QS=0

[Jani Nikula]

On Wed, 11 Jan 2017, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
>
> HDMI 2.0 recommends that we set the Q bits in the AVI infoframe
> even when the sink does not support quantization range selection (QS=0).
> According to CEA-861 we can do that as long as the Q we send matches
> the default quantization range for the mode.
>
> Previosuly I think I had misread the spec as saying that you can't
  ^^

> send a non-zero Q at all when QS=0. But that's not what the spec
> actually says.

Agreed.

Reviewed-by: Jani Nikula 

>
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_edid.c| 8 +++-
>  drivers/gpu/drm/i915/intel_hdmi.c | 6 --
>  drivers/gpu/drm/vc4/vc4_hdmi.c| 2 +-
>  include/drm/drm_edid.h| 1 +
>  4 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 548c20250b95..caa2435bac31 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4295,11 +4295,13 @@ 
> EXPORT_SYMBOL(drm_hdmi_avi_infoframe_from_display_mode);
>   * drm_hdmi_avi_infoframe_quant_range() - fill the HDMI AVI infoframe
>   *quantization range information
>   * @frame: HDMI AVI infoframe
> + * @mode: DRM display mode
>   * @rgb_quant_range: RGB quantization range (Q)
>   * @rgb_quant_range_selectable: Sink support selectable RGB quantization 
> range (QS)
>   */
>  void
>  drm_hdmi_avi_infoframe_quant_range(struct hdmi_avi_infoframe *frame,
> +const struct drm_display_mode *mode,
>  enum hdmi_quantization_range rgb_quant_range,
>  bool rgb_quant_range_selectable)
>  {
> @@ -4309,8 +4311,12 @@ drm_hdmi_avi_infoframe_quant_range(struct 
> hdmi_avi_infoframe *frame,
>*  to the default RGB Quantization Range for the transmitted Picture
>*  unless the Sink indicates support for the Q bit in a Video
>*  Capabilities Data Block."
> +  *
> +  * HDMI 2.0 recommends sending non-zero Q when it does match the
> +  * default RGB quantization range for the mode, even when QS=0.
>*/
> - if (rgb_quant_range_selectable)
> + if (rgb_quant_range_selectable ||
> + rgb_quant_range == drm_default_rgb_quant_range(mode))
>   frame->quantization_range = rgb_quant_range;
>   else
>   frame->quantization_range = HDMI_QUANTIZATION_RANGE_DEFAULT;
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 351f837b09a0..af16b0fa6b69 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -455,17 +455,19 @@ static void intel_hdmi_set_avi_infoframe(struct 
> drm_encoder *encoder,
>const struct intel_crtc_state 
> *crtc_state)
>  {
>   struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
> + const struct drm_display_mode *adjusted_mode =
> + &crtc_state->base.adjusted_mode;
>   union hdmi_infoframe frame;
>   int ret;
>  
>   ret = drm_hdmi_avi_infoframe_from_display_mode(&frame.avi,
> -
> &crtc_state->base.adjusted_mode);
> +adjusted_mode);
>   if (ret < 0) {
>   DRM_ERROR("couldn't fill AVI infoframe\n");
>   return;
>   }
>  
> - drm_hdmi_avi_infoframe_quant_range(&frame.avi,
> + drm_hdmi_avi_infoframe_quant_range(&frame.avi, adjusted_mode,
>  crtc_state->limited_color_range ?
>  HDMI_QUANTIZATION_RANGE_LIMITED :
>  HDMI_QUANTIZATION_RANGE_FULL,
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index a588156b5410..f38fdbac2878 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -356,7 +356,7 @@ static void vc4_hdmi_set_avi_infoframe(struct drm_encoder 
> *encoder)
>   return;
>   }
>  
> - drm_hdmi_avi_infoframe_quant_range(&frame.avi,
> + drm_hdmi_avi_infoframe_quant_range(&frame.avi, mode,
>  vc4_encoder->limited_rgb_range ?
>  HDMI_QUANTIZATION_RANGE_LIMITED :
>  HDMI_QUANTIZATION_RANGE_FULL,
> diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> index cfad4d89589f..43fb0ac5eb9c 100644
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -347,6 +347,7 @@ drm_hdmi_vendor_infoframe_from_display_mode(struct 
> hdmi_vendor_infoframe *frame,
>   const struct drm_display_mode 
> *mode);
>  void
>  drm_hdmi_avi_infoframe_quant_range(struct hdmi_avi_infoframe *frame,
> +const

Re: [PATCH 1/5] drm/msm: Stop using drm_framebuffer_unregister_private

[Archit Taneja]

On 12/27/2016 04:19 PM, Daniel Vetter wrote:

This is the deprecated function for when you embedded the framebuffer
somewhere else (which breaks refcounting). But msm is using
drm_framebuffer_remove and a free-standing fb, so this is rendundant.

Cc: Rob Clark 
Signed-off-by: Daniel Vetter 


Reviewed-by: Archit Taneja 


---
 drivers/gpu/drm/msm/msm_fbdev.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/msm_fbdev.c b/drivers/gpu/drm/msm/msm_fbdev.c
index 5d68ab362d75..f8a587eac6b8 100644
--- a/drivers/gpu/drm/msm/msm_fbdev.c
+++ b/drivers/gpu/drm/msm/msm_fbdev.c
@@ -174,10 +174,8 @@ static int msm_fbdev_create(struct drm_fb_helper *helper,
 fail:

if (ret) {
-   if (fb) {
-   drm_framebuffer_unregister_private(fb);
+   if (fb)
drm_framebuffer_remove(fb);
-   }
}

return ret;
@@ -247,7 +245,6 @@ void msm_fbdev_free(struct drm_device *dev)
/* this will free the backing object */
if (fbdev->fb) {
msm_gem_put_vaddr(fbdev->bo);
-   drm_framebuffer_unregister_private(fbdev->fb);
drm_framebuffer_remove(fbdev->fb);
}




--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: fix MMU dependencies

[Daniel Vetter]

On Thu, Jan 12, 2017 at 09:57:36AM +0100, Benjamin Gaignard wrote:
> DRM_VM and DRM_LEGACY shouldn't be selected if MMU isn't set.
> 
> Fixes: 62a0d98a188c ("drm: allow to use mmuless SoC")
> Signed-off-by: Benjamin Gaignard 
> Cc: Arnd Bergmann 
> Cc: Daniel Vetter 

Let's see how much we're going to anger Kconfig with this one :-)

Thanks, Daniel

> ---
>  drivers/gpu/drm/Kconfig | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 6f3f9e6..90bc65d 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -138,7 +138,7 @@ config DRM_KMS_CMA_HELPER
>  
>  config DRM_VM
>   bool
> - depends on DRM
> + depends on DRM && MMU
>  
>  source "drivers/gpu/drm/i2c/Kconfig"
>  
> @@ -267,7 +267,7 @@ source "drivers/gpu/drm/meson/Kconfig"
>  
>  menuconfig DRM_LEGACY
>   bool "Enable legacy drivers (DANGEROUS)"
> - depends on DRM
> + depends on DRM && MMU
>   select DRM_VM
>   help
> Enable legacy DRI1 drivers. Those drivers expose unsafe and dangerous
> -- 
> 1.9.1
> 

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

Re: [PATCH 4/5] drm/omap: Stop using drm_framebuffer_unregister_private

[Laurent Pinchart]

Hi Daniel,

Thank you for the patch.

On Tuesday 27 Dec 2016 11:49:24 Daniel Vetter wrote:
> This is the deprecated function for when you embedded the framebuffer
> somewhere else (which breaks refcounting). But omapdrm is using
> drm_framebuffer_remove and a free-standing fb, so this is rendundant.
> 
> Cc: Tomi Valkeinen 
> Signed-off-by: Daniel Vetter 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/omapdrm/omap_fbdev.c | 8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c
> b/drivers/gpu/drm/omapdrm/omap_fbdev.c index aed99a0fc44b..2a839956dae6
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
> +++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
> @@ -225,10 +225,8 @@ static int omap_fbdev_create(struct drm_fb_helper
> *helper,
> 
>   drm_fb_helper_release_fbi(helper);
> 
> - if (fb) {
> - drm_framebuffer_unregister_private(fb);
> + if (fb)
>   drm_framebuffer_remove(fb);
> - }
>   }
> 
>   return ret;
> @@ -314,10 +312,8 @@ void omap_fbdev_free(struct drm_device *dev)
>   omap_gem_put_paddr(fbdev->bo);
> 
>   /* this will free the backing object */
> - if (fbdev->fb) {
> - drm_framebuffer_unregister_private(fbdev->fb);
> + if (fbdev->fb)
>   drm_framebuffer_remove(fbdev->fb);
> - }
> 
>   kfree(fbdev);

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 2/5] drm/cma-helper: Stop using drm_framebuffer_unregister_private

[Laurent Pinchart]

Hi Daniel,

Thank you for the patch.

On Tuesday 27 Dec 2016 11:49:22 Daniel Vetter wrote:
> This is the deprecated function for when you embedded the framebuffer
> somewhere else (which breaks refcounting). But cma helpers are using
> drm_framebuffer_remove and a free-standing fb, so this is rendundant.
> 
> Cc: Laurent Pinchart 
> Signed-off-by: Daniel Vetter 

Reviewed-by: Laurent Pinchart 

> ---
>  drivers/gpu/drm/drm_fb_cma_helper.c | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> b/drivers/gpu/drm/drm_fb_cma_helper.c index 591f30ebc42a..769a3b3236ee
> 100644
> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> @@ -485,8 +485,7 @@ int drm_fbdev_cma_create_with_funcs(struct drm_fb_helper
> *helper, return 0;
> 
>  err_cma_destroy:
> - drm_framebuffer_unregister_private(&fbdev_cma->fb->fb);
> - drm_fb_cma_destroy(&fbdev_cma->fb->fb);
> + drm_framebuffer_remove(&fbdev_cma->fb->fb);
>  err_fb_info_destroy:
>   drm_fb_helper_release_fbi(helper);
>  err_gem_free_object:
> @@ -592,10 +591,8 @@ void drm_fbdev_cma_fini(struct drm_fbdev_cma
> *fbdev_cma) drm_fbdev_cma_defio_fini(fbdev_cma->fb_helper.fbdev);
>   drm_fb_helper_release_fbi(&fbdev_cma->fb_helper);
> 
> - if (fbdev_cma->fb) {
> - drm_framebuffer_unregister_private(&fbdev_cma->fb->fb);
> - drm_fb_cma_destroy(&fbdev_cma->fb->fb);
> - }
> + if (fbdev_cma->fb)
> + drm_framebuffer_remove(&fbdev_cma->fb->fb);
> 
>   drm_fb_helper_fini(&fbdev_cma->fb_helper);
>   kfree(fbdev_cma);

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 5/5] drm/edid: Set YQ bits in the AVI infoframe according to CEA-861-F

[Jani Nikula]

On Wed, 11 Jan 2017, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
>
> CEA-861-F tells us:
> "When transmitting any RGB colorimetry, the Source should set the
>  YQ-field to match the RGB Quantization Range being transmitted
>  (e.g., when Limited Range RGB, set YQ=0 or when Full Range RGB,
>  set YQ=1) and the Sink shall ignore the YQ-field."
>
> So let's go ahead and do that. Perhaps there are sinks that don't
> ignore the YQ as they should for RGB?
>
> I wasn't able to find similar text in CEA-861-E, so it would seem
> to be a fairly "recent" addition.
>
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/drm_edid.c | 14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index caa2435bac31..6ba9a1a6eae4 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4320,6 +4320,20 @@ drm_hdmi_avi_infoframe_quant_range(struct 
> hdmi_avi_infoframe *frame,
>   frame->quantization_range = rgb_quant_range;
>   else
>   frame->quantization_range = HDMI_QUANTIZATION_RANGE_DEFAULT;
> +
> + /*
> +  * CEA-861-F:
> +  * "When transmitting any RGB colorimetry, the Source should set the
> +  *  YQ-field to match the RGB Quantization Range being transmitted
> +  *  (e.g., when Limited Range RGB, set YQ=0 or when Full Range RGB,
> +  *  set YQ=1) and the Sink shall ignore the YQ-field."
> +  */

*rolls eyes* but that's what the spec says.

> + if (rgb_quant_range == HDMI_QUANTIZATION_RANGE_LIMITED)
> + frame->ycc_quantization_range =
> + HDMI_YCC_QUANTIZATION_RANGE_LIMITED;
> + else
> + frame->ycc_quantization_range =
> + HDMI_YCC_QUANTIZATION_RANGE_FULL;

Shouldn't this take into account QS=0 and rgb_quant_range != default?

BR,
Jani.



>  }
>  EXPORT_SYMBOL(drm_hdmi_avi_infoframe_quant_range);

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

Re: [PATCH 5/5] drm/tegra: Stop using drm_framebuffer_unregister_private

[Archit Taneja]

On 12/27/2016 04:19 PM, Daniel Vetter wrote:

This is the deprecated function for when you embedded the framebuffer
somewhere else (which breaks refcounting). But tegra is using
drm_framebuffer_remove and a free-standing fb, so this is rendundant.


s/rendundant/redundant



One caveat here is that the failur path in the init code still


s/failur/failure


manually cleaned up the fb. I presume that was an oversigth and


s/oversigth/oversight


changed it over to drm_framebuffer_remove too.


Reviewed-by: Archit Taneja 



Cc: Thierry Reding 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/tegra/fb.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/gpu/drm/tegra/fb.c
index 8df7783cecc2..f896e2ff7d47 100644
--- a/drivers/gpu/drm/tegra/fb.c
+++ b/drivers/gpu/drm/tegra/fb.c
@@ -271,8 +271,7 @@ static int tegra_fbdev_probe(struct drm_fb_helper *helper,
return 0;

 destroy:
-   drm_framebuffer_unregister_private(fb);
-   tegra_fb_destroy(fb);
+   drm_framebuffer_remove(fb);
 release:
drm_fb_helper_release_fbi(helper);
return err;
@@ -342,10 +341,8 @@ static void tegra_fbdev_exit(struct tegra_fbdev *fbdev)
drm_fb_helper_unregister_fbi(&fbdev->base);
drm_fb_helper_release_fbi(&fbdev->base);

-   if (fbdev->fb) {
-   drm_framebuffer_unregister_private(&fbdev->fb->base);
+   if (fbdev->fb)
drm_framebuffer_remove(&fbdev->fb->base);
-   }

drm_fb_helper_fini(&fbdev->base);
tegra_fbdev_free(fbdev);



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 1/3] drm: Add new DRM_IOCTL_MODE_GETPLANE2

[Ville Syrjälä]

On Wed, Jan 11, 2017 at 04:51:16PM -0800, Ben Widawsky wrote:
> Originally based off of a patch by Kristian.
> 
> This new ioctl extends DRM_IOCTL_MODE_GETPLANE, by returning information
> about the modifiers that will work with each format.
> 
> It's modified from Kristian's patch in that the modifiers and formats
> are setup by the driver, and then a callback is used to create the
> format list. The LOC was enough difference that I don't think it made
> sense to leave his authorship, but the new UABI was primarily his idea.
> 
> Additionally, I hit a couple of drivers which Kristian missed updating.
> 
> It also contains a change requested by Daniel to make the modifiers
> array a sentinel based structure instead of a sized one. Upon discussion
> on IRC, it was determined that having an invalid modifier might make
> sense in general as well.
> 
> References: https://patchwork.kernel.org/patch/9482393/
> Signed-off-by: Ben Widawsky 
> ---

> diff --git a/drivers/gpu/drm/drm_modeset_helper.c 
> b/drivers/gpu/drm/drm_modeset_helper.c
> index 2b33825f2f93..9cb1eede0b4d 100644
> --- a/drivers/gpu/drm/drm_modeset_helper.c
> +++ b/drivers/gpu/drm/drm_modeset_helper.c
> @@ -124,6 +124,7 @@ static struct drm_plane *create_primary_plane(struct 
> drm_device *dev)
>  &drm_primary_helper_funcs,
>  safe_modeset_formats,
>  ARRAY_SIZE(safe_modeset_formats),
> +NULL,
>  DRM_PLANE_TYPE_PRIMARY, NULL);
>   if (ret) {
>   kfree(primary);
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 7b7275f0c2df..2d4fad5db8ed 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -70,6 +70,7 @@ static unsigned int drm_num_planes(struct drm_device *dev)
>   * @funcs: callbacks for the new plane
>   * @formats: array of supported formats (DRM_FORMAT\_\*)
>   * @format_count: number of elements in @formats
> + * @format_modifiers: array of struct drm_format modifiers terminated by 
> INVALID
>   * @type: type of plane (overlay, primary, cursor)
>   * @name: printf style format string for the plane name, or NULL for default 
> name
>   *
> @@ -82,10 +83,12 @@ int drm_universal_plane_init(struct drm_device *dev, 
> struct drm_plane *plane,
>uint32_t possible_crtcs,
>const struct drm_plane_funcs *funcs,
>const uint32_t *formats, unsigned int format_count,
> +  const uint64_t *format_modifiers,
>enum drm_plane_type type,
>const char *name, ...)
>  {
>   struct drm_mode_config *config = &dev->mode_config;
> + unsigned int format_modifier_count = 0;
>   int ret;
>  
>   ret = drm_mode_object_get(dev, &plane->base, DRM_MODE_OBJECT_PLANE);
> @@ -105,6 +108,28 @@ int drm_universal_plane_init(struct drm_device *dev, 
> struct drm_plane *plane,
>   return -ENOMEM;
>   }
>  
> + if (format_modifiers) {
> + const uint64_t *temp_modifiers = format_modifiers;
> + while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID)
> + format_modifier_count++;
> + }
> +
> + if (format_modifier_count)
> + DRM_DEBUG_KMS("%d format modifiers added to list\n",
> +   format_modifier_count);

nit: Not sure this is printk worthy.

> +
> + plane->modifier_count = format_modifier_count;
> + plane->modifiers = kmalloc_array(format_modifier_count,
> +  sizeof(format_modifiers[0]),
> +  GFP_KERNEL);
> +
> + if (format_modifier_count && !plane->modifiers) {
> + DRM_DEBUG_KMS("out of memory when allocating plane\n");
> + kfree(plane->format_types);
> + drm_mode_object_unregister(dev, &plane->base);
> + return -ENOMEM;
> + }
> +
>   if (name) {
>   va_list ap;
>  
> @@ -117,12 +142,15 @@ int drm_universal_plane_init(struct drm_device *dev, 
> struct drm_plane *plane,
>   }
>   if (!plane->name) {
>   kfree(plane->format_types);
> + kfree(plane->modifiers);
>   drm_mode_object_unregister(dev, &plane->base);
>   return -ENOMEM;
>   }
>  
>   memcpy(plane->format_types, formats, format_count * sizeof(uint32_t));
>   plane->format_count = format_count;
> + memcpy(plane->modifiers, format_modifiers,
> +format_modifier_count * sizeof(format_modifiers[0]));

Looks all right since we do the same for formats anyway. But it did
occur to me (twice at least) that a kmemdup_array() might a nice thing
to have for things like this. But that's a separate topic.

>   plane->possible_crtcs = possible_crtcs;
>   plane->type = type

Re: [PATCH 5/5] drm/edid: Set YQ bits in the AVI infoframe according to CEA-861-F

[Ville Syrjälä]

On Thu, Jan 12, 2017 at 12:13:47PM +0200, Jani Nikula wrote:
> On Wed, 11 Jan 2017, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> >
> > CEA-861-F tells us:
> > "When transmitting any RGB colorimetry, the Source should set the
> >  YQ-field to match the RGB Quantization Range being transmitted
> >  (e.g., when Limited Range RGB, set YQ=0 or when Full Range RGB,
> >  set YQ=1) and the Sink shall ignore the YQ-field."
> >
> > So let's go ahead and do that. Perhaps there are sinks that don't
> > ignore the YQ as they should for RGB?
> >
> > I wasn't able to find similar text in CEA-861-E, so it would seem
> > to be a fairly "recent" addition.
> >
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/drm_edid.c | 14 ++
> >  1 file changed, 14 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index caa2435bac31..6ba9a1a6eae4 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -4320,6 +4320,20 @@ drm_hdmi_avi_infoframe_quant_range(struct 
> > hdmi_avi_infoframe *frame,
> > frame->quantization_range = rgb_quant_range;
> > else
> > frame->quantization_range = HDMI_QUANTIZATION_RANGE_DEFAULT;
> > +
> > +   /*
> > +* CEA-861-F:
> > +* "When transmitting any RGB colorimetry, the Source should set the
> > +*  YQ-field to match the RGB Quantization Range being transmitted
> > +*  (e.g., when Limited Range RGB, set YQ=0 or when Full Range RGB,
> > +*  set YQ=1) and the Sink shall ignore the YQ-field."
> > +*/
> 
> *rolls eyes* but that's what the spec says.
> 
> > +   if (rgb_quant_range == HDMI_QUANTIZATION_RANGE_LIMITED)
> > +   frame->ycc_quantization_range =
> > +   HDMI_YCC_QUANTIZATION_RANGE_LIMITED;
> > +   else
> > +   frame->ycc_quantization_range =
> > +   HDMI_YCC_QUANTIZATION_RANGE_FULL;
> 
> Shouldn't this take into account QS=0 and rgb_quant_range != default?

There is no YQ setting similar to the default Q=0. YQ=0 means "limited",
YQ=1 means "full", others values are reserved. So we can't really not
specify the YCC quantization range. So I can't really see any better
option than telling the truth.

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

Re: [PATCH 2/3] drm/i915: Add format modifiers for Intel

[Ville Syrjälä]

On Wed, Jan 11, 2017 at 04:51:17PM -0800, Ben Widawsky wrote:
> This was based on a patch originally by Kristian. It has been modified
> pretty heavily to use the new callbacks from the previous patch.
> 
> Cc: Kristian H. Kristensen 
> Signed-off-by: Ben Widawsky 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 109 
> ++-
>  drivers/gpu/drm/i915/intel_sprite.c  |  33 ++-
>  2 files changed, 137 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 8715b1083d1d..26f3a911b999 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -61,6 +61,11 @@ static const uint32_t i8xx_primary_formats[] = {
>   DRM_FORMAT_XRGB,
>  };
>  
> +static const uint64_t i8xx_format_modifiers[] = {
> + I915_FORMAT_MOD_X_TILED,

Did we want to list the linear modifier in these as well?

> + DRM_FORMAT_MOD_INVALID
> +};
> +
>  /* Primary plane formats for gen >= 4 */
>  static const uint32_t i965_primary_formats[] = {
>   DRM_FORMAT_C8,
> @@ -71,6 +76,11 @@ static const uint32_t i965_primary_formats[] = {
>   DRM_FORMAT_XBGR2101010,
>  };
>  
> +static const uint64_t i965_format_modifiers[] = {
> + I915_FORMAT_MOD_X_TILED,
> + DRM_FORMAT_MOD_INVALID
> +};

We could just share the i8xx array. The name of the array should perhaps
be i9xx_format_modifiers[] in that case. That's sort of the naming
convention we've been left with for things that apply to more or less
all the platforms.

> +
>  static const uint32_t skl_primary_formats[] = {
>   DRM_FORMAT_C8,
>   DRM_FORMAT_RGB565,
> @@ -86,6 +96,12 @@ static const uint32_t skl_primary_formats[] = {
>   DRM_FORMAT_VYUY,
>  };
>  
> +static const uint64_t skl_format_modifiers[] = {
> + I915_FORMAT_MOD_Y_TILED,

Yf missing? and linear

> + I915_FORMAT_MOD_X_TILED,
> + DRM_FORMAT_MOD_INVALID
> +};
> +
>  /* Cursor formats */
>  static const uint32_t intel_cursor_formats[] = {
>   DRM_FORMAT_ARGB,
> @@ -15173,6 +15189,87 @@ void intel_plane_destroy(struct drm_plane *plane)
>   kfree(to_intel_plane(plane));
>  }
>  
> +static bool i8xx_mod_supported(uint32_t format, uint64_t modifier)
> +{
> + if (modifier == DRM_FORMAT_MOD_NONE)
> + return true;
> +
> + switch (format) {
> + case DRM_FORMAT_C8:
> + case DRM_FORMAT_RGB565:
> + case DRM_FORMAT_XRGB1555:
> + case DRM_FORMAT_XRGB:
> + return modifier == I915_FORMAT_MOD_X_TILED;
> + default:
> + return false;
> + }
> +}
> +
> +static bool i965_mod_supported(uint32_t format, uint64_t modifier)
> +{
> + switch (format) {
> + case DRM_FORMAT_C8:
> + case DRM_FORMAT_RGB565:
> + case DRM_FORMAT_XRGB:
> + case DRM_FORMAT_XBGR:
> + case DRM_FORMAT_XRGB2101010:
> + case DRM_FORMAT_XBGR2101010:
> + return modifier == I915_FORMAT_MOD_X_TILED;
> + default:
> + return false;
> + }
> +}

Hmm. There should be no format vs. tiling restrictions on these
platforms, so presumably a simple "return true" should cover it all.
That does perhaps remove the usefulness of these functions for
verifying that the format or modifier is supported at all, but I've been
thinking that addfb should perhaps just iterate through the format and
modifier lists for every plane. Would avoid having to effectively 
maintain the same lists in multiple places.

> +
> +static bool skl_mod_supported(uint32_t format, uint64_t modifier)
> +{
> + switch (format) {
> + case DRM_FORMAT_C8:
> + case DRM_FORMAT_RGB565:
> + case DRM_FORMAT_XRGB:
> + case DRM_FORMAT_XBGR:
> + case DRM_FORMAT_ARGB:
> + case DRM_FORMAT_ABGR:
> + return modifier == I915_FORMAT_MOD_Y_TILED ||
> + modifier == I915_FORMAT_MOD_X_TILED;
> + case DRM_FORMAT_XRGB2101010:
> + case DRM_FORMAT_XBGR2101010:
> + return modifier == I915_FORMAT_MOD_X_TILED;
> + case DRM_FORMAT_YUYV:
> + case DRM_FORMAT_YVYU:
> + case DRM_FORMAT_UYVY:
> + case DRM_FORMAT_VYUY:

IIRC on SKL the only restrictions should be that CCS modifiers are
limited to 8:8:8:8 formats only. Other modifiers should work
with any format.

> + default:
> + return false;
> + }
> +
> +}
> +
> +static bool intel_plane_format_mod_supported(struct drm_plane *plane,
> +  uint32_t format,
> +  uint64_t modifier)
> +{
> + struct drm_i915_private *dev_priv = to_i915(plane->dev);
> +
> + if (modifier == DRM_FORMAT_MOD_NONE)
> + return true;
> +
> + if (WARN_ON(modifier == DRM_FORMAT_MOD_INVALID))
> + return false;
> +
> + if (WARN_ON(plane->type != DRM_PLANE_TYPE_PRIMARY &&
> + plane->type != DRM_PLANE_TYPE_OVERLAY))
> + return false;
> +

[Bug 94900] HD6950 GPU lockup loop with various steam games (octodad[always], saints row 4[always], dead island[always], grid autosport[sometimes])

[bugzilla-daemon]

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

Andreas Boll  changed:

   What|Removed |Added

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

--- Comment #37 from Andreas Boll  ---
Thanks to Heiko for fixing this issue!

Fixed by

commit e933246013eef376804662f3fcf4646c143c6c88
Author: Heiko Przybyl 
Date:   Sun Nov 20 14:42:28 2016 +0100

r600/sb: Fix loop optimization related hangs on eg

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

Re: [PATCH 5/5] drm/edid: Set YQ bits in the AVI infoframe according to CEA-861-F

[Jani Nikula]

On Thu, 12 Jan 2017, Ville Syrjälä  wrote:
> On Thu, Jan 12, 2017 at 12:13:47PM +0200, Jani Nikula wrote:
>> On Wed, 11 Jan 2017, ville.syrj...@linux.intel.com wrote:
>> > From: Ville Syrjälä 
>> >
>> > CEA-861-F tells us:
>> > "When transmitting any RGB colorimetry, the Source should set the
>> >  YQ-field to match the RGB Quantization Range being transmitted
>> >  (e.g., when Limited Range RGB, set YQ=0 or when Full Range RGB,
>> >  set YQ=1) and the Sink shall ignore the YQ-field."
>> >
>> > So let's go ahead and do that. Perhaps there are sinks that don't
>> > ignore the YQ as they should for RGB?
>> >
>> > I wasn't able to find similar text in CEA-861-E, so it would seem
>> > to be a fairly "recent" addition.
>> >
>> > Signed-off-by: Ville Syrjälä 
>> > ---
>> >  drivers/gpu/drm/drm_edid.c | 14 ++
>> >  1 file changed, 14 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> > index caa2435bac31..6ba9a1a6eae4 100644
>> > --- a/drivers/gpu/drm/drm_edid.c
>> > +++ b/drivers/gpu/drm/drm_edid.c
>> > @@ -4320,6 +4320,20 @@ drm_hdmi_avi_infoframe_quant_range(struct 
>> > hdmi_avi_infoframe *frame,
>> >frame->quantization_range = rgb_quant_range;
>> >else
>> >frame->quantization_range = HDMI_QUANTIZATION_RANGE_DEFAULT;
>> > +
>> > +  /*
>> > +   * CEA-861-F:
>> > +   * "When transmitting any RGB colorimetry, the Source should set the
>> > +   *  YQ-field to match the RGB Quantization Range being transmitted
>> > +   *  (e.g., when Limited Range RGB, set YQ=0 or when Full Range RGB,
>> > +   *  set YQ=1) and the Sink shall ignore the YQ-field."
>> > +   */
>> 
>> *rolls eyes* but that's what the spec says.
>> 
>> > +  if (rgb_quant_range == HDMI_QUANTIZATION_RANGE_LIMITED)
>> > +  frame->ycc_quantization_range =
>> > +  HDMI_YCC_QUANTIZATION_RANGE_LIMITED;
>> > +  else
>> > +  frame->ycc_quantization_range =
>> > +  HDMI_YCC_QUANTIZATION_RANGE_FULL;
>> 
>> Shouldn't this take into account QS=0 and rgb_quant_range != default?
>
> There is no YQ setting similar to the default Q=0. YQ=0 means "limited",
> YQ=1 means "full", others values are reserved. So we can't really not
> specify the YCC quantization range. So I can't really see any better
> option than telling the truth.

Hmm, I was confused about the caller choosing the range based on the
mode already.

Reviewed-by: Jani Nikula 



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

[PATCH] drm: tegra: shut up harmless warning on NOMMU

[Arnd Bergmann]

The tegra DRM driver is almost ok without an MMU, but there
is one small warning that I get:

drivers/gpu/drm/tegra/gem.c: In function 'tegra_drm_mmap':
drivers/gpu/drm/tegra/gem.c:508:12: unused variable 'prot'

This marks the variable as __maybe_unused instead.

Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/tegra/gem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index 7d853e6b5ff0..63f14b7a59a0 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -505,7 +505,7 @@ int tegra_drm_mmap(struct file *file, struct vm_area_struct 
*vma)
 
vma->vm_pgoff = vm_pgoff;
} else {
-   pgprot_t prot = vm_get_page_prot(vma->vm_flags);
+   pgprot_t prot __maybe_unused = vm_get_page_prot(vma->vm_flags);
 
vma->vm_flags |= VM_MIXEDMAP;
vma->vm_flags &= ~VM_PFNMAP;
-- 
2.9.0

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

Re: [Intel-gfx] GPU hang with kernel 4.10rc3

[Juergen Gross]

On 11/01/17 18:08, Chris Wilson wrote:
> On Wed, Jan 11, 2017 at 05:33:34PM +0100, Juergen Gross wrote:
>> With kernel 4.10rc3 running as Xen dm0 I get at each boot:
>>
>> [   49.213697] [drm] GPU HANG: ecode 7:0:0x3d1d3d3d, in gnome-shell
>> [1431], reason: Hang on render ring, action: reset
>> [   49.213699] [drm] GPU hangs can indicate a bug anywhere in the entire
>> gfx stack, including userspace.
>> [   49.213700] [drm] Please file a _new_ bug report on
>> bugs.freedesktop.org against DRI -> DRM/Intel
>> [   49.213700] [drm] drm/i915 developers can then reassign to the right
>> component if it's not a kernel issue.
>> [   49.213700] [drm] The gpu crash dump is required to analyze gpu
>> hangs, so please always attach it.
>> [   49.213701] [drm] GPU crash dump saved to /sys/class/drm/card0/error
>> [   49.213755] drm/i915: Resetting chip after gpu hang
>> [   60.213769] drm/i915: Resetting chip after gpu hang
>> [   71.189737] drm/i915: Resetting chip after gpu hang
>> [   82.165747] drm/i915: Resetting chip after gpu hang
>> [   93.205727] drm/i915: Resetting chip after gpu hang
>>
>> The dump is attached.
> 
> That's a nasty one. The first couple of pages of the batchbuffer appear
> to be overwritten. (Full of 0xc2c2c2c2, i.e. probably pixel data.) That
> may be a concurrent write by either the GPU or CPU, or we may have
> incorrected mapped a set of pages. That it doesn't recovered suggests
> that the corruption occurs frequently, probably on every request/batch.

I hoped someone would have an idea already.

> Is this a new bug? Bisection would be the fastest way to triage it.

Commit 7453c549f was still okay. Starting bisect now (2882 commits, 12
steps) ...


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

Re: [PATCH 1/3] drm: bridge: dw-hdmi: Define and use macros for PHY register addresses

[Nickey.Yang]

Hi Laurent,


在 2017年01月12日 07:49, Laurent Pinchart 写道:

Replace the hardcoded register address numerical values with macros to
clarify the code.

This change has been tested by comparing the assembly code before and
after the change.

Signed-off-by: Laurent Pinchart 
---
  drivers/gpu/drm/bridge/dw-hdmi.c | 35 -
  drivers/gpu/drm/bridge/dw-hdmi.h | 66 
  2 files changed, 86 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c b/drivers/gpu/drm/bridge/dw-hdmi.c
index ef4f2f96ed2c..6e605fd910ef 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/dw-hdmi.c
@@ -997,21 +997,26 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi, int 
cscon)
HDMI_PHY_I2CM_SLAVE_ADDR);
hdmi_phy_test_clear(hdmi, 0);
  
-	hdmi_phy_i2c_write(hdmi, mpll_config->res[0].cpce, 0x06);

-   hdmi_phy_i2c_write(hdmi, mpll_config->res[0].gmp, 0x15);
-
-   /* CURRCTRL */
-   hdmi_phy_i2c_write(hdmi, curr_ctrl->curr[0], 0x10);
-
-   hdmi_phy_i2c_write(hdmi, 0x, 0x13);  /* PLLPHBYCTRL */
-   hdmi_phy_i2c_write(hdmi, 0x0006, 0x17);
-
-   hdmi_phy_i2c_write(hdmi, phy_config->term, 0x19);  /* TXTERM */
-   hdmi_phy_i2c_write(hdmi, phy_config->sym_ctr, 0x09); /* CKSYMTXCTRL */
-   hdmi_phy_i2c_write(hdmi, phy_config->vlev_ctr, 0x0E); /* VLEVCTRL */
-
-   /* REMOVE CLK TERM */
-   hdmi_phy_i2c_write(hdmi, 0x8000, 0x05);  /* CKCALCTRL */
+   hdmi_phy_i2c_write(hdmi, mpll_config->res[0].cpce,
+  HDMI_3D_TX_PHY_CPCE_CTRL);
+   hdmi_phy_i2c_write(hdmi, mpll_config->res[0].gmp,
+  HDMI_3D_TX_PHY_GMPCTRL);
+   hdmi_phy_i2c_write(hdmi, curr_ctrl->curr[0],
+  HDMI_3D_TX_PHY_CURRCTRL);
+
+   hdmi_phy_i2c_write(hdmi, 0, HDMI_3D_TX_PHY_PLLPHBYCTRL);
+   hdmi_phy_i2c_write(hdmi, HDMI_3D_TX_PHY_MSM_CTRL_CKO_SEL_FB_CLK,
+  HDMI_3D_TX_PHY_MSM_CTRL);
+
+   hdmi_phy_i2c_write(hdmi, phy_config->term, HDMI_3D_TX_PHY_TXTERM);
+   hdmi_phy_i2c_write(hdmi, phy_config->sym_ctr,
+  HDMI_3D_TX_PHY_CKSYMTXCTRL);
+   hdmi_phy_i2c_write(hdmi, phy_config->vlev_ctr,
+  HDMI_3D_TX_PHY_VLEVCTRL);
+
+   /* Override and disable clock termination. */
+   hdmi_phy_i2c_write(hdmi, HDMI_3D_TX_PHY_CKCALCTRL_OVERRIDE,
+  HDMI_3D_TX_PHY_CKCALCTRL);
  
  	dw_hdmi_phy_enable_powerdown(hdmi, false);
  
diff --git a/drivers/gpu/drm/bridge/dw-hdmi.h b/drivers/gpu/drm/bridge/dw-hdmi.h

index a4fd64a203c9..f3c149c88d71 100644
--- a/drivers/gpu/drm/bridge/dw-hdmi.h
+++ b/drivers/gpu/drm/bridge/dw-hdmi.h
@@ -1085,4 +1085,70 @@ enum {
HDMI_I2CM_CTLINT_ARB_MASK = 0x4,
  };
  
+/*

+ * HDMI 3D TX PHY registers
+ */


Why is there 3D related words？I did not find "3D" words in PHY IP vendor 
document.

+#define HDMI_3D_TX_PHY_PWRCTRL 0x00
+#define HDMI_3D_TX_PHY_SERDIVCTRL  0x01
+#define HDMI_3D_TX_PHY_SERCKCTRL   0x02
+#define HDMI_3D_TX_PHY_SERCKKILLCTRL   0x03
+#define HDMI_3D_TX_PHY_TXRESCTRL   0x04
+#define HDMI_3D_TX_PHY_CKCALCTRL   0x05
+#define HDMI_3D_TX_PHY_CPCE_CTRL   0x06
+#define HDMI_3D_TX_PHY_TXCLKMEASCTRL   0x07
+#define HDMI_3D_TX_PHY_TXMEASCTRL  0x08
+#define HDMI_3D_TX_PHY_CKSYMTXCTRL 0x09
+#define HDMI_3D_TX_PHY_CMPSEQCTRL  0x0a
+#define HDMI_3D_TX_PHY_CMPPWRCTRL  0x0b
+#define HDMI_3D_TX_PHY_CMPMODECTRL 0x0c
+#define HDMI_3D_TX_PHY_MEASCTRL0x0d
+#define HDMI_3D_TX_PHY_VLEVCTRL0x0e
+#define HDMI_3D_TX_PHY_D2ACTRL 0x0f
+#define HDMI_3D_TX_PHY_CURRCTRL0x10
+#define HDMI_3D_TX_PHY_DRVANACTRL  0x11
+#define HDMI_3D_TX_PHY_PLLMEASCTRL 0x12
+#define HDMI_3D_TX_PHY_PLLPHBYCTRL 0x13
+#define HDMI_3D_TX_PHY_GRP_CTRL0x14
+#define HDMI_3D_TX_PHY_GMPCTRL 0x15
+#define HDMI_3D_TX_PHY_MPLLMEASCTRL0x16
+#define HDMI_3D_TX_PHY_MSM_CTRL0x17
+#define HDMI_3D_TX_PHY_SCRPB_STATUS0x18
+#define HDMI_3D_TX_PHY_TXTERM  0x19
+#define HDMI_3D_TX_PHY_PTRPT_ENBL  0x1a
+#define HDMI_3D_TX_PHY_PATTERNGEN  0x1b
+#define HDMI_3D_TX_PHY_SDCAP_MODE  0x1c
+#define HDMI_3D_TX_PHY_SCOPEMODE   0x1d
+#define HDMI_3D_TX_PHY_DIGTXMODE   0x1e
+#define HDMI_3D_TX_PHY_STR_STATUS  0x1f
+#define HDMI_3D_TX_PHY_SCOPECNT0   0x20
+#define HDMI_3D_TX_PHY_SCOPECNT1   0x21
+#define HDMI_3D_TX_PHY_SCOPECNT2   0x22
+#define HDMI_3D_TX_PHY_SCOPECNTCLK 0x23
+#define HDMI_3D_TX_PHY_SCOPESAMPLE 0x24
+#define HDMI_3D_TX_PHY_SCOPECNTMSB01  

[PATCH 2/2] drm/nouveau: Handle fbcon suspend/resume in seperate worker

[Lyude]

Resuming from RPM can happen while already holding
dev->mode_config.mutex. This means we can't actually handle fbcon in
any RPM resume workers, since restoring fbcon requires grabbing
dev->mode_config.mutex again. So move the fbcon suspend/resume code into
it's own worker, and rely on that instead to avoid deadlocking.

This fixes more deadlocks for runtime suspending the GPU on the ThinkPad
W541. Reproduction recipe:

 - Get a machine with both optimus and a nvidia card with connectors
   attached to it
 - Wait for the nvidia GPU to suspend
 - Attempt to manually reprobe any of the connectors on the nvidia GPU
   using sysfs
 - *deadlock*

Signed-off-by: Lyude 
Cc: Hans de Goede 
Cc: Kilian Singer 
Cc: Lukas Wunner 
Cc: David Airlie 
---
 drivers/gpu/drm/nouveau/nouveau_drv.h   |  2 ++
 drivers/gpu/drm/nouveau/nouveau_fbcon.c | 43 ++---
 2 files changed, 36 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h 
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index 8d5ed5b..42c1fa5 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -165,6 +165,8 @@ struct nouveau_drm {
struct backlight_device *backlight;
struct list_head bl_connectors;
struct work_struct hpd_work;
+   struct work_struct fbcon_work;
+   int fbcon_new_state;
 #ifdef CONFIG_ACPI
struct notifier_block acpi_nb;
 #endif
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index 2f2a3dc..87cd30b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -470,19 +470,43 @@ static const struct drm_fb_helper_funcs 
nouveau_fbcon_helper_funcs = {
.fb_probe = nouveau_fbcon_create,
 };
 
+static void
+nouveau_fbcon_set_suspend_work(struct work_struct *work)
+{
+   struct nouveau_drm *drm = container_of(work, typeof(*drm), fbcon_work);
+   int state = drm->fbcon_new_state;
+
+   if (state == FBINFO_STATE_RUNNING)
+   pm_runtime_get_sync(drm->dev->dev);
+
+   console_lock();
+   if (state == FBINFO_STATE_RUNNING)
+   nouveau_fbcon_accel_restore(drm->dev);
+   drm_fb_helper_set_suspend(&drm->fbcon->helper, state);
+   if (state != FBINFO_STATE_RUNNING)
+   nouveau_fbcon_accel_save_disable(drm->dev);
+   console_unlock();
+
+   if (state == FBINFO_STATE_RUNNING) {
+   pm_runtime_mark_last_busy(drm->dev->dev);
+   pm_runtime_put_sync(drm->dev->dev);
+   }
+}
+
 void
 nouveau_fbcon_set_suspend(struct drm_device *dev, int state)
 {
struct nouveau_drm *drm = nouveau_drm(dev);
-   if (drm->fbcon) {
-   console_lock();
-   if (state == FBINFO_STATE_RUNNING)
-   nouveau_fbcon_accel_restore(dev);
-   drm_fb_helper_set_suspend(&drm->fbcon->helper, state);
-   if (state != FBINFO_STATE_RUNNING)
-   nouveau_fbcon_accel_save_disable(dev);
-   console_unlock();
-   }
+
+   if (!drm->fbcon)
+   return;
+
+   drm->fbcon_new_state = state;
+   /* Since runtime resume can happen as a result of a sysfs operation,
+* it's possible we already have the console locked. So handle fbcon
+* init/deinit from a seperate work thread
+*/
+   schedule_work(&drm->fbcon_work);
 }
 
 int
@@ -502,6 +526,7 @@ nouveau_fbcon_init(struct drm_device *dev)
return -ENOMEM;
 
drm->fbcon = fbcon;
+   INIT_WORK(&drm->fbcon_work, nouveau_fbcon_set_suspend_work);
 
drm_fb_helper_prepare(dev, &fbcon->helper, &nouveau_fbcon_helper_funcs);
 
-- 
2.9.3

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

Re: Enabling peer to peer device transactions for PCIe devices

[Stephen Bates]

On Fri, January 6, 2017 4:10 pm, Logan Gunthorpe wrote:
>
>
> On 06/01/17 11:26 AM, Jason Gunthorpe wrote:
>
>
>> Make a generic API for all of this and you'd have my vote..
>>
>>
>> IMHO, you must support basic pinning semantics - that is necessary to
>> support generic short lived DMA (eg filesystem, etc). That hardware can
>> clearly do that if it can support ODP.
>
> I agree completely.
>
>
> What we want is for RDMA, O_DIRECT, etc to just work with special VMAs
> (ie. at least those backed with ZONE_DEVICE memory). Then
> GPU/NVME/DAX/whatever drivers can just hand these VMAs to userspace
> (using whatever interface is most appropriate) and userspace can do what
> it pleases with them. This makes _so_ much sense and actually largely
> already works today (as demonstrated by iopmem).

+1 for iopmem ;-)

I feel like we are going around and around on this topic. I would like to
see something that is upstream that enables P2P even if it is only the
minimum viable useful functionality to begin. I think aiming for the moon
(which is what HMM and things like it are) are simply going to take more
time if they ever get there.

There is a use case for in-kernel P2P PCIe transfers between two NVMe
devices and between an NVMe device and an RDMA NIC (using NVMe CMBs or
BARs on the NIC). I am even seeing users who now want to move data P2P
between FPGAs and NVMe SSDs and the upstream kernel should be able to
support these users or they will look elsewhere.

The iopmem patchset addressed all the use cases above and while it is not
an in kernel API it could have been modified to be one reasonably easily.
As Logan states the driver can then choose to pass the VMAs to user-space
in a manner that makes sense.

Earlier in the thread someone mentioned LSF/MM. There is already a
proposal to discuss this topic so if you are interested please respond to
the email letting the committee know this topic is of interest to you [1].

Also earlier in the thread someone discussed the issues around the IOMMU.
Given the known issues around P2P transfers in certain CPU root complexes
[2] it might just be a case of only allowing P2P when a PCIe switch
connects the two EPs. Another option is just to use CONFIG_EXPERT and make
sure people are aware of the pitfalls if they invoke the P2P option.

Finally, as Jason noted, we could all just wait until
CAPI/OpenCAPI/CCIX/GenZ comes along. However given that these interfaces
are the remit of the CPU vendors I think it behooves us to solve this
problem before then. Also some of the above mentioned protocols are not
even switchable and may not be amenable to a P2P topology...

Stephen

[1] http://marc.info/?l=linux-mm&m=148156541804940&w=2
[2] https://community.mellanox.com/docs/DOC-1119

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

[PATCH v2 1/2] drm/nouveau: Don't enabling polling twice on runtime resume

[Lyude]

As it turns out, on cards that actually have CRTCs on them we're already
calling drm_kms_helper_poll_enable(drm_dev) from
nouveau_display_resume() before we call it in
nouveau_pmops_runtime_resume(). This leads us to accidentally trying to
enable polling twice, which results in a potential deadlock between the
RPM locks and drm_dev->mode_config.mutex if we end up trying to enable
polling the second time while output_poll_execute is running and holding
the mode_config lock. As such, make sure we only enable polling in
nouveau_pmops_runtime_resume() if we need to.

This fixes hangs observed on the ThinkPad W541

Signed-off-by: Lyude 
Cc: Hans de Goede 
Cc: Kilian Singer 
Cc: Lukas Wunner 
Cc: David Airlie 
---
Changes since v1:
 - Rebase to work with master

 drivers/gpu/drm/nouveau/nouveau_display.c | 3 ++-
 drivers/gpu/drm/nouveau/nouveau_drm.c | 5 -
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c
index cef08da..6a15776 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -411,7 +411,8 @@ nouveau_display_init(struct drm_device *dev)
return ret;
 
/* enable polling for external displays */
-   drm_kms_helper_poll_enable(dev);
+   if (!dev->mode_config.poll_enabled)
+   drm_kms_helper_poll_enable(dev);
 
/* enable hotplug interrupts */
list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 59348fc..bc85a45 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -773,7 +773,10 @@ nouveau_pmops_runtime_resume(struct device *dev)
pci_set_master(pdev);
 
ret = nouveau_do_resume(drm_dev, true);
-   drm_kms_helper_poll_enable(drm_dev);
+
+   if (!drm_dev->mode_config.poll_enabled)
+   drm_kms_helper_poll_enable(drm_dev);
+
/* do magic */
nvif_mask(&device->object, 0x088488, (1 << 25), (1 << 25));
vga_switcheroo_set_dynamic_switch(pdev, VGA_SWITCHEROO_ON);
-- 
2.9.3

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

[PULL] drm-intel-fixes

[Jani Nikula]

Hi Dave -

Mostly GVT-g fixes, with a couple of other fixes from Chris.

BR,
Jani.

The following changes since commit a121103c922847ba5010819a3f250f1f7fc84ab8:

  Linux 4.10-rc3 (2017-01-08 14:18:17 -0800)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-intel tags/drm-intel-fixes-2017-01-12

for you to fetch changes up to e4621b73b6b472fe2b434b4f0f76b8f33ee26a73:

  drm/i915: Fix phys pwrite for struct_mutex-less operation (2017-01-12 
10:15:44 +0200)


Changbin Du (5):
  drm/i915/gvt: fix error handing of tlb_control emulation
  drm/i915/gvt: fix return value in mul_force_wake_write
  drm/i915/gvt: always use readq and writeq
  drm/i915/gvt: fix use after free for workload
  drm/i915/gvt: dec vgpu->running_workload_num after the workload is really 
done

Chris Wilson (2):
  drm/i915: Clear ret before unbinding in i915_gem_evict_something()
  drm/i915: Fix phys pwrite for struct_mutex-less operation

Jani Nikula (1):
  Merge tag 'gvt-fixes-2017-01-10' of https://github.com/01org/gvt-linux 
into drm-intel-fixes

Jike Song (5):
  drm/i915/gvt: init/destroy vgpu_idr properly
  drm/i915/gvt: destroy the allocated idr on vgpu creating failures
  drm/i915/gvt: cleanup opregion memory allocation code
  drm/i915/gvt/kvmgt: return meaningful error for vgpu creating failure
  drm/i915/gvt: cleanup GFP flags

Nicolas Iooss (1):
  drm/i915/gvt: verify functions types in new_mmio_info()

Pei Zhang (1):
  drm/i915/gvt: print correct value for untracked mmio

Zhenyu Wang (2):
  drm/i915/gvt: adjust high memory size for default vGPU type
  drm/i915/gvt: remove duplicated definition

 drivers/gpu/drm/i915/gvt/aperture_gm.c |  7 -
 drivers/gpu/drm/i915/gvt/gtt.c | 54 +++---
 drivers/gpu/drm/i915/gvt/gvt.c |  8 -
 drivers/gpu/drm/i915/gvt/handlers.c| 13 
 drivers/gpu/drm/i915/gvt/kvmgt.c   | 14 ++---
 drivers/gpu/drm/i915/gvt/mmio.c| 31 +--
 drivers/gpu/drm/i915/gvt/opregion.c|  8 ++---
 drivers/gpu/drm/i915/gvt/reg.h |  3 +-
 drivers/gpu/drm/i915/gvt/scheduler.c   | 14 -
 drivers/gpu/drm/i915/gvt/vgpu.c|  8 +++--
 drivers/gpu/drm/i915/i915_gem.c| 34 +++--
 drivers/gpu/drm/i915/i915_gem_evict.c  |  1 +
 12 files changed, 78 insertions(+), 117 deletions(-)

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

Re: [Intel-gfx] [PATCH v2 2/5] drm/edid: Introduce drm_default_rgb_quant_range()

[Ville Syrjälä]

On Thu, Jan 12, 2017 at 11:29:18AM +0200, Jani Nikula wrote:
> On Wed, 11 Jan 2017, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> >
> > Make the code selecting the RGB quantization range a little less magicy
> > by wrapping it up in a small helper.
> >
> > v2: s/adjusted_mode/mode in vc4 to make it actually compile
> >
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/drm_edid.c| 18 ++
> >  drivers/gpu/drm/i915/intel_dp.c   |  4 +++-
> >  drivers/gpu/drm/i915/intel_hdmi.c |  3 ++-
> >  drivers/gpu/drm/vc4/vc4_hdmi.c|  4 +++-
> >  include/drm/drm_edid.h|  2 ++
> >  5 files changed, 28 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> > index 4ff04aa84dd0..304c583b8000 100644
> > --- a/drivers/gpu/drm/drm_edid.c
> > +++ b/drivers/gpu/drm/drm_edid.c
> > @@ -3768,6 +3768,24 @@ bool drm_rgb_quant_range_selectable(struct edid 
> > *edid)
> >  }
> >  EXPORT_SYMBOL(drm_rgb_quant_range_selectable);
> >  
> > +/**
> > + * drm_default_rgb_quant_range - default RGB quantization range
> > + * @mode: display mode
> > + *
> > + * Determine the default RGB quantization range for the mode,
> > + * as specified in CEA-861.
> > + *
> > + * Return: The default RGB quantization range for the mode
> > + */
> > +enum hdmi_quantization_range
> > +drm_default_rgb_quant_range(const struct drm_display_mode *mode)
> > +{
> > +   return drm_match_cea_mode(mode) > 1 ?
> > +   HDMI_QUANTIZATION_RANGE_LIMITED :
> > +   HDMI_QUANTIZATION_RANGE_FULL;
> > +}
> > +EXPORT_SYMBOL(drm_default_rgb_quant_range);
> 
> Or just bool drm_default_to_limited_range() or similar?

That's what I had initially, but then I thought it might be better to
start moving towards something a bit more explicit everwhere. But I
stopped short of actually making the drivers store the enum in their
state. We might want to do that, I think.

> 
> *shrug*
> 
> Reviewed-by: Jani Nikula 
> 
> 
> 
> > +
> >  static void drm_parse_hdmi_deep_color_info(struct drm_connector *connector,
> >const u8 *hdmi)
> >  {
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 343e1d9fa761..d4befbbe834a 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -1713,7 +1713,9 @@ intel_dp_compute_config(struct intel_encoder *encoder,
> >  * VESA DisplayPort Ver.1.2a - 5.1.1.1 Video Colorimetry
> >  */
> > pipe_config->limited_color_range =
> > -   bpp != 18 && drm_match_cea_mode(adjusted_mode) > 1;
> > +   bpp != 18 &&
> > +   drm_default_rgb_quant_range(adjusted_mode) ==
> > +   HDMI_QUANTIZATION_RANGE_LIMITED;
> > } else {
> > pipe_config->limited_color_range =
> > intel_dp->limited_color_range;
> > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> > b/drivers/gpu/drm/i915/intel_hdmi.c
> > index 0bcfead14571..19bd13f53729 100644
> > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > @@ -1330,7 +1330,8 @@ bool intel_hdmi_compute_config(struct intel_encoder 
> > *encoder,
> > /* See CEA-861-E - 5.1 Default Encoding Parameters */
> > pipe_config->limited_color_range =
> > pipe_config->has_hdmi_sink &&
> > -   drm_match_cea_mode(adjusted_mode) > 1;
> > +   drm_default_rgb_quant_range(adjusted_mode) ==
> > +   HDMI_QUANTIZATION_RANGE_LIMITED;
> > } else {
> > pipe_config->limited_color_range =
> > intel_hdmi->limited_color_range;
> > diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > index c4cb2e26de32..5d49bf948162 100644
> > --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> > +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > @@ -463,7 +463,9 @@ static void vc4_hdmi_encoder_mode_set(struct 
> > drm_encoder *encoder,
> > csc_ctl = VC4_SET_FIELD(VC4_HD_CSC_CTL_ORDER_BGR,
> > VC4_HD_CSC_CTL_ORDER);
> >  
> > -   if (vc4_encoder->hdmi_monitor && drm_match_cea_mode(mode) > 1) {
> > +   if (vc4_encoder->hdmi_monitor &&
> > +   drm_default_rgb_quant_range(mode) ==
> > +   HDMI_QUANTIZATION_RANGE_LIMITED) {
> > /* CEA VICs other than #1 requre limited range RGB
> >  * output unless overridden by an AVI infoframe.
> >  * Apply a colorspace conversion to squash 0-255 down
> > diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
> > index 838eaf2b42e9..25cdf5f7a0d8 100644
> > --- a/include/drm/drm_edid.h
> > +++ b/include/drm/drm_edid.h
> > @@ -441,6 +441,8 @@ enum hdmi_picture_aspect drm_get_cea_aspect_ratio(const 
> > u8 video_code);
> >  bool drm_detect_hdmi_monitor(struct edid *edid);
> >  bool drm_detect_monitor_audio(struct edid *edid);
> >  boo

Re: [PATCH 5/5] drm/tegra: Stop using drm_framebuffer_unregister_private

[Thierry Reding]

On Tue, Dec 27, 2016 at 11:49:25AM +0100, Daniel Vetter wrote:
> This is the deprecated function for when you embedded the framebuffer
> somewhere else (which breaks refcounting). But tegra is using
> drm_framebuffer_remove and a free-standing fb, so this is rendundant.

Nit: "Tegra", "redundant", "FB"?

> 
> One caveat here is that the failur path in the init code still

"failure"

> manually cleaned up the fb. I presume that was an oversigth and

"oversight"

> changed it over to drm_framebuffer_remove too.
> 
> Cc: Thierry Reding 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/tegra/fb.c | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)

Yes, drm_framebuffer_remove() ends up calling tegra_fb_destroy(), which
is really what we need here, so:

Acked-by: Thierry Reding 


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

Re: [PATCH] drm/amdgpu/gfx8: fix bugon.cocci warnings

[Alex Deucher]

On Tue, Jan 10, 2017 at 4:38 AM, Yu, Xiangliang  wrote:
>>  Use BUG_ON instead of a if condition followed by BUG.
>>
>> Generated by: scripts/coccinelle/misc/bugon.cocci
>>
>> CC: Xiangliang Yu 
>> Signed-off-by: Julia Lawall 
>> Signed-off-by: Fengguang Wu 

Applied.  thanks!

Alex

>> ---
>>
>>  gfx_v8_0.c |3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
>> @@ -6623,8 +6623,7 @@ static void gfx_v8_0_ring_emit_fence_kiq
>>u64 seq, unsigned int flags)
>>  {
>>   /* we only allocate 32bit for each seq wb address */
>> - if (flags & AMDGPU_FENCE_FLAG_64BIT)
>> - BUG();
>> + BUG_ON(flags & AMDGPU_FENCE_FLAG_64BIT);
>>
>>   /* write fence seq to the "addr" */
>>   amdgpu_ring_write(ring, PACKET3(PACKET3_WRITE_DATA, 3));
>
> Reviewd-by: Xiangliang.Yu 
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH 1/3] drm: Add new DRM_IOCTL_MODE_GETPLANE2

[Rob Clark]

On Thu, Jan 12, 2017 at 4:38 AM, Ville Syrjälä
 wrote:
> On Wed, Jan 11, 2017 at 08:43:16PM -0500, Rob Clark wrote:
>> On Wed, Jan 11, 2017 at 7:51 PM, Ben Widawsky  wrote:
>> >
>> > +struct drm_format_modifier {
>> > +   /* Bitmask of formats in get_plane format list this info
>> > +* applies to. */
>> > +   uint64_t formats;
>>
>> re: the uabi, I'd suggest to at least make this 'u32 offset; u32
>> formats'.. we can keep the existing implementation in this patch and
>> always set 'offset' to zero, and let the first one to hit more than 32
>> formats deal with the implementation.  (Maybe a strategically placed
>> WARN_ON() if you go that route..)
>
> Isn't an implicit offset enough? As in first mask for a specific
> modifier is for format indexes 0-63, second mask for the same modifier
> is for 64-127, and so on.

hmm, hadn't thought of that approach.  Definitely if we go w/ implicit
then we want to have userspace support from the get-go.  For explicit,
I guess userspace could complain and ignore if it saw a non-zero
offset similar to what we do w/ pad and unknown flags in the other
direction?

Not sure if that would fly or not..  I guess it is not a *critical*
fail, it just means userspace won't realize that some modifiers are
supported on some formats.. otoh the implicit approach could confuse a
userspace that didn't realize the offset into thinking modifiers
*were* supported on formats where they are not.. that seems like a
bigger problem.

BR,
-R

> The bigger issue is the userspace side I think. If we don't add the
> userspace side code to handle this case from the get go, it's going to
> be hard to actually start doing it from the kernel side.
>
>>
>> Otherwise I guess it is just a couple years until getplane3 ;-)
>>
>> BR,
>> -R
>>
>> > +
>> > +   /* This modifier can be used with the format for this plane. */
>> > +   uint64_t modifier;
>> > +};
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Ville Syrjälä
> Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Enabling peer to peer device transactions for PCIe devices

[Jerome Glisse]

On Wed, Jan 11, 2017 at 10:54:39PM -0600, Stephen Bates wrote:
> On Fri, January 6, 2017 4:10 pm, Logan Gunthorpe wrote:
> >
> >
> > On 06/01/17 11:26 AM, Jason Gunthorpe wrote:
> >
> >
> >> Make a generic API for all of this and you'd have my vote..
> >>
> >>
> >> IMHO, you must support basic pinning semantics - that is necessary to
> >> support generic short lived DMA (eg filesystem, etc). That hardware can
> >> clearly do that if it can support ODP.
> >
> > I agree completely.
> >
> >
> > What we want is for RDMA, O_DIRECT, etc to just work with special VMAs
> > (ie. at least those backed with ZONE_DEVICE memory). Then
> > GPU/NVME/DAX/whatever drivers can just hand these VMAs to userspace
> > (using whatever interface is most appropriate) and userspace can do what
> > it pleases with them. This makes _so_ much sense and actually largely
> > already works today (as demonstrated by iopmem).
> 
> +1 for iopmem ;-)
> 
> I feel like we are going around and around on this topic. I would like to
> see something that is upstream that enables P2P even if it is only the
> minimum viable useful functionality to begin. I think aiming for the moon
> (which is what HMM and things like it are) are simply going to take more
> time if they ever get there.
> 
> There is a use case for in-kernel P2P PCIe transfers between two NVMe
> devices and between an NVMe device and an RDMA NIC (using NVMe CMBs or
> BARs on the NIC). I am even seeing users who now want to move data P2P
> between FPGAs and NVMe SSDs and the upstream kernel should be able to
> support these users or they will look elsewhere.
> 
> The iopmem patchset addressed all the use cases above and while it is not
> an in kernel API it could have been modified to be one reasonably easily.
> As Logan states the driver can then choose to pass the VMAs to user-space
> in a manner that makes sense.
> 
> Earlier in the thread someone mentioned LSF/MM. There is already a
> proposal to discuss this topic so if you are interested please respond to
> the email letting the committee know this topic is of interest to you [1].
> 
> Also earlier in the thread someone discussed the issues around the IOMMU.
> Given the known issues around P2P transfers in certain CPU root complexes
> [2] it might just be a case of only allowing P2P when a PCIe switch
> connects the two EPs. Another option is just to use CONFIG_EXPERT and make
> sure people are aware of the pitfalls if they invoke the P2P option.


iopmem is not applicable to GPU what i propose is to split the issue in 2
so that everyone can reuse the part that needs to be common namely the DMA
API part where you have to create IOMMU mapping for one device to point
to the other device memory.

We can have a DMA API that is agnostic to how the device memory is manage
(so does not matter if device memory have struct page or not). This what
i have been arguing in this thread. To make progress on this issue we need
to stop conflicting different use case.

So i say let solve the IOMMU issue first and let everyone use it in their
own way with their device. I do not think we can share much more than
that.

Cheers,
Jérôme
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm: bridge: dw-hdmi: Define and use macros for PHY register addresses

[Laurent Pinchart]

Hi Nickey,

On Thursday 12 Jan 2017 09:45:31 Nickey.Yang wrote:
> 在 2017年01月12日 07:49, Laurent Pinchart 写道:
> > Replace the hardcoded register address numerical values with macros to
> > clarify the code.
> > 
> > This change has been tested by comparing the assembly code before and
> > after the change.
> > 
> > Signed-off-by: Laurent Pinchart
> > 
> > ---
> > 
> > drivers/gpu/drm/bridge/dw-hdmi.c | 35 -
> > drivers/gpu/drm/bridge/dw-hdmi.h | 66 
> > 2 files changed, 86 insertions(+), 15 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/bridge/dw-hdmi.c
> > b/drivers/gpu/drm/bridge/dw-hdmi.c index ef4f2f96ed2c..6e605fd910ef
> > 100644
> > --- a/drivers/gpu/drm/bridge/dw-hdmi.c
> > +++ b/drivers/gpu/drm/bridge/dw-hdmi.c
> > @@ -997,21 +997,26 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi,
> > int cscon)
> > HDMI_PHY_I2CM_SLAVE_ADDR);
> > hdmi_phy_test_clear(hdmi, 0);
> > 
> > -   hdmi_phy_i2c_write(hdmi, mpll_config->res[0].cpce, 0x06);
> > -   hdmi_phy_i2c_write(hdmi, mpll_config->res[0].gmp, 0x15);
> > -
> > -   /* CURRCTRL */
> > -   hdmi_phy_i2c_write(hdmi, curr_ctrl->curr[0], 0x10);
> > -
> > -   hdmi_phy_i2c_write(hdmi, 0x, 0x13);  /* PLLPHBYCTRL */
> > -   hdmi_phy_i2c_write(hdmi, 0x0006, 0x17);
> > -
> > -   hdmi_phy_i2c_write(hdmi, phy_config->term, 0x19);  /* TXTERM */
> > -   hdmi_phy_i2c_write(hdmi, phy_config->sym_ctr, 0x09); /* CKSYMTXCTRL */
> > -   hdmi_phy_i2c_write(hdmi, phy_config->vlev_ctr, 0x0E); /* VLEVCTRL */
> > -
> > -   /* REMOVE CLK TERM */
> > -   hdmi_phy_i2c_write(hdmi, 0x8000, 0x05);  /* CKCALCTRL */
> > +   hdmi_phy_i2c_write(hdmi, mpll_config->res[0].cpce,
> > +  HDMI_3D_TX_PHY_CPCE_CTRL);
> > +   hdmi_phy_i2c_write(hdmi, mpll_config->res[0].gmp,
> > +  HDMI_3D_TX_PHY_GMPCTRL);
> > +   hdmi_phy_i2c_write(hdmi, curr_ctrl->curr[0],
> > +  HDMI_3D_TX_PHY_CURRCTRL);
> > +
> > +   hdmi_phy_i2c_write(hdmi, 0, HDMI_3D_TX_PHY_PLLPHBYCTRL);
> > +   hdmi_phy_i2c_write(hdmi, HDMI_3D_TX_PHY_MSM_CTRL_CKO_SEL_FB_CLK,
> > +  HDMI_3D_TX_PHY_MSM_CTRL);
> > +
> > +   hdmi_phy_i2c_write(hdmi, phy_config->term, HDMI_3D_TX_PHY_TXTERM);
> > +   hdmi_phy_i2c_write(hdmi, phy_config->sym_ctr,
> > +  HDMI_3D_TX_PHY_CKSYMTXCTRL);
> > +   hdmi_phy_i2c_write(hdmi, phy_config->vlev_ctr,
> > +  HDMI_3D_TX_PHY_VLEVCTRL);
> > +
> > +   /* Override and disable clock termination. */
> > +   hdmi_phy_i2c_write(hdmi, HDMI_3D_TX_PHY_CKCALCTRL_OVERRIDE,
> > +  HDMI_3D_TX_PHY_CKCALCTRL);
> > 
> > dw_hdmi_phy_enable_powerdown(hdmi, false);
> > 
> > diff --git a/drivers/gpu/drm/bridge/dw-hdmi.h
> > b/drivers/gpu/drm/bridge/dw-hdmi.h index a4fd64a203c9..f3c149c88d71
> > 100644
> > --- a/drivers/gpu/drm/bridge/dw-hdmi.h
> > +++ b/drivers/gpu/drm/bridge/dw-hdmi.h
> > @@ -1085,4 +1085,70 @@ enum {
> > HDMI_I2CM_CTLINT_ARB_MASK = 0x4,
> >   };
> > 
> > +/*
> > + * HDMI 3D TX PHY registers
> > + */
> 
> Why is there 3D related words？

The register names come from the i.MX6 datasheet. I don't have access to any 
PHY datasheet from Synopsys, and the Rockchip RK3288 manuals I've been able to 
find don't document the HDMI PHY register. As the PHY used by i.MX6 is a "DWC 
HDMI 3D TX PHY", I'd used that name in the code.

The "DWC MHL PHY" used by RK3288 seems to be use a similar (if not identical) 
registers map, at least for the registers configured by the driver. The "DWC 
HDMI 2.0 TX PHY" PHY used by R-Car Gen3, however, seems not to have a 
compatible register interface, except for the HDMI_3D_TX_PHY_PTRPT_ENBL 
register.

I'm open to suggestions for a better naming scheme. If you have additional 
information that I don't have access to, please feel free to use them to 
propose improvements or to point out my mistakes :-)

> I did not find "3D" words in PHY IP vendor document.

How is the PHY named in the documentation you have access to ?

> > +#define HDMI_3D_TX_PHY_PWRCTRL 0x00
> > +#define HDMI_3D_TX_PHY_SERDIVCTRL  0x01
> > +#define HDMI_3D_TX_PHY_SERCKCTRL   0x02
> > +#define HDMI_3D_TX_PHY_SERCKKILLCTRL   0x03
> > +#define HDMI_3D_TX_PHY_TXRESCTRL   0x04
> > +#define HDMI_3D_TX_PHY_CKCALCTRL   0x05
> > +#define HDMI_3D_TX_PHY_CPCE_CTRL   0x06
> > +#define HDMI_3D_TX_PHY_TXCLKMEASCTRL   0x07
> > +#define HDMI_3D_TX_PHY_TXMEASCTRL  0x08
> > +#define HDMI_3D_TX_PHY_CKSYMTXCTRL 0x09
> > +#define HDMI_3D_TX_PHY_CMPSEQCTRL  0x0a
> > +#define HDMI_3D_TX_PHY_CMPPWRCTRL  0x0b
> > +#define HDMI_3D_TX_PHY_CMPMODECTRL 0x0c
> > +#define HDMI_3D_TX_PHY_MEASCTRL0x0d
> > +#define HDMI_3D_TX_PHY_VLEVCTRL0x0e
> > +#define HDMI_3D_TX_PHY_D2ACTRL 0x0f
> > +#define HDMI_3D_TX_PHY_CURRCTRL0x10
> > +#defi

[PATCH] drm: Don't race connector registration

[Daniel Vetter]

I was under the misconception that the sysfs dev stuff can be fully
set up, and then registered all in one step with device_add. That's
true for properties and property groups, but not for parents and child
devices. Those must be fully registered before you can register a
child.

Add a bit of tracking to make sure that asynchronous mst connector
hotplugging gets this right. For consistency we rely upon the implicit
barriers of the connector->mutex, which is taken anyway, to ensure
that at least either the connector or device registration call will
work out.

Mildly tested since I can't reliably reproduce this on my mst box
here.

Reported-by: Dave Hansen 
Cc: Dave Hansen 
Cc: Chris Wilson 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_connector.c | 3 +++
 drivers/gpu/drm/drm_drv.c   | 4 
 include/drm/drmP.h  | 1 +
 3 files changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index c75ab242f907..5999cb83d05b 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -378,6 +378,9 @@ int drm_connector_register(struct drm_connector *connector)
 {
int ret = 0;
 
+   if (!connector->dev->registered)
+   return 0;
+
mutex_lock(&connector->mutex);
if (connector->registered)
goto unlock;
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 7e24103c47f1..cad6df626678 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -749,6 +749,8 @@ int drm_dev_register(struct drm_device *dev, unsigned long 
flags)
if (ret)
goto err_minors;
 
+   dev->registered = true;
+
if (dev->driver->load) {
ret = dev->driver->load(dev, flags);
if (ret)
@@ -796,6 +798,8 @@ void drm_dev_unregister(struct drm_device *dev)
 
drm_lastclose(dev);
 
+   dev->registered = false;
+
if (drm_core_check_feature(dev, DRIVER_MODESET))
drm_modeset_unregister_all(dev);
 
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index c537c278a4be..ec105c339347 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -518,6 +518,7 @@ struct drm_device {
struct drm_minor *control;  /**< Control node */
struct drm_minor *primary;  /**< Primary node */
struct drm_minor *render;   /**< Render node */
+   bool registered;
 
/* currently active master for this device. Protected by master_mutex */
struct drm_master *master;
-- 
2.5.5

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

[PATCH 1/3] drm: qxl: Let DRM core handle connector registering

[Gabriel Krisman Bertazi]

Registering the connector explicitly right after creation is not
necessary for modesetting drivers, because drm_dev_register already takes
care of this on the core side, by calling drm_modeset_register_all.

In addition, performing the initialization too early will get in the way
of the load() hook removal, because the connector interface cannot be
published prior to registering the minors.

Signed-off-by: Gabriel Krisman Bertazi 
CC: Dave Airlie 
CC: Daniel Vetter 
CC: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/qxl/qxl_display.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index 659c77742649..416ade8566b7 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -1077,7 +1077,6 @@ static int qdev_output_init(struct drm_device *dev, int 
num_output)
   dev->mode_config.suggested_x_property, 0);
drm_object_attach_property(&connector->base,
   dev->mode_config.suggested_y_property, 0);
-   drm_connector_register(connector);
return 0;
 }
 
-- 
2.11.0

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

[PATCH 3/3] drm: qxl: Open code teardown function for qxl

[Gabriel Krisman Bertazi]

This avoids using the deprecated drm_put_dev() and unload() hook
interfaces in the qxl driver.

Signed-off-by: Gabriel Krisman Bertazi 
CC: Dave Airlie 
CC: Daniel Vetter 
CC: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/qxl/qxl_drv.c | 11 +--
 drivers/gpu/drm/qxl/qxl_drv.h |  2 --
 drivers/gpu/drm/qxl/qxl_kms.c | 16 
 3 files changed, 9 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index 7cc29027a612..6e0f8a2d8ac9 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -129,8 +129,16 @@ static void
 qxl_pci_remove(struct pci_dev *pdev)
 {
struct drm_device *dev = pci_get_drvdata(pdev);
+   struct qxl_device *qdev = dev->dev_private;
+
+   drm_dev_unregister(dev);
+
+   qxl_modeset_fini(qdev);
+   qxl_device_fini(qdev);
 
-   drm_put_dev(dev);
+   dev->dev_private = NULL;
+   kfree(qdev);
+   drm_dev_unref(dev);
 }
 
 static const struct file_operations qxl_fops = {
@@ -285,7 +293,6 @@ static struct pci_driver qxl_pci_driver = {
 static struct drm_driver qxl_driver = {
.driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
   DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED,
-   .unload = qxl_driver_unload,
.get_vblank_counter = qxl_noop_get_vblank_counter,
.enable_vblank = qxl_noop_enable_vblank,
.disable_vblank = qxl_noop_disable_vblank,
diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index d0aed9ed12d2..458501534313 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.h
+++ b/drivers/gpu/drm/qxl/qxl_drv.h
@@ -340,8 +340,6 @@ int qxl_device_init(struct qxl_device *qdev, struct 
drm_device *ddev,
struct pci_dev *pdev,  unsigned long flags);
 void qxl_device_fini(struct qxl_device *qdev);
 
-void qxl_driver_unload(struct drm_device *dev);
-
 int qxl_modeset_init(struct qxl_device *qdev);
 void qxl_modeset_fini(struct qxl_device *qdev);
 
diff --git a/drivers/gpu/drm/qxl/qxl_kms.c b/drivers/gpu/drm/qxl/qxl_kms.c
index 6848057d0917..d0666f5dccd6 100644
--- a/drivers/gpu/drm/qxl/qxl_kms.c
+++ b/drivers/gpu/drm/qxl/qxl_kms.c
@@ -284,19 +284,3 @@ void qxl_device_fini(struct qxl_device *qdev)
qdev->mode_info.num_modes = 0;
qxl_debugfs_remove_files(qdev);
 }
-
-void qxl_driver_unload(struct drm_device *dev)
-{
-   struct qxl_device *qdev = dev->dev_private;
-
-   if (qdev == NULL)
-   return;
-
-   drm_vblank_cleanup(dev);
-
-   qxl_modeset_fini(qdev);
-   qxl_device_fini(qdev);
-
-   kfree(qdev);
-   dev->dev_private = NULL;
-}
-- 
2.11.0

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

[PATCH 2/3] drm: qxl: Open code probing sequence for qxl

[Gabriel Krisman Bertazi]

This avoids using the deprecated drm_get_pci_dev() and load() hook
interfaces in the qxl driver.

The only tricky part is to ensure TTM debugfs initialization
happens after the debugfs root node is created, which is done by moving
that code into the debufs_init() hook.  Since the hook is called 3 times
for each minor function, we make sure it is only executed for the
primary minor.

Tested on qemu with igt and running a WM on top of X.

Signed-off-by: Gabriel Krisman Bertazi 
CC: Dave Airlie 
CC: Daniel Vetter 
CC: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/qxl/qxl_debugfs.c | 12 
 drivers/gpu/drm/qxl/qxl_drv.c | 58 +--
 drivers/gpu/drm/qxl/qxl_drv.h |  7 -
 drivers/gpu/drm/qxl/qxl_kms.c | 40 ++-
 drivers/gpu/drm/qxl/qxl_ttm.c |  8 +-
 5 files changed, 77 insertions(+), 48 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_debugfs.c 
b/drivers/gpu/drm/qxl/qxl_debugfs.c
index 241af9131dc8..417b538b3ed8 100644
--- a/drivers/gpu/drm/qxl/qxl_debugfs.c
+++ b/drivers/gpu/drm/qxl/qxl_debugfs.c
@@ -84,8 +84,20 @@ int
 qxl_debugfs_init(struct drm_minor *minor)
 {
 #if defined(CONFIG_DEBUG_FS)
+   int r;
+   struct qxl_device *dev =
+   (struct qxl_device *) minor->dev->dev_private;
+
drm_debugfs_create_files(qxl_debugfs_list, QXL_DEBUGFS_ENTRIES,
 minor->debugfs_root, minor);
+
+   if (minor->type == DRM_MINOR_PRIMARY) {
+   r = qxl_ttm_debugfs_init(dev);
+   if (r) {
+   DRM_ERROR("Failed to init TTM debugfs\n");
+   return r;
+   }
+   }
 #endif
return 0;
 }
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index 460bbceae297..7cc29027a612 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -62,12 +62,67 @@ static struct pci_driver qxl_pci_driver;
 static int
 qxl_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
 {
+   struct drm_device *drm;
+   struct qxl_device *qdev;
+   int ret;
+
if (pdev->revision < 4) {
DRM_ERROR("qxl too old, doesn't support client_monitors_config,"
  " use xf86-video-qxl in user mode");
return -EINVAL; /* TODO: ENODEV ? */
}
-   return drm_get_pci_dev(pdev, ent, &qxl_driver);
+
+   drm = drm_dev_alloc(&qxl_driver, &pdev->dev);
+   if (IS_ERR(drm))
+   return -ENOMEM;
+
+   qdev = kzalloc(sizeof(struct qxl_device), GFP_KERNEL);
+   if (!qdev) {
+   ret = -ENOMEM;
+   goto free_drm_device;
+   }
+
+   ret = pci_enable_device(pdev);
+   if (ret)
+   goto free_drm_device;
+
+   drm->pdev = pdev;
+   pci_set_drvdata(pdev, drm);
+   drm->dev_private = qdev;
+
+   ret = qxl_device_init(qdev, drm, pdev, ent->driver_data);
+   if (ret)
+   goto disable_pci;
+
+   ret = drm_vblank_init(drm, 1);
+   if (ret)
+   goto unload;
+
+   ret = qxl_modeset_init(qdev);
+   if (ret)
+   goto vblank_cleanup;
+
+   drm_kms_helper_poll_init(qdev->ddev);
+
+   /* Complete initialization. */
+   ret = drm_dev_register(drm, ent->driver_data);
+   if (ret)
+   goto modeset_cleanup;
+
+   return 0;
+
+modeset_cleanup:
+   qxl_modeset_fini(qdev);
+vblank_cleanup:
+   drm_vblank_cleanup(drm);
+unload:
+   qxl_device_fini(qdev);
+disable_pci:
+   pci_disable_device(pdev);
+free_drm_device:
+   kfree(qdev);
+   kfree(drm);
+   return ret;
 }
 
 static void
@@ -230,7 +285,6 @@ static struct pci_driver qxl_pci_driver = {
 static struct drm_driver qxl_driver = {
.driver_features = DRIVER_GEM | DRIVER_MODESET | DRIVER_PRIME |
   DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED,
-   .load = qxl_driver_load,
.unload = qxl_driver_unload,
.get_vblank_counter = qxl_noop_get_vblank_counter,
.enable_vblank = qxl_noop_enable_vblank,
diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
index 883d8639c04e..d0aed9ed12d2 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.h
+++ b/drivers/gpu/drm/qxl/qxl_drv.h
@@ -336,7 +336,10 @@ __printf(2,3) void qxl_io_log(struct qxl_device *qdev, 
const char *fmt, ...);
 extern const struct drm_ioctl_desc qxl_ioctls[];
 extern int qxl_max_ioctl;
 
-int qxl_driver_load(struct drm_device *dev, unsigned long flags);
+int qxl_device_init(struct qxl_device *qdev, struct drm_device *ddev,
+   struct pci_dev *pdev,  unsigned long flags);
+void qxl_device_fini(struct qxl_device *qdev);
+
 void qxl_driver_unload(struct drm_device *dev);
 
 int qxl_modeset_init(struct qxl_device *qdev);
@@ -345,6 +348,8 @@ void qxl_modeset_fini(struct qxl_device *qdev);
 int qxl_bo_init(struct qxl_device *qdev);
 void qxl_bo_fini(struct qxl_d

Re: [PATCH] drm: Don't race connector registration

[Daniel Vetter]

On Thu, Jan 12, 2017 at 05:15:56PM +0100, Daniel Vetter wrote:
> I was under the misconception that the sysfs dev stuff can be fully
> set up, and then registered all in one step with device_add. That's
> true for properties and property groups, but not for parents and child
> devices. Those must be fully registered before you can register a
> child.
> 
> Add a bit of tracking to make sure that asynchronous mst connector
> hotplugging gets this right. For consistency we rely upon the implicit
> barriers of the connector->mutex, which is taken anyway, to ensure
> that at least either the connector or device registration call will
> work out.
> 
> Mildly tested since I can't reliably reproduce this on my mst box
> here.
> 
> Reported-by: Dave Hansen 
> Cc: Dave Hansen 
> Cc: Chris Wilson 
> Signed-off-by: Daniel Vetter 

Cc: sta...@vger.kernel.org

> ---
>  drivers/gpu/drm/drm_connector.c | 3 +++
>  drivers/gpu/drm/drm_drv.c   | 4 
>  include/drm/drmP.h  | 1 +
>  3 files changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index c75ab242f907..5999cb83d05b 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -378,6 +378,9 @@ int drm_connector_register(struct drm_connector 
> *connector)
>  {
>   int ret = 0;
>  
> + if (!connector->dev->registered)
> + return 0;
> +
>   mutex_lock(&connector->mutex);
>   if (connector->registered)
>   goto unlock;
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 7e24103c47f1..cad6df626678 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -749,6 +749,8 @@ int drm_dev_register(struct drm_device *dev, unsigned 
> long flags)
>   if (ret)
>   goto err_minors;
>  
> + dev->registered = true;
> +
>   if (dev->driver->load) {
>   ret = dev->driver->load(dev, flags);
>   if (ret)
> @@ -796,6 +798,8 @@ void drm_dev_unregister(struct drm_device *dev)
>  
>   drm_lastclose(dev);
>  
> + dev->registered = false;
> +
>   if (drm_core_check_feature(dev, DRIVER_MODESET))
>   drm_modeset_unregister_all(dev);
>  
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index c537c278a4be..ec105c339347 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -518,6 +518,7 @@ struct drm_device {
>   struct drm_minor *control;  /**< Control node */
>   struct drm_minor *primary;  /**< Primary node */
>   struct drm_minor *render;   /**< Render node */
> + bool registered;
>  
>   /* currently active master for this device. Protected by master_mutex */
>   struct drm_master *master;
> -- 
> 2.5.5
> 

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

[PATCH 0/3] Use nonblocking atomic helpers

[Fabien Dessenne]

This series replaces the driver customized atomic_commit implementation with 
the drm core helpers (patch 1).
The vblank event management is reworked (patch 2) and a side-effect is fixed 
(patch 3).
Fabien

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

[PATCH 1/3] drm/sti: use atomic_helper for commit

[Fabien Dessenne]

Since nonblocking atomic commits are now supported, the driver can
now use drm_atomic_helper_commit().

Signed-off-by: Fabien Dessenne 
---
 drivers/gpu/drm/sti/sti_drv.c | 83 +--
 drivers/gpu/drm/sti/sti_drv.h |  6 
 2 files changed, 1 insertion(+), 88 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
index ff71e25..9a9b9a2 100644
--- a/drivers/gpu/drm/sti/sti_drv.c
+++ b/drivers/gpu/drm/sti/sti_drv.c
@@ -150,52 +150,6 @@ static void sti_drm_dbg_cleanup(struct drm_minor *minor)
 1, minor);
 }
 
-static void sti_atomic_schedule(struct sti_private *private,
-   struct drm_atomic_state *state)
-{
-   private->commit.state = state;
-   schedule_work(&private->commit.work);
-}
-
-static void sti_atomic_complete(struct sti_private *private,
-   struct drm_atomic_state *state)
-{
-   struct drm_device *drm = private->drm_dev;
-
-   /*
-* Everything below can be run asynchronously without the need to grab
-* any modeset locks at all under one condition: It must be guaranteed
-* that the asynchronous work has either been cancelled (if the driver
-* supports it, which at least requires that the framebuffers get
-* cleaned up with drm_atomic_helper_cleanup_planes()) or completed
-* before the new state gets committed on the software side with
-* drm_atomic_helper_swap_state().
-*
-* This scheme allows new atomic state updates to be prepared and
-* checked in parallel to the asynchronous completion of the previous
-* update. Which is important since compositors need to figure out the
-* composition of the next frame right after having submitted the
-* current layout.
-*/
-
-   drm_atomic_helper_commit_modeset_disables(drm, state);
-   drm_atomic_helper_commit_planes(drm, state, 0);
-   drm_atomic_helper_commit_modeset_enables(drm, state);
-
-   drm_atomic_helper_wait_for_vblanks(drm, state);
-
-   drm_atomic_helper_cleanup_planes(drm, state);
-   drm_atomic_state_put(state);
-}
-
-static void sti_atomic_work(struct work_struct *work)
-{
-   struct sti_private *private = container_of(work,
-   struct sti_private, commit.work);
-
-   sti_atomic_complete(private, private->commit.state);
-}
-
 static int sti_atomic_check(struct drm_device *dev,
struct drm_atomic_state *state)
 {
@@ -216,38 +170,6 @@ static int sti_atomic_check(struct drm_device *dev,
return ret;
 }
 
-static int sti_atomic_commit(struct drm_device *drm,
-struct drm_atomic_state *state, bool nonblock)
-{
-   struct sti_private *private = drm->dev_private;
-   int err;
-
-   err = drm_atomic_helper_prepare_planes(drm, state);
-   if (err)
-   return err;
-
-   /* serialize outstanding nonblocking commits */
-   mutex_lock(&private->commit.lock);
-   flush_work(&private->commit.work);
-
-   /*
-* This is the point of no return - everything below never fails except
-* when the hw goes bonghits. Which means we can commit the new state on
-* the software side now.
-*/
-
-   drm_atomic_helper_swap_state(state, true);
-
-   drm_atomic_state_get(state);
-   if (nonblock)
-   sti_atomic_schedule(private, state);
-   else
-   sti_atomic_complete(private, state);
-
-   mutex_unlock(&private->commit.lock);
-   return 0;
-}
-
 static void sti_output_poll_changed(struct drm_device *ddev)
 {
struct sti_private *private = ddev->dev_private;
@@ -271,7 +193,7 @@ static const struct drm_mode_config_funcs 
sti_mode_config_funcs = {
.fb_create = drm_fb_cma_create,
.output_poll_changed = sti_output_poll_changed,
.atomic_check = sti_atomic_check,
-   .atomic_commit = sti_atomic_commit,
+   .atomic_commit = drm_atomic_helper_commit,
 };
 
 static void sti_mode_config_init(struct drm_device *dev)
@@ -352,9 +274,6 @@ static int sti_init(struct drm_device *ddev)
dev_set_drvdata(ddev->dev, ddev);
private->drm_dev = ddev;
 
-   mutex_init(&private->commit.lock);
-   INIT_WORK(&private->commit.work, sti_atomic_work);
-
drm_mode_config_init(ddev);
 
sti_mode_config_init(ddev);
diff --git a/drivers/gpu/drm/sti/sti_drv.h b/drivers/gpu/drm/sti/sti_drv.h
index 78ebe5e..f9276cd 100644
--- a/drivers/gpu/drm/sti/sti_drv.h
+++ b/drivers/gpu/drm/sti/sti_drv.h
@@ -25,12 +25,6 @@ struct sti_private {
struct drm_property *plane_zorder_property;
struct drm_device *drm_dev;
struct drm_fbdev_cma *fbdev;
-
-   struct {
-   struct drm_atomic_state *state;
-   struct work_struct work;
-   struct mutex lock;
-   } commit;
 };
 
 e

[PATCH 3/3] drm/sti: do not check hw scaling if mode is not set

[Fabien Dessenne]

Fix a division by 0 case : in some cases, when the HQVDP plane is being
disabled atomic_check() is called with "mode->clock = 0".
In that case, do not check for scaling capabilities.

Signed-off-by: Fabien Dessenne 
---
 drivers/gpu/drm/sti/sti_hqvdp.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_hqvdp.c b/drivers/gpu/drm/sti/sti_hqvdp.c
index f88130f..723ac30 100644
--- a/drivers/gpu/drm/sti/sti_hqvdp.c
+++ b/drivers/gpu/drm/sti/sti_hqvdp.c
@@ -1035,9 +1035,9 @@ static int sti_hqvdp_atomic_check(struct drm_plane 
*drm_plane,
src_w = state->src_w >> 16;
src_h = state->src_h >> 16;
 
-   if (!sti_hqvdp_check_hw_scaling(hqvdp, mode,
-   src_w, src_h,
-   dst_w, dst_h)) {
+   if (mode->clock && !sti_hqvdp_check_hw_scaling(hqvdp, mode,
+  src_w, src_h,
+  dst_w, dst_h)) {
DRM_ERROR("Scaling beyond HW capabilities\n");
return -EINVAL;
}
-- 
2.7.4

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

[PATCH 2/3] drm/sti: Fix up crtc_state->event handling

[Fabien Dessenne]

Use drm-core to handle event.
This is required to be able to use the nonblocking helpers.

Signed-off-by: Fabien Dessenne 
---
 drivers/gpu/drm/sti/sti_crtc.c  | 46 +
 drivers/gpu/drm/sti/sti_mixer.h |  2 --
 2 files changed, 14 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/sti/sti_crtc.c b/drivers/gpu/drm/sti/sti_crtc.c
index e992bed..d45a433 100644
--- a/drivers/gpu/drm/sti/sti_crtc.c
+++ b/drivers/gpu/drm/sti/sti_crtc.c
@@ -134,21 +134,6 @@ sti_crtc_mode_set_nofb(struct drm_crtc *crtc)
sti_crtc_mode_set(crtc, &crtc->state->adjusted_mode);
 }
 
-static void sti_crtc_atomic_begin(struct drm_crtc *crtc,
- struct drm_crtc_state *old_crtc_state)
-{
-   struct sti_mixer *mixer = to_sti_mixer(crtc);
-
-   if (crtc->state->event) {
-   crtc->state->event->pipe = drm_crtc_index(crtc);
-
-   WARN_ON(drm_crtc_vblank_get(crtc) != 0);
-
-   mixer->pending_event = crtc->state->event;
-   crtc->state->event = NULL;
-   }
-}
-
 static void sti_crtc_atomic_flush(struct drm_crtc *crtc,
  struct drm_crtc_state *old_crtc_state)
 {
@@ -156,6 +141,8 @@ static void sti_crtc_atomic_flush(struct drm_crtc *crtc,
struct sti_mixer *mixer = to_sti_mixer(crtc);
struct sti_compositor *compo = dev_get_drvdata(mixer->dev);
struct drm_plane *p;
+   struct drm_pending_vblank_event *event;
+   unsigned long flags;
 
DRM_DEBUG_DRIVER("\n");
 
@@ -220,13 +207,24 @@ static void sti_crtc_atomic_flush(struct drm_crtc *crtc,
break;
}
}
+
+   event = crtc->state->event;
+   if (event) {
+   crtc->state->event = NULL;
+
+   spin_lock_irqsave(&crtc->dev->event_lock, flags);
+   if (drm_crtc_vblank_get(crtc) == 0)
+   drm_crtc_arm_vblank_event(crtc, event);
+   else
+   drm_crtc_send_vblank_event(crtc, event);
+   spin_unlock_irqrestore(&crtc->dev->event_lock, flags);
+   }
 }
 
 static const struct drm_crtc_helper_funcs sti_crtc_helper_funcs = {
.enable = sti_crtc_enable,
.disable = sti_crtc_disabling,
.mode_set_nofb = sti_crtc_mode_set_nofb,
-   .atomic_begin = sti_crtc_atomic_begin,
.atomic_flush = sti_crtc_atomic_flush,
 };
 
@@ -250,7 +248,6 @@ int sti_crtc_vblank_cb(struct notifier_block *nb,
struct sti_compositor *compo;
struct drm_crtc *crtc = data;
struct sti_mixer *mixer;
-   unsigned long flags;
struct sti_private *priv;
unsigned int pipe;
 
@@ -267,14 +264,6 @@ int sti_crtc_vblank_cb(struct notifier_block *nb,
 
drm_crtc_handle_vblank(crtc);
 
-   spin_lock_irqsave(&crtc->dev->event_lock, flags);
-   if (mixer->pending_event) {
-   drm_crtc_send_vblank_event(crtc, mixer->pending_event);
-   drm_crtc_vblank_put(crtc);
-   mixer->pending_event = NULL;
-   }
-   spin_unlock_irqrestore(&crtc->dev->event_lock, flags);
-
if (mixer->status == STI_MIXER_DISABLING) {
struct drm_plane *p;
 
@@ -317,19 +306,12 @@ void sti_crtc_disable_vblank(struct drm_device *drm_dev, 
unsigned int pipe)
struct sti_private *priv = drm_dev->dev_private;
struct sti_compositor *compo = priv->compo;
struct notifier_block *vtg_vblank_nb = &compo->vtg_vblank_nb[pipe];
-   struct drm_crtc *crtc = &compo->mixer[pipe]->drm_crtc;
struct sti_vtg *vtg = compo->vtg[pipe];
 
DRM_DEBUG_DRIVER("\n");
 
if (sti_vtg_unregister_client(vtg, vtg_vblank_nb))
DRM_DEBUG_DRIVER("Warning: cannot unregister VTG notifier\n");
-
-   /* free the resources of the pending requests */
-   if (compo->mixer[pipe]->pending_event) {
-   drm_crtc_vblank_put(crtc);
-   compo->mixer[pipe]->pending_event = NULL;
-   }
 }
 
 static int sti_crtc_late_register(struct drm_crtc *crtc)
diff --git a/drivers/gpu/drm/sti/sti_mixer.h b/drivers/gpu/drm/sti/sti_mixer.h
index 830a3c4..e64a00e 100644
--- a/drivers/gpu/drm/sti/sti_mixer.h
+++ b/drivers/gpu/drm/sti/sti_mixer.h
@@ -28,7 +28,6 @@ enum sti_mixer_status {
  * @regs: mixer registers
  * @id: id of the mixer
  * @drm_crtc: crtc object link to the mixer
- * @pending_event: set if a flip event is pending on crtc
  * @status: to know the status of the mixer
  */
 struct sti_mixer {
@@ -36,7 +35,6 @@ struct sti_mixer {
void __iomem *regs;
int id;
struct drm_crtc drm_crtc;
-   struct drm_pending_vblank_event *pending_event;
enum sti_mixer_status status;
 };
 
-- 
2.7.4

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

Re: [PATCH] drm: Don't race connector registration

[Chris Wilson]

On Thu, Jan 12, 2017 at 05:15:56PM +0100, Daniel Vetter wrote:
> I was under the misconception that the sysfs dev stuff can be fully
> set up, and then registered all in one step with device_add. That's
> true for properties and property groups, but not for parents and child
> devices. Those must be fully registered before you can register a
> child.
> 
> Add a bit of tracking to make sure that asynchronous mst connector
> hotplugging gets this right. For consistency we rely upon the implicit
> barriers of the connector->mutex, which is taken anyway, to ensure
> that at least either the connector or device registration call will
> work out.
> 
> Mildly tested since I can't reliably reproduce this on my mst box
> here.

Hmm, right it should prevent the oops on load. I think we need to
control the async dp-mst better and stop it running until we have the
device registered, and so if we use in the interim, plonk a WARN_ON on
top for -next and try and fix it for realz. (Probably a
drm_dp_mst_mgr_register() hook?)

Acked-by: Chris Wilson 
-Chris

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

[Bug 99236] System (seems to) completely freeze when interacting with java swing applications.

[bugzilla-daemon]

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

--- Comment #16 from Vitaly Ostrosablin  ---
Have successfully updated to latest mesa. Seems like issue was fixed recently.

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

Re: [Intel-gfx] [PATCH 1/3] drm: Add new DRM_IOCTL_MODE_GETPLANE2

[Daniel Stone]

Hi,

On 12 January 2017 at 14:56, Rob Clark  wrote:
> On Thu, Jan 12, 2017 at 4:38 AM, Ville Syrjälä
>  wrote:
>> Isn't an implicit offset enough? As in first mask for a specific
>> modifier is for format indexes 0-63, second mask for the same modifier
>> is for 64-127, and so on.
>
> hmm, hadn't thought of that approach.  Definitely if we go w/ implicit
> then we want to have userspace support from the get-go.  For explicit,
> I guess userspace could complain and ignore if it saw a non-zero
> offset similar to what we do w/ pad and unknown flags in the other
> direction?

Implicit is clever but horrible. AFAICT, the only way to do it
properly would be to have a nested forwards loop walk when you first
hit a modifier, searching for further occurrences of that modifier to
collect the complete set of formats that modifier applies to.
Depending on what you did with the structures, you'd either have to
destroy the drm_format_modifiers in the GetPlane return so further
instances of your outer loop didn't hit them, or have a _second_
nested loop walk into wherever you copied the formats/modifiers,
searching for anything with that.

Too clever by half, and everyone will get it wrong. Just add an explicit offset.

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

Re: [Intel-gfx] [PATCH 1/3] drm: Add new DRM_IOCTL_MODE_GETPLANE2

[Ville Syrjälä]

On Thu, Jan 12, 2017 at 05:04:46PM +, Daniel Stone wrote:
> Hi,
> 
> On 12 January 2017 at 14:56, Rob Clark  wrote:
> > On Thu, Jan 12, 2017 at 4:38 AM, Ville Syrjälä
> >  wrote:
> >> Isn't an implicit offset enough? As in first mask for a specific
> >> modifier is for format indexes 0-63, second mask for the same modifier
> >> is for 64-127, and so on.
> >
> > hmm, hadn't thought of that approach.  Definitely if we go w/ implicit
> > then we want to have userspace support from the get-go.  For explicit,
> > I guess userspace could complain and ignore if it saw a non-zero
> > offset similar to what we do w/ pad and unknown flags in the other
> > direction?
> 
> Implicit is clever but horrible. AFAICT, the only way to do it
> properly would be to have a nested forwards loop walk when you first
> hit a modifier, searching for further occurrences of that modifier to
> collect the complete set of formats that modifier applies to.

Not sure for what that is the "only way". In fact I can't right now
think of any operation that would require an extra loop necessarily.
For some things you might just want to look for a specific
format+modifier combo, for that it doesn't matter how many blocks there
are. And if you want to transform the reply into some less convoluted
form, well then you'd just need some modifier+dynamic format list thing,
or if you want to keep to bitmasks you'd either need a bitmask that can
grow when running out of bits or just make it big enough to handle a
sufficiently large worst case number of bits.

Dunno, maybe I just lack imagination. Then again, I'm not even sure if
we're talking about userspace of kernel code here, which might explain
my general confusion :)

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

Re: [Intel-gfx] [PATCH 1/3] drm: Add new DRM_IOCTL_MODE_GETPLANE2

[Daniel Stone]

Hi,

On 12 January 2017 at 17:45, Ville Syrjälä
 wrote:
> On Thu, Jan 12, 2017 at 05:04:46PM +, Daniel Stone wrote:
>> Implicit is clever but horrible. AFAICT, the only way to do it
>> properly would be to have a nested forwards loop walk when you first
>> hit a modifier, searching for further occurrences of that modifier to
>> collect the complete set of formats that modifier applies to.
>
> Not sure for what that is the "only way". In fact I can't right now
> think of any operation that would require an extra loop necessarily.
> For some things you might just want to look for a specific
> format+modifier combo, for that it doesn't matter how many blocks there
> are.

Right, that just needs a local variable to act as a counter.

> And if you want to transform the reply into some less convoluted
> form, well then you'd just need some modifier+dynamic format list thing,
> or if you want to keep to bitmasks you'd either need a bitmask that can
> grow when running out of bits or just make it big enough to handle a
> sufficiently large worst case number of bits.
>
> Dunno, maybe I just lack imagination. Then again, I'm not even sure if
> we're talking about userspace of kernel code here, which might explain
> my general confusion :)

I'm talking about userspace, where I want to have:
struct drm_plane {
struct {
uint32_t format;
uint64_t modifiers[];
} formats[];
}

Rather than keeping the original format around and doing the lookup every time.

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

Re: [PATCH 2/3] drm/i915: Add format modifiers for Intel

[Ben Widawsky]

On 17-01-12 12:51:20, Ville Syrjälä wrote:

On Wed, Jan 11, 2017 at 04:51:17PM -0800, Ben Widawsky wrote:

This was based on a patch originally by Kristian. It has been modified
pretty heavily to use the new callbacks from the previous patch.

Cc: Kristian H. Kristensen 
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/i915/intel_display.c | 109 ++-
 drivers/gpu/drm/i915/intel_sprite.c  |  33 ++-
 2 files changed, 137 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 8715b1083d1d..26f3a911b999 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -61,6 +61,11 @@ static const uint32_t i8xx_primary_formats[] = {
DRM_FORMAT_XRGB,
 };

+static const uint64_t i8xx_format_modifiers[] = {
+   I915_FORMAT_MOD_X_TILED,


Did we want to list the linear modifier in these as well?



Yeah. My initial response was no, but yes. We should. I was using
DRM_FORMAT_MOD_NONE in its place, it should be linear, and it should be defined
in the array.


+   DRM_FORMAT_MOD_INVALID
+};
+
 /* Primary plane formats for gen >= 4 */
 static const uint32_t i965_primary_formats[] = {
DRM_FORMAT_C8,
@@ -71,6 +76,11 @@ static const uint32_t i965_primary_formats[] = {
DRM_FORMAT_XBGR2101010,
 };

+static const uint64_t i965_format_modifiers[] = {
+   I915_FORMAT_MOD_X_TILED,
+   DRM_FORMAT_MOD_INVALID
+};


We could just share the i8xx array. The name of the array should perhaps
be i9xx_format_modifiers[] in that case. That's sort of the naming
convention we've been left with for things that apply to more or less
all the platforms.



Got it thanks. This is a relic from Kristian's original patch which tied the
modifiers to the formats in place. It made more sense there to have a separate
i8xx


+
 static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_C8,
DRM_FORMAT_RGB565,
@@ -86,6 +96,12 @@ static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_VYUY,
 };

+static const uint64_t skl_format_modifiers[] = {
+   I915_FORMAT_MOD_Y_TILED,


Yf missing? and linear



Yes, thanks. I'm kind of scared to add Yf to be honest :P


+   I915_FORMAT_MOD_X_TILED,
+   DRM_FORMAT_MOD_INVALID
+};
+
 /* Cursor formats */
 static const uint32_t intel_cursor_formats[] = {
DRM_FORMAT_ARGB,
@@ -15173,6 +15189,87 @@ void intel_plane_destroy(struct drm_plane *plane)
kfree(to_intel_plane(plane));
 }

+static bool i8xx_mod_supported(uint32_t format, uint64_t modifier)
+{
+   if (modifier == DRM_FORMAT_MOD_NONE)
+   return true;
+
+   switch (format) {
+   case DRM_FORMAT_C8:
+   case DRM_FORMAT_RGB565:
+   case DRM_FORMAT_XRGB1555:
+   case DRM_FORMAT_XRGB:
+   return modifier == I915_FORMAT_MOD_X_TILED;
+   default:
+   return false;
+   }
+}
+
+static bool i965_mod_supported(uint32_t format, uint64_t modifier)
+{
+   switch (format) {
+   case DRM_FORMAT_C8:
+   case DRM_FORMAT_RGB565:
+   case DRM_FORMAT_XRGB:
+   case DRM_FORMAT_XBGR:
+   case DRM_FORMAT_XRGB2101010:
+   case DRM_FORMAT_XBGR2101010:
+   return modifier == I915_FORMAT_MOD_X_TILED;
+   default:
+   return false;
+   }
+}


Hmm. There should be no format vs. tiling restrictions on these
platforms, so presumably a simple "return true" should cover it all.
That does perhaps remove the usefulness of these functions for
verifying that the format or modifier is supported at all


One of the reasons for changing to this current format-modifier lookup at all
was Kristian's approach was considered fragile. If for whatever reason formats
are added, or removed, we'll catch it here. Also, it maybe let's us do something
on cursor plane at some point (I don't actually know). So yeah, we can return
true, but I like that it's spelled out explicitly. Makes it easy to compare it
to the docs as well to make sure our code is correct.

The benefit is of course I can combine i965_mod_supported() with
i8xx_mod_supported()

I'm honestly fine with changing it as well, I just don't see a huge reason to
change it since I've already typed it up. I'll leave it to you.

[ ] Yes, change it.
[ ] No, leave it.


but I've been thinking that addfb should perhaps just iterate through the
format and modifier lists for every plane. Would avoid having to effectively
maintain the same lists in multiple places.



I don't quite follow this. Can you elaborate?


+
+static bool skl_mod_supported(uint32_t format, uint64_t modifier)
+{
+   switch (format) {
+   case DRM_FORMAT_C8:
+   case DRM_FORMAT_RGB565:
+   case DRM_FORMAT_XRGB:
+   case DRM_FORMAT_XBGR:
+   case DRM_FORMAT_ARGB:
+   case DRM_FORMAT_ABGR:
+   return modifier == I915_FORMAT_MOD_Y_TILED ||
+   m

Re: [Intel-gfx] [PATCH 1/3] drm: Add new DRM_IOCTL_MODE_GETPLANE2

[Ville Syrjälä]

On Thu, Jan 12, 2017 at 05:50:15PM +, Daniel Stone wrote:
> Hi,
> 
> On 12 January 2017 at 17:45, Ville Syrjälä
>  wrote:
> > On Thu, Jan 12, 2017 at 05:04:46PM +, Daniel Stone wrote:
> >> Implicit is clever but horrible. AFAICT, the only way to do it
> >> properly would be to have a nested forwards loop walk when you first
> >> hit a modifier, searching for further occurrences of that modifier to
> >> collect the complete set of formats that modifier applies to.
> >
> > Not sure for what that is the "only way". In fact I can't right now
> > think of any operation that would require an extra loop necessarily.
> > For some things you might just want to look for a specific
> > format+modifier combo, for that it doesn't matter how many blocks there
> > are.
> 
> Right, that just needs a local variable to act as a counter.
> 
> > And if you want to transform the reply into some less convoluted
> > form, well then you'd just need some modifier+dynamic format list thing,
> > or if you want to keep to bitmasks you'd either need a bitmask that can
> > grow when running out of bits or just make it big enough to handle a
> > sufficiently large worst case number of bits.
> >
> > Dunno, maybe I just lack imagination. Then again, I'm not even sure if
> > we're talking about userspace of kernel code here, which might explain
> > my general confusion :)
> 
> I'm talking about userspace, where I want to have:
> struct drm_plane {
> struct {
> uint32_t format;
> uint64_t modifiers[];
> } formats[];
> }

Flipping formats[] vs. modifiers[] here would seem like it should make
this easier with the proposed kernel API. And if the kernel will also
uarantee that multiple instances of the same modifier must be returned
contiguously, then it should be even easier.

Oh and flipping formats[] and modifiers[] should also save a quite a
bit of space since each format takes twice as much space as each
modifier. But I suppose that might come at a runtime cost if you have
to look for a specific format in each modifier's format list instead
of having to look at just the modifier list of a specific format. So
I suppose not flipping might be better after all, which I guess would
complicate populating the infromation somewhat.

Anyways, that's all a bit unrelated to the matter at hand, so I'll stop
now and just state that I don't mind having an explicit offset if
people really want it.

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

RE: [PATCH] drm/atomic: Add target_vblank support in atomic helpers (v2)

[Grodzovsky, Andrey]

> -Original Message-
> From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> Daniel Vetter
> Sent: Thursday, January 12, 2017 3:51 AM
> To: Michel Dänzer
> Cc: Grodzovsky, Andrey; Deucher, Alexander; dri-
> de...@lists.freedesktop.org
> Subject: Re: [PATCH] drm/atomic: Add target_vblank support in atomic
> helpers (v2)
> 
> On Thu, Jan 12, 2017 at 9:28 AM, Michel Dänzer 
> wrote:
> > On 12/01/17 12:48 AM, Grodzovsky, Andrey wrote:
> >>> From: Michel Dänzer [mailto:mic...@daenzer.net] On 09/01/17 06:59
> >>> PM, Daniel Vetter wrote:
>  On Fri, Jan 06, 2017 at 03:39:40PM -0500, Andrey Grodzovsky wrote:
> > Allows usage of the new page_flip_target hook for drivers
> > implementing the atomic path.
> > Provides default atomic helper for the new hook.
> >
> > v2:
> > Update code sharing logic between exsiting and the new flip hooks.
> > Improve kerneldoc.
> >
> > Signed-off-by: Andrey Grodzovsky 
> 
>  Looks all reasonable, I think an ack from Alex that the amd side is
>  in shape too, and I'll pull this into drm-misc.
> >>>
> >>> Andrey, is there an updated patch 2 adapted to current patch 1?
> >>> Other than that and some questionable indentation of parameters in
> >>> function signatures, looks good to me FWIW.
> >>
> >> We are unable to use the atomic helpers both for page_flip and
> >> page_flip_target At their current form mostly due to
> DRM_MODE_PAGE_FLIP_ASYNC flag rejection they do.
> >> I discussed this with Daniel Vetter on IRC and suggested to remove
> >> the rejection but he said the precise semantics of atomic async flip
> >> is not clear yet and it's better to leave that out for now until
> >> there is a  userspace asking for it.
> >> So I tested it by just hacking  the helper to remove the rejection.
> >> Until that settled the original change [PATCH 2/2] drm/amd/dal:
> >> Switch to page_flip_target hook in DAL Is what we plan to use in DAL
> >
> > IIRC Daniel suggested (on IRC?) to use the helper for non-async flips
> > and the current DC code for async flips. Is that feasible?
> 
> We do have some async flip flag reserved for atomic, so we could route it
> through. But since atm there's no one asking for async flips on the atomic
> ioctl I'm a bit wary for fear of ending up with ill-defined semantics. But I 
> guess
> if we do this for legacy pageflips only, and make sure we do still reject 
> async
> flips submitted through the atomic ioctl that should be all fine. And it 
> should
> allow amdgpu to entirely get rid of the legacy flip path, which would be nice.
> 
> Once we have that we could even use it for cursor plane updates (through
> the legacy ioctl, for drivers with universal planes), for those drivers that
> support it.
> -Daniel

So are we ok with a follow-up patch removing the ASYNC_FLIP restriction in the 
legacy IOCTL
+ adding the drm_mode_crtc_page_flip_target.flags to drm_crtc_state ? In that 
case as I said before,
at least for DAL we could drop our own page_flip hook and use the avaialbe 
helpers.

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

Re: [PATCH 2/3] drm/i915: Add format modifiers for Intel

[Ville Syrjälä]

On Thu, Jan 12, 2017 at 10:00:55AM -0800, Ben Widawsky wrote:
> On 17-01-12 12:51:20, Ville Syrjälä wrote:
> >On Wed, Jan 11, 2017 at 04:51:17PM -0800, Ben Widawsky wrote:
> >> This was based on a patch originally by Kristian. It has been modified
> >> pretty heavily to use the new callbacks from the previous patch.
> >>
> >> Cc: Kristian H. Kristensen 
> >> Signed-off-by: Ben Widawsky 
> >> ---
> >>  drivers/gpu/drm/i915/intel_display.c | 109 
> >> ++-
> >>  drivers/gpu/drm/i915/intel_sprite.c  |  33 ++-
> >>  2 files changed, 137 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> >> b/drivers/gpu/drm/i915/intel_display.c
> >> index 8715b1083d1d..26f3a911b999 100644
> >> --- a/drivers/gpu/drm/i915/intel_display.c
> >> +++ b/drivers/gpu/drm/i915/intel_display.c
> >> @@ -61,6 +61,11 @@ static const uint32_t i8xx_primary_formats[] = {
> >>DRM_FORMAT_XRGB,
> >>  };
> >>
> >> +static const uint64_t i8xx_format_modifiers[] = {
> >> +  I915_FORMAT_MOD_X_TILED,
> >
> >Did we want to list the linear modifier in these as well?
> >
> 
> Yeah. My initial response was no, but yes. We should. I was using
> DRM_FORMAT_MOD_NONE in its place, it should be linear, and it should be 
> defined
> in the array.
> 
> >> +  DRM_FORMAT_MOD_INVALID
> >> +};
> >> +
> >>  /* Primary plane formats for gen >= 4 */
> >>  static const uint32_t i965_primary_formats[] = {
> >>DRM_FORMAT_C8,
> >> @@ -71,6 +76,11 @@ static const uint32_t i965_primary_formats[] = {
> >>DRM_FORMAT_XBGR2101010,
> >>  };
> >>
> >> +static const uint64_t i965_format_modifiers[] = {
> >> +  I915_FORMAT_MOD_X_TILED,
> >> +  DRM_FORMAT_MOD_INVALID
> >> +};
> >
> >We could just share the i8xx array. The name of the array should perhaps
> >be i9xx_format_modifiers[] in that case. That's sort of the naming
> >convention we've been left with for things that apply to more or less
> >all the platforms.
> >
> 
> Got it thanks. This is a relic from Kristian's original patch which tied the
> modifiers to the formats in place. It made more sense there to have a separate
> i8xx
> 
> >> +
> >>  static const uint32_t skl_primary_formats[] = {
> >>DRM_FORMAT_C8,
> >>DRM_FORMAT_RGB565,
> >> @@ -86,6 +96,12 @@ static const uint32_t skl_primary_formats[] = {
> >>DRM_FORMAT_VYUY,
> >>  };
> >>
> >> +static const uint64_t skl_format_modifiers[] = {
> >> +  I915_FORMAT_MOD_Y_TILED,
> >
> >Yf missing? and linear
> >
> 
> Yes, thanks. I'm kind of scared to add Yf to be honest :P
> 
> >> +  I915_FORMAT_MOD_X_TILED,
> >> +  DRM_FORMAT_MOD_INVALID
> >> +};
> >> +
> >>  /* Cursor formats */
> >>  static const uint32_t intel_cursor_formats[] = {
> >>DRM_FORMAT_ARGB,
> >> @@ -15173,6 +15189,87 @@ void intel_plane_destroy(struct drm_plane *plane)
> >>kfree(to_intel_plane(plane));
> >>  }
> >>
> >> +static bool i8xx_mod_supported(uint32_t format, uint64_t modifier)
> >> +{
> >> +  if (modifier == DRM_FORMAT_MOD_NONE)
> >> +  return true;
> >> +
> >> +  switch (format) {
> >> +  case DRM_FORMAT_C8:
> >> +  case DRM_FORMAT_RGB565:
> >> +  case DRM_FORMAT_XRGB1555:
> >> +  case DRM_FORMAT_XRGB:
> >> +  return modifier == I915_FORMAT_MOD_X_TILED;
> >> +  default:
> >> +  return false;
> >> +  }
> >> +}
> >> +
> >> +static bool i965_mod_supported(uint32_t format, uint64_t modifier)
> >> +{
> >> +  switch (format) {
> >> +  case DRM_FORMAT_C8:
> >> +  case DRM_FORMAT_RGB565:
> >> +  case DRM_FORMAT_XRGB:
> >> +  case DRM_FORMAT_XBGR:
> >> +  case DRM_FORMAT_XRGB2101010:
> >> +  case DRM_FORMAT_XBGR2101010:
> >> +  return modifier == I915_FORMAT_MOD_X_TILED;
> >> +  default:
> >> +  return false;
> >> +  }
> >> +}
> >
> >Hmm. There should be no format vs. tiling restrictions on these
> >platforms, so presumably a simple "return true" should cover it all.
> >That does perhaps remove the usefulness of these functions for
> >verifying that the format or modifier is supported at all
> 
> One of the reasons for changing to this current format-modifier lookup at all
> was Kristian's approach was considered fragile. If for whatever reason formats
> are added, or removed, we'll catch it here. Also, it maybe let's us do 
> something
> on cursor plane at some point (I don't actually know). So yeah, we can return
> true, but I like that it's spelled out explicitly. Makes it easy to compare it
> to the docs as well to make sure our code is correct.
> 
> The benefit is of course I can combine i965_mod_supported() with
> i8xx_mod_supported()
> 
> I'm honestly fine with changing it as well, I just don't see a huge reason to
> change it since I've already typed it up. I'll leave it to you.

Feel free to keep it. We can always change it later if it becomes too much
work to maintain the duplicated format lists (the function and the array).
Not that I really expect these lists to be all that volatile.

> 
> [ ] Yes, change it.
> [ ] No, leave it.
> 

Re: [PATCH 03/10] drm/i915/psr: fix blank screen issue for psr2

[Vivi, Rodrigo]

Reviewed-by: Rodrigo Vivi 

On Thu, 2017-01-12 at 23:30 +0530, vathsala nagaraju wrote:
> Psr1 and psr2 are mutually exclusive,ie when psr2 is enabled,
> psr1 should be disabled.When psr2 is exited , bit 31 of reg
> PSR2_CTL must be set to 0 but currently bit 31 of SRD_CTL
> (psr1 control register)is set to 0.
> Also ,PSR2_IDLE state is looked up from SRD_STATUS(psr1 register)
> instead of PSR2_STATUS register, which has wrong data, resulting
> in blankscreen.
> hsw_enable_source is split into hsw_enable_source_psr1 and
> hsw_enable_source_psr2 for easier code review and maintenance,
> as suggested by rodrigo and jim.
> 
> v2: (Rodrigo)
> - Rename hsw_enable_source_psr* to intel_enable_source_psr*
> 
> v3: (Rodrigo)
> - In hsw_psr_disable ,
>   1) for psr active case, handle psr2 followed by psr1.
>   2) psr inactive case, handle psr2 followed by psr1
> 
> v4:(Rodrigo)
> - move psr2 restriction(32X20) to match_conditions function
>   returning false and fully blocking PSR to a new patch before
>   this one.
> 
> v5: in source_psr2, removed val = EDP_PSR_ENABLE
> 
> Cc: Rodrigo Vivi 
> Cc: Jim Bride 
> Signed-off-by: Vathsala Nagaraju 
> Signed-off-by: Patil Deepti 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  |   3 +
>  drivers/gpu/drm/i915/intel_psr.c | 122 
> +--
>  2 files changed, 95 insertions(+), 30 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 00970aa..7830e6e 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3615,6 +3615,9 @@ enum {
>  #define   EDP_PSR2_FRAME_BEFORE_SU_MASK  (0xf<<4)
>  #define   EDP_PSR2_IDLE_MASK 0xf
>  
> +#define EDP_PSR2_STATUS_CTL_MMIO(0x6f940)
> +#define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
> +
>  /* VGA port control */
>  #define ADPA _MMIO(0x61100)
>  #define PCH_ADPA_MMIO(0xe1100)
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 707cae8..8827647 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -261,7 +261,7 @@ static void vlv_psr_activate(struct intel_dp *intel_dp)
>  VLV_EDP_PSR_ACTIVE_ENTRY);
>  }
>  
> -static void hsw_psr_enable_source(struct intel_dp *intel_dp)
> +static void intel_enable_source_psr1(struct intel_dp *intel_dp)
>  {
>   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>   struct drm_device *dev = dig_port->base.base.dev;
> @@ -312,14 +312,29 @@ static void hsw_psr_enable_source(struct intel_dp 
> *intel_dp)
>   val |= EDP_PSR_TP1_TP2_SEL;
>  
>   I915_WRITE(EDP_PSR_CTL, val);
> +}
>  
> - if (!dev_priv->psr.psr2_support)
> - return;
> +static void intel_enable_source_psr2(struct intel_dp *intel_dp)
> +{
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> + struct drm_device *dev = dig_port->base.base.dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
> + /*
> +  * Let's respect VBT in case VBT asks a higher idle_frame value.
> +  * Let's use 6 as the minimum to cover all known cases including
> +  * the off-by-one issue that HW has in some cases. Also there are
> +  * cases where sink should be able to train
> +  * with the 5 or 6 idle patterns.
> +  */
> + uint32_t idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
> + uint32_t val;
> +
> + val = idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
>  
>   /* FIXME: selective update is probably totally broken because it doesn't
>* mesh at all with our frontbuffer tracking. And the hw alone isn't
>* good enough. */
> - val = EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
> + val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
>  
>   if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
>   val |= EDP_PSR2_TP2_TIME_2500;
> @@ -333,6 +348,19 @@ static void hsw_psr_enable_source(struct intel_dp 
> *intel_dp)
>   I915_WRITE(EDP_PSR2_CTL, val);
>  }
>  
> +static void hsw_psr_enable_source(struct intel_dp *intel_dp)
> +{
> + struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> + struct drm_device *dev = dig_port->base.base.dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
> +
> + /* psr1 and psr2 are mutually exclusive.*/
> + if (dev_priv->psr.psr2_support)
> + intel_enable_source_psr2(intel_dp);
> + else
> + intel_enable_source_psr1(intel_dp);
> +}
> +
>  static bool intel_psr_match_conditions(struct intel_dp *intel_dp)
>  {
>   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> @@ -417,7 +445,10 @@ static void intel_psr_activate(struct intel_dp *intel_dp)
>   struct drm_device *dev = intel_dig_port->base.base.dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
>  
> - WARN_ON(I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE);
> + if (dev_priv->psr.psr2_suppor

[Bug 97025] flip queue failed: Device or resource busy

[bugzilla-daemon]

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

--- Comment #24 from Kevin McCormack  ---
I am experiencing what I think may be a similar issue. When my display sleeps,
it often does not wake up on keypress. I have to wait anywhere from a few
seconds to a few minutes and then have errors in my log like the following

[drm:amdgpu_atombios_dp_link_train [amdgpu]] *ERROR* clock recovery failed
[drm:amdgpu_atombios_dp_link_train [amdgpu]] *ERROR* clock recovery failed

I am running Antergos 64-bit with GNOME 3.22.2 on Wayland
Kernels 4.8.13 and 4.10.0-rc3-ga121103c9228
AMD FX-8370 
Sapphire Fury X

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

[Bug 97025] flip queue failed: Device or resource busy

[bugzilla-daemon]

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

--- Comment #25 from Kevin McCormack  ---
Created attachment 128916
  --> https://bugs.freedesktop.org/attachment.cgi?id=128916&action=edit
Delayed recovery from display sleep logs

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

Re: [PATCH 3/7] i2c: designware-baytrail: Take punit lock on bus acquire

[Wolfram Sang]

On Sun, Jan 08, 2017 at 02:44:23PM +0100, Hans de Goede wrote:
> Take the punit lock to stop others from accessing the punit while the
> pmic i2c bus is in use. This is necessary because accessing the punit
> from the kernel may result in the punit trying to access the pmic i2c
> bus, which results in a hang when it happens while we own the pmic i2c
> bus semaphore.
> 
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241
> Signed-off-by: Hans de Goede 
> Tested-by: tagorereddy 

I don't think the I2C patches need to go via I2C tree, so:

Acked-by: Wolfram Sang 

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

Re: [PATCH 4/7] i2c: designware-baytrail: Call pmic_bus_access_notifier_chain

[Wolfram Sang]

On Sun, Jan 08, 2017 at 02:44:24PM +0100, Hans de Goede wrote:
> Call the iosf_mbi pmic_bus_access_notifier_chain on bus acquire / release.
> 
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241
> Signed-off-by: Hans de Goede 
> Tested-by: tagorereddy 

Acked-by: Wolfram Sang 

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

Re: [PATCH 2/3] drm/i915: Add format modifiers for Intel

[Ben Widawsky]

On 17-01-12 20:32:07, Ville Syrjälä wrote:

On Thu, Jan 12, 2017 at 10:00:55AM -0800, Ben Widawsky wrote:

On 17-01-12 12:51:20, Ville Syrjälä wrote:
>On Wed, Jan 11, 2017 at 04:51:17PM -0800, Ben Widawsky wrote:
>> This was based on a patch originally by Kristian. It has been modified
>> pretty heavily to use the new callbacks from the previous patch.
>>
>> Cc: Kristian H. Kristensen 
>> Signed-off-by: Ben Widawsky 
>> ---
>>  drivers/gpu/drm/i915/intel_display.c | 109 
++-
>>  drivers/gpu/drm/i915/intel_sprite.c  |  33 ++-
>>  2 files changed, 137 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
>> index 8715b1083d1d..26f3a911b999 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -61,6 +61,11 @@ static const uint32_t i8xx_primary_formats[] = {
>>DRM_FORMAT_XRGB,
>>  };
>>
>> +static const uint64_t i8xx_format_modifiers[] = {
>> +  I915_FORMAT_MOD_X_TILED,
>
>Did we want to list the linear modifier in these as well?
>

Yeah. My initial response was no, but yes. We should. I was using
DRM_FORMAT_MOD_NONE in its place, it should be linear, and it should be defined
in the array.

>> +  DRM_FORMAT_MOD_INVALID
>> +};
>> +
>>  /* Primary plane formats for gen >= 4 */
>>  static const uint32_t i965_primary_formats[] = {
>>DRM_FORMAT_C8,
>> @@ -71,6 +76,11 @@ static const uint32_t i965_primary_formats[] = {
>>DRM_FORMAT_XBGR2101010,
>>  };
>>
>> +static const uint64_t i965_format_modifiers[] = {
>> +  I915_FORMAT_MOD_X_TILED,
>> +  DRM_FORMAT_MOD_INVALID
>> +};
>
>We could just share the i8xx array. The name of the array should perhaps
>be i9xx_format_modifiers[] in that case. That's sort of the naming
>convention we've been left with for things that apply to more or less
>all the platforms.
>

Got it thanks. This is a relic from Kristian's original patch which tied the
modifiers to the formats in place. It made more sense there to have a separate
i8xx

>> +
>>  static const uint32_t skl_primary_formats[] = {
>>DRM_FORMAT_C8,
>>DRM_FORMAT_RGB565,
>> @@ -86,6 +96,12 @@ static const uint32_t skl_primary_formats[] = {
>>DRM_FORMAT_VYUY,
>>  };
>>
>> +static const uint64_t skl_format_modifiers[] = {
>> +  I915_FORMAT_MOD_Y_TILED,
>
>Yf missing? and linear
>

Yes, thanks. I'm kind of scared to add Yf to be honest :P

>> +  I915_FORMAT_MOD_X_TILED,
>> +  DRM_FORMAT_MOD_INVALID
>> +};
>> +
>>  /* Cursor formats */
>>  static const uint32_t intel_cursor_formats[] = {
>>DRM_FORMAT_ARGB,
>> @@ -15173,6 +15189,87 @@ void intel_plane_destroy(struct drm_plane *plane)
>>kfree(to_intel_plane(plane));
>>  }
>>
>> +static bool i8xx_mod_supported(uint32_t format, uint64_t modifier)
>> +{
>> +  if (modifier == DRM_FORMAT_MOD_NONE)
>> +  return true;
>> +
>> +  switch (format) {
>> +  case DRM_FORMAT_C8:
>> +  case DRM_FORMAT_RGB565:
>> +  case DRM_FORMAT_XRGB1555:
>> +  case DRM_FORMAT_XRGB:
>> +  return modifier == I915_FORMAT_MOD_X_TILED;
>> +  default:
>> +  return false;
>> +  }
>> +}
>> +
>> +static bool i965_mod_supported(uint32_t format, uint64_t modifier)
>> +{
>> +  switch (format) {
>> +  case DRM_FORMAT_C8:
>> +  case DRM_FORMAT_RGB565:
>> +  case DRM_FORMAT_XRGB:
>> +  case DRM_FORMAT_XBGR:
>> +  case DRM_FORMAT_XRGB2101010:
>> +  case DRM_FORMAT_XBGR2101010:
>> +  return modifier == I915_FORMAT_MOD_X_TILED;
>> +  default:
>> +  return false;
>> +  }
>> +}
>
>Hmm. There should be no format vs. tiling restrictions on these
>platforms, so presumably a simple "return true" should cover it all.
>That does perhaps remove the usefulness of these functions for
>verifying that the format or modifier is supported at all

One of the reasons for changing to this current format-modifier lookup at all
was Kristian's approach was considered fragile. If for whatever reason formats
are added, or removed, we'll catch it here. Also, it maybe let's us do something
on cursor plane at some point (I don't actually know). So yeah, we can return
true, but I like that it's spelled out explicitly. Makes it easy to compare it
to the docs as well to make sure our code is correct.

The benefit is of course I can combine i965_mod_supported() with
i8xx_mod_supported()

I'm honestly fine with changing it as well, I just don't see a huge reason to
change it since I've already typed it up. I'll leave it to you.


Feel free to keep it. We can always change it later if it becomes too much
work to maintain the duplicated format lists (the function and the array).
Not that I really expect these lists to be all that volatile.



[ ] Yes, change it.
[ ] No, leave it.

>but I've been thinking that addfb should perhaps just iterate through the
>format and 

[Bug 99387] Kernel 4.9: Kaveri + Hainan choked on boot using amdgpu

[bugzilla-daemon]

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

Bug ID: 99387
   Summary: Kernel 4.9: Kaveri + Hainan choked on boot using
amdgpu
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: blocker
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: l...@fedoraproject.org

Created attachment 128917
  --> https://bugs.freedesktop.org/attachment.cgi?id=128917&action=edit
Journal report

Hardware used in test:
ASUS X550ZE powered with R7 M265DX 
Kaveri (R7 M265DX) + Hainan (R5 M230)
running on Fedora 25

Kernel provided from this repository
https://copr.fedorainfracloud.org/coprs/mystro256/amd-staging-kernel/build/498630/

Enabling "amdgpu.exp_hw_support=1 modprobe.blacklist=radeon" parameter

Result: kernel crashed with signal "BUG: unable to handle kernel NULL pointer
dereference at   (null)"

See details attached on the journal log

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

Re: Why does OUT_FENCE_PTR point not to an fd (s32) but to an s64?

[Gustavo Padovan]

2017-01-10 Laurent Pinchart :

> Hi Daniel,
> 
> On Monday 09 Jan 2017 11:23:23 Daniel Vetter wrote:
> > On Fri, Jan 06, 2017 at 01:04:55PM -0800, Chad Versace wrote:
> > > Was this a mistake in the API? If so, can we fix this ABI mistake before
> > > kernel consumers rely on this?
> > > 
> > > I naïvely expected that OUT_FENCE_PTR would be a pointer to, obviously, a
> > > fence fd (s32 __user *). But it's not. It's s64 __user *. Due to that
> > > surprise, I spent several hours chasing down weird corruption in Rob
> > > Clark's kmscube. The kernel unexpectedly cleared the 32 bits *above* an
> > > `int kms_fence_fd` in userspace.
> > 
> > Never use unsized types for uabi. I guess we could have used s32, but then
> > someone is going to store this in a long and it goes boom on 64 bit,
> 
> Why so ? And why do we care ? The commonly accepted practice is to store file 
> descriptors in int variables. s32 is an int on all platforms, so that's fine 
> too. If we use a s32 pointer here, and someone decides to store it in a long, 
> bool or cast it to a complex, that's their problem :-)

The only thing that really needs to be s64 here is the OUT_FENCE_PTR
property in the Atomic interface because we carry a pointer there, but
all the manipulation after that is actually done after can easily be
done on s32 or int.

We can't expect that userspace will know that we store as s64 and clear
the bits above if a int was passed down. if we use s32 we will be in
complaince with other linux apis that deals with fds. I'd say we fix
this before it can cause more damage out there.

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

Re: Why does OUT_FENCE_PTR point not to an fd (s32) but to an s64?

[Daniel Vetter]

On Thu, Jan 12, 2017 at 05:17:26PM -0200, Gustavo Padovan wrote:
> 2017-01-10 Laurent Pinchart :
> 
> > Hi Daniel,
> > 
> > On Monday 09 Jan 2017 11:23:23 Daniel Vetter wrote:
> > > On Fri, Jan 06, 2017 at 01:04:55PM -0800, Chad Versace wrote:
> > > > Was this a mistake in the API? If so, can we fix this ABI mistake before
> > > > kernel consumers rely on this?
> > > > 
> > > > I naïvely expected that OUT_FENCE_PTR would be a pointer to, obviously, 
> > > > a
> > > > fence fd (s32 __user *). But it's not. It's s64 __user *. Due to that
> > > > surprise, I spent several hours chasing down weird corruption in Rob
> > > > Clark's kmscube. The kernel unexpectedly cleared the 32 bits *above* an
> > > > `int kms_fence_fd` in userspace.
> > > 
> > > Never use unsized types for uabi. I guess we could have used s32, but then
> > > someone is going to store this in a long and it goes boom on 64 bit,
> > 
> > Why so ? And why do we care ? The commonly accepted practice is to store 
> > file 
> > descriptors in int variables. s32 is an int on all platforms, so that's 
> > fine 
> > too. If we use a s32 pointer here, and someone decides to store it in a 
> > long, 
> > bool or cast it to a complex, that's their problem :-)
> 
> The only thing that really needs to be s64 here is the OUT_FENCE_PTR
> property in the Atomic interface because we carry a pointer there, but
> all the manipulation after that is actually done after can easily be
> done on s32 or int.
> 
> We can't expect that userspace will know that we store as s64 and clear
> the bits above if a int was passed down. if we use s32 we will be in
> complaince with other linux apis that deals with fds. I'd say we fix
> this before it can cause more damage out there.

Changing uabi is kinda tricky, but it's still very new, so if we make sure
it gets applied everywhere and doesn't accidentally ship we can it. Iirc
fences are only in 4.10, so we should be fine ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Why does OUT_FENCE_PTR point not to an fd (s32) but to an s64?

[Laurent Pinchart]

Hi Daniel,

On Thursday 12 Jan 2017 20:26:40 Daniel Vetter wrote:
> On Thu, Jan 12, 2017 at 05:17:26PM -0200, Gustavo Padovan wrote:
> > 2017-01-10 Laurent Pinchart :
> >> On Monday 09 Jan 2017 11:23:23 Daniel Vetter wrote:
> >>> On Fri, Jan 06, 2017 at 01:04:55PM -0800, Chad Versace wrote:
>  Was this a mistake in the API? If so, can we fix this ABI mistake
>  before kernel consumers rely on this?
>  
>  I naïvely expected that OUT_FENCE_PTR would be a pointer to,
>  obviously, a fence fd (s32 __user *). But it's not. It's s64 __user
>  *. Due to that surprise, I spent several hours chasing down weird
>  corruption in Rob Clark's kmscube. The kernel unexpectedly cleared
>  the 32 bits *above* an `int kms_fence_fd` in userspace.
> >>> 
> >>> Never use unsized types for uabi. I guess we could have used s32, but
> >>> then someone is going to store this in a long and it goes boom on 64
> >>> bit,
> >> 
> >> Why so ? And why do we care ? The commonly accepted practice is to store
> >> file descriptors in int variables. s32 is an int on all platforms, so
> >> that's fine too. If we use a s32 pointer here, and someone decides to
> >> store it in a long, bool or cast it to a complex, that's their problem
> >> :-)
> > 
> > The only thing that really needs to be s64 here is the OUT_FENCE_PTR
> > property in the Atomic interface because we carry a pointer there, but
> > all the manipulation after that is actually done after can easily be
> > done on s32 or int.
> > 
> > We can't expect that userspace will know that we store as s64 and clear
> > the bits above if a int was passed down. if we use s32 we will be in
> > complaince with other linux apis that deals with fds. I'd say we fix
> > this before it can cause more damage out there.
> 
> Changing uabi is kinda tricky, but it's still very new, so if we make sure
> it gets applied everywhere and doesn't accidentally ship we can it. Iirc
> fences are only in 4.10, so we should be fine ...

Correct. That sounds good to me, there's still time for a v4.10-rc fix.

-- 
Regards,

Laurent Pinchart

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

Re: Why does OUT_FENCE_PTR point not to an fd (s32) but to an s64?

[Gustavo Padovan]

2017-01-12 Laurent Pinchart :

> Hi Daniel,
> 
> On Thursday 12 Jan 2017 20:26:40 Daniel Vetter wrote:
> > On Thu, Jan 12, 2017 at 05:17:26PM -0200, Gustavo Padovan wrote:
> > > 2017-01-10 Laurent Pinchart :
> > >> On Monday 09 Jan 2017 11:23:23 Daniel Vetter wrote:
> > >>> On Fri, Jan 06, 2017 at 01:04:55PM -0800, Chad Versace wrote:
> >  Was this a mistake in the API? If so, can we fix this ABI mistake
> >  before kernel consumers rely on this?
> >  
> >  I naïvely expected that OUT_FENCE_PTR would be a pointer to,
> >  obviously, a fence fd (s32 __user *). But it's not. It's s64 __user
> >  *. Due to that surprise, I spent several hours chasing down weird
> >  corruption in Rob Clark's kmscube. The kernel unexpectedly cleared
> >  the 32 bits *above* an `int kms_fence_fd` in userspace.
> > >>> 
> > >>> Never use unsized types for uabi. I guess we could have used s32, but
> > >>> then someone is going to store this in a long and it goes boom on 64
> > >>> bit,
> > >> 
> > >> Why so ? And why do we care ? The commonly accepted practice is to store
> > >> file descriptors in int variables. s32 is an int on all platforms, so
> > >> that's fine too. If we use a s32 pointer here, and someone decides to
> > >> store it in a long, bool or cast it to a complex, that's their problem
> > >> :-)
> > > 
> > > The only thing that really needs to be s64 here is the OUT_FENCE_PTR
> > > property in the Atomic interface because we carry a pointer there, but
> > > all the manipulation after that is actually done after can easily be
> > > done on s32 or int.
> > > 
> > > We can't expect that userspace will know that we store as s64 and clear
> > > the bits above if a int was passed down. if we use s32 we will be in
> > > complaince with other linux apis that deals with fds. I'd say we fix
> > > this before it can cause more damage out there.
> > 
> > Changing uabi is kinda tricky, but it's still very new, so if we make sure
> > it gets applied everywhere and doesn't accidentally ship we can it. Iirc
> > fences are only in 4.10, so we should be fine ...
> 
> Correct. That sounds good to me, there's still time for a v4.10-rc fix.

I'd expect users defining an int and hitting the issue Chad hit instead
of going to long types. So I hope we are safe here. I'll prepare a
patch to make it s32.

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

Re: [PATCH] drm/atomic: Add target_vblank support in atomic helpers (v2)

[Daniel Vetter]

On Thu, Jan 12, 2017 at 06:18:20PM +, Grodzovsky, Andrey wrote:
> > -Original Message-
> > From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> > Daniel Vetter
> > Sent: Thursday, January 12, 2017 3:51 AM
> > To: Michel Dänzer
> > Cc: Grodzovsky, Andrey; Deucher, Alexander; dri-
> > de...@lists.freedesktop.org
> > Subject: Re: [PATCH] drm/atomic: Add target_vblank support in atomic
> > helpers (v2)
> > 
> > On Thu, Jan 12, 2017 at 9:28 AM, Michel Dänzer 
> > wrote:
> > > On 12/01/17 12:48 AM, Grodzovsky, Andrey wrote:
> > >>> From: Michel Dänzer [mailto:mic...@daenzer.net] On 09/01/17 06:59
> > >>> PM, Daniel Vetter wrote:
> >  On Fri, Jan 06, 2017 at 03:39:40PM -0500, Andrey Grodzovsky wrote:
> > > Allows usage of the new page_flip_target hook for drivers
> > > implementing the atomic path.
> > > Provides default atomic helper for the new hook.
> > >
> > > v2:
> > > Update code sharing logic between exsiting and the new flip hooks.
> > > Improve kerneldoc.
> > >
> > > Signed-off-by: Andrey Grodzovsky 
> > 
> >  Looks all reasonable, I think an ack from Alex that the amd side is
> >  in shape too, and I'll pull this into drm-misc.
> > >>>
> > >>> Andrey, is there an updated patch 2 adapted to current patch 1?
> > >>> Other than that and some questionable indentation of parameters in
> > >>> function signatures, looks good to me FWIW.
> > >>
> > >> We are unable to use the atomic helpers both for page_flip and
> > >> page_flip_target At their current form mostly due to
> > DRM_MODE_PAGE_FLIP_ASYNC flag rejection they do.
> > >> I discussed this with Daniel Vetter on IRC and suggested to remove
> > >> the rejection but he said the precise semantics of atomic async flip
> > >> is not clear yet and it's better to leave that out for now until
> > >> there is a  userspace asking for it.
> > >> So I tested it by just hacking  the helper to remove the rejection.
> > >> Until that settled the original change [PATCH 2/2] drm/amd/dal:
> > >> Switch to page_flip_target hook in DAL Is what we plan to use in DAL
> > >
> > > IIRC Daniel suggested (on IRC?) to use the helper for non-async flips
> > > and the current DC code for async flips. Is that feasible?
> > 
> > We do have some async flip flag reserved for atomic, so we could route it
> > through. But since atm there's no one asking for async flips on the atomic
> > ioctl I'm a bit wary for fear of ending up with ill-defined semantics. But 
> > I guess
> > if we do this for legacy pageflips only, and make sure we do still reject 
> > async
> > flips submitted through the atomic ioctl that should be all fine. And it 
> > should
> > allow amdgpu to entirely get rid of the legacy flip path, which would be 
> > nice.
> > 
> > Once we have that we could even use it for cursor plane updates (through
> > the legacy ioctl, for drivers with universal planes), for those drivers that
> > support it.
> > -Daniel
> 
> So are we ok with a follow-up patch removing the ASYNC_FLIP restriction in 
> the legacy IOCTL
> + adding the drm_mode_crtc_page_flip_target.flags to drm_crtc_state ? In that 
> case as I said before,
> at least for DAL we could drop our own page_flip hook and use the avaialbe 
> helpers.

Yeah, reconsidering all I think that'd be rather reasonable approach.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99387] Kernel 4.9: Kaveri + Hainan choked on boot using amdgpu

[bugzilla-daemon]

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

--- Comment #1 from Jeremy Newton  ---
FYI, this is build off of Alexander Deucher's freedesktop mirror,
amd-staging-4.9 branch, with the 4.9.2 patch-set and Fedora's patchset (minus
the amd patches that conflict or are already applied in this branch):

https://cgit.freedesktop.org/~agd5f/linux/?h=amd-staging-4.9

I'm assuming you're using the latest Fedora snapshot of linux firmware, if so
it's a snapshot of this commit:

https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/commit/?id=91ddce492dc0a6a718396e0c79101087134f622d

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

Re: [PATCH 06/10] drm/i915/psr: set CHICKEN_TRANS for psr2

[Vivi, Rodrigo]

Reviewed-by: Rodrigo Vivi 

On Fri, 2017-01-13 at 00:31 +0530, vathsala nagaraju wrote:
> As per bpsec, CHICKEN_TRANS_EDP bit 12 ,15 must be programmed in
> psr2 enable sequence.
> bit 12 : Program Transcoder EDP VSC DIP header with a valid setting for
> PSR2 and Set CHICKEN_TRANS_EDP(0x420cc) bit 12 for programmable
> header packet.
> bit 15 : Set CHICKEN_TRANS_EDP(0x420cc) bit 15 if Y coordinate is supported
> 
> v2: (Rodrigo)
> - move CHICKEN_TRANS_EDP bit set logic right after setup_vsc
> 
> v3:(Rodrigo)
> - initialize chicken_trans to CHICKEN_TRANS_BIT12 instead of 0
> 
> v4:(chris wilson)
> - use BIT(12), remove CHICKEN_TRANS_BIT12
> - remove unnecessary comments
> - update commit message
> 
> v5:
> - rename bit 12 PSR2_VSC_ENABLE_PROG_HEADER
> - rename bit 15 PSR2_ADD_VERTICAL_LINE_COUNT
> 
> v6:(Rodrigo)
> - remove TRANS_EDP=3, use cpu_transcoder
> 
> Cc: Rodrigo Vivi 
> Cc: Jim Bride 
> Signed-off-by: vathsala nagaraju 
> Signed-off-by: Patil Deepti 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  | 6 ++
>  drivers/gpu/drm/i915/intel_psr.c | 7 +++
>  2 files changed, 13 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 7830e6e..c9c1ccd 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6449,6 +6449,12 @@ enum {
>  #define  BDW_DPRS_MASK_VBLANK_SRD(1 << 0)
>  #define CHICKEN_PIPESL_1(pipe) _MMIO_PIPE(pipe, _CHICKEN_PIPESL_1_A, 
> _CHICKEN_PIPESL_1_B)
>  
> +#define CHICKEN_TRANS_A 0x420c0
> +#define CHICKEN_TRANS_B 0x420c4
> +#define CHICKEN_TRANS(trans) _MMIO_TRANS(trans, CHICKEN_TRANS_A, 
> CHICKEN_TRANS_B)
> +#define PSR2_VSC_ENABLE_PROG_HEADER(1<<12)
> +#define PSR2_ADD_VERTICAL_LINE_COUNT   (1<<15)
> +
>  #define DISP_ARB_CTL _MMIO(0x45000)
>  #define  DISP_FBC_MEMORY_WAKE(1<<31)
>  #define  DISP_TILE_SURFACE_SWIZZLING (1<<13)
> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
> b/drivers/gpu/drm/i915/intel_psr.c
> index 36c4045..935402e 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -480,6 +480,9 @@ void intel_psr_enable(struct intel_dp *intel_dp)
>   struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
>   struct drm_device *dev = intel_dig_port->base.base.dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
> + struct intel_crtc *crtc = to_intel_crtc(intel_dig_port->base.base.crtc);
> + enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
> + u32 chicken;
>  
>   if (!HAS_PSR(dev_priv)) {
>   DRM_DEBUG_KMS("PSR not supported on this platform\n");
> @@ -505,6 +508,10 @@ void intel_psr_enable(struct intel_dp *intel_dp)
>   if (HAS_DDI(dev_priv)) {
>   if (dev_priv->psr.psr2_support) {
>   skl_psr_setup_su_vsc(intel_dp);
> + chicken = PSR2_VSC_ENABLE_PROG_HEADER;
> + if (dev_priv->psr.y_cord_support)
> + chicken |= PSR2_ADD_VERTICAL_LINE_COUNT;
> + I915_WRITE(CHICKEN_TRANS(cpu_transcoder), chicken);
>   } else {
>   /* set up vsc header for psr1 */
>   hsw_psr_setup_vsc(intel_dp);

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

[PATCH libdrm 1/2] xf86drmMode.h: Use consistent padding

[Thierry Reding]

From: Thierry Reding 

Signed-off-by: Thierry Reding 
---
 xf86drmMode.h | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/xf86drmMode.h b/xf86drmMode.h
index b68496787b84..00ad81d17ef3 100644
--- a/xf86drmMode.h
+++ b/xf86drmMode.h
@@ -123,13 +123,13 @@ extern "C" {
 #define DRM_MODE_DITHERING_OFF  0
 #define DRM_MODE_DITHERING_ON   1
 
-#define DRM_MODE_ENCODER_NONE   0
-#define DRM_MODE_ENCODER_DAC1
-#define DRM_MODE_ENCODER_TMDS   2
-#define DRM_MODE_ENCODER_LVDS   3
-#define DRM_MODE_ENCODER_TVDAC  4
+#define DRM_MODE_ENCODER_NONE0
+#define DRM_MODE_ENCODER_DAC 1
+#define DRM_MODE_ENCODER_TMDS2
+#define DRM_MODE_ENCODER_LVDS3
+#define DRM_MODE_ENCODER_TVDAC   4
 #define DRM_MODE_ENCODER_VIRTUAL 5
-#define DRM_MODE_ENCODER_DSI   6
+#define DRM_MODE_ENCODER_DSI 6
 
 #define DRM_MODE_SUBCONNECTOR_Automatic 0
 #define DRM_MODE_SUBCONNECTOR_Unknown   0
@@ -153,8 +153,8 @@ extern "C" {
 #define DRM_MODE_CONNECTOR_DisplayPort  10
 #define DRM_MODE_CONNECTOR_HDMIA11
 #define DRM_MODE_CONNECTOR_HDMIB12
-#define DRM_MODE_CONNECTOR_TV  13
-#define DRM_MODE_CONNECTOR_eDP 14
+#define DRM_MODE_CONNECTOR_TV   13
+#define DRM_MODE_CONNECTOR_eDP  14
 #define DRM_MODE_CONNECTOR_VIRTUAL  15
 #define DRM_MODE_CONNECTOR_DSI  16
 
-- 
2.11.0

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

[PATCH libdrm 2/2] xf86drmMode.h: Add DisplayPort MST and DPI encoders/connectors

[Thierry Reding]

From: Thierry Reding 

This brings xf86drmMode.h in sync with include/drm/drm_mode.h.
Eventually we really should only have a single set of definitions rather
than duplicating this in two files.

v2: add DPI encoder and connector types introduced in Linux v4.7

Signed-off-by: Thierry Reding 
---
 xf86drmMode.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/xf86drmMode.h b/xf86drmMode.h
index 00ad81d17ef3..5b390d9fbeb6 100644
--- a/xf86drmMode.h
+++ b/xf86drmMode.h
@@ -130,6 +130,8 @@ extern "C" {
 #define DRM_MODE_ENCODER_TVDAC   4
 #define DRM_MODE_ENCODER_VIRTUAL 5
 #define DRM_MODE_ENCODER_DSI 6
+#define DRM_MODE_ENCODER_DPMST   7
+#define DRM_MODE_ENCODER_DPI 8
 
 #define DRM_MODE_SUBCONNECTOR_Automatic 0
 #define DRM_MODE_SUBCONNECTOR_Unknown   0
@@ -157,6 +159,7 @@ extern "C" {
 #define DRM_MODE_CONNECTOR_eDP  14
 #define DRM_MODE_CONNECTOR_VIRTUAL  15
 #define DRM_MODE_CONNECTOR_DSI  16
+#define DRM_MODE_CONNECTOR_DPI  17
 
 #define DRM_MODE_PROP_PENDING   (1<<0)
 #define DRM_MODE_PROP_RANGE (1<<1)
-- 
2.11.0

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

Re: [PATCH libdrm 2/2] Add .editorconfig

[Thierry Reding]

On Sat, Dec 24, 2016 at 05:04:14PM +, Emil Velikov wrote:
> On 23 December 2016 at 17:36, Thierry Reding  wrote:
> > From: Thierry Reding 
> >
> > This encodes the indentation style for libdrm and can be used with
> > various editors. See http://editorconfig.org for instructions.
> >
> Thanks for these and the usb/platform work Thierry.
> 
> We might want more a few more .editorconfig files, for ./intel/ and
> others but that will happen in due time.
> 
> These two, and 1/3 are
> Reviewed-by: Emil Velikov 

I've pushed these two patches to master.

Thierry


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

[PATCH libdrm] xf86drm: Fix type-punned pointer build warning

[Thierry Reding]

From: Thierry Reding 

  CC   libdrm_la-xf86drmMode.lo
../xf86drmMode.c: In function 'drmHandleEvent':
../xf86drmMode.c:854:15: warning: dereferencing type-punned pointer will 
break strict-aliasing rules [-Wstrict-aliasing]
   e = (struct drm_event *)(&buffer[i]);
   ^

Signed-off-by: Thierry Reding 
---
 xf86drmMode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xf86drmMode.c b/xf86drmMode.c
index 43cdbbd1ede4..c669774f8fc5 100644
--- a/xf86drmMode.c
+++ b/xf86drmMode.c
@@ -901,7 +901,7 @@ int drmHandleEvent(int fd, drmEventContextPtr evctx)
 
i = 0;
while (i < len) {
-   e = (struct drm_event *) &buffer[i];
+   e = (struct drm_event *)(buffer + i);
switch (e->type) {
case DRM_EVENT_VBLANK:
if (evctx->version < 1 ||
-- 
2.11.0

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

[PATCH libdrm v2 0/4] xf86drm: Add USB, platform and host1x bus support

[Thierry Reding]

From: Thierry Reding 

This series enables support for USB, platform and host1x busses in the
drmDevice infrastructure. The goal is to make use of these in Mesa for PRIME
support (via the DRI_PRIME environment variable) for devices on one of these
busses.

Changes in v2:
- add USB, platform and host1x bus support to tests/drmdevice
- make sure not to overflow path names and device fullnames
- read compatible strings into platform/host1x device info

I've tested both platform and host1x bus support on Tegra and also verified
that there aren't any leaks by running tests/drmdevice through valgrind.

Since I don't have any UDL devices myself I'm adding the X.Org development
mailing list on Cc, as suggested by Emil Velikov, in the hopes that someone
with access to that hardware will be generous enough to give these a run.

Thierry

Thierry Reding (4):
  xf86drm: Factor out drmDeviceAlloc()
  xf86drm: Add USB support
  xf86drm: Add platform and host1x bus support
  tests/drmdevice: Add USB, platform and host1x support

 tests/drmdevice.c |  37 
 xf86drm.c | 521 +++---
 xf86drm.h |  41 -
 3 files changed, 571 insertions(+), 28 deletions(-)

-- 
2.11.0

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

[PATCH libdrm v2 1/4] xf86drm: Factor out drmDeviceAlloc()

[Thierry Reding]

From: Thierry Reding 

Subsequent patches will add support for other bus types to drmDevice and
they will duplicate a lot of the code to allocate a drmDevice. Factor
out the common code so it can be reused.

Signed-off-by: Thierry Reding 
---
 xf86drm.c | 78 +--
 1 file changed, 51 insertions(+), 27 deletions(-)

diff --git a/xf86drm.c b/xf86drm.c
index b8b2cfe5412b..c123650a1e23 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -3157,57 +3157,81 @@ void drmFreeDevices(drmDevicePtr devices[], int count)
 drmFreeDevice(&devices[i]);
 }
 
+static drmDevicePtr drmDeviceAlloc(unsigned int type, const char *node,
+   size_t bus_size, size_t device_size,
+   char **ptrp)
+{
+size_t max_node_length, extra, size;
+drmDevicePtr device;
+unsigned int i;
+char *ptr;
+
+max_node_length = ALIGN(drmGetMaxNodeName(), sizeof(void *));
+extra = DRM_NODE_MAX * (sizeof(void *) + max_node_length);
+
+size = sizeof(*device) + extra + bus_size + device_size;
+
+device = calloc(1, size);
+if (!device)
+return NULL;
+
+device->available_nodes = 1 << type;
+
+ptr = (char *)device + sizeof(*device);
+device->nodes = (char **)ptr;
+
+ptr += DRM_NODE_MAX * sizeof(void *);
+
+for (i = 0; i < DRM_NODE_MAX; i++) {
+device->nodes[i] = ptr;
+ptr += max_node_length;
+}
+
+memcpy(device->nodes[type], node, max_node_length);
+
+*ptrp = ptr;
+
+return device;
+}
+
 static int drmProcessPciDevice(drmDevicePtr *device,
const char *node, int node_type,
int maj, int min, bool fetch_deviceinfo,
uint32_t flags)
 {
-const int max_node_str = ALIGN(drmGetMaxNodeName(), sizeof(void *));
-int ret, i;
+drmDevicePtr dev;
 char *addr;
+int ret;
 
-*device = calloc(1, sizeof(drmDevice) +
- (DRM_NODE_MAX * (sizeof(void *) + max_node_str)) +
- sizeof(drmPciBusInfo) +
- sizeof(drmPciDeviceInfo));
-if (!*device)
+dev = drmDeviceAlloc(node_type, node, sizeof(drmPciBusInfo),
+ sizeof(drmPciDeviceInfo), &addr);
+if (!dev)
 return -ENOMEM;
 
-addr = (char*)*device;
+dev->bustype = DRM_BUS_PCI;
 
-(*device)->bustype = DRM_BUS_PCI;
-(*device)->available_nodes = 1 << node_type;
+dev->businfo.pci = (drmPciBusInfoPtr)addr;
 
-addr += sizeof(drmDevice);
-(*device)->nodes = (char**)addr;
-
-addr += DRM_NODE_MAX * sizeof(void *);
-for (i = 0; i < DRM_NODE_MAX; i++) {
-(*device)->nodes[i] = addr;
-addr += max_node_str;
-}
-memcpy((*device)->nodes[node_type], node, max_node_str);
-
-(*device)->businfo.pci = (drmPciBusInfoPtr)addr;
-
-ret = drmParsePciBusInfo(maj, min, (*device)->businfo.pci);
+ret = drmParsePciBusInfo(maj, min, dev->businfo.pci);
 if (ret)
 goto free_device;
 
 // Fetch the device info if the user has requested it
 if (fetch_deviceinfo) {
 addr += sizeof(drmPciBusInfo);
-(*device)->deviceinfo.pci = (drmPciDeviceInfoPtr)addr;
+dev->deviceinfo.pci = (drmPciDeviceInfoPtr)addr;
 
-ret = drmParsePciDeviceInfo(maj, min, (*device)->deviceinfo.pci, 
flags);
+ret = drmParsePciDeviceInfo(maj, min, dev->deviceinfo.pci, flags);
 if (ret)
 goto free_device;
 }
+
+*device = dev;
+
 return 0;
 
 free_device:
-free(*device);
-*device = NULL;
+free(dev);
 return ret;
 }
 
-- 
2.11.0

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

[PATCH libdrm v2 2/4] xf86drm: Add USB support

[Thierry Reding]

Allow DRM/KMS devices hosted on USB to be detected by the drmDevice
infrastructure.

v2:
- make sysfs_uevent_get() more flexible using a format string

Signed-off-by: Thierry Reding 
---
 xf86drm.c | 163 ++
 xf86drm.h |  13 +
 2 files changed, 176 insertions(+)

diff --git a/xf86drm.c b/xf86drm.c
index c123650a1e23..27cd6eb5193e 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -2906,6 +2906,9 @@ static int drmParseSubsystemType(int maj, int min)
 if (strncmp(name, "/pci", 4) == 0)
 return DRM_BUS_PCI;
 
+if (strncmp(name, "/usb", 4) == 0)
+return DRM_BUS_USB;
+
 return -EINVAL;
 #elif defined(__OpenBSD__)
 return DRM_BUS_PCI;
@@ -2992,6 +2995,10 @@ static int drmCompareBusInfo(drmDevicePtr a, 
drmDevicePtr b)
 switch (a->bustype) {
 case DRM_BUS_PCI:
 return memcmp(a->businfo.pci, b->businfo.pci, sizeof(drmPciBusInfo));
+
+case DRM_BUS_USB:
+return memcmp(a->businfo.usb, b->businfo.usb, sizeof(drmUsbBusInfo));
+
 default:
 break;
 }
@@ -3235,6 +3242,145 @@ free_device:
 return ret;
 }
 
+static char * DRM_PRINTFLIKE(2, 3)
+sysfs_uevent_get(const char *path, const char *fmt, ...)
+{
+char filename[PATH_MAX + 1], *key, *line = NULL, *value = NULL;
+size_t size = 0, len;
+ssize_t num;
+va_list ap;
+FILE *fp;
+
+va_start(ap, fmt);
+num = vasprintf(&key, fmt, ap);
+va_end(ap);
+len = num;
+
+snprintf(filename, sizeof(filename), "%s/uevent", path);
+
+fp = fopen(filename, "r");
+if (!fp) {
+free(key);
+return NULL;
+}
+
+while ((num = getline(&line, &size, fp)) >= 0) {
+if ((strncmp(line, key, len) == 0) && (line[len] == '=')) {
+char *start = line + len + 1, *end = line + num - 1;
+
+if (*end != '\n')
+end++;
+
+value = strndup(start, end - start);
+break;
+}
+}
+
+free(line);
+fclose(fp);
+
+free(key);
+
+return value;
+}
+
+static int drmParseUsbBusInfo(int maj, int min, drmUsbBusInfoPtr info)
+{
+char path[PATH_MAX + 1], *value;
+unsigned int bus, dev;
+int ret;
+
+snprintf(path, sizeof(path), "/sys/dev/char/%d:%d/device", maj, min);
+
+value = sysfs_uevent_get(path, "BUSNUM");
+if (!value)
+return -ENOENT;
+
+ret = sscanf(value, "%03u", &bus);
+free(value);
+
+if (ret <= 0)
+return -errno;
+
+value = sysfs_uevent_get(path, "DEVNUM");
+if (!value)
+return -ENOENT;
+
+ret = sscanf(value, "%03u", &dev);
+free(value);
+
+if (ret <= 0)
+return -errno;
+
+info->bus = bus;
+info->dev = dev;
+
+return 0;
+}
+
+static int drmParseUsbDeviceInfo(int maj, int min, drmUsbDeviceInfoPtr info)
+{
+char path[PATH_MAX + 1], *value;
+unsigned int vendor, product;
+int ret;
+
+snprintf(path, sizeof(path), "/sys/dev/char/%d:%d/device", maj, min);
+
+value = sysfs_uevent_get(path, "PRODUCT");
+if (!value)
+return -ENOENT;
+
+ret = sscanf(value, "%x/%x", &vendor, &product);
+free(value);
+
+if (ret <= 0)
+return -errno;
+
+info->vendor = vendor;
+info->product = product;
+
+return 0;
+}
+
+static int drmProcessUsbDevice(drmDevicePtr *device, const char *node,
+   int node_type, int maj, int min,
+   bool fetch_deviceinfo, uint32_t flags)
+{
+drmDevicePtr dev;
+char *ptr;
+int ret;
+
+dev = drmDeviceAlloc(node_type, node, sizeof(drmUsbBusInfo),
+ sizeof(drmUsbDeviceInfo), &ptr);
+if (!dev)
+return -ENOMEM;
+
+dev->bustype = DRM_BUS_USB;
+
+dev->businfo.usb = (drmUsbBusInfoPtr)ptr;
+
+ret = drmParseUsbBusInfo(maj, min, dev->businfo.usb);
+if (ret < 0)
+goto free_device;
+
+if (fetch_deviceinfo) {
+ptr += sizeof(drmUsbBusInfo);
+dev->deviceinfo.usb = (drmUsbDeviceInfoPtr)ptr;
+
+ret = drmParseUsbDeviceInfo(maj, min, dev->deviceinfo.usb);
+if (ret < 0)
+goto free_device;
+}
+
+*device = dev;
+
+return 0;
+
+free_device:
+free(dev);
+return ret;
+}
+
 /* Consider devices located on the same bus as duplicate and fold the 
respective
  * entries into a single one.
  *
@@ -3410,6 +3556,14 @@ int drmGetDevice2(int fd, uint32_t flags, drmDevicePtr 
*device)
 continue;
 
 break;
+
+case DRM_BUS_USB:
+ret = drmProcessUsbDevice(&d, node, node_type, maj, min, true, 
flags);
+if (ret)
+goto free_devices;
+
+break;
+
 default:
 continue;
 }
@@ -3541,6 +3695,15 @@ int drmGetDevices2(uint32_t flags, drmDevicePtr 
devices[], int max_devices)
 continue;
 
 break;
+
+case DRM_BUS_USB:
+ret = drmProcessUsbDevice(&device, node, nod

[PATCH libdrm v2 3/4] xf86drm: Add platform and host1x bus support

[Thierry Reding]

From: Thierry Reding 

ARM SoCs usually have their DRM/KMS devices on the platform bus, so add
support for that to enable these devices to be used with the drmDevice
infrastructure.

NVIDIA Tegra SoCs have an additional level in the hierarchy and DRM/KMS
devices can also be on the host1x bus. This is mostly equivalent to the
platform bus.

v2:
- be careful not to overflow the full name
- read compatible strings into device info

Signed-off-by: Thierry Reding 
---
 xf86drm.c | 280 ++
 xf86drm.h |  30 ++-
 2 files changed, 308 insertions(+), 2 deletions(-)

diff --git a/xf86drm.c b/xf86drm.c
index 27cd6eb5193e..69e1ecd47be3 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -2909,6 +2909,12 @@ static int drmParseSubsystemType(int maj, int min)
 if (strncmp(name, "/usb", 4) == 0)
 return DRM_BUS_USB;
 
+if (strncmp(name, "/platform", 9) == 0)
+return DRM_BUS_PLATFORM;
+
+if (strncmp(name, "/host1x", 7) == 0)
+return DRM_BUS_HOST1X;
+
 return -EINVAL;
 #elif defined(__OpenBSD__)
 return DRM_BUS_PCI;
@@ -2999,6 +3005,12 @@ static int drmCompareBusInfo(drmDevicePtr a, 
drmDevicePtr b)
 case DRM_BUS_USB:
 return memcmp(a->businfo.usb, b->businfo.usb, sizeof(drmUsbBusInfo));
 
+case DRM_BUS_PLATFORM:
+return memcmp(a->businfo.platform, b->businfo.platform, 
sizeof(drmPlatformBusInfo));
+
+case DRM_BUS_HOST1X:
+return memcmp(a->businfo.host1x, b->businfo.host1x, 
sizeof(drmHost1xBusInfo));
+
 default:
 break;
 }
@@ -3143,11 +3155,55 @@ static int drmParsePciDeviceInfo(int maj, int min,
 #endif
 }
 
+static void drmFreePlatformDevice(drmDevicePtr device)
+{
+if (device->deviceinfo.platform) {
+if (device->deviceinfo.platform->compatible) {
+char **compatible = device->deviceinfo.platform->compatible;
+
+while (*compatible) {
+free(*compatible);
+compatible++;
+}
+
+free(device->deviceinfo.platform->compatible);
+}
+}
+}
+
+static void drmFreeHost1xDevice(drmDevicePtr device)
+{
+if (device->deviceinfo.host1x) {
+if (device->deviceinfo.host1x->compatible) {
+char **compatible = device->deviceinfo.host1x->compatible;
+
+while (*compatible) {
+free(*compatible);
+compatible++;
+}
+
+free(device->deviceinfo.host1x->compatible);
+}
+}
+}
+
 void drmFreeDevice(drmDevicePtr *device)
 {
 if (device == NULL)
 return;
 
+if (*device) {
+switch ((*device)->bustype) {
+case DRM_BUS_PLATFORM:
+drmFreePlatformDevice(*device);
+break;
+
+case DRM_BUS_HOST1X:
+drmFreeHost1xDevice(*device);
+break;
+}
+}
+
 free(*device);
 *device = NULL;
 }
@@ -3381,6 +3437,200 @@ free_device:
 return ret;
 }
 
+static int drmParsePlatformBusInfo(int maj, int min, drmPlatformBusInfoPtr 
info)
+{
+char path[PATH_MAX + 1], *name;
+
+snprintf(path, sizeof(path), "/sys/dev/char/%d:%d/device", maj, min);
+
+name = sysfs_uevent_get(path, "OF_FULLNAME");
+if (!name)
+return -ENOENT;
+
+strncpy(info->fullname, name, DRM_PLATFORM_DEVICE_NAME_LEN);
+info->fullname[DRM_PLATFORM_DEVICE_NAME_LEN - 1] = '\0';
+free(name);
+
+return 0;
+}
+
+static int drmParsePlatformDeviceInfo(int maj, int min,
+  drmPlatformDeviceInfoPtr info)
+{
+char path[PATH_MAX + 1], *value;
+unsigned int count, i;
+int err;
+
+snprintf(path, sizeof(path), "/sys/dev/char/%d:%d/device", maj, min);
+
+value = sysfs_uevent_get(path, "OF_COMPATIBLE_N");
+if (!value)
+return -ENOENT;
+
+sscanf(value, "%u", &count);
+free(value);
+
+info->compatible = calloc(count + 1, sizeof(*info->compatible));
+if (!info->compatible)
+return -ENOMEM;
+
+for (i = 0; i < count; i++) {
+value = sysfs_uevent_get(path, "OF_COMPATIBLE_%u", i);
+if (!value) {
+err = -ENOENT;
+goto free;
+}
+
+info->compatible[i] = value;
+}
+
+return 0;
+
+free:
+while (i--)
+free(info->compatible[i]);
+
+free(info->compatible);
+return err;
+}
+
+static int drmProcessPlatformDevice(drmDevicePtr *device,
+const char *node, int node_type,
+int maj, int min, bool fetch_deviceinfo,
+uint32_t flags)
+{
+drmDevicePtr dev;
+char *ptr;
+int ret;
+
+dev = drmDeviceAlloc(node_type, node, sizeof(drmPlatformBusInfo),
+ sizeof(drmPlatformDeviceInfo), &ptr);
+if (!dev)
+return -ENOMEM;
+
+dev->bustype = DRM_BUS_PLATFORM;
+
+dev->businfo.platform = (drmPlatformBusInfoPtr)ptr;
+
+ret = drmParsePlatfo

[PATCH libdrm v2 4/4] tests/drmdevice: Add USB, platform and host1x support

[Thierry Reding]

From: Thierry Reding 

Extend the drmdevice test with support for the newly added USB, platform
and host1x busses.

Signed-off-by: Thierry Reding 
---
 tests/drmdevice.c | 37 +
 1 file changed, 37 insertions(+)

diff --git a/tests/drmdevice.c b/tests/drmdevice.c
index 8c4f091a9972..9dd5098a211f 100644
--- a/tests/drmdevice.c
+++ b/tests/drmdevice.c
@@ -62,6 +62,43 @@ print_device_info(drmDevicePtr device, int i, bool 
print_revision)
 else
 printf("\t\t\trevision_id\tIGNORED\n");
 
+} else if (device->bustype == DRM_BUS_USB) {
+printf("\t\tusb\n");
+printf("\t\t\tbus\t%03u\n", device->businfo.usb->bus);
+printf("\t\t\tdev\t%03u\n", device->businfo.usb->dev);
+
+printf("\tdeviceinfo\n");
+printf("\t\tusb\n");
+printf("\t\t\tvendor\t%04x\n", device->deviceinfo.usb->vendor);
+printf("\t\t\tproduct\t%04x\n", device->deviceinfo.usb->product);
+} else if (device->bustype == DRM_BUS_PLATFORM) {
+char **compatible = device->deviceinfo.platform->compatible;
+
+printf("\t\tplatform\n");
+printf("\t\t\tfullname\t%s\n", device->businfo.platform->fullname);
+
+printf("\tdeviceinfo\n");
+printf("\t\tplatform\n");
+printf("\t\t\tcompatible\n");
+
+while (*compatible) {
+printf("\t\t\t\t%s\n", *compatible);
+compatible++;
+}
+} else if (device->bustype == DRM_BUS_HOST1X) {
+char **compatible = device->deviceinfo.platform->compatible;
+
+printf("\t\thost1x\n");
+printf("\t\t\tfullname\t%s\n", device->businfo.host1x->fullname);
+
+printf("\tdeviceinfo\n");
+printf("\t\tplatform\n");
+printf("\t\t\tcompatible\n");
+
+while (*compatible) {
+printf("\t\t\t\t%s\n", *compatible);
+compatible++;
+}
 } else {
 printf("Unknown/unhandled bustype\n");
 }
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH 1/3] drm: Add new DRM_IOCTL_MODE_GETPLANE2

[Daniel Stone]

Hi,

On 12 January 2017 at 18:11, Ville Syrjälä
 wrote:
> On Thu, Jan 12, 2017 at 05:50:15PM +, Daniel Stone wrote:
>> struct drm_plane {
>> struct {
>> uint32_t format;
>> uint64_t modifiers[];
>> } formats[];
>> }
>
> Flipping formats[] vs. modifiers[] here would seem like it should make
> this easier with the proposed kernel API. And if the kernel will also
> uarantee that multiple instances of the same modifier must be returned
> contiguously, then it should be even easier.
>
> Oh and flipping formats[] and modifiers[] should also save a quite a
> bit of space since each format takes twice as much space as each
> modifier. But I suppose that might come at a runtime cost if you have
> to look for a specific format in each modifier's format list instead
> of having to look at just the modifier list of a specific format. So
> I suppose not flipping might be better after all, which I guess would
> complicate populating the infromation somewhat.
>
> Anyways, that's all a bit unrelated to the matter at hand, so I'll stop
> now and just state that I don't mind having an explicit offset if
> people really want it.

It would make sense, but then gbm_surface_create_with_modifiers takes
a fixed pixel format and a list of acceptable modifiers (which to me
seems like the right way around as an API), so whenever I was creating
a surface, I'd have to walk through and create a new list, flipped
back the other way.

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

[Bug 99387] Kernel 4.9: Kaveri + Hainan choked on boot using amdgpu

[bugzilla-daemon]

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

--- Comment #2 from Luya Tshimbalanga  ---
Checking the linux-firmware, the system was still on 20160923 snapshot. Koji
has the lastest version so I upgrade to it. I will report if that fixes the
issue.

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

[Bug 99387] Kernel 4.9: Kaveri + Hainan choked on boot using amdgpu

[bugzilla-daemon]

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

--- Comment #3 from Alex Deucher  ---
You don't need amdgpu.exp_hw_support=1  You just have to make sure SI and CIK
support are enabled.

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

[Bug 98513] [REGRESSION][drm-next-4.10-wip][AMDGPU][CIK] Unable to suspend, hangs on hibernation bad commit 86f8c599b09c916f9aad30563271440dbd79213a

[bugzilla-daemon]

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

--- Comment #4 from Shawn Starr  ---
As noted on IRC 4.10-rc2 w/ drm-next-4.10-wip and 4.10-rc3 w/ drm-next-4.11-wip
do not require this commit to be reverted.

Hibernate (freeze), Resume (thaw) seem to work fine here, keeping ticket open
for further testing.

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

[Bug 99392] Ark survival evolved won't start

[bugzilla-daemon]

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

Bug ID: 99392
   Summary: Ark survival evolved won't start
   Product: Mesa
   Version: 13.0
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: predator-...@web.de
QA Contact: dri-devel@lists.freedesktop.org

Hi,
I have problems to start ark with the open source mesa driver 13x (tested
13.0.2 and 13.0.3) on my kubuntu 16.10.

It works with the standard ubuntu supported 12.0.3 version.

I'am using the ppas form this guide:
https://www.epicgames.com/unrealtournament/forums/showthread.php?23665-How-to-update-Open-Source-graphic-driver-in-Ubuntu

I also tried out the padoka and the oilbav ones.

The problem is a error message with one or two letters by starting the game.
I tried out to start steam in terminal without any useful new informations
about that ark error. 

I also tried out to change some mesa enviroment variables without any solution.

Does anyone have a useful solution for that problem ? Maybe some new way to
find out what kind of error this message is.

Thanks.

glxinfo | grep OpenGL:
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD TAHITI (DRM 2.46.0 /
4.8.0-34-generic, LLVM 4.0.0)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.0.0-devel -
padoka PPA
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 17.0.0-devel - padoka PPA
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 17.0.0-devel - padoka PPA
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10

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

[Bug 99393] mesa build failure when using config.status: sid_tables.h generation

[bugzilla-daemon]

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

Bug ID: 99393
   Summary: mesa build failure when using config.status:
sid_tables.h generation
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: snowman...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 128922
  --> https://bugs.freedesktop.org/attachment.cgi?id=128922&action=edit
part of build.log

sid_tables.h generation fails because there is no src/amd/common directory

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

[PATCH -next] drm/hisilicon/hibmc: Fix wrong pointer passed to PTR_ERR()

[Wei Yongjun]

From: Wei Yongjun 

PTR_ERR should access the value just tested by IS_ERR, otherwise
the wrong error code will be returned.

Fixes: d1667b86795a ("drm/hisilicon/hibmc: Add support for frame buffer")
Signed-off-by: Wei Yongjun 
---
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
index 7a6957a..16fe790 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_fbdev.c
@@ -121,7 +121,7 @@ static int hibmc_drm_fb_create(struct drm_fb_helper *helper,
 
hi_fbdev->fb = hibmc_framebuffer_init(priv->dev, &mode_cmd, gobj);
if (IS_ERR(hi_fbdev->fb)) {
-   ret = PTR_ERR(info);
+   ret = PTR_ERR(hi_fbdev->fb);
DRM_ERROR("failed to initialize framebuffer: %d\n", ret);
goto out_release_fbi;
}

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

[Bug 99393] mesa build failure when using config.status: sid_tables.h generation

[bugzilla-daemon]

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

Ivan Fomin  changed:

   What|Removed |Added

   Severity|normal  |trivial

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

Re: [PATCH v2 7/7] uapi: export all headers under uapi directories

[Nicolas Dichtel]

Le 09/01/2017 à 13:56, Christoph Hellwig a écrit :
> On Fri, Jan 06, 2017 at 10:43:59AM +0100, Nicolas Dichtel wrote:
>> Regularly, when a new header is created in include/uapi/, the developer
>> forgets to add it in the corresponding Kbuild file. This error is usually
>> detected after the release is out.
>>
>> In fact, all headers under uapi directories should be exported, thus it's
>> useless to have an exhaustive list.
>>
>> After this patch, the following files, which were not exported, are now
>> exported (with make headers_install_all):
> 
> ... snip ...
> 
>> linux/genwqe/.install
>> linux/genwqe/..install.cmd
>> linux/cifs/.install
>> linux/cifs/..install.cmd
> 
> I'm pretty sure these should not be exported!
> 
Those files are created in every directory:
$ find usr/include/ -name '\.\.install.cmd' | wc -l
71
$ find usr/include/ -name '\.install' | wc -l
71

See also
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/scripts/Makefile.headersinst#n32


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

[PATCH 06/10] drm/i915/psr: set CHICKEN_TRANS for psr2

[vathsala nagaraju]

As per bpsec, CHICKEN_TRANS_EDP bit 12 ,15 must be programmed in
psr2 enable sequence.
bit 12 : Program Transcoder EDP VSC DIP header with a valid setting for
PSR2 and Set CHICKEN_TRANS_EDP(0x420cc) bit 12 for programmable
header packet.
bit 15 : Set CHICKEN_TRANS_EDP(0x420cc) bit 15 if Y coordinate is supported

v2: (Rodrigo)
- move CHICKEN_TRANS_EDP bit set logic right after setup_vsc

v3:(Rodrigo)
- initialize chicken_trans to CHICKEN_TRANS_BIT12 instead of 0

v4:(chris wilson)
- use BIT(12), remove CHICKEN_TRANS_BIT12
- remove unnecessary comments
- update commit message

v5:
- rename bit 12 PSR2_VSC_ENABLE_PROG_HEADER
- rename bit 15 PSR2_ADD_VERTICAL_LINE_COUNT

v6:(Rodrigo)
- remove TRANS_EDP=3, use cpu_transcoder

Cc: Rodrigo Vivi 
Cc: Jim Bride 
Signed-off-by: vathsala nagaraju 
Signed-off-by: Patil Deepti 
---
 drivers/gpu/drm/i915/i915_reg.h  | 6 ++
 drivers/gpu/drm/i915/intel_psr.c | 7 +++
 2 files changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7830e6e..c9c1ccd 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6449,6 +6449,12 @@ enum {
 #define  BDW_DPRS_MASK_VBLANK_SRD  (1 << 0)
 #define CHICKEN_PIPESL_1(pipe) _MMIO_PIPE(pipe, _CHICKEN_PIPESL_1_A, 
_CHICKEN_PIPESL_1_B)
 
+#define CHICKEN_TRANS_A 0x420c0
+#define CHICKEN_TRANS_B 0x420c4
+#define CHICKEN_TRANS(trans) _MMIO_TRANS(trans, CHICKEN_TRANS_A, 
CHICKEN_TRANS_B)
+#define PSR2_VSC_ENABLE_PROG_HEADER(1<<12)
+#define PSR2_ADD_VERTICAL_LINE_COUNT   (1<<15)
+
 #define DISP_ARB_CTL   _MMIO(0x45000)
 #define  DISP_FBC_MEMORY_WAKE  (1<<31)
 #define  DISP_TILE_SURFACE_SWIZZLING   (1<<13)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 36c4045..935402e 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -480,6 +480,9 @@ void intel_psr_enable(struct intel_dp *intel_dp)
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = intel_dig_port->base.base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
+   struct intel_crtc *crtc = to_intel_crtc(intel_dig_port->base.base.crtc);
+   enum transcoder cpu_transcoder = crtc->config->cpu_transcoder;
+   u32 chicken;
 
if (!HAS_PSR(dev_priv)) {
DRM_DEBUG_KMS("PSR not supported on this platform\n");
@@ -505,6 +508,10 @@ void intel_psr_enable(struct intel_dp *intel_dp)
if (HAS_DDI(dev_priv)) {
if (dev_priv->psr.psr2_support) {
skl_psr_setup_su_vsc(intel_dp);
+   chicken = PSR2_VSC_ENABLE_PROG_HEADER;
+   if (dev_priv->psr.y_cord_support)
+   chicken |= PSR2_ADD_VERTICAL_LINE_COUNT;
+   I915_WRITE(CHICKEN_TRANS(cpu_transcoder), chicken);
} else {
/* set up vsc header for psr1 */
hsw_psr_setup_vsc(intel_dp);
-- 
1.9.1

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

[PATCH 07/10] drm/i915/psr: set PSR_MASK bits for deep sleep

[vathsala nagaraju]

Program EDP_PSR_DEBUG_CTL (PSR_MASK) to enable system
to go to deep sleep while in psr2.PSR2_STATUS bit 31:28
should report value 8 , if system enters deep sleep state.

Also, EDP_FRAMES_BEFORE_SU_ENTRY is set 1 , if not set,
flickering is observed on psr2 panel.

v2: (Ilia Mirkin)
- Remove duplicate bit definition 25:27

v3: rebase

v4: rebase

v5: rebase

Cc: Rodrigo Vivi 
Cc: Jim Bride 
Signed-off-by: Vathsala Nagaraju 
Signed-off-by: Patil Deepti 
Reviewed-by: Jim Bride 
---
 drivers/gpu/drm/i915/i915_reg.h  | 10 +++---
 drivers/gpu/drm/i915/intel_psr.c | 30 --
 2 files changed, 27 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c9c1ccd..ca76887 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3597,9 +3597,12 @@ enum {
 #define   EDP_PSR_PERF_CNT_MASK0xff
 
 #define EDP_PSR_DEBUG_CTL  _MMIO(dev_priv->psr_mmio_base + 0x60)
-#define   EDP_PSR_DEBUG_MASK_LPSP  (1<<27)
-#define   EDP_PSR_DEBUG_MASK_MEMUP (1<<26)
-#define   EDP_PSR_DEBUG_MASK_HPD   (1<<25)
+#define   EDP_PSR_DEBUG_MASK_MAX_SLEEP (1<<28)
+#define   EDP_PSR_DEBUG_MASK_LPSP  (1<<27)
+#define   EDP_PSR_DEBUG_MASK_MEMUP (1<<26)
+#define   EDP_PSR_DEBUG_MASK_HPD   (1<<25)
+#define   EDP_PSR_DEBUG_MASK_DISP_REG_WRITE(1<<16)
+#define   EDP_PSR_DEBUG_EXIT_ON_PIXEL_UNDERRUN (1<<15)
 
 #define EDP_PSR2_CTL   _MMIO(0x6f900)
 #define   EDP_PSR2_ENABLE  (1<<31)
@@ -3614,6 +3617,7 @@ enum {
 #define   EDP_PSR2_FRAME_BEFORE_SU_SHIFT 4
 #define   EDP_PSR2_FRAME_BEFORE_SU_MASK(0xf<<4)
 #define   EDP_PSR2_IDLE_MASK   0xf
+#define   EDP_FRAMES_BEFORE_SU_ENTRY   (1<<4)
 
 #define EDP_PSR2_STATUS_CTL_MMIO(0x6f940)
 #define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 935402e..3611c42 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -338,7 +338,9 @@ static void intel_enable_source_psr2(struct intel_dp 
*intel_dp)
/* FIXME: selective update is probably totally broken because it doesn't
 * mesh at all with our frontbuffer tracking. And the hw alone isn't
 * good enough. */
-   val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
+   val |= EDP_PSR2_ENABLE |
+   EDP_SU_TRACK_ENABLE |
+   EDP_FRAMES_BEFORE_SU_ENTRY;
 
if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
val |= EDP_PSR2_TP2_TIME_2500;
@@ -512,20 +514,28 @@ void intel_psr_enable(struct intel_dp *intel_dp)
if (dev_priv->psr.y_cord_support)
chicken |= PSR2_ADD_VERTICAL_LINE_COUNT;
I915_WRITE(CHICKEN_TRANS(cpu_transcoder), chicken);
+   I915_WRITE(EDP_PSR_DEBUG_CTL,
+  EDP_PSR_DEBUG_MASK_MEMUP |
+  EDP_PSR_DEBUG_MASK_HPD |
+  EDP_PSR_DEBUG_MASK_LPSP |
+  EDP_PSR_DEBUG_MASK_MAX_SLEEP |
+  EDP_PSR_DEBUG_MASK_DISP_REG_WRITE);
} else {
/* set up vsc header for psr1 */
hsw_psr_setup_vsc(intel_dp);
+   /*
+* Per Spec: Avoid continuous PSR exit by masking MEMUP
+* and HPD. also mask LPSP to avoid dependency on other
+* drivers that might block runtime_pm besides
+* preventing  other hw tracking issues now we can rely
+* on frontbuffer tracking.
+*/
+   I915_WRITE(EDP_PSR_DEBUG_CTL,
+  EDP_PSR_DEBUG_MASK_MEMUP |
+  EDP_PSR_DEBUG_MASK_HPD |
+  EDP_PSR_DEBUG_MASK_LPSP);
}
 
-   /*
-* Per Spec: Avoid continuous PSR exit by masking MEMUP and HPD.
-* Also mask LPSP to avoid dependency on other drivers that
-* might block runtime_pm besides preventing other hw tracking
-* issues now we can rely on frontbuffer tracking.
-*/
-   I915_WRITE(EDP_PSR_DEBUG_CTL, EDP_PSR_DEBUG_MASK_MEMUP |
-  EDP_PSR_DEBUG_MASK_HPD | EDP_PSR_DEBUG_MASK_LPSP);
-
/* Enable PSR on the panel */
hsw_psr_enable_sink(intel_dp);
 
-- 
1.9.1

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

Re: Enabling peer to peer device transactions for PCIe devices

[Jason Gunthorpe]

On Thu, Jan 12, 2017 at 10:11:29AM -0500, Jerome Glisse wrote:
> On Wed, Jan 11, 2017 at 10:54:39PM -0600, Stephen Bates wrote:
> > > What we want is for RDMA, O_DIRECT, etc to just work with special VMAs
> > > (ie. at least those backed with ZONE_DEVICE memory). Then
> > > GPU/NVME/DAX/whatever drivers can just hand these VMAs to userspace
> > > (using whatever interface is most appropriate) and userspace can do what
> > > it pleases with them. This makes _so_ much sense and actually largely
> > > already works today (as demonstrated by iopmem).

> So i say let solve the IOMMU issue first and let everyone use it in their
> own way with their device. I do not think we can share much more than
> that.

Solve it for the easy ZONE_DIRECT/etc case then.

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

[PATCH 03/10] drm/i915/psr: fix blank screen issue for psr2

[vathsala nagaraju]

Psr1 and psr2 are mutually exclusive,ie when psr2 is enabled,
psr1 should be disabled.When psr2 is exited , bit 31 of reg
PSR2_CTL must be set to 0 but currently bit 31 of SRD_CTL
(psr1 control register)is set to 0.
Also ,PSR2_IDLE state is looked up from SRD_STATUS(psr1 register)
instead of PSR2_STATUS register, which has wrong data, resulting
in blankscreen.
hsw_enable_source is split into hsw_enable_source_psr1 and
hsw_enable_source_psr2 for easier code review and maintenance,
as suggested by rodrigo and jim.

v2: (Rodrigo)
- Rename hsw_enable_source_psr* to intel_enable_source_psr*

v3: (Rodrigo)
- In hsw_psr_disable ,
  1) for psr active case, handle psr2 followed by psr1.
  2) psr inactive case, handle psr2 followed by psr1

v4:(Rodrigo)
- move psr2 restriction(32X20) to match_conditions function
  returning false and fully blocking PSR to a new patch before
  this one.

v5: in source_psr2, removed val = EDP_PSR_ENABLE

Cc: Rodrigo Vivi 
Cc: Jim Bride 
Signed-off-by: Vathsala Nagaraju 
Signed-off-by: Patil Deepti 
---
 drivers/gpu/drm/i915/i915_reg.h  |   3 +
 drivers/gpu/drm/i915/intel_psr.c | 122 +--
 2 files changed, 95 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 00970aa..7830e6e 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3615,6 +3615,9 @@ enum {
 #define   EDP_PSR2_FRAME_BEFORE_SU_MASK(0xf<<4)
 #define   EDP_PSR2_IDLE_MASK   0xf
 
+#define EDP_PSR2_STATUS_CTL_MMIO(0x6f940)
+#define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
+
 /* VGA port control */
 #define ADPA   _MMIO(0x61100)
 #define PCH_ADPA_MMIO(0xe1100)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 707cae8..8827647 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -261,7 +261,7 @@ static void vlv_psr_activate(struct intel_dp *intel_dp)
   VLV_EDP_PSR_ACTIVE_ENTRY);
 }
 
-static void hsw_psr_enable_source(struct intel_dp *intel_dp)
+static void intel_enable_source_psr1(struct intel_dp *intel_dp)
 {
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct drm_device *dev = dig_port->base.base.dev;
@@ -312,14 +312,29 @@ static void hsw_psr_enable_source(struct intel_dp 
*intel_dp)
val |= EDP_PSR_TP1_TP2_SEL;
 
I915_WRITE(EDP_PSR_CTL, val);
+}
 
-   if (!dev_priv->psr.psr2_support)
-   return;
+static void intel_enable_source_psr2(struct intel_dp *intel_dp)
+{
+   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+   struct drm_device *dev = dig_port->base.base.dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   /*
+* Let's respect VBT in case VBT asks a higher idle_frame value.
+* Let's use 6 as the minimum to cover all known cases including
+* the off-by-one issue that HW has in some cases. Also there are
+* cases where sink should be able to train
+* with the 5 or 6 idle patterns.
+*/
+   uint32_t idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
+   uint32_t val;
+
+   val = idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
 
/* FIXME: selective update is probably totally broken because it doesn't
 * mesh at all with our frontbuffer tracking. And the hw alone isn't
 * good enough. */
-   val = EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
+   val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
 
if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
val |= EDP_PSR2_TP2_TIME_2500;
@@ -333,6 +348,19 @@ static void hsw_psr_enable_source(struct intel_dp 
*intel_dp)
I915_WRITE(EDP_PSR2_CTL, val);
 }
 
+static void hsw_psr_enable_source(struct intel_dp *intel_dp)
+{
+   struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
+   struct drm_device *dev = dig_port->base.base.dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+
+   /* psr1 and psr2 are mutually exclusive.*/
+   if (dev_priv->psr.psr2_support)
+   intel_enable_source_psr2(intel_dp);
+   else
+   intel_enable_source_psr1(intel_dp);
+}
+
 static bool intel_psr_match_conditions(struct intel_dp *intel_dp)
 {
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
@@ -417,7 +445,10 @@ static void intel_psr_activate(struct intel_dp *intel_dp)
struct drm_device *dev = intel_dig_port->base.base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
 
-   WARN_ON(I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE);
+   if (dev_priv->psr.psr2_support)
+   WARN_ON(I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE);
+   else
+   WARN_ON(I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE);
WARN_ON(dev_priv->psr.active);
lockdep_assert_held(&dev_priv->psr.lock);
 
@@ -468,10 

Re: [PATCH v2 7/7] uapi: export all headers under uapi directories

[Nicolas Dichtel]

Le 12/01/2017 à 17:28, Jan Engelhardt a écrit :
> On Thursday 2017-01-12 16:52, Nicolas Dichtel wrote:
> 
>> Le 09/01/2017 à 13:56, Christoph Hellwig a écrit :
>>> On Fri, Jan 06, 2017 at 10:43:59AM +0100, Nicolas Dichtel wrote:
 Regularly, when a new header is created in include/uapi/, the developer
 forgets to add it in the corresponding Kbuild file. This error is usually
 detected after the release is out.

 In fact, all headers under uapi directories should be exported, thus it's
 useless to have an exhaustive list.

 After this patch, the following files, which were not exported, are now
 exported (with make headers_install_all):
>>>
>>> ... snip ...
>>>
 linux/genwqe/.install
 linux/genwqe/..install.cmd
 linux/cifs/.install
 linux/cifs/..install.cmd
>>>
>>> I'm pretty sure these should not be exported!
>>>
>> Those files are created in every directory:
>> $ find usr/include/ -name '\.\.install.cmd' | wc -l
>> 71
> 
> That still does not mean they should be exported.
> 
> Anything but headers (and directories as a skeleton structure) is maximally 
> suspicious.
> 
What I was trying to say is that I export those directories like other are.
Removing those files is not related to that series.


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

[PATCH -next] drm/atomic: make release_crtc_commit() static

[Wei Yongjun]

From: Wei Yongjun 

Fixes the following sparse warning:

drivers/gpu/drm/drm_atomic_helper.c:1360:6: warning:
 symbol 'release_crtc_commit' was not declared. Should it be static?

Signed-off-by: Wei Yongjun 
---
 drivers/gpu/drm/drm_atomic_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 7b71ac4..e2e5a74 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1357,7 +1357,7 @@ static int stall_checks(struct drm_crtc *crtc, bool 
nonblock)
return ret < 0 ? ret : 0;
 }
 
-void release_crtc_commit(struct completion *completion)
+static void release_crtc_commit(struct completion *completion)
 {
struct drm_crtc_commit *commit = container_of(completion,
  typeof(*commit),

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