date:20160825

On Thu, Aug 25, 2016 at 05:55:18PM +0530, Archit Taneja wrote:
> On 08/18/2016 02:26 AM, Daniel Vetter wrote:
> > +void drm_mode_object_unregister(struct drm_device *dev,
> > +   struct drm_mode_object *object);
> 
> Alignment issue in the declaration here.

Again I don't like touching code when moving it. I guess I'll squash all
your suggestions into the polish patches.
-Daneil
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 1/9] drm: Extract drm_encoder.[hc]

On Thu, Aug 25, 2016 at 05:53:51PM +0530, Archit Taneja wrote:
> 
> Hi,
> 
> On 08/18/2016 02:25 AM, Daniel Vetter wrote:
> > Same treatment as before. Only hiccup is drm_crtc_mask, which
> > unfortunately can't be resolved until drm_crtc.h is less of a monster.
> > Untangle the header loop with a forward delcaration for that static
> 
> s/delcaration/declaration
> 
> > inline.
> > 
> > Signed-off-by: Daniel Vetter 
> > ---
> >   Documentation/gpu/drm-kms.rst   |   9 ++
> >   drivers/gpu/drm/Makefile|   3 +-
> >   drivers/gpu/drm/drm_crtc.c  | 193 ---
> >   drivers/gpu/drm/drm_crtc_internal.h |  10 +-
> >   drivers/gpu/drm/drm_encoder.c   | 220 
> > 
> >   include/drm/drm_crtc.h  | 134 +-
> >   include/drm/drm_encoder.h   | 167 +++
> >   7 files changed, 407 insertions(+), 329 deletions(-)
> >   create mode 100644 drivers/gpu/drm/drm_encoder.c
> >   create mode 100644 include/drm/drm_encoder.h
> > 
> 
> 
> 
> > +
> > +/**
> > + * drm_encoder_init - Init a preallocated encoder
> > + * @dev: drm device
> > + * @encoder: the encoder to init
> > + * @funcs: callbacks for this encoder
> > + * @encoder_type: user visible type of the encoder
> > + * @name: printf style format string for the encoder name, or NULL for 
> > default name
> > + *
> > + * Initialises a preallocated encoder. Encoder should be
> > + * subclassed as part of driver encoder objects.
> > + *
> > + * Returns:
> > + * Zero on success, error code on failure.
> > + */
> > +int drm_encoder_init(struct drm_device *dev,
> > + struct drm_encoder *encoder,
> > + const struct drm_encoder_funcs *funcs,
> > + int encoder_type, const char *name, ...)
> 
> Alignment with the open parentheses is needed here.
> 
> > +{
> > +   int ret;
> > +
> > +   drm_modeset_lock_all(dev);
> > +
> > +   ret = drm_mode_object_get(dev, >base, DRM_MODE_OBJECT_ENCODER);
> > +   if (ret)
> > +   goto out_unlock;
> > +
> > +   encoder->dev = dev;
> > +   encoder->encoder_type = encoder_type;
> > +   encoder->funcs = funcs;
> > +   if (name) {
> > +   va_list ap;
> > +
> > +   va_start(ap, name);
> > +   encoder->name = kvasprintf(GFP_KERNEL, name, ap);
> > +   va_end(ap);
> > +   } else {
> > +   encoder->name = kasprintf(GFP_KERNEL, "%s-%d",
> > + 
> > drm_encoder_enum_list[encoder_type].name,
> > + encoder->base.id);
> > +   }
> > +   if (!encoder->name) {
> > +   ret = -ENOMEM;
> > +   goto out_put;
> > +   }
> > +
> > +   list_add_tail(>head, >mode_config.encoder_list);
> > +   encoder->index = dev->mode_config.num_encoder++;
> > +
> > +out_put:
> > +   if (ret)
> > +   drm_mode_object_unregister(dev, >base);
> > +
> > +out_unlock:
> > +   drm_modeset_unlock_all(dev);
> > +
> > +   return ret;
> > +}
> > +EXPORT_SYMBOL(drm_encoder_init);
> > +
> > +/**
> > + * drm_encoder_cleanup - cleans up an initialised encoder
> > + * @encoder: encoder to cleanup
> > + *
> > + * Cleans up the encoder but doesn't free the object.
> > + */
> > +void drm_encoder_cleanup(struct drm_encoder *encoder)
> > +{
> > +   struct drm_device *dev = encoder->dev;
> > +
> > +   /* Note that the encoder_list is considered to be static; should we
> > +* remove the drm_encoder at runtime we would have to decrement all
> > +* the indices on the drm_encoder after us in the encoder_list.
> > +*/
> > +
> > +   drm_modeset_lock_all(dev);
> > +   drm_mode_object_unregister(dev, >base);
> > +   kfree(encoder->name);
> > +   list_del(>head);
> > +   dev->mode_config.num_encoder--;
> > +   drm_modeset_unlock_all(dev);
> > +
> > +   memset(encoder, 0, sizeof(*encoder));
> > +}
> > +EXPORT_SYMBOL(drm_encoder_cleanup);
> > +
> > +static struct drm_crtc *drm_encoder_get_crtc(struct drm_encoder *encoder)
> > +{
> > +   struct drm_connector *connector;
> > +   struct drm_device *dev = encoder->dev;
> > +   bool uses_atomic = false;
> > +
> > +   /* For atomic drivers only state objects are synchronously updated and
> > +* protected by modeset locks, so check those first. */
> > +   drm_for_each_connector(connector, dev) {
> > +   if (!connector->state)
> > +   continue;
> > +
> > +   uses_atomic = true;
> > +
> > +   if (connector->state->best_encoder != encoder)
> > +   continue;
> > +
> > +   return connector->state->crtc;
> > +   }
> > +
> > +   /* Don't return stale data (e.g. pending async disable). */
> > +   if (uses_atomic)
> > +   return NULL;
> > +
> > +   return encoder->crtc;
> > +}
> > +
> > +/**
> > + * drm_mode_getencoder - get encoder configuration
> > + * @dev: drm device for the ioctl
> > + * @data: data pointer for the ioctl
> > + * @file_priv: drm file for the ioctl call

[PATCH v2] drm: cleanup drm_core_{init,exit}()

2016-08-25 Thread David Herrmann

Various cleanups to the DRM core initialization and exit handlers:

 - Register chrdev last: Once register_chrdev() returns, open() will
   succeed on the given chrdevs. This is usually not an issue, as no
   chardevs are registered, yet. However, nodes can be created by
   user-space via mknod(2), even though such major/minor combinations are
   unknown to the kernel. Avoid calling into drm_stub_open() in those
   cases.
   Again, drm_stub_open() would just bail out as the inode is unknown,
   but it's really non-obvious if you hack on drm_stub_open().

 - Unify error-paths into just one label. All the error-path helpers can
   be called even though the constructors were not called yet, or failed.
   Hence, just call all cleanups unconditionally.

 - Call into drm_global_release(). This is a no-op, but provides
   debugging helpers in case there're GLOBALS left on module unload. This
   function was unused until now.

 - Use DRM_ERROR() instead of printk(), and also print the error-code on
   failure (even if it is static!).

 - Don't throw away error-codes of register_chrdev()!

 - Don't hardcode -1 as errno. This is just plain wrong.

 - Order exit-handlers in the exact reverse order of initialization
   (except if the order actually matters for syncing-reasons, which is
   not the case here, though).

v2:
 - Call drm_core_exit() directly from the init-error-handler. Requires to
   drop __exit annotation, though.

Signed-off-by: David Herrmann 
---
Hey

This is based on top of
"[PATCH] drm: drop obsolete drm_core.h"
Should be trivial to rebase, though. Just a DRM_ERROR()-message conflict.

Thanks
David

 drivers/gpu/drm/drm_drv.c | 48 ++-
 1 file changed, 22 insertions(+), 26 deletions(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index d771453..0773547 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -941,52 +941,48 @@ static const struct file_operations drm_stub_fops = {
.llseek = noop_llseek,
 };

+static void drm_core_exit(void)
+{
+   unregister_chrdev(DRM_MAJOR, "drm");
+   debugfs_remove(drm_debugfs_root);
+   drm_sysfs_destroy();
+   idr_destroy(_minors_idr);
+   drm_connector_ida_destroy();
+   drm_global_release();
+}
+
 static int __init drm_core_init(void)
 {
-   int ret = -ENOMEM;
+   int ret;

drm_global_init();
drm_connector_ida_init();
idr_init(_minors_idr);

-   if (register_chrdev(DRM_MAJOR, "drm", _stub_fops))
-   goto err_p1;
-
ret = drm_sysfs_init();
if (ret < 0) {
-   printk(KERN_ERR "DRM: Error creating drm class.\n");
-   goto err_p2;
+   DRM_ERROR("Cannot create DRM class: %d\n", ret);
+   goto error;
}

drm_debugfs_root = debugfs_create_dir("dri", NULL);
if (!drm_debugfs_root) {
-   DRM_ERROR("Cannot create /sys/kernel/debug/dri\n");
-   ret = -1;
-   goto err_p3;
+   ret = -ENOMEM;
+   DRM_ERROR("Cannot create debugfs-root: %d\n", ret);
+   goto error;
}

+   ret = register_chrdev(DRM_MAJOR, "drm", _stub_fops);
+   if (ret < 0)
+   goto error;
+
DRM_INFO("Initialized\n");
return 0;
-err_p3:
-   drm_sysfs_destroy();
-err_p2:
-   unregister_chrdev(DRM_MAJOR, "drm");

-   idr_destroy(_minors_idr);
-err_p1:
+error:
+   drm_core_exit();
return ret;
 }

-static void __exit drm_core_exit(void)
-{
-   debugfs_remove(drm_debugfs_root);
-   drm_sysfs_destroy();
-
-   unregister_chrdev(DRM_MAJOR, "drm");
-
-   drm_connector_ida_destroy();
-   idr_destroy(_minors_idr);
-}
-
 module_init(drm_core_init);
 module_exit(drm_core_exit);
-- 
2.9.3

[Bug 97461] FS-UAE waits forever with glClientWaitSync() when using glFenceSync() on amdgpu/radeonsi

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

Marek OlÅ¡Ã¡k  changed:

   What|Removed |Added

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

--- Comment #4 from Marek OlÅ¡Ã¡k  ---
I pushed the fix. Closing.

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

[Bug 97413] BioShock Infinite crashes on startup with Mesa Git version, R7 370

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

Marek OlÅ¡Ã¡k  changed:

   What|Removed |Added

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

--- Comment #2 from Marek OlÅ¡Ã¡k  ---
Pushed as a491b9e945423a81f785220b85a9b395060952aa.

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

[PATCH] drm/simple-helpers: Always add planes to the state update

On Thu, Aug 25, 2016 at 07:13:07PM +0200, Noralf TrÃ¸nnes wrote:
> 
> Den 25.08.2016 08:30, skrev Daniel Vetter:
> > On Wed, Aug 24, 2016 at 08:38:37PM +0200, Noralf TrÃ¸nnes wrote:
> > > Den 23.08.2016 08:25, skrev Daniel Vetter:
> > > > Our update function is hooked to the single plane, which might not get
> > > > called for crtc-only updates. Which is surprising, so fix this by
> > > > always adding the plane.
> > > > 
> > > > While at it document how the event should be sent out better in
> > > > the kerneldoc.
> > > > 
> > > > Cc: Noralf TrÃ¸nnes 
> > > > Cc: andrea.merello at gmail.com
> > > > Tested-and-Reported-by: andrea.merello at gmail.com
> > > > Signed-off-by: Daniel Vetter 
> > > > ---
> > > > I'm not entirely sure we really want to put the responsibility for
> > > > this onto driver. Plan B) would be to remove the kerneldoc I added
> > > > here and call the right function from 
> > > > drm_simple_kms_plane_atomic_update.
> > > > That way simple drivers don't need to deal with that detail, and in
> > > > general those drivers don't care that much about the miniscule
> > > > possible race a generic implementation would cause. What do you
> > > > suggest as the best approach?
> > > If the driver is responsible, a helper like this would be nice:
> > > 
> > > void drm_simple_display_pipe_handle_vblank_event(struct
> > > drm_simple_display_pipe *pipe)
> > > {
> > >  struct drm_crtc *crtc = >crtc;
> > > 
> > >  if (crtc->state && crtc->state->event) {
> > >  spin_lock_irq(>dev->event_lock);
> > >  drm_crtc_send_vblank_event(crtc, crtc->state->event);
> > >  spin_unlock_irq(>dev->event_lock);
> > >  crtc->state->event = NULL;
> > For a generic version we probably want to automatically switch to
> > drm_crtc_arm_vblank_event, if vblank support is available. That can be
> > checked by looking at drm_device->num_crtcs.
> > 
> > >  }
> > > }
> > > 
> > > Then if the update() callback is not set, 
> > > drm_simple_kms_plane_atomic_update
> > > calls this, and if it is set, then the driver has to do it or something
> > > similar.
> > > 
> > > It is difficult to predict what future drivers will need.
> > > Unless there are drivers on the horizon that will need to handle the
> > > event themselves, I suggest that we follow your plan B. If the need 
> > > arises,
> > > we just add a one-liner to all drivers that has the update() callback set.
> > Hm yeah. What about merging this patch here for now (would need your
> > formal reviewed-by), and then later on when we have 2-3 simple drivers
> > using this we can reconsider? Since I dont have hw for any of them I can't
> > do this myself.
> > 
> > > Noralf.
> > > 
> > > Sidenote:
> > > When I converted simpledrm I had problems with flip_done timeouts.
> > > In the end I had to check for the event in disable/enable/update.
> > > Trying it again now, it's enough to do it in update().
> > > Not sure what has changed.
> > Trying again with this patch, or without? Since this patch here is meant
> > to exactly the problem that you need to handle the event in too many
> > places. If it's fixed with just latest drm-misc, that would be surprising
> > ...
> 
> I have updated Raspian so I could use xorg to test with, and indeed
> without this patch and without sending vblank event in disable and enable,
> the flip_done timeout showed up. modetest -v didn't trigger it.
> With this patch I only have to send the vblank event in update().
> 
> Reviewed-by: Noralf TrÃ¸nnes 

Thanks for the review, pushed onto -misc.
-Daniel

> 
> > -Daniel
> > 
> > > > -Daniel
> > > > ---
> > > >drivers/gpu/drm/drm_simple_kms_helper.c | 7 +++
> > > >include/drm/drm_simple_kms_helper.h | 6 ++
> > > >2 files changed, 13 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
> > > > b/drivers/gpu/drm/drm_simple_kms_helper.c
> > > > index bada17166512..447631018426 100644
> > > > --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> > > > +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> > > > @@ -34,6 +34,12 @@ static const struct drm_encoder_funcs 
> > > > drm_simple_kms_encoder_funcs = {
> > > > .destroy = drm_encoder_cleanup,
> > > >};
> > > > +static int drm_simple_kms_crtc_check(struct drm_crtc *crtc,
> > > > +struct drm_crtc_state *state)
> > > > +{
> > > > +   return drm_atomic_add_affected_planes(state->state, crtc);
> > > > +}
> > > > +
> > > >static void drm_simple_kms_crtc_enable(struct drm_crtc *crtc)
> > > >{
> > > > struct drm_simple_display_pipe *pipe;
> > > > @@ -57,6 +63,7 @@ static void drm_simple_kms_crtc_disable(struct 
> > > > drm_crtc *crtc)
> > > >}
> > > >static const struct drm_crtc_helper_funcs 
> > > > drm_simple_kms_crtc_helper_funcs = {
> > > > +   .atomic_check = drm_simple_kms_crtc_check,
> > > > .disable = drm_simple_kms_crtc_disable,
> > > > .enable = drm_simple_kms_crtc_enable,
>

[RFC 0/2] New feature: Framebuffer processors

2016-08-25 Thread Inki Dae



2016ë 08ì 25ì¼ 17:42ì Daniel Vetter ì´(ê°) ì´ ê¸:
> On Thu, Aug 25, 2016 at 05:06:55PM +0900, Inki Dae wrote:
>>
>>
>> 2016ë 08ì 24ì¼ 20:57ì Daniel Vetter ì´(ê°) ì´ ê¸:
>>> On Wed, Aug 24, 2016 at 08:44:24PM +0900, Inki Dae wrote:
 Hi,

 2016ë 08ì 23ì¼ 18:41ì Daniel Stone ì´(ê°) ì´ ê¸:
> Hi,
>
> On 22 August 2016 at 16:23, Rob Clark  wrote:
>> I guess a lot comes down to 'how long before hw designers bolt a CP to
>> the thing'..  at that point, I think you especially don't want a
>> per-blit kernel interface.
>
> Regardless of whether or not we want it, we already _have_ it, in the
> form of V4L2 M2M. There are already a few IP blocks working on that, I
> believe. If V4L2 <-> KMS interop is painful, well, we need to fix that
> anyway ...

 So we are trying this. We had expereneced using V4L2 and DRM together on
 Linux Platform makes it too complicated, and also integrated DRM with
 M2M such as 2D and Post processor makes it simplified.  So We have been
 trying to move existing V4L2 based drivers into DRM excepting HW Video
 Codec - called it MFC - and Camera sensor and relevant things.
 I think now V4L2 and DRM frameworks may make many engineers confusing
 because there are the same devices which can be controlled by V4L2 and
 DRM frameworks - maybe we would need more efforts like Laurent did with
 Live source[1] in the future.
>>>
>>> Can you pls explain in more detail where working with both v4l and drm
>>> drivers and making them cooperate using dma-bufs poses problems? We should
>>> definitely fix that.
>>
>> I think it would be most Linux Platforms - Android, Chrome and Tizen -
>> which would use OpenMAX/GStreammer for Multimedia and X or
>> Wayland/SurfaceFlinger for Display.
> 
> Yes, that's the use case. Where is the problem in making this happen? v4l
> can import dma-bufs, drm can export them, and there's plenty devices
> shipping (afaik) that make use of exact this pipeline. Can you pls explain
> what problem you've hit trying to make this work on exynos?

No problem but just make it complicated as I mentioned above - the stream 
operations - S_FMT, REQBUF, QUARYBUF, QBUF, STREAM ON and DQBUF of V4L2 would 
never be simple as DRM.
Do you think M2M device should be controlled by V4L2 interfaces? and even 2D 
accelerator? As long as I know, The Graphics card on Desktop has all devices 
such as 2D/3D GPU, HW Video codec and Display controller, and these devices are 
controlled by DRM interfaces. So we - ARM Exynos - are trying to move these 
things to DRM world and also trying to implement more convenient interfaces 
like Marek did.

Thanks,
Inki Dae

> -Daniel
>

[PATCH v4 3/5] drm: add SimpleDRM driver

2016-08-25 Thread Noralf Trønnes


Den 25.08.2016 15:09, skrev Rob Herring:
> On Mon, Aug 22, 2016 at 3:25 PM, Noralf TrÃ¸nnes  
> wrote:
>> The SimpleDRM driver binds to simple-framebuffer devices and provides a
>> DRM/KMS API. It provides only a single CRTC+encoder+connector combination
>> plus one initial mode.
>>
>> Userspace can create dumb-buffers which can be blit into the real
>> framebuffer similar to UDL. No access to the real framebuffer is allowed
>> (compared to earlier version of this driver) to avoid security issues.
>> Furthermore, this way we can support arbitrary modes as long as we have a
>> conversion-helper.
>>
>> The driver was originally written by David Herrmann in 2014.
>> My main contribution is to make use of drm_simple_kms_helper and
>> rework the probe path to avoid use of the deprecated drm_platform_init()
>> and drm_driver.{load,unload}().
>> Additions have also been made for later changes to the Device Tree binding
>> document, like support for clocks, regulators and having the node under
>> /chosen. This code was lifted verbatim from simplefb.c.
>>
>> Cc: dh.herrmann at gmail.com
>> Cc: libv at skynet.be
>> Signed-off-by: Noralf TrÃ¸nnes 
> [...]
>
>> +   /* Count the number of regulator supplies */
>> +   for_each_property_of_node(np, prop) {
>> +   p = strstr(prop->name, SUPPLY_SUFFIX);
>> +   if (p && p != prop->name)
>> +   count++;
>> +   }
> The regulator API should have functions for this rather than open coding it.

I couldn't find anything that matches this usecase. There are regulator
bulk functions, but they require the names to be known in advance.
And I don't know how many regulators there are nor their names.

>From Documentation/devicetree/bindings/display/simple-framebuffer.txt:

- *-supply : Any number of regulators used by the framebuffer. These should
  be named according to the names in the device's design.

>> +
>> +   if (!count)
>> +   return 0;
>> +
>> +   sdrm->regulators = devm_kcalloc(>dev, count,
>> +   sizeof(struct regulator *),
>> +   GFP_KERNEL);
>> +   if (!sdrm->regulators)
>> +   return -ENOMEM;
>> +
>> +   /* Get all the regulators */
>> +   for_each_property_of_node(np, prop) {
>> +   char name[32]; /* 32 is max size of property name */
>> +
>> +   p = strstr(prop->name, SUPPLY_SUFFIX);
>> +   if (!p || p == prop->name)
>> +   continue;
> This too.
>
>> +
>> +   strlcpy(name, prop->name,
>> +   strlen(prop->name) - strlen(SUPPLY_SUFFIX) + 1);
>> +   regulator = devm_regulator_get_optional(>dev, name);
> [...]
>
>> +   if (IS_ENABLED(CONFIG_OF_ADDRESS) && of_chosen) {
>> +   struct device_node *np;
>> +
>> +   for_each_child_of_node(of_chosen, np) {
>> +   if (of_device_is_compatible(np, 
>> "simple-framebuffer"))
> Rather than exporting of_chosen, this whole chunk can be replaced with
> a of_find_compatible_node call. Yes, that would match if
> simple-framebuffer exists somewhere else in the DT, but it is not the
> kernel's job to do DT validation.

This seems to do the job:

 /*
  * The binding doc states that simplefb nodes should be sub-nodes of
  * chosen and that older devicetree files can have them in a different
  * place. of_platform_device_create() just returns NULL if a device
  * has already been created for the node.
  */
 for_each_compatible_node(np, NULL, "simple-framebuffer")
 of_platform_device_create(np, NULL, NULL);


Noralf.

>> +   of_platform_device_create(np, NULL, NULL);
>> +   }
>> +   }
> Rob
>

[Bug 97119] screen flickerin under KDE when compositor was dis- and reenabled

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

Johannes Hirte  changed:

   What|Removed |Added

Summary|screen distortion under KDE |screen flickerin under KDE
   |when running without|when compositor was dis-
   |compositor  |and reenabled

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

[Bug 97119] screen distortion under KDE when running without compositor

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

--- Comment #13 from Johannes Hirte  ---
(In reply to network723 from comment #12)
> The video resembles kwin bug: https://bugs.kde.org/show_bug.cgi?id=361154
> which was fixed in plasma 5.7.4.

I'm running plasma 5.7.4 here and still have the problem. Additionally it's
only affecting amdgpu systems like Carrizo. I don't see this on a Sumo system
(radeon/r600). Tomorrow I can try if I can trigger this on Kabini too.

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

[PATCH] drm/simple-helpers: Always add planes to the state update

2016-08-25 Thread Noralf Trønnes


Den 25.08.2016 08:30, skrev Daniel Vetter:
> On Wed, Aug 24, 2016 at 08:38:37PM +0200, Noralf TrÃ¸nnes wrote:
>> Den 23.08.2016 08:25, skrev Daniel Vetter:
>>> Our update function is hooked to the single plane, which might not get
>>> called for crtc-only updates. Which is surprising, so fix this by
>>> always adding the plane.
>>>
>>> While at it document how the event should be sent out better in
>>> the kerneldoc.
>>>
>>> Cc: Noralf TrÃ¸nnes 
>>> Cc: andrea.merello at gmail.com
>>> Tested-and-Reported-by: andrea.merello at gmail.com
>>> Signed-off-by: Daniel Vetter 
>>> ---
>>> I'm not entirely sure we really want to put the responsibility for
>>> this onto driver. Plan B) would be to remove the kerneldoc I added
>>> here and call the right function from drm_simple_kms_plane_atomic_update.
>>> That way simple drivers don't need to deal with that detail, and in
>>> general those drivers don't care that much about the miniscule
>>> possible race a generic implementation would cause. What do you
>>> suggest as the best approach?
>> If the driver is responsible, a helper like this would be nice:
>>
>> void drm_simple_display_pipe_handle_vblank_event(struct
>> drm_simple_display_pipe *pipe)
>> {
>>  struct drm_crtc *crtc = >crtc;
>>
>>  if (crtc->state && crtc->state->event) {
>>  spin_lock_irq(>dev->event_lock);
>>  drm_crtc_send_vblank_event(crtc, crtc->state->event);
>>  spin_unlock_irq(>dev->event_lock);
>>  crtc->state->event = NULL;
> For a generic version we probably want to automatically switch to
> drm_crtc_arm_vblank_event, if vblank support is available. That can be
> checked by looking at drm_device->num_crtcs.
>
>>  }
>> }
>>
>> Then if the update() callback is not set, drm_simple_kms_plane_atomic_update
>> calls this, and if it is set, then the driver has to do it or something
>> similar.
>>
>> It is difficult to predict what future drivers will need.
>> Unless there are drivers on the horizon that will need to handle the
>> event themselves, I suggest that we follow your plan B. If the need arises,
>> we just add a one-liner to all drivers that has the update() callback set.
> Hm yeah. What about merging this patch here for now (would need your
> formal reviewed-by), and then later on when we have 2-3 simple drivers
> using this we can reconsider? Since I dont have hw for any of them I can't
> do this myself.
>
>> Noralf.
>>
>> Sidenote:
>> When I converted simpledrm I had problems with flip_done timeouts.
>> In the end I had to check for the event in disable/enable/update.
>> Trying it again now, it's enough to do it in update().
>> Not sure what has changed.
> Trying again with this patch, or without? Since this patch here is meant
> to exactly the problem that you need to handle the event in too many
> places. If it's fixed with just latest drm-misc, that would be surprising
> ...

I have updated Raspian so I could use xorg to test with, and indeed
without this patch and without sending vblank event in disable and enable,
the flip_done timeout showed up. modetest -v didn't trigger it.
With this patch I only have to send the vblank event in update().

Reviewed-by: Noralf TrÃ¸nnes 

> -Daniel
>
>>> -Daniel
>>> ---
>>>drivers/gpu/drm/drm_simple_kms_helper.c | 7 +++
>>>include/drm/drm_simple_kms_helper.h | 6 ++
>>>2 files changed, 13 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
>>> b/drivers/gpu/drm/drm_simple_kms_helper.c
>>> index bada17166512..447631018426 100644
>>> --- a/drivers/gpu/drm/drm_simple_kms_helper.c
>>> +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
>>> @@ -34,6 +34,12 @@ static const struct drm_encoder_funcs 
>>> drm_simple_kms_encoder_funcs = {
>>> .destroy = drm_encoder_cleanup,
>>>};
>>> +static int drm_simple_kms_crtc_check(struct drm_crtc *crtc,
>>> +struct drm_crtc_state *state)
>>> +{
>>> +   return drm_atomic_add_affected_planes(state->state, crtc);
>>> +}
>>> +
>>>static void drm_simple_kms_crtc_enable(struct drm_crtc *crtc)
>>>{
>>> struct drm_simple_display_pipe *pipe;
>>> @@ -57,6 +63,7 @@ static void drm_simple_kms_crtc_disable(struct drm_crtc 
>>> *crtc)
>>>}
>>>static const struct drm_crtc_helper_funcs 
>>> drm_simple_kms_crtc_helper_funcs = {
>>> +   .atomic_check = drm_simple_kms_crtc_check,
>>> .disable = drm_simple_kms_crtc_disable,
>>> .enable = drm_simple_kms_crtc_enable,
>>>};
>>> diff --git a/include/drm/drm_simple_kms_helper.h 
>>> b/include/drm/drm_simple_kms_helper.h
>>> index 269039722f91..826946ca2b82 100644
>>> --- a/include/drm/drm_simple_kms_helper.h
>>> +++ b/include/drm/drm_simple_kms_helper.h
>>> @@ -60,6 +60,12 @@ struct drm_simple_display_pipe_funcs {
>>>  *
>>>  * This function is called when the underlying plane state is updated.
>>>  * This hook is optional.
>>> +*
>>> +* This is the function drivers should submit the
>>> +* _pending_vblank_event

[PATCH] drm/amdgpu: Add amdkfd softdep

2016-08-25 Thread Michal Marek

amdgpu loads amdkfd via symbol_request(). Add a softdep hint so that
userspace knows that amdgpu needs amdkfd in the initrd.

Reported-and-tested-by: Martin Jambor 
Signed-off-by: Michal Marek 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 9aa533cf4ad1..9c469cd311ca 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -633,3 +633,4 @@ module_exit(amdgpu_exit);
 MODULE_AUTHOR(DRIVER_AUTHOR);
 MODULE_DESCRIPTION(DRIVER_DESC);
 MODULE_LICENSE("GPL and additional rights");
+MODULE_SOFTDEP("pre: amdkfd");
-- 
2.6.6

[Bug 96530] Awesomenauts game in upper left corner when monitor resolution is greater than game resolution

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

--- Comment #1 from Marek OlÅ¡Ã¡k  ---
This can be a game bug. It's definitely not a Mesa bug. Mesa doesn't deal with
resolution changes.

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

[Bug 91969] [radeonsi][bonaire] Stalls with Borderlands 2

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

--- Comment #7 from Marek OlÅ¡Ã¡k  ---
The stalls were reduced a lot in February 2016, but they didn't disappear
completely.

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

[Bug 97119] screen distortion under KDE when running without compositor

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

--- Comment #12 from network723 at rkmail.ru ---
The video resembles kwin bug: https://bugs.kde.org/show_bug.cgi?id=361154 which
was fixed in plasma 5.7.4.

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

[Bug 97119] screen distortion under KDE when running without compositor

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

--- Comment #11 from Johannes Hirte  ---
It seems the flickering is related to the repaint rate of the screen. With
video playback it's more heavy than by typing some text. The faster the typing
is, the heavier the flickering becomes.

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

[Bug 97413] BioShock Infinite crashes on startup with Mesa Git version, R7 370

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

--- Comment #1 from Marek OlÅ¡Ã¡k  ---
The fix was sent to mesa-dev:
"radeonsi: don't use allocas for arrays with LLVM 3.8"

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

[Bug 97119] screen distortion under KDE when running without compositor

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

--- Comment #10 from Johannes Hirte  ---
Created attachment 126033
  --> https://bugs.freedesktop.org/attachment.cgi?id=126033=edit
screencast with flickering

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

[Bug 97119] screen distortion under KDE when running without compositor

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

Johannes Hirte  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|DUPLICATE   |---

--- Comment #9 from Johannes Hirte  ---
Reopening for tracking flickering separately from 97029.

Flickering is happening mostly with amdgpu driver. Sometimes I've observed this
with modesetting too, but I can't trigger it reliable with this driver.

With amdgpu I can trigger this easily by starting a video with mpv and putting
it into fullscreen. Ending the video or the fullscreen mode causes the
flickering around newly created windows. I'll add a screencast how this look
like.

The flickering can be stopped by starting again a video in fullscreen. As long
as the video is on one virtual desktop, everything works like expected. It
doesn't matter if xv, opengl, vdpau or vaapi output is used.

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

[PATCH 8/9] drm: Unify handling of blob and object properties



On 08/18/2016 02:26 AM, Daniel Vetter wrote:
> They work exactly the same now, after the refcounting unification a bit
> ago. The only reason they're distinct is backwards compat with existing
> userspace.
>
> Cc: Daniel Stone 
> Signed-off-by: Daniel Vetter 

Reviewed-by: Archit Taneja 

Archit

> ---
>   drivers/gpu/drm/drm_property.c | 23 +--
>   1 file changed, 5 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
> index 162cc9032ae5..b5521f705b1c 100644
> --- a/drivers/gpu/drm/drm_property.c
> +++ b/drivers/gpu/drm/drm_property.c
> @@ -911,20 +911,8 @@ bool drm_property_change_valid_get(struct drm_property 
> *property,
>   for (i = 0; i < property->num_values; i++)
>   valid_mask |= (1ULL << property->values[i]);
>   return !(value & ~valid_mask);
> - } else if (drm_property_type_is(property, DRM_MODE_PROP_BLOB)) {
> - struct drm_property_blob *blob;
> -
> - if (value == 0)
> - return true;
> -
> - blob = drm_property_lookup_blob(property->dev, value);
> - if (blob) {
> - *ref = >base;
> - return true;
> - } else {
> - return false;
> - }
> - } else if (drm_property_type_is(property, DRM_MODE_PROP_OBJECT)) {
> + } else if (drm_property_type_is(property, DRM_MODE_PROP_BLOB) ||
> +drm_property_type_is(property, DRM_MODE_PROP_OBJECT)) {
>   /* a zero value for an object property translates to null: */
>   if (value == 0)
>   return true;
> @@ -941,13 +929,12 @@ bool drm_property_change_valid_get(struct drm_property 
> *property,
>   }
>
>   void drm_property_change_valid_put(struct drm_property *property,
> - struct drm_mode_object *ref)
> +struct drm_mode_object *ref)
>   {
>   if (!ref)
>   return;
>
> - if (drm_property_type_is(property, DRM_MODE_PROP_OBJECT)) {
> + if (drm_property_type_is(property, DRM_MODE_PROP_OBJECT) ||
> + drm_property_type_is(property, DRM_MODE_PROP_BLOB))
>   drm_mode_object_unreference(ref);
> - } else if (drm_property_type_is(property, DRM_MODE_PROP_BLOB))
> - drm_property_unreference_blob(obj_to_blob(ref));
>   }
>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 5/9] drm/doc: Polish docs for drm_mode_object



On 08/18/2016 02:26 AM, Daniel Vetter wrote:
> I figured an overview section here is overkill, and better
> to just document the 2 structures themselves well enough.
>
> Signed-off-by: Daniel Vetter 
> ---
>   drivers/gpu/drm/drm_mode_object.c |  9 +++
>   include/drm/drm_mode_object.h | 50 
> ---
>   2 files changed, 56 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_mode_object.c 
> b/drivers/gpu/drm/drm_mode_object.c
> index a92aeed51156..a4dd3fa258b4 100644
> --- a/drivers/gpu/drm/drm_mode_object.c
> +++ b/drivers/gpu/drm/drm_mode_object.c
> @@ -222,6 +222,12 @@ EXPORT_SYMBOL(drm_object_attach_property);
>* changes the software state of the property, it does not call into the
>* driver's ->set_property callback.
>*
> + * Note that atomic drivers should not have any need to call this, the core 
> will
> + * ensure consistency of values reported back to userspace through the
> + * appropriate ->atomic_get_property callback. Only legacy drivers should 
> call
> + * this function to update the tracked value (after clamping and other
> + * restrictions have been applied).
> + *
>* Returns:
>* Zero on success, error code on failure.
>*/
> @@ -252,6 +258,9 @@ EXPORT_SYMBOL(drm_object_property_set_value);
>* value this might be out of sync with the hardware, depending upon the 
> driver
>* and property.
>*
> + * Atomic drivers should never call this function directly, the core will 
> read
> + * out property values through the various ->atomic_get_property callbacks.
> + *
>* Returns:
>* Zero on success, error code on failure.
>*/
> diff --git a/include/drm/drm_mode_object.h b/include/drm/drm_mode_object.h
> index b8adb6425f2a..7967ffeda3c4 100644
> --- a/include/drm/drm_mode_object.h
> +++ b/include/drm/drm_mode_object.h
> @@ -27,6 +27,28 @@
>   struct drm_object_properties;
>   struct drm_property;
>
> +/**
> + * struct drm_mode_object - base structure for modeset objecst

s/objecst/object

> + * @id: userspace visible identifier
> + * @type: type of the object, one of DRM_MODE_OBJECT\_\*
> + * @properties: properties attached to this object, including values
> + * @refcount: reference count for objects which with dynamic lifetime
> + * @free_cb: free function callback, only set for objects with dynamic 
> lifetime
> + *
> + * Base structure for modeset objects visible to userspace. Objects can be
> + * looked up using drm_mode_object_find(). Besides basic uapi interface
> + * properties like @id and @type it provides two servies:

s/servies/services

> + *
> + * - It tracks attached properties and their values. This is used by 
> _crtc,
> + *   _plane and _connector. Properties are attached by calling
> + *   drm_object_attach_property() before the object is visible to userspace.
> + *
> + * - For objects with dynamic lifetimes (as indicated by a non-NULL 
> @free_cb) it
> + *   provides reference counting through drm_mode_object_reference() and
> + *   drm_mode_object_unreference(). This is used by _framebuffer,
> + *   _connector and _property_blob. These objects provide specialized
> + *   reference counting wrappers.
> + */
>   struct drm_mode_object {
>   uint32_t id;
>   uint32_t type;
> @@ -36,16 +58,38 @@ struct drm_mode_object {
>   };
>
>   #define DRM_OBJECT_MAX_PROPERTY 24
> +/**
> + * struct drm_object_properties - property tracking for _mode_object
> + */
>   struct drm_object_properties {
> + /**
> +  * @count: number of valid properties, must be less than or equal to
> +  * DRM_OBJECT_MAX_PROPERTY.
> +  */
> +
>   int count;
> - /* NOTE: if we ever start dynamically destroying properties (ie.
> + /**
> +  * @properties: Array of pointers to _property.
> +  *
> +  * NOTE: if we ever start dynamically destroying properties (ie.
>* not at drm_mode_config_cleanup() time), then we'd have to do
>* a better job of detaching property from mode objects to avoid
>* dangling property pointers:
>*/
>   struct drm_property *properties[DRM_OBJECT_MAX_PROPERTY];
> - /* do not read/write values directly, but use 
> drm_object_property_get_value()
> -  * and drm_object_property_set_value():
> +
> + /**
> +  * @values: Array to store the property values, matching @properties. Do
> +  * not read/write values directly, but use
> +  * drm_object_property_get_value() and drm_object_property_set_value().
> +  *
> +  * Note that atomic drivers do not store mutable properties in this
> +  * aray, but only the decoded values in the corresponding state

s/aray/array

Otherwise:

Reviewed-by: Archit Taneja 

Archit

> +  * structure. The decoding is done using the ->atomic_get_property and
> +  * ->atomic_set_property hooks of the corresponding object. Hence atomic
> +  * drivers should not use drm_object_property_set_value() and
> +  * drm_object_property_get_value() on

[PATCH 7/9] drm: Extract drm_property.[hc]



On 08/18/2016 02:26 AM, Daniel Vetter wrote:
> This just contains the base property classes and all the code to
> handle blobs. I think for any kind of standardized/shared properties
> it's better to have separate files - this is fairly big already as-is.
>
> v2: resurrect misplaced hunk (Daniel Stone)
>
> Cc: Daniel Stone 
> Signed-off-by: Daniel Vetter 

checkpatch throws a few errors on usage of spaces instead of tabs,
probably stuff that existed before, but it would be nice to get
rid of them now. Otherwise:

Reviewed-by: Archit Taneja 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 6/9] drm: move drm_mode_legacy_fb_format to drm_fourcc.c



On 08/18/2016 02:26 AM, Daniel Vetter wrote:
> It's part of the drm fourcc handling code, mapping the old depth/bpp
> values to new fourcc codes.

Reviewed-by: Archit Taneja 
>
> Cc: Laurent Pinchart 
> Signed-off-by: Daniel Vetter 
> ---
>   drivers/gpu/drm/drm_crtc.c   | 43 
> ---
>   drivers/gpu/drm/drm_fourcc.c | 43 
> +++
>   include/drm/drm_crtc.h   |  2 --
>   include/drm/drm_fourcc.h |  1 +
>   4 files changed, 44 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index d7f68ec049d1..27b49ad0989b 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1666,49 +1666,6 @@ int drm_mode_cursor2_ioctl(struct drm_device *dev,
>   return drm_mode_cursor_common(dev, req, file_priv);
>   }
>
> -/**
> - * drm_mode_legacy_fb_format - compute drm fourcc code from legacy 
> description
> - * @bpp: bits per pixels
> - * @depth: bit depth per pixel
> - *
> - * Computes a drm fourcc pixel format code for the given @bpp/@depth values.
> - * Useful in fbdev emulation code, since that deals in those values.
> - */
> -uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth)
> -{
> - uint32_t fmt;
> -
> - switch (bpp) {
> - case 8:
> - fmt = DRM_FORMAT_C8;
> - break;
> - case 16:
> - if (depth == 15)
> - fmt = DRM_FORMAT_XRGB1555;
> - else
> - fmt = DRM_FORMAT_RGB565;
> - break;
> - case 24:
> - fmt = DRM_FORMAT_RGB888;
> - break;
> - case 32:
> - if (depth == 24)
> - fmt = DRM_FORMAT_XRGB;
> - else if (depth == 30)
> - fmt = DRM_FORMAT_XRGB2101010;
> - else
> - fmt = DRM_FORMAT_ARGB;
> - break;
> - default:
> - DRM_ERROR("bad bpp, assuming x8r8g8b8 pixel format\n");
> - fmt = DRM_FORMAT_XRGB;
> - break;
> - }
> -
> - return fmt;
> -}
> -EXPORT_SYMBOL(drm_mode_legacy_fb_format);
> -
>   static bool drm_property_type_valid(struct drm_property *property)
>   {
>   if (property->flags & DRM_MODE_PROP_EXTENDED_TYPE)
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index c81546c15c93..29c56b4331e0 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -36,6 +36,49 @@ static char printable_char(int c)
>   }
>
>   /**
> + * drm_mode_legacy_fb_format - compute drm fourcc code from legacy 
> description
> + * @bpp: bits per pixels
> + * @depth: bit depth per pixel
> + *
> + * Computes a drm fourcc pixel format code for the given @bpp/@depth values.
> + * Useful in fbdev emulation code, since that deals in those values.
> + */
> +uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth)
> +{
> + uint32_t fmt;
> +
> + switch (bpp) {
> + case 8:
> + fmt = DRM_FORMAT_C8;
> + break;
> + case 16:
> + if (depth == 15)
> + fmt = DRM_FORMAT_XRGB1555;
> + else
> + fmt = DRM_FORMAT_RGB565;
> + break;
> + case 24:
> + fmt = DRM_FORMAT_RGB888;
> + break;
> + case 32:
> + if (depth == 24)
> + fmt = DRM_FORMAT_XRGB;
> + else if (depth == 30)
> + fmt = DRM_FORMAT_XRGB2101010;
> + else
> + fmt = DRM_FORMAT_ARGB;
> + break;
> + default:
> + DRM_ERROR("bad bpp, assuming x8r8g8b8 pixel format\n");
> + fmt = DRM_FORMAT_XRGB;
> + break;
> + }
> +
> + return fmt;
> +}
> +EXPORT_SYMBOL(drm_mode_legacy_fb_format);
> +
> +/**
>* drm_get_format_name - return a string for drm fourcc format
>* @format: format to compute name of
>*
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 1abcc182e92b..f5e51e5e9724 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -2135,8 +2135,6 @@ extern int drm_mode_crtc_set_gamma_size(struct drm_crtc 
> *crtc,
>
>   extern int drm_mode_set_config_internal(struct drm_mode_set *set);
>
> -extern uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth);
> -
>   extern struct drm_tile_group *drm_mode_create_tile_group(struct drm_device 
> *dev,
>char topology[8]);
>   extern struct drm_tile_group *drm_mode_get_tile_group(struct drm_device 
> *dev,
> diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
> index b106337de1bf..30c30fa87ee8 100644
> --- a/include/drm/drm_fourcc.h
> +++ b/include/drm/drm_fourcc.h
> @@ -25,6 +25,7 @@
>   #include 
>   #include 
>
> +uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth);
>

[PATCH 3/9] drm: Extract drm_mode_object.[hc]



On 08/18/2016 02:26 AM, Daniel Vetter wrote:
> Just for the struct drm_mode_object base class. The header file was
> already partially extracted to help untangle the include loops.
>
> v2:
> - Also move the generic get/set property ioctls. At first this seemed
>like a bad idea since it requires making drm_mode_crtc_set_obj_prop
>non-static. But eventually that will get split away too (like
>the connector version already is) for both crtc and planes. Hence I
>reconsidered.
>
> - drm_mode_object.[hc] instead of drm_modeset.[hc], which requires
>renaming the drm_modeset.h header I already started building up.
>This is more consistent (matches the name of the main structure),
>and I want to be able to use drm_modeset.[hc] for the basic modeset
>init/cleanup functionality like drm_mode_config_init.
>
> Signed-off-by: Daniel Vetter 
> ---
>   Documentation/gpu/drm-kms.rst   |   9 +
>   drivers/gpu/drm/Makefile|   2 +-
>   drivers/gpu/drm/drm_crtc.c  | 413 +-
>   drivers/gpu/drm/drm_crtc_internal.h |  52 +++--
>   drivers/gpu/drm/drm_mode_object.c   | 435 
> 
>   include/drm/drm_connector.h |   2 +-
>   include/drm/drm_crtc.h  |  12 +-
>   include/drm/drm_encoder.h   |   2 +-
>   include/drm/drm_framebuffer.h   |   2 +-
>   include/drm/drm_mode_object.h   |  80 +++
>   include/drm/drm_modes.h |   2 +-
>   include/drm/drm_modeset.h   |  70 --
>   12 files changed, 562 insertions(+), 519 deletions(-)
>   create mode 100644 drivers/gpu/drm/drm_mode_object.c
>   create mode 100644 include/drm/drm_mode_object.h
>   delete mode 100644 include/drm/drm_modeset.h
>
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 47c2835b7c2d..b164472f2157 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -15,6 +15,15 @@ be setup by initializing the following fields.
>   -  struct drm_mode_config_funcs \*funcs;
>  Mode setting functions.
>
> +Modeset Base Object Abstraction
> +===
> +
> +.. kernel-doc:: include/drm/drm_mode_object.h
> +   :internal:
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_mode_object.c
> +   :export:
> +
>   KMS Data Structures
>   ===
>
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index efdb4176230f..59979f3f3648 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -14,7 +14,7 @@ drm-y   :=  drm_auth.o drm_bufs.o drm_cache.o \
>   drm_rect.o drm_vma_manager.o drm_flip_work.o \
>   drm_modeset_lock.o drm_atomic.o drm_bridge.o \
>   drm_framebuffer.o drm_connector.o drm_blend.o \
> - drm_encoder.o
> + drm_encoder.o drm_mode_object.o
>
>   drm-$(CONFIG_COMPAT) += drm_ioc32.o
>   drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index f89711b16d3e..d7f68ec049d1 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -57,162 +57,6 @@ static const struct drm_prop_enum_list 
> drm_plane_type_enum_list[] = {
>   /*
>* Optional properties
>*/
> -/*
> - * Internal function to assign a slot in the object idr and optionally
> - * register the object into the idr.
> - */
> -int drm_mode_object_get_reg(struct drm_device *dev,
> - struct drm_mode_object *obj,
> - uint32_t obj_type,
> - bool register_obj,
> - void (*obj_free_cb)(struct kref *kref))
> -{
> - int ret;
> -
> - mutex_lock(>mode_config.idr_mutex);
> - ret = idr_alloc(>mode_config.crtc_idr, register_obj ? obj : NULL, 
> 1, 0, GFP_KERNEL);
> - if (ret >= 0) {
> - /*
> -  * Set up the object linking under the protection of the idr
> -  * lock so that other users can't see inconsistent state.
> -  */
> - obj->id = ret;
> - obj->type = obj_type;
> - if (obj_free_cb) {
> - obj->free_cb = obj_free_cb;
> - kref_init(>refcount);
> - }
> - }
> - mutex_unlock(>mode_config.idr_mutex);
> -
> - return ret < 0 ? ret : 0;
> -}
> -
> -/**
> - * drm_mode_object_get - allocate a new modeset identifier
> - * @dev: DRM device
> - * @obj: object pointer, used to generate unique ID
> - * @obj_type: object type
> - *
> - * Create a unique identifier based on @ptr in @dev's identifier space.  Used
> - * for tracking modes, CRTCs and connectors. Note that despite the _get 
> postfix
> - * modeset identifiers are _not_ reference counted. Hence don't use this for
> - * reference counted modeset objects like framebuffers.
> - *
> - * Returns:
> - * Zero on success, error code on failure.
> - */
> -int

[PATCH 4/9] drm: Remove drm_mode_object->atomic_count



On 08/18/2016 02:26 AM, Daniel Vetter wrote:
> It's only used in drm_mode_object_get_properties, and we can compute
> it there directly with a bit of code shuffling.
>

Reviewed-by: Archit Taneja 

> Signed-off-by: Daniel Vetter 
> ---
>   drivers/gpu/drm/drm_mode_object.c | 31 ---
>   include/drm/drm_mode_object.h |  2 +-
>   2 files changed, 13 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_mode_object.c 
> b/drivers/gpu/drm/drm_mode_object.c
> index cef9104e8285..a92aeed51156 100644
> --- a/drivers/gpu/drm/drm_mode_object.c
> +++ b/drivers/gpu/drm/drm_mode_object.c
> @@ -209,8 +209,6 @@ void drm_object_attach_property(struct drm_mode_object 
> *obj,
>   obj->properties->properties[count] = property;
>   obj->properties->values[count] = init_val;
>   obj->properties->count++;
> - if (property->flags & DRM_MODE_PROP_ATOMIC)
> - obj->properties->atomic_count++;
>   }
>   EXPORT_SYMBOL(drm_object_attach_property);
>
> @@ -288,35 +286,30 @@ int drm_mode_object_get_properties(struct 
> drm_mode_object *obj, bool atomic,
>  uint64_t __user *prop_values,
>  uint32_t *arg_count_props)
>   {
> - int props_count;
> - int i, ret, copied;
> + int i, ret, count;
>
> - props_count = obj->properties->count;
> - if (!atomic)
> - props_count -= obj->properties->atomic_count;
> + for (i = 0, count = 0; i < obj->properties->count; i++) {
> + struct drm_property *prop = obj->properties->properties[i];
> + uint64_t val;
>
> - if ((*arg_count_props >= props_count) && props_count) {
> - for (i = 0, copied = 0; copied < props_count; i++) {
> - struct drm_property *prop = 
> obj->properties->properties[i];
> - uint64_t val;
> -
> - if ((prop->flags & DRM_MODE_PROP_ATOMIC) && !atomic)
> - continue;
> + if ((prop->flags & DRM_MODE_PROP_ATOMIC) && !atomic)
> + continue;
>
> + if (*arg_count_props > count) {
>   ret = drm_object_property_get_value(obj, prop, );
>   if (ret)
>   return ret;
>
> - if (put_user(prop->base.id, prop_ptr + copied))
> + if (put_user(prop->base.id, prop_ptr + count))
>   return -EFAULT;
>
> - if (put_user(val, prop_values + copied))
> + if (put_user(val, prop_values + count))
>   return -EFAULT;
> -
> - copied++;
>   }
> +
> + count++;
>   }
> - *arg_count_props = props_count;
> + *arg_count_props = count;
>
>   return 0;
>   }
> diff --git a/include/drm/drm_mode_object.h b/include/drm/drm_mode_object.h
> index c0e4414299f7..b8adb6425f2a 100644
> --- a/include/drm/drm_mode_object.h
> +++ b/include/drm/drm_mode_object.h
> @@ -37,7 +37,7 @@ struct drm_mode_object {
>
>   #define DRM_OBJECT_MAX_PROPERTY 24
>   struct drm_object_properties {
> - int count, atomic_count;
> + int count;
>   /* NOTE: if we ever start dynamically destroying properties (ie.
>* not at drm_mode_config_cleanup() time), then we'd have to do
>* a better job of detaching property from mode objects to avoid
>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 2/9] drm/doc: Polish kerneldoc for encoders



On 08/18/2016 02:25 AM, Daniel Vetter wrote:
> - Move missing bits into struct drm_encoder docs.
> - Explain that encoders are 95% internal and only 5% uapi, and that in
>general the uapi part is broken.
> - Remove verbose comments for functions not exposed to drivers.
>
> Signed-off-by: Daniel Vetter 
> ---
>   Documentation/gpu/drm-kms.rst | 46 --
>   drivers/gpu/drm/drm_encoder.c | 41 +--
>   include/drm/drm_encoder.h | 65 
> ---
>   3 files changed, 93 insertions(+), 59 deletions(-)
>
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 7f788caebea3..47c2835b7c2d 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -128,6 +128,12 @@ Connector Functions Reference
>   Encoder Abstraction
>   ===
>
> +.. kernel-doc:: drivers/gpu/drm/drm_encoder.c
> +   :doc: overview
> +
> +Encoder Functions Reference
> +---
> +
>   .. kernel-doc:: include/drm/drm_encoder.h
>  :internal:
>
> @@ -207,46 +213,6 @@ future); drivers that do not wish to provide special 
> handling for
>   primary planes may make use of the helper functions described in ? to
>   create and register a primary plane with standard capabilities.
>
> -Encoders (:c:type:`struct drm_encoder `)
> --
> -
> -An encoder takes pixel data from a CRTC and converts it to a format
> -suitable for any attached connectors. On some devices, it may be
> -possible to have a CRTC send data to more than one encoder. In that
> -case, both encoders would receive data from the same scanout buffer,
> -resulting in a "cloned" display configuration across the connectors
> -attached to each encoder.
> -
> -Encoder Initialization
> -~~
> -
> -As for CRTCs, a KMS driver must create, initialize and register at least
> -one :c:type:`struct drm_encoder ` instance. The
> -instance is allocated and zeroed by the driver, possibly as part of a
> -larger structure.
> -
> -Drivers must initialize the :c:type:`struct drm_encoder
> -` possible_crtcs and possible_clones fields before
> -registering the encoder. Both fields are bitmasks of respectively the
> -CRTCs that the encoder can be connected to, and sibling encoders
> -candidate for cloning.
> -
> -After being initialized, the encoder must be registered with a call to
> -:c:func:`drm_encoder_init()`. The function takes a pointer to the
> -encoder functions and an encoder type. Supported types are
> -
> --  DRM_MODE_ENCODER_DAC for VGA and analog on DVI-I/DVI-A
> --  DRM_MODE_ENCODER_TMDS for DVI, HDMI and (embedded) DisplayPort
> --  DRM_MODE_ENCODER_LVDS for display panels
> --  DRM_MODE_ENCODER_TVDAC for TV output (Composite, S-Video,
> -   Component, SCART)
> --  DRM_MODE_ENCODER_VIRTUAL for virtual machine displays
> -
> -Encoders must be attached to a CRTC to be used. DRM drivers leave
> -encoders unattached at initialization time. Applications (or the fbdev
> -compatibility layer when implemented) are responsible for attaching the
> -encoders they want to use to a CRTC.
> -
>   Cleanup
>   ---
>
> diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
> index bce781b7bb5f..977d8cad9321 100644
> --- a/drivers/gpu/drm/drm_encoder.c
> +++ b/drivers/gpu/drm/drm_encoder.c
> @@ -26,6 +26,29 @@
>
>   #include "drm_crtc_internal.h"
>
> +/**
> + * DOC: overview
> + *
> + * Encoders represent the connecting element between the CRTC (as the overall
> + * pixel pipeline, represented by struct _crtc) and the connectors (as 
> the
> + * generic sink entity, represented by struct _connector). Encoders are
> + * objects exposed to userspace, originally to allow userspace to infer 
> cloning
> + * and connector/CRTC restrictions. Unfortunately almost all drivers get this
> + * wrong, making the uabi pretty much useless. On top of that the exposed
> + * restrictions are too simple for todays hardware, and the recommend way to
> + * infer restrictions is by using the DRM_MODE_ATOMIC_TEST_ONLY flag for the
> + * atomic IOCTL.
> + *
> + * Otherwise encoders aren't used in the uapi at all (any modeset request 
> from
> + * userspace directly connects a connector with a CRTC), drivers are 
> therefore
> + * free to use them however they wish. Modeset helper libraries make strong 
> use
> + * of encoders to facilitate code sharing. But for more complex settings it 
> is
> + * usually better to move shared code into a separate _bridge, which also
> + * doesn't have any issues with being exposed to userspace.

I guess the last line could say that the drm_bridge isn't exposed to
userspace at all.

> + *
> + * Encoders are initialized with drm_encoder_init() and cleaned up using
> + * drm_encoder_cleanup().
> + */
>   static const struct drm_prop_enum_list drm_encoder_enum_list[] = {
>   { DRM_MODE_ENCODER_NONE, "None" },
>   {

[PATCH 1/9] drm: Extract drm_encoder.[hc]


Hi,

On 08/18/2016 02:25 AM, Daniel Vetter wrote:
> Same treatment as before. Only hiccup is drm_crtc_mask, which
> unfortunately can't be resolved until drm_crtc.h is less of a monster.
> Untangle the header loop with a forward delcaration for that static

s/delcaration/declaration

> inline.
>
> Signed-off-by: Daniel Vetter 
> ---
>   Documentation/gpu/drm-kms.rst   |   9 ++
>   drivers/gpu/drm/Makefile|   3 +-
>   drivers/gpu/drm/drm_crtc.c  | 193 ---
>   drivers/gpu/drm/drm_crtc_internal.h |  10 +-
>   drivers/gpu/drm/drm_encoder.c   | 220 
> 
>   include/drm/drm_crtc.h  | 134 +-
>   include/drm/drm_encoder.h   | 167 +++
>   7 files changed, 407 insertions(+), 329 deletions(-)
>   create mode 100644 drivers/gpu/drm/drm_encoder.c
>   create mode 100644 include/drm/drm_encoder.h
>



> +
> +/**
> + * drm_encoder_init - Init a preallocated encoder
> + * @dev: drm device
> + * @encoder: the encoder to init
> + * @funcs: callbacks for this encoder
> + * @encoder_type: user visible type of the encoder
> + * @name: printf style format string for the encoder name, or NULL for 
> default name
> + *
> + * Initialises a preallocated encoder. Encoder should be
> + * subclassed as part of driver encoder objects.
> + *
> + * Returns:
> + * Zero on success, error code on failure.
> + */
> +int drm_encoder_init(struct drm_device *dev,
> +   struct drm_encoder *encoder,
> +   const struct drm_encoder_funcs *funcs,
> +   int encoder_type, const char *name, ...)

Alignment with the open parentheses is needed here.

> +{
> + int ret;
> +
> + drm_modeset_lock_all(dev);
> +
> + ret = drm_mode_object_get(dev, >base, DRM_MODE_OBJECT_ENCODER);
> + if (ret)
> + goto out_unlock;
> +
> + encoder->dev = dev;
> + encoder->encoder_type = encoder_type;
> + encoder->funcs = funcs;
> + if (name) {
> + va_list ap;
> +
> + va_start(ap, name);
> + encoder->name = kvasprintf(GFP_KERNEL, name, ap);
> + va_end(ap);
> + } else {
> + encoder->name = kasprintf(GFP_KERNEL, "%s-%d",
> +   
> drm_encoder_enum_list[encoder_type].name,
> +   encoder->base.id);
> + }
> + if (!encoder->name) {
> + ret = -ENOMEM;
> + goto out_put;
> + }
> +
> + list_add_tail(>head, >mode_config.encoder_list);
> + encoder->index = dev->mode_config.num_encoder++;
> +
> +out_put:
> + if (ret)
> + drm_mode_object_unregister(dev, >base);
> +
> +out_unlock:
> + drm_modeset_unlock_all(dev);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(drm_encoder_init);
> +
> +/**
> + * drm_encoder_cleanup - cleans up an initialised encoder
> + * @encoder: encoder to cleanup
> + *
> + * Cleans up the encoder but doesn't free the object.
> + */
> +void drm_encoder_cleanup(struct drm_encoder *encoder)
> +{
> + struct drm_device *dev = encoder->dev;
> +
> + /* Note that the encoder_list is considered to be static; should we
> +  * remove the drm_encoder at runtime we would have to decrement all
> +  * the indices on the drm_encoder after us in the encoder_list.
> +  */
> +
> + drm_modeset_lock_all(dev);
> + drm_mode_object_unregister(dev, >base);
> + kfree(encoder->name);
> + list_del(>head);
> + dev->mode_config.num_encoder--;
> + drm_modeset_unlock_all(dev);
> +
> + memset(encoder, 0, sizeof(*encoder));
> +}
> +EXPORT_SYMBOL(drm_encoder_cleanup);
> +
> +static struct drm_crtc *drm_encoder_get_crtc(struct drm_encoder *encoder)
> +{
> + struct drm_connector *connector;
> + struct drm_device *dev = encoder->dev;
> + bool uses_atomic = false;
> +
> + /* For atomic drivers only state objects are synchronously updated and
> +  * protected by modeset locks, so check those first. */
> + drm_for_each_connector(connector, dev) {
> + if (!connector->state)
> + continue;
> +
> + uses_atomic = true;
> +
> + if (connector->state->best_encoder != encoder)
> + continue;
> +
> + return connector->state->crtc;
> + }
> +
> + /* Don't return stale data (e.g. pending async disable). */
> + if (uses_atomic)
> + return NULL;
> +
> + return encoder->crtc;
> +}
> +
> +/**
> + * drm_mode_getencoder - get encoder configuration
> + * @dev: drm device for the ioctl
> + * @data: data pointer for the ioctl
> + * @file_priv: drm file for the ioctl call
> + *
> + * Construct a encoder configuration structure to return to the user.
> + *
> + * Called by the user via ioctl.
> + *
> + * Returns:
> + * Zero on success, negative errno on failure.
> + */
> +int drm_mode_getencoder(struct drm_device *dev,

I want to use VA-API to support new platform, I want know something about Intel implementation

2016-08-25 Thread Randy Li


On 08/24/2016 11:35 PM, Xiang, Haihao wrote:
>
>
>> -Original Message-
>> From: Randy Li [mailto:randy.li at rock-chips.com]
>> Sent: Wednesday, August 24, 2016 6:30 PM
>> To: Xiang, Haihao ; libva at lists.freedesktop.org
>> Cc: nicolas.dufresne at collabora.co.uk; Balachandran, Sreerenj
>> 
>> Subject: Re: I want to use VA-API to support new platform, I want know
>> something about Intel implementation
>>
>>
>>
>> On 08/18/2016 10:31 AM, Xiang, Haihao wrote:
>>>
>>> Hi Randy,
>>>
>>> You can get lots of information / docs via internet. You may search for
>>> dri, libdrm, drm, gem, i915 etc.
>>>
>>> dri wiki
>>> https://dri.freedesktop.org/wiki/
>>>
>>> drm:
>>> https://en.wikipedia.org/wiki/Direct_Rendering_Manager
>>>
>>> libdrm:
>>> https://01.org/linuxgraphics/community/libdrm
>>>
>>> intel graphics kernel
>>> https://01.org/linuxgraphics/community/kernel
>> I have read the documents you offered to me, I have a basic view of them
>> and the relationship of them.
>>
>> But I want to know more about the detail of Intel implementation.I have
>> read the Intel driver of VA-API before, I think the Intel video process
>> video in this way.
>> 1. Allocate the DRI buffer from the kernel driver using the libdrm.
>
> It is a GEM buffer object in intel driver.
>
>> 2. Intel DRM driver in kernel would allocate buffer throught the GEM.
>> 3. Intel VA-API driver push the codec data and parameters to those buffers
>
> And setup the corresponding pipeline in a batch buffer which is also a gem 
> buffer object and submit this batch buffer
> to i915 driver  via libdrm.  The batch buffer will be chained into a ring 
> buffer via MI_BATCH_BUFFER_START command
> for execution.
It seems that it is only used by MFC(video encoder)?
I saw the MFD use MFX_IND_OBJ_BASE_ADDR_STATE followed with the  
OUT_BCS_RELOC which would render the slice data into MFD?
You can refer to 
https://01.org/linuxgraphics/documentation/hardware-specification-prms 
(Programmer's
> Reference Manuals) for how do ring buffer and batch buffer work.
Intel implementation is really really complex to me.
But After a quick read and read volume 8 deeply, I know that the MFX 
doesn't based on register at all. So you need to push and MFC codec 
commands and those decoding information to VCS, the VCS would decide and 
parse how to execute those data. Is that right?

Our rockchip would still use the registers on a video IP to store the 
decoder settings for the picture to be process, we may not choose the 
same implementation, but I could still map the register
range to the memory, using a buffer to set them at the same time.

Anyway, that explains why I didn't see any register about video codec
in Linux kernel DRM driver, becuase Intel MFX is not based on it. The
Intel driver at kernel just need the allocate and manage the buffer for 
the VCS, then most of work could be move to libdrm and VA-API driver.
That is really great for stateless video processor.
>
>> 4. Got result from DRI buffer.
>>
>> Is it correct ?
>>
>> If it is correct, does it mean that the registers(used for configure
>> decoding parameters) at Intel video processing unit would be mapped as
>> PRIME buffers to be used in DRI?
>> And where is the kernel driver do that ? I know it is easy to find the
>> DRM driver in linux kernel in drivers/gpu/drm/i915/ , but which file is
>> doing the job for video processing part? They looks like the graphics
>> to me. I think different Intel platform generation would have a
>> different registers.
>>
>>>
>>> Hope it can help you.
>>>
>>> Thanks
>>> Haihao
>>>
>>>
 Hi all
I am using VA-API to support the Video Process Unit in a ARM
 platform, but it didn't use the standard kernel interface. Without
 the
 help of DRI, I can't implement something like vaDeriveImage() leading
 a lose in performance.
I read the Intel driver, it looks the Intel driver could access
 the
 the Memory of Video Unit of Intel Graphics card through the libdrm.
 If that is right, could somebody told me how does it implemented in
 linux kernel(which files?).
 And I am really newbies to this area(DRI), could somebody give me
 guide and documents about this?
Thank you all very much.
>>
>> Thank you so much.
>> --
>> Randy Li
>> The third produce department
>
Thank you for help, it is really a great work what Intel have done.
-- 
Randy Li
The third produce department

[RFC 0/2] New feature: Framebuffer processors

2016-08-25 Thread Inki Dae



2016ë 08ì 24ì¼ 20:57ì Daniel Vetter ì´(ê°) ì´ ê¸:
> On Wed, Aug 24, 2016 at 08:44:24PM +0900, Inki Dae wrote:
>> Hi,
>>
>> 2016ë 08ì 23ì¼ 18:41ì Daniel Stone ì´(ê°) ì´ ê¸:
>>> Hi,
>>>
>>> On 22 August 2016 at 16:23, Rob Clark  wrote:
 I guess a lot comes down to 'how long before hw designers bolt a CP to
 the thing'..  at that point, I think you especially don't want a
 per-blit kernel interface.
>>>
>>> Regardless of whether or not we want it, we already _have_ it, in the
>>> form of V4L2 M2M. There are already a few IP blocks working on that, I
>>> believe. If V4L2 <-> KMS interop is painful, well, we need to fix that
>>> anyway ...
>>
>> So we are trying this. We had expereneced using V4L2 and DRM together on
>> Linux Platform makes it too complicated, and also integrated DRM with
>> M2M such as 2D and Post processor makes it simplified.  So We have been
>> trying to move existing V4L2 based drivers into DRM excepting HW Video
>> Codec - called it MFC - and Camera sensor and relevant things.
>> I think now V4L2 and DRM frameworks may make many engineers confusing
>> because there are the same devices which can be controlled by V4L2 and
>> DRM frameworks - maybe we would need more efforts like Laurent did with
>> Live source[1] in the future.
> 
> Can you pls explain in more detail where working with both v4l and drm
> drivers and making them cooperate using dma-bufs poses problems? We should
> definitely fix that.

I think it would be most Linux Platforms - Android, Chrome and Tizen - which 
would use OpenMAX/GStreammer for Multimedia and X or Wayland/SurfaceFlinger for 
Display.

Thanks,
Inki Dae

> -Daniel
>

[PATCH v2] drm: reduce GETCLIENT to a minimum

On Thu, Aug 25, 2016 at 04:35:05PM +0200, David Herrmann wrote:
> The *only* known user of GETCLIENT is libva, which uses it to check
> whether its own context is authenticated. It used to iterate all clients,
> look for one that matches its own pid and then check its state.
> 
> The entire purpose for us to still have a GETCLIENT implementation is to
> serve libva. So lets not pretend we do anything else: Make this function
> return information on the caller's context only, fake the PID to the
> caller's pid so they always match, and just fill in the "authenticated"
> bit, nothing else.
> 
> This patch reduces the complexity of GETCLIENT to a bare minimum, avoids
> any dependency on priv->uid or priv->pid (allows us to get rid of them),
> and makes libva happy by always *exactly* returning the information it
> wants.
> 
> Signed-off-by: David Herrmann 
> ---
> v2: Just re-order the series and send individual patches, since they do
> not depend on each other.
> 
>  drivers/gpu/drm/drm_ioctl.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index 33af4a5..bc5c65e 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -189,9 +189,8 @@ static int drm_getclient(struct drm_device *dev, void 
> *data,
>*/
>   if (client->idx == 0) {
>   client->auth = file_priv->authenticated;
> - client->pid = pid_vnr(file_priv->pid);
> - client->uid = from_kuid_munged(current_user_ns(),
> -file_priv->uid);
> + client->pid = task_pid_vnr(current);
> + client->uid = overflowuid;
>   client->magic = 0;
>   client->iocs = 0;

Merged to drm-misc, thanks.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm: drop obsolete drm_core.h

2016-08-25 Thread David Herrmann

The drm_core.h header contains a set of constants meant to be used
throughout DRM. However, as it turns out, they're each used just once and
don't bring any benefit. They're also grossly mis-named and lack
name-spacing. This patch inlines them, or moves them into drm_internal.h
as appropriate:

 - CORE_AUTHOR and CORE_DESC are inlined into corresponding MODULE_*()
   macros. It's just confusing having to follow 2 pointers when trying to
   find the definition of these fields. Grep'ping for MODULE_AUTHOR()
   should reveal the full information, if there's no strong reason not to.

 - CORE_NAME, CORE_DATE, CORE_MAJOR, CORE_MINOR, and CORE_PATCHLEVEL are
   inlined into the sysfs 'version' attribute. They're stripped
   everywhere else (which is just some printk() statements). CORE_NAME
   just doesn't make *any* sense, as we hard-code it in many places,
   anyway. The other constants are outdated and just serve
   binary-compatibility purposes. Hence, inline them in 'version' sysfs
   attribute (we might even try dropping it..).

 - DRM_IF_MAJOR and DRM_IF_MINOR are moved into drm_internal.h as they're
   only used by the global ioctl handlers. Furthermore, versioning
   interfaces breaks backports and as such is deprecated, anyway. We just
   keep them for historic reasons. I doubt anyone will ever modify them
   again.

Signed-off-by: David Herrmann 
---
 drivers/gpu/drm/drm_drv.c  |  8 +++-
 drivers/gpu/drm/drm_internal.h |  3 +++
 drivers/gpu/drm/drm_ioc32.c|  1 -
 drivers/gpu/drm/drm_ioctl.c|  1 -
 drivers/gpu/drm/drm_sysfs.c|  8 +---
 include/drm/drm_core.h | 34 --
 6 files changed, 7 insertions(+), 48 deletions(-)
 delete mode 100644 include/drm/drm_core.h

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 9ab0016..d771453 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -33,7 +33,6 @@
 #include 
 #include 
 #include 
-#include 
 #include "drm_crtc_internal.h"
 #include "drm_legacy.h"
 #include "drm_internal.h"
@@ -46,8 +45,8 @@
 unsigned int drm_debug = 0;
 EXPORT_SYMBOL(drm_debug);

-MODULE_AUTHOR(CORE_AUTHOR);
-MODULE_DESCRIPTION(CORE_DESC);
+MODULE_AUTHOR("Gareth Hughes, Leif Delgass, JosÃ© Fonseca, Jon Smirl");
+MODULE_DESCRIPTION("DRM shared core routines");
 MODULE_LICENSE("GPL and additional rights");
 MODULE_PARM_DESC(debug, "Enable debug output, where each bit enables a debug 
category.\n"
 "\t\tBit 0 (0x01) will enable CORE messages (drm core code)\n"
@@ -966,8 +965,7 @@ static int __init drm_core_init(void)
goto err_p3;
}

-   DRM_INFO("Initialized %s %d.%d.%d %s\n",
-CORE_NAME, CORE_MAJOR, CORE_MINOR, CORE_PATCHLEVEL, CORE_DATE);
+   DRM_INFO("Initialized\n");
return 0;
 err_p3:
drm_sysfs_destroy();
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 9b66cc4..3d6a587 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -21,6 +21,9 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  */

+#define DRM_IF_MAJOR 1
+#define DRM_IF_MINOR 4
+
 /* drm_irq.c */
 extern unsigned int drm_timestamp_monotonic;

diff --git a/drivers/gpu/drm/drm_ioc32.c b/drivers/gpu/drm/drm_ioc32.c
index 57676f8..2795d6a 100644
--- a/drivers/gpu/drm/drm_ioc32.c
+++ b/drivers/gpu/drm/drm_ioc32.c
@@ -32,7 +32,6 @@
 #include 

 #include 
-#include 

 #define DRM_IOCTL_VERSION32DRM_IOWR(0x00, drm_version32_t)
 #define DRM_IOCTL_GET_UNIQUE32 DRM_IOWR(0x01, drm_unique32_t)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index bc5c65e..845390f 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -29,7 +29,6 @@
  */

 #include 
-#include 
 #include 
 #include "drm_legacy.h"
 #include "drm_internal.h"
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 32dd821..9a37196 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -19,7 +19,6 @@
 #include 

 #include 
-#include 
 #include 
 #include "drm_internal.h"

@@ -37,12 +36,7 @@ static char *drm_devnode(struct device *dev, umode_t *mode)
return kasprintf(GFP_KERNEL, "dri/%s", dev_name(dev));
 }

-static CLASS_ATTR_STRING(version, S_IRUGO,
-   CORE_NAME " "
-   __stringify(CORE_MAJOR) "."
-   __stringify(CORE_MINOR) "."
-   __stringify(CORE_PATCHLEVEL) " "
-   CORE_DATE);
+static CLASS_ATTR_STRING(version, S_IRUGO, "drm 1.1.0 20060810");

 /**
  * drm_sysfs_init - initialize sysfs helpers
diff --git a/include/drm/drm_core.h b/include/drm/drm_core.h
deleted file mode 100644
index 4e75238..000
--- a/include/drm/drm_core.h
+++ /dev/null
@@ -1,34 +0,0 @@
-/*
- * Copyright 2004 Jon Smirl 
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software

[PATCH v2] drm: reduce GETCLIENT to a minimum

2016-08-25 Thread David Herrmann

The *only* known user of GETCLIENT is libva, which uses it to check
whether its own context is authenticated. It used to iterate all clients,
look for one that matches its own pid and then check its state.

The entire purpose for us to still have a GETCLIENT implementation is to
serve libva. So lets not pretend we do anything else: Make this function
return information on the caller's context only, fake the PID to the
caller's pid so they always match, and just fill in the "authenticated"
bit, nothing else.

This patch reduces the complexity of GETCLIENT to a bare minimum, avoids
any dependency on priv->uid or priv->pid (allows us to get rid of them),
and makes libva happy by always *exactly* returning the information it
wants.

Signed-off-by: David Herrmann 
---
v2: Just re-order the series and send individual patches, since they do
not depend on each other.

 drivers/gpu/drm/drm_ioctl.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 33af4a5..bc5c65e 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -189,9 +189,8 @@ static int drm_getclient(struct drm_device *dev, void *data,
 */
if (client->idx == 0) {
client->auth = file_priv->authenticated;
-   client->pid = pid_vnr(file_priv->pid);
-   client->uid = from_kuid_munged(current_user_ns(),
-  file_priv->uid);
+   client->pid = task_pid_vnr(current);
+   client->uid = overflowuid;
client->magic = 0;
client->iocs = 0;

-- 
2.9.3

[Bug 96398] [radeonsi tessellation] Single-pixel rasterization issue (Shadow of Mordor)

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

Jan Ziak <0xe2.0x9a.0x9b at gmail.com> changed:

   What|Removed |Added

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

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

[PATCH 2/2] drm: make DRI1 drivers depend on BROKEN

2016-08-25 Thread Emil Velikov

On 25 August 2016 at 12:14, Daniel Vetter  wrote:
> On Thu, Aug 04, 2016 at 09:15:07AM +0100, Chris Wilson wrote:
>> On Thu, Aug 04, 2016 at 10:06:57AM +0200, David Herrmann wrote:
>> > The legacy DRI1 drivers expose highly broken interfaces to user-space. No
>> > modern system should enable them, or you will effectively allow user-space
>> > to circumvent most of your kernel security measures. The DRI1 kernel APIs
>> > are simply broken.
>> >
>> > User-space can always use vesafb/efifb/simplefb and friends to get working
>> > graphics.
>> >
>> > Lets hide the old drivers behind CONFIG_BROKEN. In case they turn out to
>> > be still used (really?), we can easily revert this and figure out a way to
>> > move them out of sight (e.g., moving all DRI1 drivers to
>> > drivers/gpu/dri1/).
>> >
>> > Signed-off-by: David Herrmann 
>>
>> Acked-by: Chris Wilson 
>>
>> I'd rather have a couple of distro devs check if they are still using
>> any of these, and would value their a-b/r-b.
>
> Mesa stopped shipping dri1 drivers years ago, and neither Fedora and
> Debian here have that old version packaged (it should keep working since
> the dri loader is an ABI). I don't think anyone needs this, and if I'm
> wrong we'll hear about it ;-)
>
Archlinux (which seems to be picking more users) is still shipping
dri1 drivers - both mesa and X. No idea for many actually use those
and/or for how much longer the packages will be around.

IIRC the maintainer, Connor, used to hack on the xf86-video-r128 with
plans(?) on getting things KMS aware. Not sure if that was by
extending the existing radeon kernel, ddx, mesa driver(s) or
otherwise.
Connor, can you shed some light ?

-Emil

[PATCH v3] drm/bridge: analogix_dp: Remove duplicated code

2016-08-25 Thread Yakir Yang

On 08/24/2016 10:54 PM, Sean Paul wrote:
> From: Tomeu Vizoso
>
> Remove code for reading the EDID and DPCD fields and use the helpers
> instead.
>
> Besides the obvious code reduction, other helpers are being added to the
> core that could be used in this driver and will be good to be able to
> use them instead of duplicating them.
>
> Signed-off-by: Tomeu Vizoso
> Tested-by: Javier Martinez Canillas
> Tested-by: Sean Paul
> Reviewed-by: Sean Paul
> Signed-off-by: Sean Paul
> Cc: Javier Martinez Canillas
> Cc: Mika Kahola
> Cc: Yakir Yang
> Cc: Daniel Vetter
> Cc: Archit Taneja

Reviewed-by: Yakir Yang 

> ---
>
> v2:
>  - A bunch of good fixes from Sean and Yakir
>  - Moved the transfer function to analogix_dp_reg.c
>  - Removed reference to the EDID from the dp struct
>
> v3:
>  - Rebased on top of Yakir's PSR series
>  - Fixed checkpatch warning about line length
>
>
>   drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 274 -
>   drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  40 +-
>   drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 451 
> ++---
>   3 files changed, 210 insertions(+), 555 deletions(-)

-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160825/a6944994/attachment.html>

[v14.1 PATCH 5/5] drm/rockchip: cdn-dp: add cdn DP support for rk3399

2016-08-25 Thread Chris Zhong

Add support for cdn DP controller which is embedded in the rk3399
SoCs. The DP is compliant with DisplayPort Specification,
Version 1.3, This IP is compatible with the rockchip type-c PHY IP.
There is a uCPU in DP controller, it need a firmware to work,
please put the firmware file to /lib/firmware/rockchip/dptx.bin. The
uCPU in charge of aux communication and link training, the host use
mailbox to communicate with the ucpu.
The dclk pin_pol of vop must not be invert for DP.

Signed-off-by: Chris Zhong 
Reviewed-by: Sean Paul 
Acked-by: Mark Yao 

---

Changes in v14.1:
- power on the power domain after clk_enable
- retry to read edid

Changes in v14:
- change super speed property name to EXTCON_PROP_USB_SS
- do a correct mode_valid check when bpc is 0

Changes in v13:
- support suspend/resume
- switch power domain dynamically
- re-training when hpd signal is triggered

Changes in v12:
- use EXTCON_PROP_USB_SUPERSPEED to replace EXTCON_USB_HOST

Changes in v11:
- add best_encoder back, since it required by drm_atomic_helper_check

Changes in v10:
- remove best_encoder ops
- support read sink count from DPCD
- control the grf_clk in DP

Changes in v9:
- do not need reset the phy before power_on
- add a orientation information for set_capability
- retry to read dpcd in 10 seconds

Changes in v8:
- optimization the err log

Changes in v7:
- support firmware standby when no dptx connection
- optimization the calculation of tu size and valid symbol

Changes in v6:
- add a port struct
- select SND_SOC_HDMI_CODEC
- force reset the phy when hpd detected

Changes in v5:
- alphabetical order
- do not use long, use u32 or u64
- return MODE_CLOCK_HIGH when requested > actual
- Optimized Coding Style
- add a formula to get better tu size and symbol value.
- modify according to Sean Paul's comments
- fixed the fw_wait always 0

Changes in v4:
- use phy framework to control DP phy
- support 2 phys

Changes in v3:
- use EXTCON_DISP_DP and EXTCON_DISP_DP_ALT cable to get dp port state.
- reset spdif before config it
- modify the firmware clk to 100Mhz
- retry load firmware if fw file is requested too early

Changes in v2:
- Alphabetic order
- remove excess error message
- use define clk_rate
- check all return value
- remove dev_set_name(dp->dev, "cdn-dp");
- use schedule_delayed_work
- remove never-called functions
- remove some unnecessary ()

Changes in v1:
- use extcon API
- use hdmi-codec for the DP Asoc
- do not initialize the "ret"
- printk a err log when drm_of_encoder_active_endpoint_id
- modify the dclk pin_pol to a single line

 drivers/gpu/drm/rockchip/Kconfig|   10 +
 drivers/gpu/drm/rockchip/Makefile   |1 +
 drivers/gpu/drm/rockchip/cdn-dp-core.c  | 1067 +++
 drivers/gpu/drm/rockchip/cdn-dp-core.h  |  106 +++
 drivers/gpu/drm/rockchip/cdn-dp-reg.c   |  961 
 drivers/gpu/drm/rockchip/cdn-dp-reg.h   |  482 
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   13 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h |9 +
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c |2 +
 9 files changed, 2648 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.c
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-core.h
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.c
 create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-reg.h

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index d30bdc3..20aaafe 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -25,6 +25,16 @@ config ROCKCHIP_ANALOGIX_DP
  for the Analogix Core DP driver. If you want to enable DP
  on RK3288 based SoC, you should selet this option.

+config ROCKCHIP_CDN_DP
+tristate "Rockchip cdn DP"
+depends on DRM_ROCKCHIP
+   select SND_SOC_HDMI_CODEC if SND_SOC
+help
+ This selects support for Rockchip SoC specific extensions
+ for the cdn DP driver. If you want to enable Dp on
+ RK3399 based SoC, you should select this
+ option.
+
 config ROCKCHIP_DW_HDMI
 tristate "Rockchip specific extensions for Synopsys DW HDMI"
 depends on DRM_ROCKCHIP
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index 9746365..6a07809 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -7,6 +7,7 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o \
 rockchipdrm-$(CONFIG_DRM_FBDEV_EMULATION) += rockchip_drm_fbdev.o

 obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
+obj-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o cdn-dp-reg.o
 obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
 obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
 obj-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c 
b/drivers/gpu/drm/rockchip/cdn-dp-core.c
new file mode 100644
index

[PATCH v2 7/7] ARM: dts: am335x-evmsk: Add blue-and-red-crossed -property to lcdc node

Add blue-and-red-crossed -property to lcdc node. The am335x-evmsk has blue
and red wires crossed to get 24-bit RGB (and 16-bit BGR) support. See
details in Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt.

Signed-off-by: Jyri Sarha 
---
 arch/arm/boot/dts/am335x-evmsk.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-evmsk.dts 
b/arch/arm/boot/dts/am335x-evmsk.dts
index 23b94e7..006d8e8 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -712,4 +712,6 @@

  {
status = "okay";
+
+   blue-and-red-crossed;
 };
-- 
1.9.1

[PATCH v2 6/7] ARM: dts: am335x-evmsk: Whitespace cleanup of lcdc related nodes

Whitespace cleanup of lcdc related nodes. Do all indentation and
alignment with tabs instead of spaces.

Signed-off-by: Jyri Sarha 
---
 arch/arm/boot/dts/am335x-evmsk.dts | 40 +++---
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-evmsk.dts 
b/arch/arm/boot/dts/am335x-evmsk.dts
index 09308d6..23b94e7 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -170,29 +170,29 @@
pinctrl-1 = <_pins_sleep>;
status = "okay";
panel-info {
-   ac-bias   = <255>;
-   ac-bias-intrpt= <0>;
-   dma-burst-sz  = <16>;
-   bpp   = <32>;
-   fdd   = <0x80>;
-   sync-edge = <0>;
-   sync-ctrl = <1>;
-   raster-order  = <0>;
-   fifo-th   = <0>;
+   ac-bias = <255>;
+   ac-bias-intrpt  = <0>;
+   dma-burst-sz= <16>;
+   bpp = <32>;
+   fdd = <0x80>;
+   sync-edge   = <0>;
+   sync-ctrl   = <1>;
+   raster-order= <0>;
+   fifo-th = <0>;
};
display-timings {
480x272 {
-   hactive = <480>;
-   vactive = <272>;
-   hback-porch = <43>;
-   hfront-porch= <8>;
-   hsync-len   = <4>;
-   vback-porch = <12>;
-   vfront-porch= <4>;
-   vsync-len   = <10>;
+   hactive = <480>;
+   vactive = <272>;
+   hback-porch = <43>;
+   hfront-porch= <8>;
+   hsync-len   = <4>;
+   vback-porch = <12>;
+   vfront-porch= <4>;
+   vsync-len   = <10>;
clock-frequency = <900>;
-   hsync-active= <0>;
-   vsync-active= <0>;
+   hsync-active= <0>;
+   vsync-active= <0>;
};
};
};
@@ -711,5 +711,5 @@
 };

  {
-  status = "okay";
+   status = "okay";
 };
-- 
1.9.1

[PATCH v2 5/7] ARM: dts: am335x-evm: Add blue-and-red-crossed -property to lcdc node

Add blue-and-red-crossed -property to lcdc node. The am335x-evm has blue
and red wires crossed to get 24-bit RGB (and 16-bit BGR) support. See
details in Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt.

Signed-off-by: Jyri Sarha 
---
 arch/arm/boot/dts/am335x-evm.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 5d28712..246453b 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -497,6 +497,8 @@

  {
status = "okay";
+
+   blue-and-red-crossed;
 };

  {
-- 
1.9.1

[PATCH v2 4/7] ARM: dts: am335x-boneblack: Add comments on how to support 24 bit RGB mode

Add comments on how to support 24 bit RGB mode. In other words how to
convert BGR from LCDC to RGB in tda19988 with video-ports property and
how to tell LCDC that blue and red wires are crossed, with
blue-and-red-crossed LCDC boolean property. This changes supported
color formats from 16 bit RGB and 24 bit BGR to 16 bit BGR and 24 bit
RGB, if the suggested changes are uncommented.

Signed-off-by: Jyri Sarha 
---
 arch/arm/boot/dts/am335x-boneblack.dts | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-boneblack.dts 
b/arch/arm/boot/dts/am335x-boneblack.dts
index 528559b..6d5159d 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -90,6 +90,15 @@

  {
status = "okay";
+
+   /* If you want to get 24 bit RGB and 16 BGR mode instead of
+* current 16 bit RGB and 24 BGR modes, uncomment the boolean
+* property below and the video-ports -property in tda19988 
+* node.
+*
+* blue-and-red-crossed;
+*/
+
port {
lcdc_0: endpoint at 0 {
remote-endpoint = <_0>;
@@ -106,6 +115,9 @@
pinctrl-0 = <_hdmi_bonelt_pins>;
pinctrl-1 = <_hdmi_bonelt_off_pins>;

+   /* Convert 24bit BGR to RGB, e.g. cross red and blue wiring */
+   /* video-ports = <0x234501>; */
+
#sound-dai-cells = <0>;
audio-ports = < TDA998x_I2S 0x03>;

-- 
1.9.1

[PATCH v2 3/7] drm/tilcdc: Choose console BPP that supports RGB

Choose console BPP that supports RGB and remove the old fbdev bpp
selection code. LCDC on AM335x has red and blue wires switched between
24 bit and 16 bit colors. If 24 format is wired for RGB colors, the 16
bit format is wired for BGR. drm_fbdev_cma_init() does not currently
like anything else but RGB formats, so we must choose such bytes per
pixel value that supports RGB.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/tilcdc/tilcdc_drv.c  | 13 -
 drivers/gpu/drm/tilcdc/tilcdc_drv.h  |  1 -
 drivers/gpu/drm/tilcdc/tilcdc_external.c |  7 +++
 drivers/gpu/drm/tilcdc/tilcdc_external.h |  2 +-
 drivers/gpu/drm/tilcdc/tilcdc_panel.c|  2 --
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c   |  2 --
 6 files changed, 8 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index bb65872..dbc00f7 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -236,7 +236,6 @@ static int tilcdc_load(struct drm_device *dev, unsigned 
long flags)
struct platform_device *pdev = dev->platformdev;
struct device_node *node = pdev->dev.of_node;
struct tilcdc_drm_private *priv;
-   struct tilcdc_module *mod;
struct resource *res;
u32 bpp = 0;
int ret;
@@ -332,14 +331,17 @@ static int tilcdc_load(struct drm_device *dev, unsigned 
long flags)
DBG("Revision 1 LCDC supports only RGB565 format");
priv->pixelformats = tilcdc_rev1_formats;
priv->num_pixelformats = ARRAY_SIZE(tilcdc_rev1_formats);
+   bpp = 16;
} else if (of_property_read_bool(node, "blue-and-red-crossed")) {
DBG("Configured for crossed blue and red wires");
priv->pixelformats = tilcdc_crossed_formats;
priv->num_pixelformats = ARRAY_SIZE(tilcdc_crossed_formats);
+   bpp = 32; /* Choose bpp with RGB support for fbdef */
} else {
DBG("Configured for straight blue and red wires");
priv->pixelformats = tilcdc_straight_formats;
priv->num_pixelformats = ARRAY_SIZE(tilcdc_straight_formats);
+   bpp = 16; /* Choose bpp with RGB support for fbdef */
}

ret = modeset_init(dev);
@@ -355,7 +357,7 @@ static int tilcdc_load(struct drm_device *dev, unsigned 
long flags)
if (ret < 0)
goto fail_mode_config_cleanup;

-   ret = tilcdc_add_external_encoders(dev, );
+   ret = tilcdc_add_external_encoders(dev);
if (ret < 0)
goto fail_component_cleanup;
}
@@ -378,13 +380,6 @@ static int tilcdc_load(struct drm_device *dev, unsigned 
long flags)
goto fail_vblank_cleanup;
}

-   list_for_each_entry(mod, _list, list) {
-   DBG("%s: preferred_bpp: %d", mod->name, mod->preferred_bpp);
-   bpp = mod->preferred_bpp;
-   if (bpp > 0)
-   break;
-   }
-
drm_mode_config_reset(dev);

priv->fbdev = drm_fbdev_cma_init(dev, bpp,
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
index 0e19c14..a6e5e6d 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
@@ -116,7 +116,6 @@ struct tilcdc_module {
const char *name;
struct list_head list;
const struct tilcdc_module_ops *funcs;
-   unsigned int preferred_bpp;
 };

 void tilcdc_module_init(struct tilcdc_module *mod, const char *name,
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_external.c 
b/drivers/gpu/drm/tilcdc/tilcdc_external.c
index 849b23e..68e8950 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_external.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_external.c
@@ -52,7 +52,7 @@ static int tilcdc_external_mode_valid(struct drm_connector 
*connector,
return MODE_OK;
 }

-static int tilcdc_add_external_encoder(struct drm_device *dev, int *bpp,
+static int tilcdc_add_external_encoder(struct drm_device *dev,
   struct drm_connector *connector)
 {
struct tilcdc_drm_private *priv = dev->dev_private;
@@ -64,7 +64,6 @@ static int tilcdc_add_external_encoder(struct drm_device 
*dev, int *bpp,
/* Only tda998x is supported at the moment. */
tilcdc_crtc_set_simulate_vesa_sync(priv->crtc, true);
tilcdc_crtc_set_panel_info(priv->crtc, _info_tda998x);
-   *bpp = panel_info_tda998x.bpp;

connector_funcs = devm_kzalloc(dev->dev, sizeof(*connector_funcs),
   GFP_KERNEL);
@@ -94,7 +93,7 @@ static int tilcdc_add_external_encoder(struct drm_device 
*dev, int *bpp,
return 0;
 }

-int tilcdc_add_external_encoders(struct drm_device *dev, int *bpp)
+int tilcdc_add_external_encoders(struct drm_device *dev)
 {
struct tilcdc_drm_private *priv = dev->dev_private;

[PATCH v2 2/7] drm/tilcdc: Add blue-and-red-crossed devicetree property

Add "blue-and-red-crossed"-device tree property and update devicetree
binding document. The red and blue components are reversed between 24
and 16 bit modes on am335x LCDC output pins. To get 24 RGB format the
red and blue wires has to be crossed and this in turn causes 16 colors
output to be in BGR format. With straight wiring the 16 color is RGB
and 24 bit is BGR. The new property describes whether the red and blue
wires are crossed or not. If the wires are crossed this boolean property
should be present in the relevant devicetree node.

The am335x-evm and am335x-evm have the blue and red wires crossed for
24 bit RGB mode and after this patch their LCDC nodes should have this
property to get correct colors in the display.

For more details see section 3.1.1 in AM335x Silicon Errata:
http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=sprz360

Signed-off-by: Jyri Sarha 
---
 .../devicetree/bindings/display/tilcdc/tilcdc.txt  | 12 +++
 drivers/gpu/drm/tilcdc/tilcdc_drv.c| 24 ++
 drivers/gpu/drm/tilcdc/tilcdc_drv.h|  4 
 drivers/gpu/drm/tilcdc/tilcdc_plane.c  |  9 +++-
 4 files changed, 43 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt 
b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
index 6efa4c5..48a660a 100644
--- a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
+++ b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
@@ -17,6 +17,8 @@ Optional properties:
the lcd controller.
  - max-pixelclock: The maximum pixel clock that can be supported
by the lcd controller in KHz.
+ - blue-and-red-crossed: Boolean property, set this of blue and red wires
+   for LCD_DATA are crossed for 24-bit RGB support (and 16-bit BGR mode). [1]

 Optional nodes:

@@ -28,6 +30,14 @@ Optional nodes:
Documentation/devicetree/bindings/display/tilcdc/tfp410.txt for connecting
tfp410 DVI encoder or lcd panel to lcdc

+[1] There is an errata about AM335x color wiring. For 16-bit color mode
+the wires work as they should (LCD_DATA[0:4] is for Blue[3:7]),
+but for 24 bit color modes the wiring of blue and red components is
+crossed and LCD_DATA[0:4] is for Red[3:7] and LCD_DATA[11:15] is
+for Blue[3-7]. For more details see section 3.1.1 in AM335x
+Silicon Errata:
+
http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=sprz360
+
 Example:

fb: fb at 4830e000 {
@@ -37,6 +47,8 @@ Example:
interrupts = <36>;
ti,hwmods = "lcdc";

+   blue-and-red-wiring = "crossed";
+
port {
lcdc_0: endpoint at 0 {
remote-endpoint = <_0>;
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index e45c268..bb65872 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -33,6 +33,16 @@

 static LIST_HEAD(module_list);

+static const u32 tilcdc_rev1_formats[] = { DRM_FORMAT_RGB565 };
+
+static const u32 tilcdc_straight_formats[] = { DRM_FORMAT_RGB565,
+  DRM_FORMAT_BGR888,
+  DRM_FORMAT_XBGR };
+
+static const u32 tilcdc_crossed_formats[] = { DRM_FORMAT_BGR565,
+ DRM_FORMAT_RGB888,
+ DRM_FORMAT_XRGB };
+
 void tilcdc_module_init(struct tilcdc_module *mod, const char *name,
const struct tilcdc_module_ops *funcs)
 {
@@ -318,6 +328,20 @@ static int tilcdc_load(struct drm_device *dev, unsigned 
long flags)

pm_runtime_put_sync(dev->dev);

+   if (priv->rev == 1) {
+   DBG("Revision 1 LCDC supports only RGB565 format");
+   priv->pixelformats = tilcdc_rev1_formats;
+   priv->num_pixelformats = ARRAY_SIZE(tilcdc_rev1_formats);
+   } else if (of_property_read_bool(node, "blue-and-red-crossed")) {
+   DBG("Configured for crossed blue and red wires");
+   priv->pixelformats = tilcdc_crossed_formats;
+   priv->num_pixelformats = ARRAY_SIZE(tilcdc_crossed_formats);
+   } else {
+   DBG("Configured for straight blue and red wires");
+   priv->pixelformats = tilcdc_straight_formats;
+   priv->num_pixelformats = ARRAY_SIZE(tilcdc_straight_formats);
+   }
+
ret = modeset_init(dev);
if (ret < 0) {
dev_err(dev->dev, "failed to initialize mode setting\n");
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
index 13001df..0e19c14 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
@@ -65,6 +65,10 @@ struct tilcdc_drm_private {
 */
uint32_t max_width;

+   /* Supported pixel formats

[PATCH v2 1/7] drm/tilcdc: Remove drm_helper_disable_unused_functions() call

drm_helper_disable_unused_functions() should not be called by atomic
drivers.

Signed-off-by: Jyri Sarha 
---
 drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c 
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 3404d24..e45c268 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -361,8 +361,6 @@ static int tilcdc_load(struct drm_device *dev, unsigned 
long flags)
break;
}

-   drm_helper_disable_unused_functions(dev);
-
drm_mode_config_reset(dev);

priv->fbdev = drm_fbdev_cma_init(dev, bpp,
-- 
1.9.1

[PATCH v2 0/7] drm/tilcdc: Address LCDC rev 2 color errata

Changes since v1:
- Change the blue-and-red-wiring property to boolean blue-and-red-crossed
  - This breaks to little backward compatibility the earlier series had, but
makes the binding more straight forward
  - This changes requires changes to am335x-evm and am335x-evmsk dts-files
  - The old beaglebone-black dts files remain compatible, but the patch
suggests in commenst on how to support 24-bit RGB mode with BBB

The first patch ("drm/tilcdc: Remove drm_helper_disable_unused_functions()
call") is completely independent fix.

The red and blue components are reversed between 24 and 16 bit modes
on am335x LCDC output pins. To get 24 RGB format the wires red and
blue wires has to be crossed and this in turn causes 16 colors output
to be in BGR format. With straight wiring the 16 color is RGB and 24
bit is BGR. These patches try to deal with the issue in reasonable
manner.

For more details see section 3.1.1 in AM335x Silicon Errata:
http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=sprz360

Jyri Sarha (7):
  drm/tilcdc: Remove drm_helper_disable_unused_functions() call
  drm/tilcdc: Add blue-and-red-crossed devicetree property
  drm/tilcdc: Choose console BPP that supports RGB
  ARM: dts: am335x-boneblack: Add comments on how to support 24 bit RGB
mode
  ARM: dts: am335x-evm: Add blue-and-red-crossed -property to lcdc node
  ARM: dts: am335x-evmsk: Whitespace cleanup of lcdc related nodes
  ARM: dts: am335x-evmsk: Add blue-and-red-crossed -property to lcdc
node

 .../devicetree/bindings/display/tilcdc/tilcdc.txt  | 12 +++
 arch/arm/boot/dts/am335x-boneblack.dts | 12 +++
 arch/arm/boot/dts/am335x-evm.dts   |  2 ++
 arch/arm/boot/dts/am335x-evmsk.dts | 42 +++---
 drivers/gpu/drm/tilcdc/tilcdc_drv.c| 39 ++--
 drivers/gpu/drm/tilcdc/tilcdc_drv.h|  5 ++-
 drivers/gpu/drm/tilcdc/tilcdc_external.c   |  7 ++--
 drivers/gpu/drm/tilcdc/tilcdc_external.h   |  2 +-
 drivers/gpu/drm/tilcdc/tilcdc_panel.c  |  2 --
 drivers/gpu/drm/tilcdc/tilcdc_plane.c  |  9 ++---
 drivers/gpu/drm/tilcdc/tilcdc_tfp410.c |  2 --
 11 files changed, 87 insertions(+), 47 deletions(-)

-- 
1.9.1

[Intel-gfx] [PATCH 3/6] drm/i915: Check PSR setup time vs. vblank length

2016-08-25 Thread Rodrigo Vivi

On Mon, Aug 8, 2016 at 1:33 AM, Jani Nikula  
wrote:
> On Sat, 06 Aug 2016, Rodrigo Vivi  wrote:
>> This patch is blocking PSR on panels that we know that our hardware support.
>
> And it also fixes a regression on Linus' laptop, and it's been merged
> upstream...

yeap, this patch is like setting i915.enable_psr=0...

I still believe we have an error somewhere else.
With this patch in place there is no panel out there with PSR
supported with preferred mode.

Maybe this ultra fast vblank is confusing this PSR blocks if this are
the expected timings...

>
> BR,
> Jani.
>
>>
>> I wonder if:
>> 1. This restrictions was for older platforms and spec is out dated
>> 2. Or Spec is not documenting the restriction properly
>> 3. Or we have some issue with out setup time calculation.
>>
>>
>> On Tue, May 31, 2016 at 8:50 AM,   wrote:
>>> From: Ville SyrjÃ¤lÃ¤ 
>>>
>>> Bspec says:
>>> "Restriction : SRD must not be enabled when the PSR Setup time from DPCD
>>> 00071h is greater than the time for vertical blank minus one line."
>>>
>>> Let's check for that and disallow PSR if we exceed the limit.
>>>
>>> Cc: Daniel Vetter 
>>> Reviewed-by: Daniel Vetter 
>>> Signed-off-by: Ville SyrjÃ¤lÃ¤ 
>>> ---
>>>  drivers/gpu/drm/i915/intel_drv.h|  2 ++
>>>  drivers/gpu/drm/i915/intel_psr.c| 19 ++-
>>>  drivers/gpu/drm/i915/intel_sprite.c |  6 +++---
>>>  3 files changed, 23 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
>>> b/drivers/gpu/drm/i915/intel_drv.h
>>> index 9b5f6634c558..56ae3b78e25e 100644
>>> --- a/drivers/gpu/drm/i915/intel_drv.h
>>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>>> @@ -1672,6 +1672,8 @@ bool intel_sdvo_init(struct drm_device *dev,
>>>
>>>
>>>  /* intel_sprite.c */
>>> +int intel_usecs_to_scanlines(const struct drm_display_mode *adjusted_mode,
>>> +int usecs);
>>>  int intel_plane_init(struct drm_device *dev, enum pipe pipe, int plane);
>>>  int intel_sprite_set_colorkey(struct drm_device *dev, void *data,
>>>   struct drm_file *file_priv);
>>> diff --git a/drivers/gpu/drm/i915/intel_psr.c 
>>> b/drivers/gpu/drm/i915/intel_psr.c
>>> index 29a09bf6bd18..aacd8d1767f2 100644
>>> --- a/drivers/gpu/drm/i915/intel_psr.c
>>> +++ b/drivers/gpu/drm/i915/intel_psr.c
>>> @@ -327,6 +327,9 @@ static bool intel_psr_match_conditions(struct intel_dp 
>>> *intel_dp)
>>> struct drm_i915_private *dev_priv = dev->dev_private;
>>> struct drm_crtc *crtc = dig_port->base.base.crtc;
>>> struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>>> +   const struct drm_display_mode *adjusted_mode =
>>> +   _crtc->config->base.adjusted_mode;
>>> +   int psr_setup_time;
>>>
>>> lockdep_assert_held(_priv->psr.lock);
>>> WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
>>> @@ -365,11 +368,25 @@ static bool intel_psr_match_conditions(struct 
>>> intel_dp *intel_dp)
>>> }
>>>
>>> if (IS_HASWELL(dev) &&
>>> -   intel_crtc->config->base.adjusted_mode.flags & 
>>> DRM_MODE_FLAG_INTERLACE) {
>>> +   adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE) {
>>> DRM_DEBUG_KMS("PSR condition failed: Interlaced is 
>>> Enabled\n");
>>> return false;
>>> }
>>>
>>> +   psr_setup_time = drm_dp_psr_setup_time(intel_dp->psr_dpcd);
>>> +   if (psr_setup_time < 0) {
>>> +   DRM_DEBUG_KMS("PSR condition failed: Invalid PSR setup time 
>>> (0x%02x)\n",
>>> + intel_dp->psr_dpcd[1]);
>>> +   return false;
>>> +   }
>>> +
>>> +   if (intel_usecs_to_scanlines(adjusted_mode, psr_setup_time) >
>>> +   adjusted_mode->crtc_vtotal - adjusted_mode->crtc_vdisplay - 1) {
>>> +   DRM_DEBUG_KMS("PSR condition failed: PSR setup time (%d us) 
>>> too long\n",
>>> + psr_setup_time);
>>> +   return false;
>>> +   }
>>> +
>>> dev_priv->psr.source_ok = true;
>>> return true;
>>>  }
>>> diff --git a/drivers/gpu/drm/i915/intel_sprite.c 
>>> b/drivers/gpu/drm/i915/intel_sprite.c
>>> index 324ccb06397d..293b48007006 100644
>>> --- a/drivers/gpu/drm/i915/intel_sprite.c
>>> +++ b/drivers/gpu/drm/i915/intel_sprite.c
>>> @@ -53,8 +53,8 @@ format_is_yuv(uint32_t format)
>>> }
>>>  }
>>>
>>> -static int usecs_to_scanlines(const struct drm_display_mode *adjusted_mode,
>>> - int usecs)
>>> +int intel_usecs_to_scanlines(const struct drm_display_mode *adjusted_mode,
>>> +int usecs)
>>>  {
>>> /* paranoia */
>>> if (!adjusted_mode->crtc_htotal)
>>> @@ -91,7 +91,7 @@ void intel_pipe_update_start(struct intel_crtc *crtc)
>>> vblank_start = DIV_ROUND_UP(vblank_start, 2);
>>>
>>> /* FIXME needs to be calibrated sensibly */
>>> -   min = vblank_start - usecs_to_scanlines(adjusted_mode, 100);

[8086:0416] i915 Inability to drive internal (eDP) panel since 4.7 final

2016-08-25 Thread Jani Nikula

On Mon, 22 Aug 2016, Tony Vroon  wrote:
> Recent i915 development appears to have stopped my eDP panel from being
> driven correctly. The last working release was 4.6.7; any 4.7 kernel
> will not drive the screen and 4.8-RC3 does not drive the screen either.
> I have both 4.6.7 and 4.8.0-rc3 kernel images available and am happy to
> run any debug/troubleshooting that you require.

Please file a bug at [1]. Please attach drm.debug=14 module parameter,
and attach dmesg all the way from boot. If you can bisect which commit
broke it, it would speed this up considerably.

BR,
Jani.

[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH v3 1/3] drm/bridge: introduce bridge detaching mechanism

On Thu, Aug 25, 2016 at 11:04:32AM +0200, Andrea Merello wrote:
> Up to now, once a bridge has been attached to a DRM device, it cannot
> be undone.
> 
> In particular you couldn't rmmod/insmod a DRM driver that uses a bridge,
> because the bridge would remain bound to the first (dead) driver instance.
> 
> This patch fixes this by introducing drm_encoder_detach() and a ->detach
> callback in drm_bridge_funcs for the bridge to be notified about detaches.
> 
> It's DRM/KMS driver responsibility to call drm_encoder_detach().
> 
> While adding the bridge detach callback, with its kerneldoc, I also added
> kerneldoc for attach callback.
> 
> Few other kerneldocs fixes around there are included.
> 
> Suggested-by: Daniel Vetter 
> Suggested-by: Lucas Stach 
> Signed-off-by: Andrea Merello 
> Cc: Archit Taneja 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Lucas Stach 

Reviewed-by: Daniel Vetter 

As discussed on the last round, I'll let Archit apply all 3 to drm-misc,
so he can check them out too.
-Daniel
> ---
>  drivers/gpu/drm/drm_bridge.c | 29 +++--
>  include/drm/drm_crtc.h   | 26 +-
>  2 files changed, 52 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index 2555430..4840466 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -98,11 +98,11 @@ EXPORT_SYMBOL(drm_bridge_remove);
>   * @dev: DRM device
>   * @bridge: bridge control structure
>   *
> - * called by a kms driver to link one of our encoder/bridge to the given
> + * Called by a kms driver to link one of our encoder/bridge to the given
>   * bridge.
>   *
>   * Note that setting up links between the bridge and our encoder/bridge
> - * objects needs to be handled by the kms driver itself
> + * objects needs to be handled by the kms driver itself.
>   *
>   * RETURNS:
>   * Zero on success, error code on failure
> @@ -125,6 +125,31 @@ int drm_bridge_attach(struct drm_device *dev, struct 
> drm_bridge *bridge)
>  EXPORT_SYMBOL(drm_bridge_attach);
>  
>  /**
> + * drm_bridge_detach - deassociate given bridge from its DRM device
> + *
> + * @bridge: bridge control structure
> + *
> + * Called by a kms driver to unlink the given bridge from its DRM device.
> + *
> + * Note that tearing down links between the bridge and our encoder/bridge
> + * objects needs to be handled by the kms driver itself.
> + */
> +void drm_bridge_detach(struct drm_bridge *bridge)
> +{
> + if (WARN_ON(!bridge))
> + return;
> +
> + if (WARN_ON(!bridge->dev))
> + return;
> +
> + if (bridge->funcs->detach)
> + bridge->funcs->detach(bridge);
> +
> + bridge->dev = NULL;
> +}
> +EXPORT_SYMBOL(drm_bridge_detach);
> +
> +/**
>   * DOC: bridge callbacks
>   *
>   * The _bridge_funcs ops are populated by the bridge driver. The DRM
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 3fa0275..bb214a1 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1118,12 +1118,33 @@ struct drm_plane {
>  
>  /**
>   * struct drm_bridge_funcs - drm_bridge control functions
> - * @attach: Called during drm_bridge_attach
>   */
>  struct drm_bridge_funcs {
> + /**
> +  * @attach:
> +  *
> +  * This callback is invoked whenever our bridge is being attached to a
> +  * _encoder.
> +  *
> +  * The attach callback is optional.
> +  *
> +  * RETURNS:
> +  *
> +  * Zero on success, error code on failure.
> +  */
>   int (*attach)(struct drm_bridge *bridge);
>  
>   /**
> +  * @detach:
> +  *
> +  * This callback is invoked whenever our bridge is being detached from a
> +  * _encoder.
> +  *
> +  * The detach callback is optional.
> +  */
> + void (*detach)(struct drm_bridge *bridge);
> +
> + /**
>* @mode_fixup:
>*
>* This callback is used to validate and adjust a mode. The paramater
> @@ -1137,6 +1158,8 @@ struct drm_bridge_funcs {
>* this function passes all other callbacks must succeed for this
>* configuration.
>*
> +  * The mode_fixup callback is optional.
> +  *
>* NOTE:
>*
>* This function is called in the check phase of atomic modesets, which
> @@ -2426,6 +2449,7 @@ extern int drm_bridge_add(struct drm_bridge *bridge);
>  extern void drm_bridge_remove(struct drm_bridge *bridge);
>  extern struct drm_bridge *of_drm_find_bridge(struct device_node *np);
>  extern int drm_bridge_attach(struct drm_device *dev, struct drm_bridge 
> *bridge);
> +extern void drm_bridge_detach(struct drm_bridge *bridge);
>  
>  bool drm_bridge_mode_fixup(struct drm_bridge *bridge,
>   const struct drm_display_mode *mode,
> -- 
> 2.7.4
> 

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

[RFC 0/2] New feature: Framebuffer processors

On Thu, Aug 25, 2016 at 08:45:25PM +0900, Inki Dae wrote:
> 
> 
> 2016ë 08ì 25ì¼ 17:42ì Daniel Vetter ì´(ê°) ì´ ê¸:
> > On Thu, Aug 25, 2016 at 05:06:55PM +0900, Inki Dae wrote:
> >>
> >>
> >> 2016ë 08ì 24ì¼ 20:57ì Daniel Vetter ì´(ê°) ì´ ê¸:
> >>> On Wed, Aug 24, 2016 at 08:44:24PM +0900, Inki Dae wrote:
>  Hi,
> 
>  2016ë 08ì 23ì¼ 18:41ì Daniel Stone ì´(ê°) ì´ ê¸:
> > Hi,
> >
> > On 22 August 2016 at 16:23, Rob Clark  wrote:
> >> I guess a lot comes down to 'how long before hw designers bolt a CP to
> >> the thing'..  at that point, I think you especially don't want a
> >> per-blit kernel interface.
> >
> > Regardless of whether or not we want it, we already _have_ it, in the
> > form of V4L2 M2M. There are already a few IP blocks working on that, I
> > believe. If V4L2 <-> KMS interop is painful, well, we need to fix that
> > anyway ...
> 
>  So we are trying this. We had expereneced using V4L2 and DRM together on
>  Linux Platform makes it too complicated, and also integrated DRM with
>  M2M such as 2D and Post processor makes it simplified.  So We have been
>  trying to move existing V4L2 based drivers into DRM excepting HW Video
>  Codec - called it MFC - and Camera sensor and relevant things.
>  I think now V4L2 and DRM frameworks may make many engineers confusing
>  because there are the same devices which can be controlled by V4L2 and
>  DRM frameworks - maybe we would need more efforts like Laurent did with
>  Live source[1] in the future.
> >>>
> >>> Can you pls explain in more detail where working with both v4l and drm
> >>> drivers and making them cooperate using dma-bufs poses problems? We should
> >>> definitely fix that.
> >>
> >> I think it would be most Linux Platforms - Android, Chrome and Tizen -
> >> which would use OpenMAX/GStreammer for Multimedia and X or
> >> Wayland/SurfaceFlinger for Display.
> >
> > Yes, that's the use case. Where is the problem in making this happen? v4l
> > can import dma-bufs, drm can export them, and there's plenty devices
> > shipping (afaik) that make use of exact this pipeline. Can you pls explain
> > what problem you've hit trying to make this work on exynos?
> 
> No problem but just make it complicated as I mentioned above - the
> stream operations - S_FMT, REQBUF, QUARYBUF, QBUF, STREAM ON and DQBUF
> of V4L2 would never be simple as DRM.  Do you think M2M device should be
> controlled by V4L2 interfaces? and even 2D accelerator? As long as I
> know, The Graphics card on Desktop has all devices such as 2D/3D GPU, HW
> Video codec and Display controller, and these devices are controlled by
> DRM interfaces. So we - ARM Exynos - are trying to move these things to
> DRM world and also trying to implement more convenient interfaces like
> Marek did.

This is a misconception, there's nothing in the drm world requiring that
everything is under the same drm device. All the work we've done over the
past years (dma-buf, reservations, fence, prime, changes in X.org and
wayland) are _all_ to make it possible to have a gfx device consisting of
multiple drm/v4l/whatever else nodes. Especially for a SoC moving back to
fake-integrating stuff really isn't a good idea I think.

And wrt drm being simpler than v4l - I don't think drm is any simpler, at
elast if you look at some of the more feature-full render drivers.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Bug 91969] [radeonsi][bonaire] Stalls with Borderlands 2

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

Andreas Hartmetz  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

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

[Bug 91969] [radeonsi][bonaire] Stalls with Borderlands 2

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

--- Comment #6 from Andreas Hartmetz  ---
Is this fixed now? I've had the same or a similar problem and it's fixed now. I
thought it wasn't fixed for a while until I discovered that limiting the frame
rate to 60 is really bad for performance in Borderlands 2...

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

[Bug 96398] [radeonsi tessellation] Single-pixel rasterization issue (Shadow of Mordor)

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

--- Comment #10 from Jan Ziak <0xe2.0x9a.0x9b at gmail.com> ---
(In reply to Marek OlÅ¡Ã¡k from comment #9)
> I can't reproduce this on Tonga and Polaris11. It seems to be fixed. Can you
> please confirm?

I can't reproduce the issue as well. It was still there just a few weeks ago.

I will do a more thorough check later today and close this issue if the problem
is no longer there.

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

[Bug 96398] [radeonsi tessellation] Single-pixel rasterization issue (Shadow of Mordor)

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

--- Comment #9 from Marek OlÅ¡Ã¡k  ---
I can't reproduce this on Tonga and Polaris11. It seems to be fixed. Can you
please confirm?

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

[PATCH v3 1/5] drm/rockchip: sort registers define by chip's number

2016-08-25 Thread Sean Paul

On Thu, Aug 25, 2016 at 1:15 PM, Sean Paul  wrote:
>
>
> On Wed, Aug 24, 2016 at 10:25 PM, Mark yao  wrote:
>>
>> On 2016å¹´08æ23æ¥ 21:13, Sean Paul wrote:
>>>
>>> On Mon, Aug 22, 2016 at 8:40 PM, Mark yao 
>>> wrote:

 On 2016å¹´08æ23æ¥ 04:30, Sean Paul wrote:
>
> On Thu, Aug 18, 2016 at 6:02 AM, Mark yao 
> wrote:
>>
>> On 2016å¹´08æ18æ¥ 17:11, Daniel Vetter wrote:
>>>
>>> On Thu, Aug 18, 2016 at 05:08:14PM +0800, Mark yao wrote:
>
> Hi Sean
>
> Thanks for send v3 patch for rk3399 vop support.
>
> But sorry for that, I had changed my mind, those patches are
> deprecated,
> I have new rk3399 patch on my downstream kernel, I will upstream
> soon.
>>>
>>> Wut? Imo merge Sean's patch here, and then rebase your downstream
>>> patches
>>> on top of it. That you have a downstream tree which is out of sync
>>> with
>>> upstream shouldn't be a reason to stall upstream development.
>>> -Daniel
>>>
>> Yeah, Sorry for that.
>>
>> In fact, on my downstream kernel, also have those patches, my new
>> rk3399
>> patches are based on them,
>> but the new rk3399 patches will cover the those patches,  Sean's
>> patches
>> is
>> old version.
>>
>> I just want to fast forward, don't want to send two version drivers to
>> upstream.
>> but if you and Dave feel ok for that, I have no problem:-) .
>>
>> merged Sean's patches and then apply new version patches.
>>
> Ok, so can I get a review/ack for these revised patches then?
> Something is better than nothing, and there's a bunch of stuff that
> depends on these changes.
>
> Sean

 Yes, But I miss your [PATCH v3 0/5] and [PATCH v3 4/5]. do you mean the
 lost
 patches use v2 version?

>>> Yes, v2 4/5 was reviewed as-is, so I just applied it.
>>>
>>> Sean
>>
>> Applied this series to my drm-next.
>>
>
> You should probably just rebase your downstream kernel on top of my branch
> here: https://cgit.freedesktop.org/~seanpaul/dogwood/log/?h=for-next
>

Resending in plain text.

Sean

> Sean
>
>
>> Thanks.
>>
>>
>
>> Thanks.
>>
>> --
>> ï¼ark Yao
>>
>>
>

 --
 ï¼ark Yao


>>>
>>>
>>
>>
>> --
>> ï¼ark Yao
>>
>>
>

[PATCH v3 1/5] drm/rockchip: sort registers define by chip's number

2016-08-25 Thread Sean Paul

On Wed, Aug 24, 2016 at 10:25 PM, Mark yao  wrote:

> On 2016å¹´08æ23æ¥ 21:13, Sean Paul wrote:
>
>> On Mon, Aug 22, 2016 at 8:40 PM, Mark yao 
>> wrote:
>>
>>> On 2016å¹´08æ23æ¥ 04:30, Sean Paul wrote:
>>>
>>>> On Thu, Aug 18, 2016 at 6:02 AM, Mark yao 
>>>> wrote:
>>>>
>>>>> On 2016å¹´08æ18æ¥ 17:11, Daniel Vetter wrote:
>>>>>
>>>>>> On Thu, Aug 18, 2016 at 05:08:14PM +0800, Mark yao wrote:
>>>>>>
>>>>>>> Hi Sean
>>>>>>>>
>>>>>>>> Thanks for send v3 patch for rk3399 vop support.
>>>>>>>>
>>>>>>>> But sorry for that, I had changed my mind, those patches are
>>>>>>>> deprecated,
>>>>>>>> I have new rk3399 patch on my downstream kernel, I will upstream
>>>>>>>> soon.
>>>>>>>>
>>>>>>> Wut? Imo merge Sean's patch here, and then rebase your downstream
>>>>>> patches
>>>>>> on top of it. That you have a downstream tree which is out of sync
>>>>>> with
>>>>>> upstream shouldn't be a reason to stall upstream development.
>>>>>> -Daniel
>>>>>>
>>>>>> Yeah, Sorry for that.
>>>>>
>>>>> In fact, on my downstream kernel, also have those patches, my new
>>>>> rk3399
>>>>> patches are based on them,
>>>>> but the new rk3399 patches will cover the those patches,  Sean's
>>>>> patches
>>>>> is
>>>>> old version.
>>>>>
>>>>> I just want to fast forward, don't want to send two version drivers to
>>>>> upstream.
>>>>> but if you and Dave feel ok for that, I have no problem:-) .
>>>>>
>>>>> merged Sean's patches and then apply new version patches.
>>>>>
>>>>> Ok, so can I get a review/ack for these revised patches then?
>>>> Something is better than nothing, and there's a bunch of stuff that
>>>> depends on these changes.
>>>>
>>>> Sean
>>>>
>>> Yes, But I miss your [PATCH v3 0/5] and [PATCH v3 4/5]. do you mean the
>>> lost
>>> patches use v2 version?
>>>
>>> Yes, v2 4/5 was reviewed as-is, so I just applied it.
>>
>> Sean
>>
> Applied this series to my drm-next.
>
>
You should probably just rebase your downstream kernel on top of my branch
here: https://cgit.freedesktop.org/~seanpaul/dogwood/log/?h=for-next

Sean


Thanks.
>
>
>
>>>> Thanks.
>>>>>
>>>>> --
>>>>> ï¼ark Yao
>>>>>
>>>>>
>>>>>
>>>>
>>> --
>>> ï¼ark Yao
>>>
>>>
>>>
>>
>>
>
> --
> ï¼ark Yao
>
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160825/270d588c/attachment.html>

[PATCH 2/2] drm: make DRI1 drivers depend on BROKEN

On Thu, Aug 04, 2016 at 09:15:07AM +0100, Chris Wilson wrote:
> On Thu, Aug 04, 2016 at 10:06:57AM +0200, David Herrmann wrote:
> > The legacy DRI1 drivers expose highly broken interfaces to user-space. No
> > modern system should enable them, or you will effectively allow user-space
> > to circumvent most of your kernel security measures. The DRI1 kernel APIs
> > are simply broken.
> > 
> > User-space can always use vesafb/efifb/simplefb and friends to get working
> > graphics.
> > 
> > Lets hide the old drivers behind CONFIG_BROKEN. In case they turn out to
> > be still used (really?), we can easily revert this and figure out a way to
> > move them out of sight (e.g., moving all DRI1 drivers to
> > drivers/gpu/dri1/).
> > 
> > Signed-off-by: David Herrmann 
> 
> Acked-by: Chris Wilson 
> 
> I'd rather have a couple of distro devs check if they are still using
> any of these, and would value their a-b/r-b.

Mesa stopped shipping dri1 drivers years ago, and neither Fedora and
Debian here have that old version packaged (it should keep working since
the dri loader is an ABI). I don't think anyone needs this, and if I'm
wrong we'll hear about it ;-)

Both applied to drm-misc.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Bug 97029] cik_sdma_copy_texture broken on Carrizo (mesa 12)

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

Marek OlÅ¡Ã¡k  changed:

   What|Removed |Added

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

--- Comment #12 from Marek OlÅ¡Ã¡k  ---
SDMA texture copying was disabled on Carrizo by:
3ff0b67e1b6b492d5793c1580f4be0c6f58a1bc2

Closing.

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

[PATCH v3] drm/fence: allow fence waiting to be interrupted by userspace

2016-08-25 Thread Gustavo Padovan

From: Gustavo Padovan 

If userspace is running an synchronously atomic commit and interrupts the
atomic operation during fence_wait() it will hang until the timer expires,
so here we change the wait to be interruptible so it stop immediately when
userspace wants to quit.

Also adds the necessary error checking for fence_wait().

v2: Comment by Daniel Vetter
- Add error checking for fence_wait()

v3: Rebase on top of new atomic noblocking support

v4: Comment by Maarten Lankhorst
- remove 'swapped' bitfield as it was duplicating information

v5: Comments by Maarten Lankhorst
- assign plane->state to plane_state if !intr
- squash previous patch into this one

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/drm_atomic_helper.c | 42 +
 drivers/gpu/drm/msm/msm_atomic.c|  2 +-
 include/drm/drm_atomic_helper.h |  5 +++--
 3 files changed, 37 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index e1f5de2..f752f9c 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1007,29 +1007,47 @@ EXPORT_SYMBOL(drm_atomic_helper_commit_modeset_enables);
  * drm_atomic_helper_wait_for_fences - wait for fences stashed in plane state
  * @dev: DRM device
  * @state: atomic state object with old state structures
+ * @intr: if true, do an interruptible wait
  *
  * For implicit sync, driver should fish the exclusive fence out from the
  * incoming fb's and stash it in the drm_plane_state.  This is called after
  * drm_atomic_helper_swap_state() so it uses the current plane state (and
  * just uses the atomic state to find the changed planes)
+ *
+ * Returns zero if sucess or < 0 if fence_wait() fails.
  */
-void drm_atomic_helper_wait_for_fences(struct drm_device *dev,
-   struct drm_atomic_state *state)
+int drm_atomic_helper_wait_for_fences(struct drm_device *dev,
+  struct drm_atomic_state *state,
+  bool intr)
 {
struct drm_plane *plane;
struct drm_plane_state *plane_state;
-   int i;
+   int i, ret;

for_each_plane_in_state(state, plane, plane_state, i) {
-   if (!plane->state->fence)
+   /*
+* If the caller asks for an interruptible wait it means
+* that the state were not swapped yet and the operation
+* can still be interrupted by userspace, so we need
+* to look to plane_state instead.
+*/
+   if (!intr)
+   plane_state = plane->state;
+
+   if (!plane_state->fence)
continue;

-   WARN_ON(!plane->state->fb);
+   WARN_ON(!plane_state->fb);
+
+   ret = fence_wait(plane_state->fence, intr);
+   if (ret)
+   return ret;

-   fence_wait(plane->state->fence, false);
-   fence_put(plane->state->fence);
-   plane->state->fence = NULL;
+   fence_put(plane_state->fence);
+   plane_state->fence = NULL;
}
+
+   return 0;
 }
 EXPORT_SYMBOL(drm_atomic_helper_wait_for_fences);

@@ -1176,7 +1194,7 @@ static void commit_tail(struct drm_atomic_state *state)

funcs = dev->mode_config.helper_private;

-   drm_atomic_helper_wait_for_fences(dev, state);
+   drm_atomic_helper_wait_for_fences(dev, state, false);

drm_atomic_helper_wait_for_dependencies(state);

@@ -1235,6 +1253,12 @@ int drm_atomic_helper_commit(struct drm_device *dev,
if (ret)
return ret;

+   if (!nonblock) {
+   ret = drm_atomic_helper_wait_for_fences(dev, state, true);
+   if (ret)
+   return ret;
+   }
+
/*
 * 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
diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index 4a8a6f1..9518e43 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -112,7 +112,7 @@ static void complete_commit(struct msm_commit *c, bool 
async)
struct msm_drm_private *priv = dev->dev_private;
struct msm_kms *kms = priv->kms;

-   drm_atomic_helper_wait_for_fences(dev, state);
+   drm_atomic_helper_wait_for_fences(dev, state, false);

kms->funcs->prepare_commit(kms, state);

diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index d86ae5d..a42c34b 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -43,8 +43,9 @@ int drm_atomic_helper_commit(struct drm_device *dev,
 struct drm_atomic_state *state,

[PATCH 2/2] drm: make DRI1 drivers depend on BROKEN

2016-08-25 Thread Connor Behan

On 25/08/16 11:13 AM, Alex Deucher wrote:
> On Thu, Aug 25, 2016 at 11:04 AM, Emil Velikov
>  wrote:
>> On 25 August 2016 at 12:14, Daniel Vetter  wrote:
>>> On Thu, Aug 04, 2016 at 09:15:07AM +0100, Chris Wilson wrote:
>>>> On Thu, Aug 04, 2016 at 10:06:57AM +0200, David Herrmann wrote:
>>>>> The legacy DRI1 drivers expose highly broken interfaces to user-space. No
>>>>> modern system should enable them, or you will effectively allow user-space
>>>>> to circumvent most of your kernel security measures. The DRI1 kernel APIs
>>>>> are simply broken.
>>>>>
>>>>> User-space can always use vesafb/efifb/simplefb and friends to get working
>>>>> graphics.
>>>>>
>>>>> Lets hide the old drivers behind CONFIG_BROKEN. In case they turn out to
>>>>> be still used (really?), we can easily revert this and figure out a way to
>>>>> move them out of sight (e.g., moving all DRI1 drivers to
>>>>> drivers/gpu/dri1/).
>>>>>
>>>>> Signed-off-by: David Herrmann 
>>>> Acked-by: Chris Wilson 
>>>>
>>>> I'd rather have a couple of distro devs check if they are still using
>>>> any of these, and would value their a-b/r-b.
>>> Mesa stopped shipping dri1 drivers years ago, and neither Fedora and
>>> Debian here have that old version packaged (it should keep working since
>>> the dri loader is an ABI). I don't think anyone needs this, and if I'm
>>> wrong we'll hear about it ;-)
>>>
>> Archlinux (which seems to be picking more users) is still shipping
>> dri1 drivers - both mesa and X. No idea for many actually use those
>> and/or for how much longer the packages will be around.
>>
>> IIRC the maintainer, Connor, used to hack on the xf86-video-r128 with
>> plans(?) on getting things KMS aware. Not sure if that was by
>> extending the existing radeon kernel, ddx, mesa driver(s) or
>> otherwise.
>> Connor, can you shed some light ?
>>
> r128 is 90% the same as early radeons so it would make sense to add
> support to radeon.
>
> Alex

Ccing Kevin Brace.

The drivers were removed from mesa and "you won't have to freeze your
kernel or anything" was one of the justifications given at the time for
why this wasn't a bad idea. So yes, I have dri1 packages in the
Archlinux repos with no plans to drop them. The people who have emailed
me about them and filed bugs are probably much less than 1% of the user
base but I've never considered that relevant. The point is that
hobbyists who want to use old hardware or play with seldomly updated
drivers should be able to do this without too many additional hurdles.

AFAIK the drivers still work as well as they did in the late 90s. And
it's easy for security conscious people to not modprobe them. My -1
would probably mean more if I were still following my initial plans of
adding r128 support to the radeon kernel module but at some point while
reading documentation I lost motivation. Hopefully this is temporary.


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

[PATCH 2/2] drm: make DRI1 drivers depend on BROKEN

2016-08-25 Thread Alex Deucher

On Thu, Aug 25, 2016 at 11:04 AM, Emil Velikov  
wrote:
> On 25 August 2016 at 12:14, Daniel Vetter  wrote:
>> On Thu, Aug 04, 2016 at 09:15:07AM +0100, Chris Wilson wrote:
>>> On Thu, Aug 04, 2016 at 10:06:57AM +0200, David Herrmann wrote:
>>> > The legacy DRI1 drivers expose highly broken interfaces to user-space. No
>>> > modern system should enable them, or you will effectively allow user-space
>>> > to circumvent most of your kernel security measures. The DRI1 kernel APIs
>>> > are simply broken.
>>> >
>>> > User-space can always use vesafb/efifb/simplefb and friends to get working
>>> > graphics.
>>> >
>>> > Lets hide the old drivers behind CONFIG_BROKEN. In case they turn out to
>>> > be still used (really?), we can easily revert this and figure out a way to
>>> > move them out of sight (e.g., moving all DRI1 drivers to
>>> > drivers/gpu/dri1/).
>>> >
>>> > Signed-off-by: David Herrmann 
>>>
>>> Acked-by: Chris Wilson 
>>>
>>> I'd rather have a couple of distro devs check if they are still using
>>> any of these, and would value their a-b/r-b.
>>
>> Mesa stopped shipping dri1 drivers years ago, and neither Fedora and
>> Debian here have that old version packaged (it should keep working since
>> the dri loader is an ABI). I don't think anyone needs this, and if I'm
>> wrong we'll hear about it ;-)
>>
> Archlinux (which seems to be picking more users) is still shipping
> dri1 drivers - both mesa and X. No idea for many actually use those
> and/or for how much longer the packages will be around.
>
> IIRC the maintainer, Connor, used to hack on the xf86-video-r128 with
> plans(?) on getting things KMS aware. Not sure if that was by
> extending the existing radeon kernel, ddx, mesa driver(s) or
> otherwise.
> Connor, can you shed some light ?
>

r128 is 90% the same as early radeons so it would make sense to add
support to radeon.

Alex

[PULL] drm-intel-fixes

2016-08-25 Thread Jani Nikula


Hi Dave, i915 fixes for v4.8.

BR,
Jani.

The following changes since commit fa8410b355251fd30341662a40ac6b22d3e38468:

  Linux 4.8-rc3 (2016-08-21 16:14:10 -0700)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2016-08-25

for you to fetch changes up to 177d91aaea4bcafb29232336bafaa521b85286aa:

  drm/i915: Fix botched merge that downgrades CSR versions. (2016-08-22 
16:08:32 +0300)


Chris Wilson (1):
  drm/i915: Unconditionally flush any chipset buffers before execbuf

Dave Gordon (1):
  drm/i915: Reattach comment, complete type specification

Lyude (3):
  drm/i915/gen6+: Interpret mailbox error flags
  drm/i915/skl: Add support for the SAGV, fix underrun hangs
  drm/i915/skl: Ensure pipes with changed wms get added to the state

Maarten Lankhorst (1):
  drm/i915: Fix botched merge that downgrades CSR versions.

Matt Roper (3):
  drm/i915/gen9: Initialize intel_state->active_crtcs during WM 
sanitization (v2)
  drm/i915/gen9: Drop invalid WARN() during data rate calculation
  drm/i915/gen9: Only copy WM results for changed pipes to skl_hw

 drivers/gpu/drm/i915/i915_drv.h|  13 +-
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |  13 +-
 drivers/gpu/drm/i915/i915_reg.h|  13 ++
 drivers/gpu/drm/i915/intel_csr.c   |   8 +-
 drivers/gpu/drm/i915/intel_display.c   |  11 ++
 drivers/gpu/drm/i915/intel_drv.h   |   3 +
 drivers/gpu/drm/i915/intel_pm.c| 270 -
 7 files changed, 309 insertions(+), 22 deletions(-)

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH v3 3/3] drm: simple_kms_helper: add support for bridges

2016-08-25 Thread Andrea Merello

Introduce drm_simple_display_pipe_attach_bridge() and
drm_simple_display_pipe_detach_bridge() in order to make it possible to use
drm encoders with the simple display pipes managed by simple_kms_helpers

Suggested-by: Daniel Vetter 
Signed-off-by: Andrea Merello 
Reviewed-by: Daniel Vetter 
Cc: Noralf TrÃ¸nnes 
Cc: Daniel Vetter 
Cc: David Airlie 
---
 drivers/gpu/drm/drm_simple_kms_helper.c | 40 +
 include/drm/drm_simple_kms_helper.h |  5 +
 2 files changed, 45 insertions(+)

diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
b/drivers/gpu/drm/drm_simple_kms_helper.c
index 3301e4a..8e9858b 100644
--- a/drivers/gpu/drm/drm_simple_kms_helper.c
+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
@@ -140,6 +140,46 @@ static const struct drm_plane_funcs 
drm_simple_kms_plane_funcs = {
 };

 /**
+ * drm_simple_display_pipe_attach_bridge - Attach a bridge to the display pipe
+ * @pipe: simple display pipe object
+ * @bridge: bridge to attach
+ *
+ * Makes it possible to still use the drm_simple_display_pipe helpers when
+ * a DRM bridge has to be used.
+ *
+ * Note that you probably want to initialize the pipe by passing a NULL
+ * connector to drm_simple_display_pipe_init().
+ *
+ * Returns:
+ * Zero on success, negative error code on failure.
+ */
+int drm_simple_display_pipe_attach_bridge(struct drm_simple_display_pipe *pipe,
+   struct drm_bridge *bridge)
+{
+   bridge->encoder = >encoder;
+   pipe->encoder.bridge = bridge;
+   return drm_bridge_attach(pipe->encoder.dev, bridge);
+}
+EXPORT_SYMBOL(drm_simple_display_pipe_attach_bridge);
+
+/**
+ * drm_simple_display_pipe_detach_bridge - Detach the bridge from the display 
pipe
+ * @pipe: simple display pipe object
+ *
+ * Detaches the drm bridge previously attached with
+ * drm_simple_display_pipe_attach_bridge()
+ */
+void drm_simple_display_pipe_detach_bridge(struct drm_simple_display_pipe 
*pipe)
+{
+   if (WARN_ON(!pipe->encoder.bridge))
+   return;
+
+   drm_bridge_detach(pipe->encoder.bridge);
+   pipe->encoder.bridge = NULL;
+}
+EXPORT_SYMBOL(drm_simple_display_pipe_detach_bridge);
+
+/**
  * drm_simple_display_pipe_init - Initialize a simple display pipeline
  * @dev: DRM device
  * @pipe: simple display pipe object to initialize
diff --git a/include/drm/drm_simple_kms_helper.h 
b/include/drm/drm_simple_kms_helper.h
index 2690397..5245d1f 100644
--- a/include/drm/drm_simple_kms_helper.h
+++ b/include/drm/drm_simple_kms_helper.h
@@ -85,6 +85,11 @@ struct drm_simple_display_pipe {
const struct drm_simple_display_pipe_funcs *funcs;
 };

+int drm_simple_display_pipe_attach_bridge(struct drm_simple_display_pipe *pipe,
+   struct drm_bridge *bridge);
+
+void drm_simple_display_pipe_detach_bridge(struct drm_simple_display_pipe 
*pipe);
+
 int drm_simple_display_pipe_init(struct drm_device *dev,
struct drm_simple_display_pipe *pipe,
const struct drm_simple_display_pipe_funcs *funcs,
-- 
2.7.4

[PATCH v3 2/3] drm: simple_kms_helper: make connector optional at init time

2016-08-25 Thread Andrea Merello

drm_simple_display_pipe_init() pretends to attach a connector
to the display pipe.

In case a drm bridge has to be used, then it's the bridge that
takes care of connectors.

This patch makes the connector parameter optional for
drm_simple_display_pipe_init(), so that a drm bridge could
handle connector by itself later.

Signed-off-by: Andrea Merello 
Reviewed-by: Daniel Vetter 
Cc: David Airlie 
Cc: Noralf TrÃ¸nnes 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/drm_simple_kms_helper.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
b/drivers/gpu/drm/drm_simple_kms_helper.c
index 4476310..3301e4a 100644
--- a/drivers/gpu/drm/drm_simple_kms_helper.c
+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
@@ -146,10 +146,15 @@ static const struct drm_plane_funcs 
drm_simple_kms_plane_funcs = {
  * @funcs: callbacks for the display pipe (optional)
  * @formats: array of supported formats (DRM_FORMAT\_\*)
  * @format_count: number of elements in @formats
- * @connector: connector to attach and register
+ * @connector: connector to attach and register (optional)
  *
  * Sets up a display pipeline which consist of a really simple
- * plane-crtc-encoder pipe coupled with the provided connector.
+ * plane-crtc-encoder pipe.
+ *
+ * If a connector is supplied, the pipe will be coupled with the provided
+ * connector. You may supply a NULL connector when using drm bridges, that
+ * handle connectors themselves (see drm_simple_display_pipe_attach_bridge()).
+ *
  * Teardown of a simple display pipe is all handled automatically by the drm
  * core through calling drm_mode_config_cleanup(). Drivers afterwards need to
  * release the memory for the structure themselves.
@@ -188,7 +193,7 @@ int drm_simple_display_pipe_init(struct drm_device *dev,
encoder->possible_crtcs = 1 << drm_crtc_index(crtc);
ret = drm_encoder_init(dev, encoder, _simple_kms_encoder_funcs,
   DRM_MODE_ENCODER_NONE, NULL);
-   if (ret)
+   if (ret || !connector)
return ret;

return drm_mode_connector_attach_encoder(connector, encoder);
-- 
2.7.4

[PATCH v3 1/3] drm/bridge: introduce bridge detaching mechanism

2016-08-25 Thread Andrea Merello

Up to now, once a bridge has been attached to a DRM device, it cannot
be undone.

In particular you couldn't rmmod/insmod a DRM driver that uses a bridge,
because the bridge would remain bound to the first (dead) driver instance.

This patch fixes this by introducing drm_encoder_detach() and a ->detach
callback in drm_bridge_funcs for the bridge to be notified about detaches.

It's DRM/KMS driver responsibility to call drm_encoder_detach().

While adding the bridge detach callback, with its kerneldoc, I also added
kerneldoc for attach callback.

Few other kerneldocs fixes around there are included.

Suggested-by: Daniel Vetter 
Suggested-by: Lucas Stach 
Signed-off-by: Andrea Merello 
Cc: Archit Taneja 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Lucas Stach 
---
 drivers/gpu/drm/drm_bridge.c | 29 +++--
 include/drm/drm_crtc.h   | 26 +-
 2 files changed, 52 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 2555430..4840466 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -98,11 +98,11 @@ EXPORT_SYMBOL(drm_bridge_remove);
  * @dev: DRM device
  * @bridge: bridge control structure
  *
- * called by a kms driver to link one of our encoder/bridge to the given
+ * Called by a kms driver to link one of our encoder/bridge to the given
  * bridge.
  *
  * Note that setting up links between the bridge and our encoder/bridge
- * objects needs to be handled by the kms driver itself
+ * objects needs to be handled by the kms driver itself.
  *
  * RETURNS:
  * Zero on success, error code on failure
@@ -125,6 +125,31 @@ int drm_bridge_attach(struct drm_device *dev, struct 
drm_bridge *bridge)
 EXPORT_SYMBOL(drm_bridge_attach);

 /**
+ * drm_bridge_detach - deassociate given bridge from its DRM device
+ *
+ * @bridge: bridge control structure
+ *
+ * Called by a kms driver to unlink the given bridge from its DRM device.
+ *
+ * Note that tearing down links between the bridge and our encoder/bridge
+ * objects needs to be handled by the kms driver itself.
+ */
+void drm_bridge_detach(struct drm_bridge *bridge)
+{
+   if (WARN_ON(!bridge))
+   return;
+
+   if (WARN_ON(!bridge->dev))
+   return;
+
+   if (bridge->funcs->detach)
+   bridge->funcs->detach(bridge);
+
+   bridge->dev = NULL;
+}
+EXPORT_SYMBOL(drm_bridge_detach);
+
+/**
  * DOC: bridge callbacks
  *
  * The _bridge_funcs ops are populated by the bridge driver. The DRM
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 3fa0275..bb214a1 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1118,12 +1118,33 @@ struct drm_plane {

 /**
  * struct drm_bridge_funcs - drm_bridge control functions
- * @attach: Called during drm_bridge_attach
  */
 struct drm_bridge_funcs {
+   /**
+* @attach:
+*
+* This callback is invoked whenever our bridge is being attached to a
+* _encoder.
+*
+* The attach callback is optional.
+*
+* RETURNS:
+*
+* Zero on success, error code on failure.
+*/
int (*attach)(struct drm_bridge *bridge);

/**
+* @detach:
+*
+* This callback is invoked whenever our bridge is being detached from a
+* _encoder.
+*
+* The detach callback is optional.
+*/
+   void (*detach)(struct drm_bridge *bridge);
+
+   /**
 * @mode_fixup:
 *
 * This callback is used to validate and adjust a mode. The paramater
@@ -1137,6 +1158,8 @@ struct drm_bridge_funcs {
 * this function passes all other callbacks must succeed for this
 * configuration.
 *
+* The mode_fixup callback is optional.
+*
 * NOTE:
 *
 * This function is called in the check phase of atomic modesets, which
@@ -2426,6 +2449,7 @@ extern int drm_bridge_add(struct drm_bridge *bridge);
 extern void drm_bridge_remove(struct drm_bridge *bridge);
 extern struct drm_bridge *of_drm_find_bridge(struct device_node *np);
 extern int drm_bridge_attach(struct drm_device *dev, struct drm_bridge 
*bridge);
+extern void drm_bridge_detach(struct drm_bridge *bridge);

 bool drm_bridge_mode_fixup(struct drm_bridge *bridge,
const struct drm_display_mode *mode,
-- 
2.7.4

[RFC 0/2] New feature: Framebuffer processors

On Thu, Aug 25, 2016 at 05:06:55PM +0900, Inki Dae wrote:
> 
> 
> 2016ë 08ì 24ì¼ 20:57ì Daniel Vetter ì´(ê°) ì´ ê¸:
> > On Wed, Aug 24, 2016 at 08:44:24PM +0900, Inki Dae wrote:
> >> Hi,
> >>
> >> 2016ë 08ì 23ì¼ 18:41ì Daniel Stone ì´(ê°) ì´ ê¸:
> >>> Hi,
> >>>
> >>> On 22 August 2016 at 16:23, Rob Clark  wrote:
>  I guess a lot comes down to 'how long before hw designers bolt a CP to
>  the thing'..  at that point, I think you especially don't want a
>  per-blit kernel interface.
> >>>
> >>> Regardless of whether or not we want it, we already _have_ it, in the
> >>> form of V4L2 M2M. There are already a few IP blocks working on that, I
> >>> believe. If V4L2 <-> KMS interop is painful, well, we need to fix that
> >>> anyway ...
> >>
> >> So we are trying this. We had expereneced using V4L2 and DRM together on
> >> Linux Platform makes it too complicated, and also integrated DRM with
> >> M2M such as 2D and Post processor makes it simplified.  So We have been
> >> trying to move existing V4L2 based drivers into DRM excepting HW Video
> >> Codec - called it MFC - and Camera sensor and relevant things.
> >> I think now V4L2 and DRM frameworks may make many engineers confusing
> >> because there are the same devices which can be controlled by V4L2 and
> >> DRM frameworks - maybe we would need more efforts like Laurent did with
> >> Live source[1] in the future.
> >
> > Can you pls explain in more detail where working with both v4l and drm
> > drivers and making them cooperate using dma-bufs poses problems? We should
> > definitely fix that.
> 
> I think it would be most Linux Platforms - Android, Chrome and Tizen -
> which would use OpenMAX/GStreammer for Multimedia and X or
> Wayland/SurfaceFlinger for Display.

Yes, that's the use case. Where is the problem in making this happen? v4l
can import dma-bufs, drm can export them, and there's plenty devices
shipping (afaik) that make use of exact this pipeline. Can you pls explain
what problem you've hit trying to make this work on exynos?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH v3 1/5] drm/rockchip: sort registers define by chip's number

2016-08-25 Thread Mark yao

On 2016å¹´08æ23æ¥ 21:13, Sean Paul wrote:
> On Mon, Aug 22, 2016 at 8:40 PM, Mark yao  wrote:
>> On 2016å¹´08æ23æ¥ 04:30, Sean Paul wrote:
>>> On Thu, Aug 18, 2016 at 6:02 AM, Mark yao  
>>> wrote:
 On 2016å¹´08æ18æ¥ 17:11, Daniel Vetter wrote:
> On Thu, Aug 18, 2016 at 05:08:14PM +0800, Mark yao wrote:
>>> Hi Sean
>>>
>>> Thanks for send v3 patch for rk3399 vop support.
>>>
>>> But sorry for that, I had changed my mind, those patches are
>>> deprecated,
>>> I have new rk3399 patch on my downstream kernel, I will upstream soon.
> Wut? Imo merge Sean's patch here, and then rebase your downstream
> patches
> on top of it. That you have a downstream tree which is out of sync with
> upstream shouldn't be a reason to stall upstream development.
> -Daniel
>
 Yeah, Sorry for that.

 In fact, on my downstream kernel, also have those patches, my new rk3399
 patches are based on them,
 but the new rk3399 patches will cover the those patches,  Sean's patches
 is
 old version.

 I just want to fast forward, don't want to send two version drivers to
 upstream.
 but if you and Dave feel ok for that, I have no problem:-) .

 merged Sean's patches and then apply new version patches.

>>> Ok, so can I get a review/ack for these revised patches then?
>>> Something is better than nothing, and there's a bunch of stuff that
>>> depends on these changes.
>>>
>>> Sean
>> Yes, But I miss your [PATCH v3 0/5] and [PATCH v3 4/5]. do you mean the lost
>> patches use v2 version?
>>
> Yes, v2 4/5 was reviewed as-is, so I just applied it.
>
> Sean
Applied this series to my drm-next.

Thanks.

>>>
 Thanks.

 --
 ï¼ark Yao


>>>
>>
>> --
>> ï¼ark Yao
>>
>>
>
>


-- 
ï¼ark Yao

[PATCH v3 5/5] gpu: drm: exynos_hdmi: Remove duplicate initialization of regulator bulk consumer

2016-08-25 Thread Andrzej Hajda

On 08/24/2016 03:07 PM, Milo Kim wrote:
> The helper, devm_regulator_bulk_get() initializes the consumer as NULL,
> so this code can be ignored.
>
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Cc: David Airlie 
> Cc: Inki Dae 
> Cc: Joonyoung Shim 
> Cc: Seung-Woo Kim 
> Cc: Kyungmin Park 
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-samsung-soc at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org
> Cc: dri-devel at lists.freedesktop.org
> Signed-off-by: Milo Kim 
Reviewed-by: Andrzej Hajda 
--
Regards
Andrzej
> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 249cb23..4e17877f 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -1669,10 +1669,9 @@ static int hdmi_resources_init(struct hdmi_context 
> *hdata)
>   if (ret)
>   return ret;
>  
> - for (i = 0; i < ARRAY_SIZE(supply); ++i) {
> + for (i = 0; i < ARRAY_SIZE(supply); ++i)
>   hdata->regul_bulk[i].supply = supply[i];
> - hdata->regul_bulk[i].consumer = NULL;
> - }
> +
>   ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(supply), 
> hdata->regul_bulk);
>   if (ret) {
>   if (ret != -EPROBE_DEFER)

[PATCH v3 3/5] gpu: drm: exynos_hdmi: Move DDC logic into single function

2016-08-25 Thread Andrzej Hajda

On 08/24/2016 03:07 PM, Milo Kim wrote:
> Paring DT properties and getting the I2C adapter in one function.
>
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Cc: David Airlie 
> Cc: Inki Dae 
> Cc: Joonyoung Shim 
> Cc: Seung-Woo Kim 
> Cc: Kyungmin Park 
> Cc: Rob Herring 
> Cc: devicetree at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-samsung-soc at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org
> Cc: dri-devel at lists.freedesktop.org
> Signed-off-by: Milo Kim 
> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 46 
> 
>  1 file changed, 25 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 2275efe..8d99b5d 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -1760,16 +1760,34 @@ static const struct component_ops hdmi_component_ops 
> = {
>   .unbind = hdmi_unbind,
>  };
>  
> -static struct device_node *hdmi_legacy_ddc_dt_binding(struct device *dev)
> +static int hdmi_get_ddc_adapter(struct hdmi_context *hdata)
>  {
>   const char *compatible_str = "samsung,exynos4210-hdmiddc";
>   struct device_node *np;
> + struct i2c_adapter *adpt;
>  
>   np = of_find_compatible_node(NULL, NULL, compatible_str);
>   if (np)
> - return of_get_next_parent(np);
> + np = of_get_next_parent(np);
> + else
> + np = of_parse_phandle(hdata->dev->of_node, "ddc", 0);
> +
> + if (!np) {
> + DRM_ERROR("Failed to find ddc node in device tree\n");
> + return -ENODEV;
> + }
>  
> - return NULL;
> + adpt = of_find_i2c_adapter_by_node(np);
You can put of_node_put here, instead of duplicating it on both
execution paths.
> + if (!adpt) {
> + DRM_ERROR("Failed to get ddc i2c adapter by node\n");
In case of probe deferring DRM_INFO should be enough, or even DRM_DEBUG.
> + of_node_put(np);
> + return -EPROBE_DEFER;
> + }
> +
> + hdata->ddc_adpt = adpt;
> + of_node_put(np);
> +
> + return 0;
>  }
>  
>  static struct device_node *hdmi_legacy_phy_dt_binding(struct device *dev)
> @@ -1781,7 +1799,7 @@ static struct device_node 
> *hdmi_legacy_phy_dt_binding(struct device *dev)
>  
>  static int hdmi_probe(struct platform_device *pdev)
>  {
> - struct device_node *ddc_node, *phy_node;
> + struct device_node *phy_node;
>   struct device *dev = >dev;
>   struct hdmi_context *hdata;
>   struct resource *res;
> @@ -1811,23 +1829,9 @@ static int hdmi_probe(struct platform_device *pdev)
>   return ret;
>   }
>  
> - ddc_node = hdmi_legacy_ddc_dt_binding(dev);
> - if (ddc_node)
> - goto out_get_ddc_adpt;
> -
> - ddc_node = of_parse_phandle(dev->of_node, "ddc", 0);
> - if (!ddc_node) {
> - DRM_ERROR("Failed to find ddc node in device tree\n");
> - return -ENODEV;
> - }
> - of_node_put(dev->of_node);
> -
> -out_get_ddc_adpt:
> - hdata->ddc_adpt = of_find_i2c_adapter_by_node(ddc_node);
> - if (!hdata->ddc_adpt) {
> - DRM_ERROR("Failed to get ddc i2c adapter by node\n");
> - return -EPROBE_DEFER;
> - }
> + ret = hdmi_get_ddc_adapter(hdata);
> + if (ret)
> + return ret;
>  
>   phy_node = hdmi_legacy_phy_dt_binding(dev);
>   if (phy_node)

[PATCH v2 3/3] drm: simple_kms_helper: add support for bridges

On Wed, Aug 24, 2016 at 02:06:01PM +0200, Andrea Merello wrote:
> Introduce drm_simple_display_pipe_attach_bridge() and
> drm_simple_display_pipe_detach_bridge() in order to make it possible to use
> drm encoders with the simple display pipes managed by simple_kms_helpers
> 
> Suggested-by: Daniel Vetter 
> Signed-off-by: Andrea Merello 
> Cc: Noralf TrÃ¸nnes 
> Cc: Daniel Vetter 
> Cc: David Airlie 
> ---
>  drivers/gpu/drm/drm_simple_kms_helper.c | 42 
> -
>  include/drm/drm_simple_kms_helper.h |  5 
>  2 files changed, 46 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
> b/drivers/gpu/drm/drm_simple_kms_helper.c
> index d07cdb8..dfa3f1b 100644
> --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> @@ -140,6 +140,46 @@ static const struct drm_plane_funcs 
> drm_simple_kms_plane_funcs = {
>  };
>  
>  /**
> + * drm_simple_display_pipe_attach_bridge - Attach a bridge to the display 
> pipe
> + * @pipe: simple display pipe object
> + * @bridge: bridge to attach
> + *
> + * Makes it possible to still use the drm_simple_display_pipe helpers when
> + * a DRM bridge has to be used.
> + * Note that you probably want to initialize the pipe by passing a NULL
> + * connector to drm_simple_display_pipe_init()

Same nit: New paragraphs need and empty line, or reflow to make it one
that uses the full width.

> + *
> + * Returns:
> + * Zero on success, negative error code on failure.
> + */
> +int drm_simple_display_pipe_attach_bridge(struct drm_simple_display_pipe 
> *pipe,
> + struct drm_bridge *bridge)
> +{
> + bridge->encoder = >encoder;
> + pipe->encoder.bridge = bridge;
> + return drm_bridge_attach(pipe->encoder.dev, bridge);
> +}
> +EXPORT_SYMBOL(drm_simple_display_pipe_attach_bridge);
> +
> +/**
> + * drm_simple_display_pipe_detach_bridge - Detach the bridge from the 
> display pipe
> + * @pipe: simple display pipe object
> + *
> + * Detaches the drm bridge previously attached with
> + * drm_simple_display_pipe_attach_bridge()
> + *

Empty line.

With the nits addressed: Reviewed-by: Daniel Vetter 

> + */
> +void drm_simple_display_pipe_detach_bridge(struct drm_simple_display_pipe 
> *pipe)
> +{
> + if (WARN_ON(!pipe->encoder.bridge))
> + return;
> +
> + drm_bridge_detach(pipe->encoder.bridge);
> + pipe->encoder.bridge = NULL;
> +}
> +EXPORT_SYMBOL(drm_simple_display_pipe_detach_bridge);
> +
> +/**
>   * drm_simple_display_pipe_init - Initialize a simple display pipeline
>   * @dev: DRM device
>   * @pipe: simple display pipe object to initialize
> @@ -152,7 +192,7 @@ static const struct drm_plane_funcs 
> drm_simple_kms_plane_funcs = {
>   * plane-crtc-encoder pipe.
>   * If a connector is supplied, the pipe will be coupled with the provided
>   * connector. You may supply a NULL connector when using drm bridges, that
> - * handle connectors themselves (see 
> drm_simple_display_pipe_bridge_attach()).
> + * handle connectors themselves (see 
> drm_simple_display_pipe_attach_bridge()).
>   * Teardown of a simple display pipe is all handled automatically by the drm
>   * core through calling drm_mode_config_cleanup(). Drivers afterwards need to
>   * release the memory for the structure themselves.
> diff --git a/include/drm/drm_simple_kms_helper.h 
> b/include/drm/drm_simple_kms_helper.h
> index 2690397..5245d1f 100644
> --- a/include/drm/drm_simple_kms_helper.h
> +++ b/include/drm/drm_simple_kms_helper.h
> @@ -85,6 +85,11 @@ struct drm_simple_display_pipe {
>   const struct drm_simple_display_pipe_funcs *funcs;
>  };
>  
> +int drm_simple_display_pipe_attach_bridge(struct drm_simple_display_pipe 
> *pipe,
> + struct drm_bridge *bridge);
> +
> +void drm_simple_display_pipe_detach_bridge(struct drm_simple_display_pipe 
> *pipe);
> +
>  int drm_simple_display_pipe_init(struct drm_device *dev,
>   struct drm_simple_display_pipe *pipe,
>   const struct drm_simple_display_pipe_funcs *funcs,
> -- 
> 2.7.4
> 

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

[PATCH v2 2/3] drm: simple_kms_helper: make connector optional at init time

On Wed, Aug 24, 2016 at 02:06:00PM +0200, Andrea Merello wrote:
> drm_simple_display_pipe_init() pretends to attach a connector
> to the display pipe.
> 
> In case a drm bridge has to be used, then it's the bridge that
> takes care of connectors.
> 
> This patch makes the connector parameter optional for
> drm_simple_display_pipe_init(), so that a drm bridge could
> handle connector by itself later.
> 
> Signed-off-by: Andrea Merello 
> Cc: David Airlie 
> Cc: Noralf TrÃ¸nnes 
> Cc: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_simple_kms_helper.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
> b/drivers/gpu/drm/drm_simple_kms_helper.c
> index aeb7a75..d07cdb8 100644
> --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> @@ -146,10 +146,13 @@ static const struct drm_plane_funcs 
> drm_simple_kms_plane_funcs = {
>   * @funcs: callbacks for the display pipe (optional)
>   * @formats: array of supported formats (%DRM_FORMAT_*)
>   * @format_count: number of elements in @formats
> - * @connector: connector to attach and register
> + * @connector: connector to attach and register (optional)
>   *
>   * Sets up a display pipeline which consist of a really simple
> - * plane-crtc-encoder pipe coupled with the provided connector.
> + * plane-crtc-encoder pipe.

Nit: Empty comment line if you want to start a new paragraph. Otherwise
pls reflow the comment to make it use the full width.

With that Reviewed-by: Daniel Vetter 

I guess I'll let Archit apply the entire series once it's all ready.
-Daniel

> + * If a connector is supplied, the pipe will be coupled with the provided
> + * connector. You may supply a NULL connector when using drm bridges, that
> + * handle connectors themselves (see 
> drm_simple_display_pipe_bridge_attach()).
>   * Teardown of a simple display pipe is all handled automatically by the drm
>   * core through calling drm_mode_config_cleanup(). Drivers afterwards need to
>   * release the memory for the structure themselves.
> @@ -188,7 +191,7 @@ int drm_simple_display_pipe_init(struct drm_device *dev,
>   encoder->possible_crtcs = 1 << drm_crtc_index(crtc);
>   ret = drm_encoder_init(dev, encoder, _simple_kms_encoder_funcs,
>  DRM_MODE_ENCODER_NONE, NULL);
> - if (ret)
> + if (ret || !connector)
>   return ret;
>  
>   return drm_mode_connector_attach_encoder(connector, encoder);
> -- 
> 2.7.4
> 

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

[PATCH v2 1/3] drm/bridge: introduce bridge detaching mechanism

On Wed, Aug 24, 2016 at 02:05:59PM +0200, Andrea Merello wrote:
> Up to now, once a bridge has been attached to a DRM device, it cannot
> be undone.
> 
> In particular you couldn't rmmod/insmod a DRM driver that uses a bridge,
> because the bridge would remain bound to the first (dead) driver instance.
> 
> This patch fixes this by introducing drm_encoder_detach() and a ->detach
> callback in drm_bridge_funcs for the bridge to be notified about detaches.
> 
> It's DRM/KMS driver responsibility to call drm_encoder_detach().
> 
> While adding the bridge detach callback, with its kerneldoc, I also added
> kerneldoc for attach callback.
> 
> Suggested-by: Daniel Vetter 
> Suggested-by: Lucas Stach 
> Signed-off-by: Andrea Merello 
> Cc: Archit Taneja 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Lucas Stach 
> ---
>  drivers/gpu/drm/drm_bridge.c | 26 ++
>  include/drm/drm_crtc.h   | 17 +
>  2 files changed, 43 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index 2555430..a77b3e0 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -125,6 +125,32 @@ int drm_bridge_attach(struct drm_device *dev, struct 
> drm_bridge *bridge)
>  EXPORT_SYMBOL(drm_bridge_attach);
>  
>  /**
> + * drm_bridge_detach - deassociate given bridge from its DRM device
> + *
> + * @bridge: bridge control structure
> + *
> + * called by a kms driver to unlink the given bridge from its DRM device
> + *
> + * Note that tearing down links between the bridge and our encoder/bridge
> + * objects needs to be handled by the kms driver itself
> + *

Empty line, and we do full sentences (including capitalization and
punctuation) in the full kernel-doc paragraphs.

> + */
> +void drm_bridge_detach(struct drm_bridge *bridge)
> +{
> + if (WARN_ON(!bridge))
> + return;
> +
> + if (WARN_ON(!bridge->dev))
> + return;
> +
> + if (bridge->funcs->detach)
> + bridge->funcs->detach(bridge);
> +
> + bridge->dev = NULL;
> +}
> +EXPORT_SYMBOL(drm_bridge_detach);
> +
> +/**
>   * DOC: bridge callbacks
>   *
>   * The _bridge_funcs ops are populated by the bridge driver. The DRM
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index b618b50..5e25e23 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1765,9 +1765,25 @@ struct drm_plane {
>   * @attach: Called during drm_bridge_attach
>   */
>  struct drm_bridge_funcs {
> + /**
> +  * @attach:
> +  *
> +  * This callback is invoked whenever our bridge is being attached.

... attached to a _encoder. Similar for @detach.

Also I think we should mentation that these callbacks are optional, like
with the others. Just noticed that that remark is missing for @mode_fixup,
can you pls add it too?

lgtm otherwise.
-Daniel

> +  *
> +  * RETURNS:
> +  *
> +  * Zero on success, error code on failure
> +  */
>   int (*attach)(struct drm_bridge *bridge);
>  
>   /**
> +  * @detach:
> +  *
> +  * This callback is invoked whenever our bridge is being detached.
> +  */
> + void (*detach)(struct drm_bridge *bridge);
> +
> + /**
>* @mode_fixup:
>*
>* This callback is used to validate and adjust a mode. The paramater
> @@ -3196,6 +3212,7 @@ extern int drm_bridge_add(struct drm_bridge *bridge);
>  extern void drm_bridge_remove(struct drm_bridge *bridge);
>  extern struct drm_bridge *of_drm_find_bridge(struct device_node *np);
>  extern int drm_bridge_attach(struct drm_device *dev, struct drm_bridge 
> *bridge);
> +extern void drm_bridge_detach(struct drm_bridge *bridge);
>  
>  bool drm_bridge_mode_fixup(struct drm_bridge *bridge,
>   const struct drm_display_mode *mode,
> -- 
> 2.7.4
> 

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

[PATCH] drm/simple-helpers: Always add planes to the state update

On Wed, Aug 24, 2016 at 08:38:37PM +0200, Noralf TrÃ¸nnes wrote:
> 
> Den 23.08.2016 08:25, skrev Daniel Vetter:
> > Our update function is hooked to the single plane, which might not get
> > called for crtc-only updates. Which is surprising, so fix this by
> > always adding the plane.
> > 
> > While at it document how the event should be sent out better in
> > the kerneldoc.
> > 
> > Cc: Noralf TrÃ¸nnes 
> > Cc: andrea.merello at gmail.com
> > Tested-and-Reported-by: andrea.merello at gmail.com
> > Signed-off-by: Daniel Vetter 
> > ---
> > I'm not entirely sure we really want to put the responsibility for
> > this onto driver. Plan B) would be to remove the kerneldoc I added
> > here and call the right function from drm_simple_kms_plane_atomic_update.
> > That way simple drivers don't need to deal with that detail, and in
> > general those drivers don't care that much about the miniscule
> > possible race a generic implementation would cause. What do you
> > suggest as the best approach?
> 
> If the driver is responsible, a helper like this would be nice:
> 
> void drm_simple_display_pipe_handle_vblank_event(struct
> drm_simple_display_pipe *pipe)
> {
> struct drm_crtc *crtc = >crtc;
> 
> if (crtc->state && crtc->state->event) {
> spin_lock_irq(>dev->event_lock);
> drm_crtc_send_vblank_event(crtc, crtc->state->event);
> spin_unlock_irq(>dev->event_lock);
> crtc->state->event = NULL;

For a generic version we probably want to automatically switch to
drm_crtc_arm_vblank_event, if vblank support is available. That can be
checked by looking at drm_device->num_crtcs.

> }
> }
> 
> Then if the update() callback is not set, drm_simple_kms_plane_atomic_update
> calls this, and if it is set, then the driver has to do it or something
> similar.
> 
> It is difficult to predict what future drivers will need.
> Unless there are drivers on the horizon that will need to handle the
> event themselves, I suggest that we follow your plan B. If the need arises,
> we just add a one-liner to all drivers that has the update() callback set.

Hm yeah. What about merging this patch here for now (would need your
formal reviewed-by), and then later on when we have 2-3 simple drivers
using this we can reconsider? Since I dont have hw for any of them I can't
do this myself.

> Noralf.
> 
> Sidenote:
> When I converted simpledrm I had problems with flip_done timeouts.
> In the end I had to check for the event in disable/enable/update.
> Trying it again now, it's enough to do it in update().
> Not sure what has changed.

Trying again with this patch, or without? Since this patch here is meant
to exactly the problem that you need to handle the event in too many
places. If it's fixed with just latest drm-misc, that would be surprising
...
-Daniel

> 
> > -Daniel
> > ---
> >   drivers/gpu/drm/drm_simple_kms_helper.c | 7 +++
> >   include/drm/drm_simple_kms_helper.h | 6 ++
> >   2 files changed, 13 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c 
> > b/drivers/gpu/drm/drm_simple_kms_helper.c
> > index bada17166512..447631018426 100644
> > --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> > +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> > @@ -34,6 +34,12 @@ static const struct drm_encoder_funcs 
> > drm_simple_kms_encoder_funcs = {
> > .destroy = drm_encoder_cleanup,
> >   };
> > +static int drm_simple_kms_crtc_check(struct drm_crtc *crtc,
> > +struct drm_crtc_state *state)
> > +{
> > +   return drm_atomic_add_affected_planes(state->state, crtc);
> > +}
> > +
> >   static void drm_simple_kms_crtc_enable(struct drm_crtc *crtc)
> >   {
> > struct drm_simple_display_pipe *pipe;
> > @@ -57,6 +63,7 @@ static void drm_simple_kms_crtc_disable(struct drm_crtc 
> > *crtc)
> >   }
> >   static const struct drm_crtc_helper_funcs 
> > drm_simple_kms_crtc_helper_funcs = {
> > +   .atomic_check = drm_simple_kms_crtc_check,
> > .disable = drm_simple_kms_crtc_disable,
> > .enable = drm_simple_kms_crtc_enable,
> >   };
> > diff --git a/include/drm/drm_simple_kms_helper.h 
> > b/include/drm/drm_simple_kms_helper.h
> > index 269039722f91..826946ca2b82 100644
> > --- a/include/drm/drm_simple_kms_helper.h
> > +++ b/include/drm/drm_simple_kms_helper.h
> > @@ -60,6 +60,12 @@ struct drm_simple_display_pipe_funcs {
> >  *
> >  * This function is called when the underlying plane state is updated.
> >  * This hook is optional.
> > +*
> > +* This is the function drivers should submit the
> > +* _pending_vblank_event from. Using either
> > +* drm_crtc_arm_vblank_event(), when the driver supports vblank
> > +* interrupt handling, or drm_crtc_send_vblank_event() directly in case
> > +* the hardware lacks vblank support entirely.
> >  */
> > void (*update)(struct drm_simple_display_pipe *pipe,
> >struct drm_plane_state *plane_state);
> 

-- 
Daniel Vetter
Software Engineer, Intel

[PATCH v4 3/5] drm: add SimpleDRM driver

2016-08-25 Thread Rob Herring

On Mon, Aug 22, 2016 at 3:25 PM, Noralf TrÃ¸nnes  wrote:
> The SimpleDRM driver binds to simple-framebuffer devices and provides a
> DRM/KMS API. It provides only a single CRTC+encoder+connector combination
> plus one initial mode.
>
> Userspace can create dumb-buffers which can be blit into the real
> framebuffer similar to UDL. No access to the real framebuffer is allowed
> (compared to earlier version of this driver) to avoid security issues.
> Furthermore, this way we can support arbitrary modes as long as we have a
> conversion-helper.
>
> The driver was originally written by David Herrmann in 2014.
> My main contribution is to make use of drm_simple_kms_helper and
> rework the probe path to avoid use of the deprecated drm_platform_init()
> and drm_driver.{load,unload}().
> Additions have also been made for later changes to the Device Tree binding
> document, like support for clocks, regulators and having the node under
> /chosen. This code was lifted verbatim from simplefb.c.
>
> Cc: dh.herrmann at gmail.com
> Cc: libv at skynet.be
> Signed-off-by: Noralf TrÃ¸nnes 

[...]

> +   /* Count the number of regulator supplies */
> +   for_each_property_of_node(np, prop) {
> +   p = strstr(prop->name, SUPPLY_SUFFIX);
> +   if (p && p != prop->name)
> +   count++;
> +   }

The regulator API should have functions for this rather than open coding it.

> +
> +   if (!count)
> +   return 0;
> +
> +   sdrm->regulators = devm_kcalloc(>dev, count,
> +   sizeof(struct regulator *),
> +   GFP_KERNEL);
> +   if (!sdrm->regulators)
> +   return -ENOMEM;
> +
> +   /* Get all the regulators */
> +   for_each_property_of_node(np, prop) {
> +   char name[32]; /* 32 is max size of property name */
> +
> +   p = strstr(prop->name, SUPPLY_SUFFIX);
> +   if (!p || p == prop->name)
> +   continue;

This too.

> +
> +   strlcpy(name, prop->name,
> +   strlen(prop->name) - strlen(SUPPLY_SUFFIX) + 1);
> +   regulator = devm_regulator_get_optional(>dev, name);

[...]

> +   if (IS_ENABLED(CONFIG_OF_ADDRESS) && of_chosen) {
> +   struct device_node *np;
> +
> +   for_each_child_of_node(of_chosen, np) {
> +   if (of_device_is_compatible(np, "simple-framebuffer"))

Rather than exporting of_chosen, this whole chunk can be replaced with
a of_find_compatible_node call. Yes, that would match if
simple-framebuffer exists somewhere else in the DT, but it is not the
kernel's job to do DT validation.

> +   of_platform_device_create(np, NULL, NULL);
> +   }
> +   }

Rob

[PATCH v4 0/4] IPUv3 prep for i.MX5/6 v4l2 staging drivers, v4

2016-08-25 Thread Tim Harvey

On Wed, Aug 17, 2016 at 5:50 PM, Steve Longerbeam  
wrote:
> In this version:
>
> - rebased against latest drm-next.
> - cleaned up header includes in ipu-vdi.c.
> - do away with struct ipu_ic_tile_off in ipu-ic.c, and move tile offsets
>   into struct ipu_ic_tile. This paves the way for possibly allowing for
>   each tile to have different dimensions in the future.
>
>
> Steve Longerbeam (4):
>   gpu: ipu-v3: Add Video Deinterlacer unit
>   gpu: ipu-v3: Add FSU channel linking support
>   gpu: ipu-ic: Add complete image conversion support with tiling
>   gpu: ipu-ic: allow multiple handles to ic
>
>  drivers/gpu/ipu-v3/Makefile |2 +-
>  drivers/gpu/ipu-v3/ipu-common.c |  142 
>  drivers/gpu/ipu-v3/ipu-ic.c | 1719 
> ++-
>  drivers/gpu/ipu-v3/ipu-prv.h|   33 +
>  drivers/gpu/ipu-v3/ipu-vdi.c|  243 ++
>  include/video/imx-ipu-v3.h  |   93 ++-
>  6 files changed, 2195 insertions(+), 37 deletions(-)
>  create mode 100644 drivers/gpu/ipu-v3/ipu-vdi.c
>

Philipp,

Have you had a chance to review this last series of Steve's submitted
last week? We are down to 4 patches in gpu/ipu-v3 needed in order to
get his IMX5/6 capture driver into staging and the sooner we do that
the sooner we can get more testing and additional support/features for
it.

Regards,

Tim

[Bug 95306] Random Blank(black) screens on "Carrizo"

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

Michel DÃ¤nzer  changed:

   What|Removed |Added

 Attachment #126013|text/x-log  |text/plain
  mime type||

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

[Bug 97029] cik_sdma_copy_texture broken on Carrizo (mesa 12)

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

--- Comment #11 from Michel DÃ¤nzer  ---
(In reply to Johannes Hirte from comment #6)
> The flickering happens even with R600_DEBUG=nodma.

The flickering should be tracked separately from this report then. Feel free to
re-open bug 97119 for that, but you'll need to provide more information about
the flickering.

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

[Bug 153911] New: Nouveau driver overly verbose

2016-08-25 Thread bugzilla-dae...@bugzilla.kernel.org

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

Bug ID: 153911
   Summary: Nouveau driver overly verbose
   Product: Drivers
   Version: 2.5
Kernel Version: 4.7.2
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: be11f157cd19c4a2ba1e9c70a38b1a74 at protonmail.com
Regression: No

drivers/gpu/drm/nouveau/nouveau_drm.c

it overflowed my kernel log over two days. Also makes the virtual terminal
completely unusable without silencing the kernel. The function(macro?) used to
print the messages is NV_INFO

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 97477] i915g: gl_FragCoord is always (0.0, max_y)

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

Bug ID: 97477
Summary: i915g: gl_FragCoord is always (0.0, max_y)
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/Gallium/i915g
Assignee: dri-devel at lists.freedesktop.org
Reporter: nicholasbishop at gmail.com
QA Contact: dri-devel at lists.freedesktop.org

Created attachment 126029
--> https://bugs.freedesktop.org/attachment.cgi?id=126029=edit
Patch: Handle I915_SEMANTIC_POS when setting texCoords for gl_FragCoord

On Intel Pineview M hardware, the i915 gallium driver doesn't output the
correct gl_FragCoord. It seems to always have an X coord of 0.0 and a Y coord
of the window's height in pixels, e.g. 600.0f or such.

I believe this is a regression caused in part by commit
afa035031ff9e0c07a2297d864e46c76f7bfff58
(https://lists.freedesktop.org/archives/mesa-commit/2016-January/061181.html)

The old behavior used output zero, while the new behavior uses actual zeroes.
In the case of gl_FragCoord output zero happened to be the correct one.

I've attached a patch that seems to fix the issue for me. I ran the piglit
"quick" tests and observed 17 new tests passing, and one regression. I suspect
the regression is unimportant since it involves derivatives that aren't
implemented for this driver anyway:

"fs-dfdy-accuracy" test failed ... in i915_fpc_translate.c:
case TGSI_OPCODE_DDY:
/* XXX We just output 0 here */
debug_printf("Punting DDX/DDX\n");

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

[Bug 87071] LLVM triggered Diagnostic Handler: unsupported call to function S2KItSaltedSHA1Generator in gpg

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

--- Comment #2 from wadecline at hotmail.com ---
I've also run into this issue, although a workaround exists (see:
https://github.com/magnumripper/JohnTheRipper/issues/2204).  The problem
appears to be with the declaration of 'inline'; removing the 'inline'
declaration fixes the compilation issue.

Hardware/software information as follows is:
frostsnow at seneca ~/software/JohnTheRipper/run $ ./john --list=OpenCL-devices
Platform #0 name: Clover, version: OpenCL 1.1 Mesa 12.0.1
Device #0 (0) name: AMD HAWAII (DRM 2.45.0 / 4.7.0, LLVM 3.8.1)
Device vendor:  AMD
Device type:GPU (LE)
Device version: OpenCL 1.1 Mesa 12.0.1
Driver version: 12.0.1 - Catalyst  
Native vector widths:   char 16, short 8, int 4, long 2
Preferred vector width: char 16, short 8, int 4, long 2
Global Memory:  1024.0 MB
Local Memory:   32.0 KB (Local)
Max memory alloc. size: 256.2 MB
Max clock (MHz):1040
Max Work Group Size:256
Parallel compute cores: 44
Stream processors:  3520  (44 x 80)
Speed index:3660800

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

[Bug 97461] FS-UAE waits forever with glClientWaitSync() when using glFenceSync() on amdgpu/radeonsi

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

--- Comment #3 from Lem  ---
I just verified it with a new apitrace. There is indeed glFenceSync() being
called. Frame 3 now looks like:

1510 @0 glFenceSync(condition = GL_SYNC_GPU_COMMANDS_COMPLETE, flags = 0) =
0x8c47bf0
1511 @0 glFlush()
1512 @0 glClientWaitSync(sync = 0x8c47bf0, flags = GL_SYNC_FLUSH_COMMANDS_BIT,
timeout = 0) = GL_TIMEOUT_EXPIRED
1513 @0 glClientWaitSync(sync = 0x8c47bf0, flags = 0x0, timeout = 0) =
GL_ALREADY_SIGNALED
1514 @0 glBegin(mode = GL_QUADS)
1515 @0 glTexCoord2d(s = 0, t = nan)
...
1523 @0 glEnd()
1524 @0 glXSwapBuffers(dpy = 0x88db6a0, drawable = 83886088)

and onto Frame 4, and so forth.

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

[Bug 97461] FS-UAE waits forever with glClientWaitSync() when using glFenceSync() on amdgpu/radeonsi

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

--- Comment #2 from Lem  ---
Hi Marek,

Thanks for the patch. I *think* it worked. I fumbled my way through building
mesa (git cloning and applying the patch was easy), then copying just the new
mesa/lib/gallium/radeonsi_dri.so to
/usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so , leaving everything else
(binaries, libraries) as it is with the Padoka PPA, and now fs-uae will run
with fences enabled.

I haven't done any other tests (games etc) for any regressions.

Cheers

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

[Bug 97029] cik_sdma_copy_texture broken on Carrizo (mesa 12)

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

--- Comment #10 from Thomas J. Moore  ---
(In reply to Marek OlÅ¡Ã¡k from comment #9)
> Right now the plan is to disable SDMA texture copying for Carrizo on master
> and Mesa 12.0.

Fine by me.  Just wanted to make sure it was taken care of before the next Mesa
release, in case you decide to wait more than a month to respond again, given
approx. 2 months between Mesa releases.

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

[Bug 97029] cik_sdma_copy_texture broken on Carrizo (mesa 12)

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

--- Comment #9 from Marek OlÅ¡Ã¡k  ---
If I had known about the issue, we wouldn't have committed the change.

Right now the plan is to disable SDMA texture copying for Carrizo on master and
Mesa 12.0.

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

[Bug 97461] FS-UAE waits forever with glClientWaitSync() when using glFenceSync() on amdgpu/radeonsi