[PATCH v4] drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter support

[Vladimir Zapolskiy]

Hi Doug,

On 28.09.2015 19:29, Doug Anderson wrote:
> Vladimir,
> 
> On Mon, Sep 21, 2015 at 8:07 AM, Vladimir Zapolskiy
>  wrote:
>> - do I2C bus controller reinitialization on every data transfer,
>>   this change hopefully solves some observed problems on RK3288 platform
> 
> My apologies, but this appears to be a bad idea...
> 
> We just discovered that this was the root cause of a bug.  If an HDCP
> transfer is happening then the soft reset messes things up.  In our
> tree we've moving things back to the way they were.  :(

therefore I do the same.

Since unfortunately I'm limited in testing your tree and RK3288
platform, probably it might be more productive, if you send any updates
on top of my changes -- I'll be capable to review/test them for
regressions on iMX6 in vanilla.

--
With best wishes,
Vladimir

[Bug 84500] [radeonsi] radeon 0000:01:00.0: Packet0 not allowed!

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

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

--- Comment #52 from Chernovsky Oleg  ---
Created attachment 118502
  --> https://bugs.freedesktop.org/attachment.cgi?id=118502=edit
dmesg log

Just got this bug and GPU lockup while trying to play Guild Wars through wine.
Happens when I rotate camera at the start of the game extensively, forcing Mesa
to compile all the shaders at once.

It's repeatable so I can provide some logs here.

Radeon R9 270

Arch x86_64, Linux 4.2.1, brand new Mesa 11.0.1

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

[Bug 105051] Radeon sets max_brightness to -1, breaking GNOME backlight control on Macbook Pro mid-2015 11,5

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

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

--- Comment #3 from Alex Deucher  ---
(In reply to Robert Abraham from comment #2)
> 
> it works perfectly fine on 4.0.x kernel though.

The radeon backlight code hasn't really changed since it was added so
presumably something else did.  Can you bisect?  Since this is a mac, it's
possible the GPU driver does not actually control the backlight.  Everything is
a one off on macs.

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

[Bug 105111] amdgpu 0000:00:01.0: Invalid ROM contents (with A8-7600)

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

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

--- Comment #4 from Alex Deucher  ---
Does the open driver work with kernel 4.1.6?

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

[Bug 90263] GPU card fans run full speed at all times

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

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

--- Comment #18 from Chernovsky Oleg  ---
Hmm let me lay it out for you:

I was like you a year ago when I had my fan speed too high. I mmiotraced
proprietary fglrx driver and proposed a patch for this. Alex said that time
that reverse-engineered patches are not welcome upstream (various licensing
issues, I suppose) and suggested to pull a set of initial patches for handling
fan control through AMD IP bureaucracy. I agreed.

This took around month or even more, IIRC. These shinies are not sort of things
so easy to get from large corporation. In the end Alex handed me over these
patches and I was able to fix typos and implement fan control for SI and CI
cards.

I can do it for r600, but again, I will need patches of same kind and moreover,
working BARTS GPU in St. Petersburg where I live to test and debug it.

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

[PATCH] drm/doc: Update docs about device instance setup

[Daniel Vetter]

->load is deprecated, bus functions are deprecated and everyone
should use drm_dev_alloc

So update the .tmpl (and pull a bunch of the overview docs into the
sourcecode to increase chances that it'll stay in sync in the future)
and add notes to functions which are deprecated. I didn't bother to
clean up and document the unload sequence similarly since that one is
still a bit a mess: drm_dev_unregister does way too much,
drm_unplug_dev does what _unregister should be doing but then has the
complication of promising something it doesn't actually do (it doesn't
unplug existing open fds for instance, only prevents new ones).

Motivated since I don't want to hunt every new driver for usage of
drm_platform_init any more ;-)

v2: Reword the deprecation note for ->load a bit, using Laurent's
suggestion as an example (but making the wording a bit stronger even).
Fix spelling in commit message.

Cc: Laurent Pinchart 
Cc: David Herrmann 
Acked-by: David Herrmann 
Signed-off-by: Daniel Vetter 
---
 Documentation/DocBook/drm.tmpl | 99 --
 drivers/gpu/drm/drm_drv.c  | 55 +--
 drivers/gpu/drm/drm_pci.c  | 11 +
 drivers/gpu/drm/drm_platform.c |  3 ++
 4 files changed, 83 insertions(+), 85 deletions(-)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 5395cde6905e..6d24ebb97cda 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -138,14 +138,10 @@
 
   At the core of every DRM driver is a drm_driver
   structure. Drivers typically statically initialize a drm_driver 
structure,
-  and then pass it to one of the drm_*_init() 
functions
-  to register it with the DRM subsystem.
-
-
-  Newer drivers that no longer require a drm_bus
-  structure can alternatively use the low-level device initialization and
-  registration functions such as drm_dev_alloc() and
-  drm_dev_register() directly.
+  and then pass it to drm_dev_alloc() to allocate a
+  device instance. After the device instance is fully initialized it can be
+  registered (which makes it accessible from userspace) using
+  drm_dev_register().
 
 
   The drm_driver structure contains static
@@ -296,83 +292,12 @@ char *date;
   
 
 
-  Device Registration
-  
-A number of functions are provided to help with device registration.
-The functions deal with PCI and platform devices, respectively.
-  
-!Edrivers/gpu/drm/drm_pci.c
-!Edrivers/gpu/drm/drm_platform.c
-  
-New drivers that no longer rely on the services provided by the
-drm_bus structure can call the low-level
-device registration functions directly. The
-drm_dev_alloc() function can be used to allocate
-and initialize a new drm_device structure.
-Drivers will typically want to perform some additional setup on this
-structure, such as allocating driver-specific data and storing a
-pointer to it in the DRM device's 
dev_private
-field. Drivers should also set the device's unique name using the
-drm_dev_set_unique() function. After it has been
-set up a device can be registered with the DRM subsystem by calling
-drm_dev_register(). This will cause the device to
-be exposed to userspace and will call the driver's
-.load() implementation. When a device is
-removed, the DRM device can safely be unregistered and freed by calling
-drm_dev_unregister() followed by a call to
-drm_dev_unref().
-  
+  Device Instance and Driver Handling
+!Pdrivers/gpu/drm/drm_drv.c driver instance overview
 !Edrivers/gpu/drm/drm_drv.c
 
 
   Driver Load
-  
-The load method is the driver and device
-initialization entry point. The method is responsible for allocating 
and
-   initializing driver private data, performing resource allocation and
-   mapping (e.g. acquiring
-clocks, mapping registers or allocating command buffers), initializing
-the memory manager (), 
installing
-the IRQ handler (), setting up
-vertical blanking handling (), mode
-   setting () and initial output
-   configuration ().
-  
-  
-If compatibility is a concern (e.g. with drivers converted over from
-User Mode Setting to Kernel Mode Setting), care must be taken to 
prevent
-device initialization and control that is incompatible with currently
-active userspace drivers. For instance, if user level mode setting
-drivers are in use, it would be problematic to perform output discovery
- configuration at load time. Likewise, if user-level drivers
-unaware of memory management are in use, memory management and command
-buffer setup may need to be omitted. These requirements are
-driver-specific, and care needs to be taken 

[PATCH] drm: Enforce unlocked ioctl operation for kms driver ioctls

[Daniel Vetter]

With the prep patches for i915 all kms drivers either have
DRM_UNLOCKED on all their ioctls. Or the ioctl always directly returns
with an invariant return value when in modeset mode. But that's only
the case for i915 and radeon. The drm core ioctls are unfortunately
too much a mess still to dare this.

Follow-up patches will remove DRM_UNLOCKED from all kms drivers to
prove that this is indeed the case.

Also update the documentation.

v2: Really only do this for driver ioctls, spotted by David Herrmann.
And drop spurious whitespace change.

Cc: David Herrmann 
Signed-off-by: Daniel Vetter 
---
 Documentation/DocBook/drm.tmpl |  4 +++-
 drivers/gpu/drm/drm_ioctl.c| 10 --
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 8c654866e1a2..5395cde6905e 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -3747,7 +3747,9 @@ int num_ioctls;

 
  DRM_UNLOCKED - The ioctl handler will be called without locking
- the DRM global mutex
+ the DRM global mutex. This is the enforced default for kms drivers
+ (i.e. using the DRIVER_MODESET flag) and hence shouldn't be used
+ any more for new drivers.

  

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 530c501422fd..8ce2a0c59116 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -691,13 +691,16 @@ long drm_ioctl(struct file *filp,
char stack_kdata[128];
char *kdata = NULL;
unsigned int usize, asize, drv_size;
+   bool is_driver_ioctl;

dev = file_priv->minor->dev;

if (drm_device_is_unplugged(dev))
return -ENODEV;

-   if (nr >= DRM_COMMAND_BASE && nr < DRM_COMMAND_END) {
+   is_driver_ioctl = nr >= DRM_COMMAND_BASE && nr < DRM_COMMAND_END;
+
+   if (is_driver_ioctl) {
/* driver ioctl */
if (nr - DRM_COMMAND_BASE >= dev->driver->num_ioctls)
goto err_i1;
@@ -756,7 +759,10 @@ long drm_ioctl(struct file *filp,
memset(kdata, 0, usize);
}

-   if (ioctl->flags & DRM_UNLOCKED)
+   /* Enforce sane locking for kms driver ioctls. Core ioctls are
+* too messy still. */
+   if ((drm_core_check_feature(dev, DRIVER_MODESET) && is_driver_ioctl) ||
+   (ioctl->flags & DRM_UNLOCKED))
retcode = func(dev, kdata, file_priv);
else {
mutex_lock(_global_mutex);
-- 
2.5.1

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

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

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

--- Comment #13 from Mathias Tillman  ---
Sorry for triple posting, but I have some more info that may or may not be
useful.
When enabling verbose output from glretrace, I can see that the next to last
operation before a hang is always glBindBuffer (I've run it 10 times) even
though the rest of the output is very different. This, however, only happens
when double buffer visuals is enabled, if I disable it using --sb the output is
the same as above, ending with glXSwapBuffers.
Not sure if this is a coincidence or not, but it seemed interesting to me.

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

[PATCH 2/2] drm/doc: Update docs about device instance setup

[David Herrmann]

Hi

On Mon, Aug 10, 2015 at 4:30 PM, Daniel Vetter  wrote:
> On Mon, Aug 10, 2015 at 02:34:18PM +0200, Thierry Reding wrote:
>> On Mon, Aug 10, 2015 at 02:07:49PM +0200, Daniel Vetter wrote:
>> > On Mon, Aug 10, 2015 at 01:59:07PM +0200, Thierry Reding wrote:
>> > > On Mon, Aug 10, 2015 at 11:55:38AM +0200, Daniel Vetter wrote:
>> > > > ->load is depracated, bus functionst are deprecated and everyone
>> > > > should use drm_dev_alloc
>> > >
>> > > Why would you want to deprecated ->load()? Even if you use
>> > > drm_dev_alloc() and drm_dev_register(), there's still use for ->load()
>> > > because it gives you the subsystem-level initialization entry point.
>> >
>> > ->load is called after the drm /dev node is registered and hence you can't
>> > really do any driver setup in there without risking races. We paper over
>> > that using drm_global_mutex, but that doesn't work for any other
>> > driver/userspace interface like sysfs/debugfs because of deadlocks.
>> >
>> > And we can't just reorder ->load to happen before the /dev nodes are
>> > registered because a lot of drivers would fall over if we do that.
>> >
>> > This is typical midlayer fail where the core calls into the driver instead
>> > of the other way round.
>>
>> Okay, but then if we're going to deprecate ->load(), I think we should
>> also come up with an upgrade plan. As it is, this just says that users
>> shouldn't do ->load(), but it doesn't tell them what to do instead.
>>
>> Would the proper procedure be to fix drivers so that ->load() can be
>> called between drm_dev_alloc() and drm_dev_register()? I suppose we
>> could add some sort of (temporary) flag for drivers to signal this and
>> then have drm_dev_register() call ->load() at the right time. If drivers
>> don't support it, we can keep what we have.
>>
>> That, of course, doesn't get rid of the midlayer, so perhaps a better
>> way forward would be to tell driver writers that they should be doing
>> subsystem-level setup between drm_dev_alloc() and drm_dev_register().
>
> That's exactly what this patch tries to accomplish by updating the
> kerneldoc and docbook. New sequence should be
>
> device_probe_callback_or_whatever()
> {
> drm_dev_alloc();
>
> ... driver init code ...
>
> drm_dev_register();
>
> return 0;
> }

_Yes_!

Acked-by: David Herrmann 

Thanks
David

[PATCH 1/4] qcom-scm: add ocmem support

[Rob Clark]

On Mon, Sep 28, 2015 at 6:35 PM, Stephen Boyd  wrote:
> On 09/28, Bjorn Andersson wrote:
>> On Mon 28 Sep 14:08 PDT 2015, Rob Clark wrote:
>>
>> > On Mon, Sep 28, 2015 at 4:51 PM, Stephen Boyd  
>> > wrote:
>> > > On 09/28, Rob Clark wrote:
>> > >> +bool qcom_scm_ocmem_secure_available(void)
>> > >> +{
>> > >> + int ret = qcom_scm_clk_enable();
>> > >
>> > > I doubt we need to enable clocks to figure out if a call is
>> > > available. Please drop clk stuff here.
>> >
>> > hmm, hdcp did, but pas didn't..  otoh it looks like the call to
>> > __qcom_scm_pas_supported() *should* be wrapped in clk enable/disable..
>> >
>> > And __qcom_scm_is_call_available() does call qcom_scm_call().  Which
>> > is, I assume, what needs the clk's..  so not entirely sure if *all*
>> > the clk enable/disable stuff should be stripped out, or if missing clk
>> > stuff should be added in qcom_scm_pas_supported()..
>> >
>>
>> The scm clocks here are the crypto engine clocks, they are not needed to
>> check if TZ implements PAS for a given processor or not.
>>
>> But it could be argued that this is simply an assumption I make of the
>> black box we're calling into...
>
> Let's not make assumptions. They're not needed to check if it has
> support for something.
>
>>
>> >
>> > >> +
>> > >> + if (ret)
>> > >> + goto clk_err;
>> > >> +
>> > >> + ret = __qcom_scm_is_call_available(QCOM_SCM_OCMEM_SECURE_SVC,
>> > >> + QCOM_SCM_OCMEM_SECURE_CFG);
>> > >> +
>> > >> + qcom_scm_clk_disable();
>> > >> +
>> > >> +clk_err:
>> > >> + return (ret > 0) ? true : false;
>> > >> +}
>> > >> +EXPORT_SYMBOL(qcom_scm_ocmem_secure_available);
>> > >> +
>> [..]
>> > >> +int qcom_scm_ocmem_unlock(uint32_t id, uint32_t offset, uint32_t size)
>> > >> +{
>> > >> + int ret = qcom_scm_clk_enable();
>> > >> +
>> > >> + if (ret)
>> > >> + return ret;
>> > >> +
>> > >> + ret = __qcom_scm_ocmem_unlock(id, offset, size);
>> > >> + qcom_scm_clk_disable();
>> > >> +
>> > >> + return ret;
>> > >> +}
>> > >> +EXPORT_SYMBOL(qcom_scm_ocmem_unlock);
>> > >
>> > > I don't think we need any clocks for lock/unlock/cfg either. The
>> > > scm clocks are some crypto clocks that the secure side isn't able
>> > > to enable and we don't have a device in DT for them. In the ocmem
>> > > case, we should rely on the ocmem device to get the clocks and
>> > > turn them on before calling any scm APIs that may require those
>> > > clocks.
>> >
>> > Hmm, if that is true then we should probably drop the clks for hdcp
>> > fxns too, and maybe add a comment somewhere since it isn't really
>> > clear what the clks are for (and when it is unclear, folks will just
>> > cargo-cult what the existing fxns are doing).  As-is it is hard to
>> > tell what is required and what is luck..
>> >
>>
>> I would expect hdcp to use the crypto engines in some way and we don't
>> want people to feel that they should add the random clocks here, so
>> commenting them is probably the way to go.
>
> Yes HDCP uses crypto for something so those clock calls should
> stay. If the clocks were used by a HDCP device then it would be
> like the ocmem case, but it isn't.
>
>>
>> > >> diff --git a/include/linux/qcom_scm.h b/include/linux/qcom_scm.h
>> > >> index 46d41e4..a934457 100644
>> > >> --- a/include/linux/qcom_scm.h
>> > >> +++ b/include/linux/qcom_scm.h
>> > >> @@ -23,10 +23,20 @@ struct qcom_scm_hdcp_req {
>> > >>   u32 val;
>> > >>  };
>> > >>
>> > >> +extern bool qcom_scm_is_available(void);
>> > >
>> > > Is this used? Looks like noise.
>> >
>> > perhaps should be split out into a separate patch..  but I am using
>> > this, and it seems like a good idea to avoid null ptr deref's of
>> > __scm.  Probably some of the scm callers should call this first..
>> > either that or we should make other scm entry points behave better if
>> > __scm is null..
>> >
>>
>> This is part of Andy's platformication, didn't he export it properly?
>> I use it as well from the remoteproc.
>
> Do we probe defer ocmem if scm isn't ready? Maybe we should name
> it qcom_scm_is_probed() and have it return -EPROBE_DEFER if it
> isn't probed and 0 if it is probed. Then drivers just call that
> function and return the error if there is one. I'd rather not
> litter scm_*() APIs with checks to see if the driver has probed
> yet. Just let those crash the system. Of course, this probably
> doesn't matter because we don't need to do any clock stuff here
> anyway.

currently, we just skip the scm calls.. which is maybe not the right
thing.  With the various kconfig options in downstream driver, I can't
say I'm really sure if there are any cases where we would skip scm
completely and do everything from kernel..

That said, I'm not a huge fan of 'crash the system' approach in
general.. it's kinda nice if the system can at least boot far enough
to tell what went wrong, especially on devices without serial ports
(or jtag, etc).

If I can assume there should always be 

[PATCH 4/4] drm/msm: add OCMEM driver

[Stephen Boyd]

On 09/28, Rob Clark wrote:
> On Mon, Sep 28, 2015 at 6:10 PM, Stephen Boyd  wrote:
> > On 09/28, Rob Clark wrote:
> >> diff --git a/drivers/gpu/drm/msm/ocmem/ocmem.c 
> >> b/drivers/gpu/drm/msm/ocmem/ocmem.c
> >> new file mode 100644
> >> index 000..d3cdd64
> >> --- /dev/null
> >> +++ b/drivers/gpu/drm/msm/ocmem/ocmem.c
> >> @@ -0,0 +1,396 @@
> >> +/*
> >> + * Copyright (C) 2015 Red Hat
> >> + * Author: Rob Clark 
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify it
> >> + * under the terms of the GNU General Public License version 2 as 
> >> published by
> >> + * the Free Software Foundation.
> >> + *
> >> + * This program is distributed in the hope that it will be useful, but 
> >> WITHOUT
> >> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> >> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License 
> >> for
> >> + * more details.
> >> + *
> >> + * You should have received a copy of the GNU General Public License 
> >> along with
> >> + * this program.  If not, see .
> >> + */
> >> +
> >> +#include 
> >> +#include 
> >
> > What is this include for?
> 
> needed for qcom_scm.h, although I guess I could just add the missing
> #includes in qcom_scm.h instead..

Ok, we should fix that in scm header files. It probably needs a
forward declare of struct cpumask and it should be struct cpumask
* instead of cpumask_t *.

> 
> >> +#include 
> >> +
> >> +#include "msm_drv.h"
> >> +#include "ocmem.h"
> >> +#include "ocmem.xml.h"
> >> +
[..]
> >> +
> >> +static void update_ocmem(struct ocmem *ocmem)
> >> +{
> >> + uint32_t region_mode_ctrl = 0x0;
> >> + unsigned pos = 0;
> >> + unsigned i = 0;
> >> +
> >> + if (!qcom_scm_ocmem_lock_available()) {
> >> + for (i = 0; i < ocmem->config->num_regions; i++) {
> >> + struct ocmem_region *region = >regions[i];
> >> + pos = i << 2;
> >> + if (region->mode == THIN_MODE)
> >> + region_mode_ctrl |= BIT(pos);
> >> + }
> >> + dev_dbg(ocmem->dev, "ocmem_region_mode_control %x\n", 
> >> region_mode_ctrl);
> >> + ocmem_write(ocmem, REG_OCMEM_REGION_MODE_CTL, 
> >> region_mode_ctrl);
> >> + /* Barrier to commit the region mode */
> >> + mb();
> >
> > msm_writel() already has a barrier, so now we have a double
> > barrier?
> 
> hmm, msm_writel() doesn't have any more barrier than writel().. so I
> kept the mb() from downstream..

Yes writel() already has a barrier. Downstream is using
writel_relaxed() instead of writel() in ocmem_write() and then
adding the barrier explicitly after ocmem_write() in the right
places.

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

[PATCH 4/4] drm/msm: add OCMEM driver

[Rob Clark]

On Mon, Sep 28, 2015 at 6:10 PM, Stephen Boyd  wrote:
> On 09/28, Rob Clark wrote:
>> @@ -322,10 +319,8 @@ static void a3xx_destroy(struct msm_gpu *gpu)
>>
>>   adreno_gpu_cleanup(adreno_gpu);
>>
>> -#ifdef CONFIG_MSM_OCMEM
>>   if (a3xx_gpu->ocmem_base)
>
> Is this supposed to be ocmem_base or ocmem_hdl? Perhaps this
> check could be put inside the ocmem_free() itself so that the
> caller doesn't have to care.

yeah, should be ocmem_hdl

I would kind of prefer to keep the check for null in the caller, just
to simplify backports to 3.10 kernel (since otherwise the API matches
downstream).. Although I guess downstream checks for null and spits
out error msg and returns -EINVAL, so maybe that is enough..

>>   ocmem_free(OCMEM_GRAPHICS, a3xx_gpu->ocmem_hdl);
>> -#endif
>>
>>   kfree(a3xx_gpu);
>>  }
>> @@ -289,10 +288,8 @@ static void a4xx_destroy(struct msm_gpu *gpu)
>>
>>   adreno_gpu_cleanup(adreno_gpu);
>>
>> -#ifdef CONFIG_MSM_OCMEM
>> - if (a4xx_gpu->ocmem_base)
>> + if (a4xx_gpu->ocmem_hdl)
>
> This one changed, so a3xx above seems highly suspicious.
>
>>   ocmem_free(OCMEM_GRAPHICS, a4xx_gpu->ocmem_hdl);
>> -#endif
>>
>>   kfree(a4xx_gpu);
>>  }
>> diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
>> index 2bbe85a..f042ba8 100644
>> --- a/drivers/gpu/drm/msm/msm_gpu.h
>> +++ b/drivers/gpu/drm/msm/msm_gpu.h
>> @@ -172,4 +172,7 @@ struct msm_gpu *adreno_load_gpu(struct drm_device *dev);
>>  void __init adreno_register(void);
>>  void __exit adreno_unregister(void);
>>
>> +void __init ocmem_register(void);
>> +void __exit ocmem_unregister(void);
>
> __init and __exit in header files is useless
>
>> +
>>  #endif /* __MSM_GPU_H__ */
>> diff --git a/drivers/gpu/drm/msm/ocmem/ocmem.c 
>> b/drivers/gpu/drm/msm/ocmem/ocmem.c
>> new file mode 100644
>> index 000..d3cdd64
>> --- /dev/null
>> +++ b/drivers/gpu/drm/msm/ocmem/ocmem.c
>> @@ -0,0 +1,396 @@
>> +/*
>> + * Copyright (C) 2015 Red Hat
>> + * Author: Rob Clark 
>> + *
>> + * This program is free software; you can redistribute it and/or modify it
>> + * under the terms of the GNU General Public License version 2 as published 
>> by
>> + * the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful, but 
>> WITHOUT
>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
>> + * more details.
>> + *
>> + * You should have received a copy of the GNU General Public License along 
>> with
>> + * this program.  If not, see .
>> + */
>> +
>> +#include 
>> +#include 
>
> What is this include for?

needed for qcom_scm.h, although I guess I could just add the missing
#includes in qcom_scm.h instead..

>> +#include 
>> +
>> +#include "msm_drv.h"
>> +#include "ocmem.h"
>> +#include "ocmem.xml.h"
>> +
>> +enum region_mode {
>> + WIDE_MODE = 0x0,
>> + THIN_MODE,
>> + MODE_DEFAULT = WIDE_MODE,
>> +};
>> +
>> +enum ocmem_tz_client {
>> + TZ_UNUSED = 0x0,
>> + TZ_GRAPHICS,
>> + TZ_VIDEO,
>> + TZ_LP_AUDIO,
>> + TZ_SENSORS,
>> + TZ_OTHER_OS,
>> + TZ_DEBUG,
>> +};
>> +
>> +struct ocmem_region {
>> + unsigned psgsc_ctrl;
>> + bool interleaved;
>> + enum region_mode mode;
>> + unsigned int num_macros;
>> + enum ocmem_macro_state macro_state[4];
>> + unsigned long macro_size;
>> + unsigned long region_size;
>> +};
>> +
>> +struct ocmem_config {
>> + uint8_t  num_regions;
>> + uint32_t macro_size;
>> +};
>> +
>> +struct ocmem {
>> + struct device *dev;
>> + const struct ocmem_config *config;
>> + struct resource *ocmem_mem;
>> + struct clk *core_clk;
>> + struct clk *iface_clk;
>> + void __iomem *mmio;
>> +
>> + unsigned num_ports;
>
> Is this used after probe?

not currently.. downstream was saving it off in pdata but on closer
look it doesn't seem to use it after probe either..

>> + unsigned num_macros;
>> + bool interleaved;
>
> Is this used after probe?

again, cargo culted from downstream, but it looks like we can drop..

>> +
>> + struct ocmem_region *regions;
>> +};
>> +
>> +struct ocmem *ocmem;
>
> static?
>
>> +
>> +static bool ocmem_exists(void);
>> +
>> +static inline void ocmem_write(struct ocmem *ocmem, u32 reg, u32 data)
>> +{
>> + msm_writel(data, ocmem->mmio + reg);
>> +}
>> +
>> +static inline u32 ocmem_read(struct ocmem *ocmem, u32 reg)
>> +{
>> + return msm_readl(ocmem->mmio + reg);
>> +}
>> +
>> +static int ocmem_clk_enable(struct ocmem *ocmem)
>> +{
>> + int ret;
>> +
>> + ret = clk_prepare_enable(ocmem->core_clk);
>> + if (ret)
>> + return ret;
>> +
>> + if (ocmem->iface_clk) {
>> + ret = clk_prepare_enable(ocmem->iface_clk);
>
> clk_prepare_enable() on NULL does nothing so it should be safe to
> drop the if.
>
>> + if (ret)
>> + 

[PATCH 2/2] drm/doc: Update docs about device instance setup

[Laurent Pinchart]

Hi Daniel,

Thank you for the patch.

On Monday 10 August 2015 11:55:38 Daniel Vetter wrote:
> ->load is depracated, bus functionst are deprecated and everyone

s/depracated/deprecated/

s/functionst/functions/

> should use drm_dev_alloc
> 
> So update the .tmpl (and pull a bunch of the overview docs into the
> sourcecode to increase chances that it'll stay in sync in the future)
> and add notes to functions which are deprecated. I didn't bother to
> clean up and document the unload sequence similarly since that one is
> still a bit a mess: drm_dev_unregister does way too much,
> drm_unplug_dev does what _unregister should be doing but then has the
> complication of promising something it doesn't actually do (it doesn't
> unplug existing open fds for instance, only prevents new ones).
> 
> Motivated since I don't want to hunt every new driver for usage of
> drm_platform_init any more ;-)
> 
> Signed-off-by: Daniel Vetter 
> ---
>  Documentation/DocBook/drm.tmpl | 99 ---
>  drivers/gpu/drm/drm_drv.c  | 55 +--
>  drivers/gpu/drm/drm_pci.c  | 11 +
>  drivers/gpu/drm/drm_platform.c |  3 ++
>  4 files changed, 83 insertions(+), 85 deletions(-)
> 
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index ec34b9becebd..f1884038b90f 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -138,14 +138,10 @@
>  
>At the core of every DRM driver is a
> drm_driver structure. Drivers typically statically
> initialize a drm_driver structure, -  and then pass it to one of the
> drm_*_init() functions -  to register it with the
> DRM subsystem.
> -
> -
> -  Newer drivers that no longer require a
> drm_bus -  structure can alternatively use the
> low-level device initialization and -  registration functions such as
> drm_dev_alloc() and - 
> drm_dev_register() directly.
> +  and then pass it to drm_dev_alloc() to allocate
> a +  device instance. After the device instance is fully initialized it
> can be +  registered (which makes it accessible from userspace) using +
>  drm_dev_register().
>  
>  
>The drm_driver structure contains static
> @@ -296,83 +292,12 @@ char *date;
>
>  
>  
> -  Device Registration
> -  
> -A number of functions are provided to help with device
> registration. -The functions deal with PCI and platform devices,
> respectively. -  
> -!Edrivers/gpu/drm/drm_pci.c
> -!Edrivers/gpu/drm/drm_platform.c
> -  
> -New drivers that no longer rely on the services provided by the
> -drm_bus structure can call the low-level
> -device registration functions directly. The
> -drm_dev_alloc() function can be used to
> allocate -and initialize a new drm_device
> structure. -Drivers will typically want to perform some additional
> setup on this -structure, such as allocating driver-specific data
> and storing a -pointer to it in the DRM device's
> dev_private -field. Drivers should also
> set the device's unique name using the -   
> drm_dev_set_unique() function. After it has been -
>set up a device can be registered with the DRM subsystem by calling -   
> drm_dev_register(). This will cause the device to
> -be exposed to userspace and will call the driver's
> -.load() implementation. When a device is
> -removed, the DRM device can safely be unregistered and freed by
> calling -drm_dev_unregister() followed by a
> call to -drm_dev_unref().
> -  
> +  Device Instance and Driver Handling
> +!Pdrivers/gpu/drm/drm_drv.c driver instance overview
>  !Edrivers/gpu/drm/drm_drv.c
>  
>  
>Driver Load
> -  
> -The load method is the driver and device
> -initialization entry point. The method is responsible for
> allocating and -  initializing driver private data, performing resource
> allocation and -  mapping (e.g. acquiring
> -clocks, mapping registers or allocating command buffers),
> initializing -the memory manager ( linkend="drm-memory-management"/>), installing -the IRQ handler
> (), setting up -vertical
> blanking handling (), mode -  setting
> () and initial output
> - configuration ().
> -  
> -  
> -If compatibility is a concern (e.g. with drivers converted over
> from -User Mode Setting to Kernel Mode Setting), care must be taken
> to prevent -device initialization and control that is incompatible
> with currently -active userspace drivers. For instance, if user
> level mode setting -drivers are in use, it would be problematic to
> perform output discovery - configuration at load time.
> Likewise, if user-level drivers -unaware of memory management are
> in use, memory management 

[PATCH] drm/radeon: Restore LCD backlight level on resume (>= R5xx)

[Michel Dänzer]

From: Michel Dänzer 

Instead of only enabling the backlight (which seems to set it to max
brightness), just re-set the current backlight level, which also takes
care of enabling the backlight if necessary.

Only the radeon_atom_encoder_dpms_dig part tested on a Kaveri laptop,
the radeon_atom_encoder_dpms_avivo part is only compile tested.

Cc: stable at vger.kernel.org
Signed-off-by: Michel Dänzer 
---
 drivers/gpu/drm/radeon/atombios_encoders.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c 
b/drivers/gpu/drm/radeon/atombios_encoders.c
index c387259..65adb9c 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -1624,8 +1624,9 @@ radeon_atom_encoder_dpms_avivo(struct drm_encoder 
*encoder, int mode)
} else
atom_execute_table(rdev->mode_info.atom_context, index, 
(uint32_t *));
if (radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT)) {
-   args.ucAction = ATOM_LCD_BLON;
-   atom_execute_table(rdev->mode_info.atom_context, index, 
(uint32_t *));
+   struct radeon_encoder_atom_dig *dig = 
radeon_encoder->enc_priv;
+
+   atombios_set_backlight_level(radeon_encoder, 
dig->backlight_level);
}
break;
case DRM_MODE_DPMS_STANDBY:
@@ -1706,8 +1707,7 @@ radeon_atom_encoder_dpms_dig(struct drm_encoder *encoder, 
int mode)
atombios_dig_encoder_setup(encoder, 
ATOM_ENCODER_CMD_DP_VIDEO_ON, 0);
}
if (radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT))
-   atombios_dig_transmitter_setup(encoder,
-  
ATOM_TRANSMITTER_ACTION_LCD_BLON, 0, 0);
+   atombios_set_backlight_level(radeon_encoder, 
dig->backlight_level);
if (ext_encoder)
atombios_external_encoder_setup(encoder, ext_encoder, 
ATOM_ENABLE);
break;
-- 
2.5.0

[PATCH] [Bug 92082] Solaris fix: 'PATH_MAX' undeclared

[Emil Velikov]

Hi Evgeny,

On 26 September 2015 at 22:43, evgeny litvinenko
 wrote:
> Hi Emil,
>
>> Including limits.h does seem like the right way forward. Can you send a git
>> format-patch created fix to the ML [1]?
> Output of format-patch is at the end of the email.
>
> I added '#include ' right before '#include '
> because on Debian 8 (jessie) the file dirent.h includes bits/posix1_lim.h
> which indirectly includes limits.h.
> Also bits/posix1_lim.h has the comment - 'Never include this file
> directly; use  instead.'
>
> After the patch I built and run make check; make distcheck on Debian -
> no errors.
>
>> Additionally you should have noticed a bunch of warnings (missing
>> implementation of XXX) on non-linux platforms.
>> If you'd like to solve these but you're unsure what exactly the functions are
>> supposed to do, let me know and I can help out. You can also catch me at
>> #dri-devel (freenode), look for xexaxo.
>
> Thanks!
> Yes I'd like and will try to solve these 'missing implementation',
> I'll ask you if I have questions.
>
Glad to hear.

>
> --- Output of format-patch --
> From 0b491abb893d0faf1a9fe0e3052255bf5ad72592 Mon Sep 17 00:00:00 2001
> From: Evgeny Litvinenko 
> Date: Sat, 26 Sep 2015 22:58:15 +0300
> Subject: [PATCH] [Bug 92082] Solaris fix: 'PATH_MAX' undeclared
>
> ---

I have applied an identical patch from Felix, hope you don't mind.
Mostly because extracting patch fixed with comments is slightly
awkward. For the future please use git send-email or paste the
contents in your email client (check for wrapping) adding any comments
after the --- line.

Thank you
Emil

[PATCH 11/11] drm: Remove dummy agp ioctl wrappers

[David Herrmann]

Hi

On Tue, Sep 8, 2015 at 1:56 PM, Daniel Vetter  wrote:
> They're only used in the drm ioctl table, and there they're excluded
> when AGP support is disabled. So this is just dead code ripe for
> removal.
>
> Signed-off-by: Daniel Vetter 

Reviewed-by: David Herrmann 

Thanks
David

> ---
>  include/drm/drm_agpsupport.h | 48 
> 
>  1 file changed, 48 deletions(-)
>
> diff --git a/include/drm/drm_agpsupport.h b/include/drm/drm_agpsupport.h
> index 3d0833c63af2..addf0ea3e158 100644
> --- a/include/drm/drm_agpsupport.h
> +++ b/include/drm/drm_agpsupport.h
> @@ -105,95 +105,47 @@ static inline int drm_agp_acquire(struct drm_device 
> *dev)
> return -ENODEV;
>  }
>
> -static inline int drm_agp_acquire_ioctl(struct drm_device *dev, void *data,
> -   struct drm_file *file_priv)
> -{
> -   return -ENODEV;
> -}
> -
>  static inline int drm_agp_release(struct drm_device *dev)
>  {
> return -ENODEV;
>  }
>
> -static inline int drm_agp_release_ioctl(struct drm_device *dev, void *data,
> -   struct drm_file *file_priv)
> -{
> -   return -ENODEV;
> -}
> -
>  static inline int drm_agp_enable(struct drm_device *dev,
>  struct drm_agp_mode mode)
>  {
> return -ENODEV;
>  }
>
> -static inline int drm_agp_enable_ioctl(struct drm_device *dev, void *data,
> -  struct drm_file *file_priv)
> -{
> -   return -ENODEV;
> -}
> -
>  static inline int drm_agp_info(struct drm_device *dev,
>struct drm_agp_info *info)
>  {
> return -ENODEV;
>  }
>
> -static inline int drm_agp_info_ioctl(struct drm_device *dev, void *data,
> -struct drm_file *file_priv)
> -{
> -   return -ENODEV;
> -}
> -
>  static inline int drm_agp_alloc(struct drm_device *dev,
> struct drm_agp_buffer *request)
>  {
> return -ENODEV;
>  }
>
> -static inline int drm_agp_alloc_ioctl(struct drm_device *dev, void *data,
> - struct drm_file *file_priv)
> -{
> -   return -ENODEV;
> -}
> -
>  static inline int drm_agp_free(struct drm_device *dev,
>struct drm_agp_buffer *request)
>  {
> return -ENODEV;
>  }
>
> -static inline int drm_agp_free_ioctl(struct drm_device *dev, void *data,
> -struct drm_file *file_priv)
> -{
> -   return -ENODEV;
> -}
> -
>  static inline int drm_agp_unbind(struct drm_device *dev,
>  struct drm_agp_binding *request)
>  {
> return -ENODEV;
>  }
>
> -static inline int drm_agp_unbind_ioctl(struct drm_device *dev, void *data,
> -  struct drm_file *file_priv)
> -{
> -   return -ENODEV;
> -}
> -
>  static inline int drm_agp_bind(struct drm_device *dev,
>struct drm_agp_binding *request)
>  {
> return -ENODEV;
>  }
>
> -static inline int drm_agp_bind_ioctl(struct drm_device *dev, void *data,
> -struct drm_file *file_priv)
> -{
> -   return -ENODEV;
> -}
> -
>  #endif /* CONFIG_AGP */
>
>  #endif /* _DRM_AGPSUPPORT_H_ */
> --
> 2.5.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 10/11] drm/: Drop DRM_UNLOCKED from modeset drivers

[David Herrmann]

Hi

On Tue, Sep 8, 2015 at 1:56 PM, Daniel Vetter  wrote:
> Just one special case (since i915 lost its ums code, yay):
> - radeon: Has slots for the old ums ioctls which don't have
>   DRM_UNLOCKED, but all filled with drm_invalid_op. So ok to drop it
>   everywhere.
>
> Every other kms driver just has DRM_UNLOCKED for all their ioctls, as
> they should.
>
> v2: admgpu happened, include that one too. And i915 lost its UMS
> support which means we can change all the i915 ioctls too.
>
> v3: Rebased on top of new vmwgfx DX interface extensions.
>
> v4: Rebase on top of render-node support in exynos.
>
> Signed-off-by: Daniel Vetter 

With the core-patch fixed:

Reviewed-by: David Herrmann 

Maybe, as a followup, you might want to turn all core-ioctls to
include a DRM_GLOBAL_LOCK flag and then drop DRM_UNLOCKED entirely.
This is more explicit and *way* easier to understand.

Thanks
David

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 24 +--
>  drivers/gpu/drm/armada/armada_drv.c |  9 ++---
>  drivers/gpu/drm/exynos/exynos_drm_drv.c | 20 -
>  drivers/gpu/drm/i915/i915_dma.c | 72 
> -
>  drivers/gpu/drm/msm/msm_drv.c   | 14 +++
>  drivers/gpu/drm/nouveau/nouveau_drm.c   | 24 +--
>  drivers/gpu/drm/omapdrm/omap_drv.c  | 12 +++---
>  drivers/gpu/drm/qxl/qxl_ioctl.c | 14 +++
>  drivers/gpu/drm/radeon/radeon_kms.c | 30 +++---
>  drivers/gpu/drm/tegra/drm.c | 28 ++---
>  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 54 -
>  11 files changed, 149 insertions(+), 152 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> index 22367939ebf1..3648fdca6359 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> @@ -685,18 +685,18 @@ int amdgpu_get_vblank_timestamp_kms(struct drm_device 
> *dev, int crtc,
>  }
>
>  const struct drm_ioctl_desc amdgpu_ioctls_kms[] = {
> -   DRM_IOCTL_DEF_DRV(AMDGPU_GEM_CREATE, amdgpu_gem_create_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> -   DRM_IOCTL_DEF_DRV(AMDGPU_CTX, amdgpu_ctx_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> -   DRM_IOCTL_DEF_DRV(AMDGPU_BO_LIST, amdgpu_bo_list_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(AMDGPU_GEM_CREATE, amdgpu_gem_create_ioctl, 
> DRM_AUTH|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(AMDGPU_CTX, amdgpu_ctx_ioctl, 
> DRM_AUTH|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(AMDGPU_BO_LIST, amdgpu_bo_list_ioctl, 
> DRM_AUTH|DRM_RENDER_ALLOW),
> /* KMS */
> -   DRM_IOCTL_DEF_DRV(AMDGPU_GEM_MMAP, amdgpu_gem_mmap_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> -   DRM_IOCTL_DEF_DRV(AMDGPU_GEM_WAIT_IDLE, amdgpu_gem_wait_idle_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> -   DRM_IOCTL_DEF_DRV(AMDGPU_CS, amdgpu_cs_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> -   DRM_IOCTL_DEF_DRV(AMDGPU_INFO, amdgpu_info_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> -   DRM_IOCTL_DEF_DRV(AMDGPU_WAIT_CS, amdgpu_cs_wait_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> -   DRM_IOCTL_DEF_DRV(AMDGPU_GEM_METADATA, amdgpu_gem_metadata_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> -   DRM_IOCTL_DEF_DRV(AMDGPU_GEM_VA, amdgpu_gem_va_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> -   DRM_IOCTL_DEF_DRV(AMDGPU_GEM_OP, amdgpu_gem_op_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> -   DRM_IOCTL_DEF_DRV(AMDGPU_GEM_USERPTR, amdgpu_gem_userptr_ioctl, 
> DRM_AUTH|DRM_UNLOCKED|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(AMDGPU_GEM_MMAP, amdgpu_gem_mmap_ioctl, 
> DRM_AUTH|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(AMDGPU_GEM_WAIT_IDLE, amdgpu_gem_wait_idle_ioctl, 
> DRM_AUTH|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(AMDGPU_CS, amdgpu_cs_ioctl, 
> DRM_AUTH|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(AMDGPU_INFO, amdgpu_info_ioctl, 
> DRM_AUTH|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(AMDGPU_WAIT_CS, amdgpu_cs_wait_ioctl, 
> DRM_AUTH|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(AMDGPU_GEM_METADATA, amdgpu_gem_metadata_ioctl, 
> DRM_AUTH|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(AMDGPU_GEM_VA, amdgpu_gem_va_ioctl, 
> DRM_AUTH|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(AMDGPU_GEM_OP, amdgpu_gem_op_ioctl, 
> DRM_AUTH|DRM_RENDER_ALLOW),
> +   DRM_IOCTL_DEF_DRV(AMDGPU_GEM_USERPTR, amdgpu_gem_userptr_ioctl, 
> DRM_AUTH|DRM_RENDER_ALLOW),
>  };
>  int amdgpu_max_kms_ioctl = ARRAY_SIZE(amdgpu_ioctls_kms);
> diff --git a/drivers/gpu/drm/armada/armada_drv.c 
> b/drivers/gpu/drm/armada/armada_drv.c
> index 225034b74cda..f73b3e2a772b 100644
> --- a/drivers/gpu/drm/armada/armada_drv.c
> +++ b/drivers/gpu/drm/armada/armada_drv.c
> @@ -268,12 +268,9 @@ static void armada_drm_disable_vblank(struct drm_device 
> *dev, int crtc)
>  }
>
>  static struct drm_ioctl_desc 

[PATCH 09/11] drm/vmwgfx: Stop checking for DRM_UNLOCKED

[David Herrmann]

Hi

On Tue, Sep 8, 2015 at 1:56 PM, Daniel Vetter  wrote:
> drm core enforces now for DRIVER_MODESET that all ioctls are unlocked.
> And all the old nasty ones from drm core aren't allowed for modern
> drivers any more. Hence this is no longer needed.
>
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 8 
>  1 file changed, 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index e13b20bd9908..2320ba8c5eb1 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -1068,14 +1068,6 @@ static struct vmw_master *vmw_master_check(struct 
> drm_device *dev,
> mutex_unlock(>master_mutex);
>
> /*
> -* Taking the drm_global_mutex after the TTM lock might deadlock
> -*/
> -   if (!(flags & DRM_UNLOCKED)) {
> -   DRM_ERROR("Refusing locked ioctl access.\n");
> -   return ERR_PTR(-EDEADLK);
> -   }

Yeah, just drop that right away, regardless of the core changes. We
have lockdep or WARN_ON() for such checks.

Reviewed-by: David Herrmann 

Thanks
David

> -
> -   /*
>  * Take the TTM lock. Possibly sleep waiting for the authenticating
>  * master to become master again, or for a SIGTERM if the
>  * authenticating master exits.
> --
> 2.5.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 08/11] drm: Enforce unlocked ioctl operation for kms driver ioctls

[David Herrmann]

Hi

On Tue, Sep 8, 2015 at 1:56 PM, Daniel Vetter  wrote:
> With the prep patches for i915 all kms drivers either have
> DRM_UNLOCKED on all their ioctls. Or the ioctl always directly returns
> with an invariant return value when in modeset mode. But that's only
> the case for i915 and radeon. The drm core ioctls are unfortunately
> too much a mess still to dare this.
>
> Follow-up patches will remove DRM_UNLOCKED from all kms drivers to
> prove that this is indeed the case.
>
> Also update the documentation.
>
> Signed-off-by: Daniel Vetter 

drm_setclientcap() should probably lock _something_. It's not very
crucial, but I think we should guarantee consistency when setting
multiple values. struct_mutex of the corresponding DRM device sounds
sufficient, though not very promising. But drm_file doesn't have any
suitable lock..

drm_setversion(): This definitely needs _some_ lock. DRM_MASTER is not
reliable (we never merged the master-reliability patches).

...skipping review of the other ioctls...
...re-reading patch description...

So this patch is just meant to drop DRM_UNLOCKED from driver-ioctls,
right? See below.

> ---
>  Documentation/DocBook/drm.tmpl | 4 +++-
>  drivers/gpu/drm/drm_ioctl.c| 6 +-
>  2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index cfb43203a6a7..55dc106686df 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -3747,7 +3747,9 @@ int num_ioctls;
> 
>  
>   DRM_UNLOCKED - The ioctl handler will be called without locking
> - the DRM global mutex
> + the DRM global mutex. This is the enforced default for kms 
> drivers
> + (i.e. using the DRIVER_MODESET flag) and hence shouldn't be used
> + any more for new drivers.
> 
>   
> 
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index 75df8ea87cd7..a5a4aa89b1b4 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -728,6 +728,7 @@ long drm_ioctl(struct file *filp,
> }
>
> retcode = drm_ioctl_permit(ioctl->flags, file_priv);
> +

Weird new-line. I actually prefer the previous style, anyway.

> if (unlikely(retcode))
> goto err_i1;
>
> @@ -755,7 +756,10 @@ long drm_ioctl(struct file *filp,
> memset(kdata, 0, usize);
> }
>
> -   if (ioctl->flags & DRM_UNLOCKED)
> +   /* Enforce sane locking for kms driver ioctls. Core ioctls are
> +* too messy still. */
> +   if (drm_core_check_feature(dev, DRIVER_MODESET) ||
> +   (ioctl->flags & DRM_UNLOCKED))
> retcode = func(dev, kdata, file_priv);

This looks.. weird. Now we *never* lock *anything* for MODESET
drivers? This contradicts your commit-message, which rather tells me
you want _driver_ ioctls of modeset drivers to never rely on
drm_global_mutex. Several ways to make that work (and I'd review it
gladly), but this looks.. weird.

Care to elaborate?

Thanks
David

> else {
> mutex_lock(_global_mutex);
> --
> 2.5.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCHv4 3/3] drm: bridge: anx78xx: Add anx78xx driver support by analogix.

[drinkcat]

Hi Enric,

On Fri, Sep 25, 2015 at 09:29:28PM +0200, Enric Balletbo i Serra wrote:
> At the moment it only supports ANX7814.
> 
> The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
> designed for portable devices.
> 
> This driver adds initial support and supports HDMI to DP pass-through mode.
> 
> Signed-off-by: Enric Balletbo i Serra 

More comments. Please look at patterns (u8->bool, use bit_ctl, etc.):
I did not comment on every single instance of these.

Best,

> ---
>  drivers/gpu/drm/bridge/Kconfig   |2 +
>  drivers/gpu/drm/bridge/Makefile  |1 +
>  drivers/gpu/drm/bridge/anx78xx/Kconfig   |7 +
>  drivers/gpu/drm/bridge/anx78xx/Makefile  |4 +
>  drivers/gpu/drm/bridge/anx78xx/anx78xx.h |   41 +
>  drivers/gpu/drm/bridge/anx78xx/anx78xx_main.c|  228 ++
>  drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.c | 3148 
> ++
>  drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.h |  214 ++
>  drivers/gpu/drm/bridge/anx78xx/slimport_tx_reg.h |  807 ++
>  9 files changed, 4452 insertions(+)
>  create mode 100644 drivers/gpu/drm/bridge/anx78xx/Kconfig
>  create mode 100644 drivers/gpu/drm/bridge/anx78xx/Makefile
>  create mode 100644 drivers/gpu/drm/bridge/anx78xx/anx78xx.h
>  create mode 100644 drivers/gpu/drm/bridge/anx78xx/anx78xx_main.c
>  create mode 100644 drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.c
>  create mode 100644 drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.h
>  create mode 100644 drivers/gpu/drm/bridge/anx78xx/slimport_tx_reg.h
> 
> diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
> index 2de52a5..aa6fe12 100644
> --- a/drivers/gpu/drm/bridge/Kconfig
> +++ b/drivers/gpu/drm/bridge/Kconfig
> @@ -29,4 +29,6 @@ config DRM_PARADE_PS8622
>   ---help---
> Parade eDP-LVDS bridge chip driver.
>  
> +source "drivers/gpu/drm/bridge/anx78xx/Kconfig"
> +
>  endmenu
> diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
> index e2eef1c..e5bd38b 100644
> --- a/drivers/gpu/drm/bridge/Makefile
> +++ b/drivers/gpu/drm/bridge/Makefile
> @@ -3,3 +3,4 @@ ccflags-y := -Iinclude/drm
>  obj-$(CONFIG_DRM_DW_HDMI) += dw_hdmi.o
>  obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
>  obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
> +obj-$(CONFIG_DRM_ANX78XX) += anx78xx/
> diff --git a/drivers/gpu/drm/bridge/anx78xx/Kconfig 
> b/drivers/gpu/drm/bridge/anx78xx/Kconfig
> new file mode 100644
> index 000..08f9c08
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/anx78xx/Kconfig
> @@ -0,0 +1,7 @@
> +config DRM_ANX78XX
> + tristate "Analogix ANX78XX bridge"
> + help
> + ANX78XX is a HD video transmitter chip over micro-USB
> + connector for smartphone device.
> +
> +
> diff --git a/drivers/gpu/drm/bridge/anx78xx/Makefile 
> b/drivers/gpu/drm/bridge/anx78xx/Makefile
> new file mode 100644
> index 000..a843733
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/anx78xx/Makefile
> @@ -0,0 +1,4 @@
> +obj-${CONFIG_DRM_ANX78XX} :=  anx78xx.o
> +
> +anx78xx-y += anx78xx_main.o
> +anx78xx-y += slimport_tx_drv.o
> diff --git a/drivers/gpu/drm/bridge/anx78xx/anx78xx.h 
> b/drivers/gpu/drm/bridge/anx78xx/anx78xx.h
> new file mode 100644
> index 000..f62c8e7
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/anx78xx/anx78xx.h
> @@ -0,0 +1,41 @@
> +/*
> + * Copyright(c) 2015, Analogix Semiconductor. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#ifndef __ANX78xx_H
> +#define __ANX78xx_H
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct anx78xx_platform_data {
> + struct gpio_desc *gpiod_pd;
> + struct gpio_desc *gpiod_reset;
> + spinlock_t lock;
> +};
> +
> +struct anx78xx {
> + struct i2c_client *client;
> + struct anx78xx_platform_data *pdata;
> + struct delayed_work work;
> + struct workqueue_struct *workqueue;
> + struct mutex lock;
> +};
> +
> +void anx78xx_poweron(struct anx78xx *data);
> +void anx78xx_poweroff(struct anx78xx *data);
> +
> +#endif
> diff --git a/drivers/gpu/drm/bridge/anx78xx/anx78xx_main.c 
> b/drivers/gpu/drm/bridge/anx78xx/anx78xx_main.c
> new file mode 100644
> index 000..1e4a87e
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/anx78xx/anx78xx_main.c
> @@ -0,0 +1,228 @@
> +/*
> + * Copyright(c) 2015, Analogix Semiconductor. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU 

[PATCH 1/4] qcom-scm: add ocmem support

[Rob Clark]

On Mon, Sep 28, 2015 at 4:51 PM, Stephen Boyd  wrote:
> On 09/28, Rob Clark wrote:
>> Add interfaces needed for configuring OCMEM.
>>
>> Signed-off-by: Rob Clark 
>> ---
>>  drivers/firmware/qcom_scm-32.c |  57 ++
>>  drivers/firmware/qcom_scm-64.c |  16 +++
>>  drivers/firmware/qcom_scm.c| 106 
>> +
>>  drivers/firmware/qcom_scm.h|  13 +
>>  include/linux/qcom_scm.h   |  10 
>>  5 files changed, 202 insertions(+)
>>
>> diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
>> index e9c306b..656d8fe 100644
>> --- a/drivers/firmware/qcom_scm-32.c
>> +++ b/drivers/firmware/qcom_scm-32.c
>> @@ -500,6 +500,63 @@ int __qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req, 
>> u32 req_cnt, u32 *resp)
>>   req, req_cnt * sizeof(*req), resp, sizeof(*resp));
>>  }
>>
>> +int __qcom_scm_ocmem_secure_cfg(unsigned sec_id)
>> +{
>> + int ret, scm_ret = 0;
>> + struct msm_scm_sec_cfg {
>> + unsigned int id;
>> + unsigned int spare;
>
>
> __le32 for both
>
>> + } cfg;
>> +
>> + cfg.id = sec_id;
>> +
>> +
>
> nitpick: drop double space
>
>> + ret = qcom_scm_call(QCOM_SCM_OCMEM_SECURE_SVC, 
>> QCOM_SCM_OCMEM_SECURE_CFG,
>> + , sizeof(cfg), _ret, sizeof(scm_ret));
>> +
>> + if (ret || scm_ret) {
>> + pr_err("ocmem: Failed to enable secure programming\n");
>
> Maybe the caller should print something if they care instead of
> burying it down here.
>
>> + return ret ? ret : -EINVAL;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +int __qcom_scm_ocmem_lock(uint32_t id, uint32_t offset, uint32_t size,
>> + uint32_t mode)
>
> Please use u32 here instead of uint32_t. uint32_t is not for
> kernel code.
>
>> +{
>> + struct ocmem_tz_lock {
>> + u32 id;
>> + u32 offset;
>> + u32 size;
>> + u32 mode;
>
> All __le32
>
>> + } request;
>> +
>> + request.id = id;
>> + request.offset = offset;
>> + request.size = size;
>> + request.mode = mode;
>
> And then do the cpu_to_le32() stuff here.
>
>> +
>> + return qcom_scm_call(QCOM_SCM_OCMEM_SVC, QCOM_SCM_OCMEM_LOCK_CMD,
>> + , sizeof(request), NULL, 0);
>> +}
>> +
>> +int __qcom_scm_ocmem_unlock(uint32_t id, uint32_t offset, uint32_t size)
>
> u32
>
>> +{
>> + struct ocmem_tz_unlock {
>> + u32 id;
>> + u32 offset;
>> + u32 size;
>
> __le32
>
>> + } request;
>> +
>> + request.id = id;
>> + request.offset = offset;
>> + request.size = size;
>> +
>> + return qcom_scm_call(QCOM_SCM_OCMEM_SVC, QCOM_SCM_OCMEM_UNLOCK_CMD,
>> + , sizeof(request), NULL, 0);
>> +}
>> +
>>  bool __qcom_scm_pas_supported(u32 peripheral)
>>  {
>>   __le32 out;
>> diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
>> index 118df0a..59b1007 100644
>> --- a/drivers/firmware/qcom_scm.c
>> +++ b/drivers/firmware/qcom_scm.c
>> @@ -154,6 +154,112 @@ int qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req, 
>> u32 req_cnt, u32 *resp)
>>  EXPORT_SYMBOL(qcom_scm_hdcp_req);
>>
>>  /**
>> + * qcom_scm_ocmem_secure_available() - Check if secure environment supports
>> + * OCMEM.
>> + *
>> + * Return true if OCMEM secure interface is supported, false if not.
>> + */
>> +bool qcom_scm_ocmem_secure_available(void)
>> +{
>> + int ret = qcom_scm_clk_enable();
>
> I doubt we need to enable clocks to figure out if a call is
> available. Please drop clk stuff here.

hmm, hdcp did, but pas didn't..  otoh it looks like the call to
__qcom_scm_pas_supported() *should* be wrapped in clk enable/disable..

And __qcom_scm_is_call_available() does call qcom_scm_call().  Which
is, I assume, what needs the clk's..  so not entirely sure if *all*
the clk enable/disable stuff should be stripped out, or if missing clk
stuff should be added in qcom_scm_pas_supported()..


>> +
>> + if (ret)
>> + goto clk_err;
>> +
>> + ret = __qcom_scm_is_call_available(QCOM_SCM_OCMEM_SECURE_SVC,
>> + QCOM_SCM_OCMEM_SECURE_CFG);
>> +
>> + qcom_scm_clk_disable();
>> +
>> +clk_err:
>> + return (ret > 0) ? true : false;
>> +}
>> +EXPORT_SYMBOL(qcom_scm_ocmem_secure_available);
>> +
>> +/**
>> + * qcom_scm_ocmem_secure_cfg() - call OCMEM secure cfg interface
>> + */
>> +int qcom_scm_ocmem_secure_cfg(unsigned sec_id)
>> +{
>> + int ret = qcom_scm_clk_enable();
>> +
>> + if (ret)
>> + return ret;
>> +
>> + ret = __qcom_scm_ocmem_secure_cfg(sec_id);
>> + qcom_scm_clk_disable();
>> +
>> + return ret;
>> +}
>> +EXPORT_SYMBOL(qcom_scm_ocmem_secure_cfg);
>> +
>> +/**
>> + * qcom_scm_ocmem_lock_available() - is OCMEM lock/unlock interface 
>> available
>> + */
>> +bool qcom_scm_ocmem_lock_available(void)
>> +{
>> + int ret = qcom_scm_clk_enable();
>
> No need for clocks?
>
>> +
>> + if 

[PATCH 07/11] drm/drm_ioctl.c: kerneldoc

[David Herrmann]

Hi

On Tue, Sep 8, 2015 at 1:56 PM, Daniel Vetter  wrote:
> As usual pull it into the drm docbook template, too. And again as
> usual I've decided to only document stuff exported to drivers, so all
> the old leftover markup from the shared drm repo days lost the magic
> ** signature.
>
> Signed-off-by: Daniel Vetter 

Reviewed-by: David Herrmann 

Thanks
David

> ---
>  Documentation/DocBook/drm.tmpl |  1 +
>  drivers/gpu/drm/drm_ioctl.c| 76 
> ++
>  2 files changed, 55 insertions(+), 22 deletions(-)
>
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index 7d10be2a2ba0..cfb43203a6a7 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -3752,6 +3752,7 @@ int num_ioctls;
>   
> 
>
> +!Edrivers/gpu/drm/drm_ioctl.c
>  
>
>
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index f0b4f581f6ce..75df8ea87cd7 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -40,7 +40,7 @@
>  static int drm_version(struct drm_device *dev, void *data,
>struct drm_file *file_priv);
>
> -/**
> +/*
>   * Get the bus id.
>   *
>   * \param inode device inode.
> @@ -75,7 +75,7 @@ drm_unset_busid(struct drm_device *dev,
> master->unique_len = 0;
>  }
>
> -/**
> +/*
>   * Set the bus id.
>   *
>   * \param inode device inode.
> @@ -149,7 +149,7 @@ static int drm_set_busid(struct drm_device *dev, struct 
> drm_file *file_priv)
> return 0;
>  }
>
> -/**
> +/*
>   * Get a mapping information.
>   *
>   * \param inode device inode.
> @@ -201,7 +201,7 @@ static int drm_getmap(struct drm_device *dev, void *data,
> return 0;
>  }
>
> -/**
> +/*
>   * Get client information.
>   *
>   * \param inode device inode.
> @@ -244,7 +244,7 @@ static int drm_getclient(struct drm_device *dev, void 
> *data,
> }
>  }
>
> -/**
> +/*
>   * Get statistics information.
>   *
>   * \param inode device inode.
> @@ -265,7 +265,7 @@ static int drm_getstats(struct drm_device *dev, void 
> *data,
> return 0;
>  }
>
> -/**
> +/*
>   * Get device/driver capabilities
>   */
>  static int drm_getcap(struct drm_device *dev, void *data, struct drm_file 
> *file_priv)
> @@ -318,7 +318,7 @@ static int drm_getcap(struct drm_device *dev, void *data, 
> struct drm_file *file_
> return 0;
>  }
>
> -/**
> +/*
>   * Set device/driver capabilities
>   */
>  static int
> @@ -352,7 +352,7 @@ drm_setclientcap(struct drm_device *dev, void *data, 
> struct drm_file *file_priv)
> return 0;
>  }
>
> -/**
> +/*
>   * Setversion ioctl.
>   *
>   * \param inode device inode.
> @@ -406,7 +406,18 @@ done:
> return retcode;
>  }
>
> -/** No-op ioctl. */
> +/**
> + * drm_noop - DRM no-op ioctl implemntation
> + * @dev: DRM device for the ioctl
> + * @data: data pointer for the ioctl
> + * @file_priv: DRM file for the ioctl call
> + *
> + * This no-op implementation for drm ioctls is useful for deprecated
> + * functionality where we can't return a failure code because existing 
> userspace
> + * checks the result of the ioctl, but doesn't care about the action.
> + *
> + * Always returns successfully with 0.
> + */
>  int drm_noop(struct drm_device *dev, void *data,
>  struct drm_file *file_priv)
>  {
> @@ -415,6 +426,21 @@ int drm_noop(struct drm_device *dev, void *data,
>  }
>  EXPORT_SYMBOL(drm_noop);
>
> +/**
> + * drm_invalid_op - DRM invalid ioctl implemntation
> + * @dev: DRM device for the ioctl
> + * @data: data pointer for the ioctl
> + * @file_priv: DRM file for the ioctl call
> + *
> + * This no-op implementation for drm ioctls is useful for deprecated
> + * functionality where we really don't want to allow userspace to call the 
> ioctl
> + * any more. This is the case for old ums interfaces for drivers that
> + * transitioned to kms gradually and so kept the old legacy tables around. 
> This
> + * only applies to radeon and i915 kms drivers, other drivers shouldn't need 
> to
> + * use this function.
> + *
> + * Always fails with a return value of -EINVAL.
> + */
>  int drm_invalid_op(struct drm_device *dev, void *data,
>struct drm_file *file_priv)
>  {
> @@ -422,7 +448,7 @@ int drm_invalid_op(struct drm_device *dev, void *data,
>  }
>  EXPORT_SYMBOL(drm_invalid_op);
>
> -/**
> +/*
>   * Copy and IOCTL return string to user space
>   */
>  static int drm_copy_field(char __user *buf, size_t *buf_len, const char 
> *value)
> @@ -445,7 +471,7 @@ static int drm_copy_field(char __user *buf, size_t 
> *buf_len, const char *value)
> return 0;
>  }
>
> -/**
> +/*
>   * Get version information
>   *
>   * \param inode device inode.
> @@ -477,7 +503,7 @@ static int drm_version(struct drm_device *dev, void *data,
> return err;
>  }
>
> -/**
> +/*
>   * drm_ioctl_permit - Check ioctl permissions against caller
>   *
>   * @flags: ioctl permission flags.
> 

[PATCH] drm: Remove __OS_HAS_AGP

[David Herrmann]

Hi

On Wed, Sep 9, 2015 at 4:45 PM, Daniel Vetter  wrote:
> We already express the drm/agp depencies correctly in Kconfig, so we
> can rip this remnant from the shared drm core days.
>
> Aside: Pretty much all the #ifdefs in radeon/nouveau could be killed
> if ttm would provide dummy functions. I'm not going to volunteer for
> that though.
>
> v2: Use IS_ENABLED(CONFIG_AGP) as suggested by Ville
>
> v3: Polish from Ville's review.
>
> Cc: Ville Syrjälä 
> Reviewed-by: Ville Syrjälä 
> Reviewed-by: Christian König  (v2)
> Signed-off-by: Daniel Vetter 

I recommend pushing it on your fdo branch to let the kbuild-bots run
it for some tests. But otherwise, looks good to me:

Reviewed-by: David Herrmann 

Thanks
David

> ---
>  drivers/gpu/drm/Makefile |  3 ++-
>  drivers/gpu/drm/drm_agpsupport.c |  4 
>  drivers/gpu/drm/drm_bufs.c   |  6 +++---
>  drivers/gpu/drm/drm_ioc32.c  |  6 +++---
>  drivers/gpu/drm/drm_ioctl.c  |  2 +-
>  drivers/gpu/drm/drm_memory.c |  6 +++---
>  drivers/gpu/drm/drm_vm.c |  8 
>  drivers/gpu/drm/mga/mga_dma.c|  4 ++--
>  drivers/gpu/drm/nouveau/nouveau_bo.c |  8 
>  drivers/gpu/drm/r128/r128_cce.c  | 12 ++--
>  drivers/gpu/drm/radeon/r600_cp.c | 14 +++---
>  drivers/gpu/drm/radeon/radeon_agp.c  |  8 
>  drivers/gpu/drm/radeon/radeon_cp.c   | 16 
>  drivers/gpu/drm/radeon/radeon_ttm.c  | 10 +-
>  include/drm/drm_agpsupport.h |  9 +++--
>  15 files changed, 55 insertions(+), 61 deletions(-)
>
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 45e7719846b1..f458d6e33655 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -6,7 +6,7 @@ drm-y   :=  drm_auth.o drm_bufs.o drm_cache.o \
> drm_context.o drm_dma.o \
> drm_fops.o drm_gem.o drm_ioctl.o drm_irq.o \
> drm_lock.o drm_memory.o drm_drv.o drm_vm.o \
> -   drm_agpsupport.o drm_scatter.o drm_pci.o \
> +   drm_scatter.o drm_pci.o \
> drm_platform.o drm_sysfs.o drm_hashtab.o drm_mm.o \
> drm_crtc.o drm_modes.o drm_edid.o \
> drm_info.o drm_debugfs.o drm_encoder_slave.o \
> @@ -19,6 +19,7 @@ drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
>  drm-$(CONFIG_PCI) += ati_pcigart.o
>  drm-$(CONFIG_DRM_PANEL) += drm_panel.o
>  drm-$(CONFIG_OF) += drm_of.o
> +drm-$(CONFIG_AGP) += drm_agpsupport.o
>
>  drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
> drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o
> diff --git a/drivers/gpu/drm/drm_agpsupport.c 
> b/drivers/gpu/drm/drm_agpsupport.c
> index 4b2b4aa5033b..a10ea6aec629 100644
> --- a/drivers/gpu/drm/drm_agpsupport.c
> +++ b/drivers/gpu/drm/drm_agpsupport.c
> @@ -36,8 +36,6 @@
>  #include 
>  #include "drm_legacy.h"
>
> -#if __OS_HAS_AGP
> -
>  #include 
>
>  /**
> @@ -502,5 +500,3 @@ drm_agp_bind_pages(struct drm_device *dev,
> return mem;
>  }
>  EXPORT_SYMBOL(drm_agp_bind_pages);
> -
> -#endif /* __OS_HAS_AGP */
> diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
> index 569064a00693..f1a204d253cc 100644
> --- a/drivers/gpu/drm/drm_bufs.c
> +++ b/drivers/gpu/drm/drm_bufs.c
> @@ -582,7 +582,7 @@ static void drm_cleanup_buf_error(struct drm_device * dev,
> }
>  }
>
> -#if __OS_HAS_AGP
> +#if IS_ENABLED(CONFIG_AGP)
>  /**
>   * Add AGP buffers for DMA transfers.
>   *
> @@ -756,7 +756,7 @@ int drm_legacy_addbufs_agp(struct drm_device *dev,
> return 0;
>  }
>  EXPORT_SYMBOL(drm_legacy_addbufs_agp);
> -#endif /* __OS_HAS_AGP */
> +#endif /* CONFIG_AGP */
>
>  int drm_legacy_addbufs_pci(struct drm_device *dev,
>struct drm_buf_desc *request)
> @@ -1145,7 +1145,7 @@ int drm_legacy_addbufs(struct drm_device *dev, void 
> *data,
> if (!drm_core_check_feature(dev, DRIVER_HAVE_DMA))
> return -EINVAL;
>
> -#if __OS_HAS_AGP
> +#if IS_ENABLED(CONFIG_AGP)
> if (request->flags & _DRM_AGP_BUFFER)
> ret = drm_legacy_addbufs_agp(dev, request);
> else
> diff --git a/drivers/gpu/drm/drm_ioc32.c b/drivers/gpu/drm/drm_ioc32.c
> index ddfa6014c2c2..57676f8d7ecf 100644
> --- a/drivers/gpu/drm/drm_ioc32.c
> +++ b/drivers/gpu/drm/drm_ioc32.c
> @@ -720,7 +720,7 @@ static int compat_drm_dma(struct file *file, unsigned int 
> cmd,
> return 0;
>  }
>
> -#if __OS_HAS_AGP
> +#if IS_ENABLED(CONFIG_AGP)
>  typedef struct drm_agp_mode32 {
> u32 mode;   /**< AGP mode */
>  } drm_agp_mode32_t;
> @@ -882,7 +882,7 @@ static int compat_drm_agp_unbind(struct file *file, 
> unsigned int cmd,
>
> return drm_ioctl(file, DRM_IOCTL_AGP_UNBIND, (unsigned long)request);
>  }
> -#endif /* __OS_HAS_AGP */
> +#endif /* CONFIG_AGP */
>
>  typedef struct 

[Bug 92082] Build on Solaris: xf86drm.c:3021: error: 'PATH_MAX' undeclared (first use in this function)

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

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

Emil Velikov  changed:

   What|Removed |Added

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

--- Comment #3 from Emil Velikov  ---
Should be fixed in master. Thanks for the report.

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

[PATCH i-g-t] tests: Adding kms_dp_aux_dev test.

[Rafael Antognolli]

This new test makes some basic testing on the proposed drm_dp_aux_dev
interface. If the feature is enabled and the drm_dp_aux_dev class is
present, it will check for available DP aux channels and test them for:
- basic seek to 0 and read 1 byte
- seek to the last address and read, to confirm 0 is returned
- seek one more byte and confirm that EINVAL is returned
- try to read 64 bytes when at 8 bytes from the end of the
address space
- try to read 64 bytes at the address 0.

So far, no write checks are done.

Signed-off-by: Rafael Antognolli 
---
 tests/.gitignore   |   1 +
 tests/Makefile.sources |   1 +
 tests/kms_dp_aux_dev.c | 134 +
 3 files changed, 136 insertions(+)
 create mode 100644 tests/kms_dp_aux_dev.c

diff --git a/tests/.gitignore b/tests/.gitignore
index dc8bb53..efdad75 100644
--- a/tests/.gitignore
+++ b/tests/.gitignore
@@ -127,6 +127,7 @@ kms_3d
 kms_addfb_basic
 kms_crtc_background_color
 kms_cursor_crc
+kms_dp_aux_dev
 kms_draw_crc
 kms_fbc_crc
 kms_fbcon_fbt
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 2e2e088..dc07737 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -64,6 +64,7 @@ TESTS_progs_M = \
gem_write_read_ring_switch \
kms_addfb_basic \
kms_cursor_crc \
+   kms_dp_aux_dev \
kms_draw_crc \
kms_fbc_crc \
kms_fbcon_fbt \
diff --git a/tests/kms_dp_aux_dev.c b/tests/kms_dp_aux_dev.c
new file mode 100644
index 000..aab8c95
--- /dev/null
+++ b/tests/kms_dp_aux_dev.c
@@ -0,0 +1,134 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * 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 without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+/** @file kms_dp_aux_dev.c
+ *
+ * This is a test of functionality of drm_dp_aux_dev.
+ */
+
+#include "igt.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define DRM_DP_AUX_SYSFS_PATH "/sys/class/drm_dp_aux_dev"
+
+IGT_TEST_DESCRIPTION("Test of drm_aux_dev nodes.");
+
+static void drm_dp_aux_test(const char *devname)
+{
+   char basedir[] = "/dev/";
+   char name[256 + sizeof(basedir)];
+   off_t address;
+   uint8_t buf;
+   uint8_t bigbuf[64];
+   int fd;
+
+   ssize_t res;
+
+   snprintf(name, sizeof(name), "%s%s", basedir, devname);
+   igt_info("Running test on %s\n", name);
+ 
+   /* Check if this DP aux channel is connected before continuing tests */
+   fd = open(name, O_RDONLY);
+   igt_assert_lte(0, fd);
+   address = lseek(fd, 0x0, SEEK_SET);
+   igt_assert_eq(address, 0x0);
+   res = read(fd, , sizeof(buf));
+   igt_skip_on(res < 0 && errno == ETIMEDOUT);
+ 
+
+   /* Channel is connected, start tests */
+   igt_assert_eq(res, sizeof(buf));
+
+   /* Test reads on the end of address space */
+   address = lseek(fd, 0, SEEK_END);
+   igt_assert_eq(address, 1 << 20);
+   res = read(fd, , sizeof(buf));
+   igt_assert_eq(res, 0);
+
+   address = lseek(fd, 1, SEEK_CUR);
+   igt_assert_eq(address, -1);
+   igt_assert_eq(errno, EINVAL);
+
+   address = lseek(fd, -8, SEEK_END);
+   res = read(fd, bigbuf, sizeof(bigbuf));
+   igt_assert_eq(res, 8);
+
+   /* Test reading more than 16 bytes at once */
+   address = lseek(fd, 0, SEEK_SET);
+   res = read(fd, bigbuf, sizeof(bigbuf));
+   igt_assert_eq(res, sizeof(bigbuf));
+}
+
+static void for_each_dp_aux(DIR *dir)
+{
+   int count = 0;
+   struct dirent *dirent;
+
+   if (!dir)
+   return;
+
+   rewinddir(dir);
+   while ((dirent = readdir(dir))) {
+   if (dirent->d_name[0] == '.')
+   continue;
+
+   count++;
+   igt_subtest(dirent->d_name)
+   drm_dp_aux_test(dirent->d_name);
+   }
+
+   closedir(dir);
+}
+
+igt_main
+{

[PATCH 2/2] drm/exynos: Use the core platform_driver component matching helper.

[Eric Anholt]

Signed-off-by: Eric Anholt 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 37 +++--
 1 file changed, 7 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 831d2e4..74826ec 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -566,32 +566,6 @@ static struct platform_driver *const 
exynos_drm_drv_with_simple_dev[] = {
 };
 #define PDEV_COUNT ARRAY_SIZE(exynos_drm_drv_with_simple_dev)

-static int compare_dev(struct device *dev, void *data)
-{
-   return dev == (struct device *)data;
-}
-
-static struct component_match *exynos_drm_match_add(struct device *dev)
-{
-   struct component_match *match = NULL;
-   int i;
-
-   for (i = 0; i < ARRAY_SIZE(exynos_drm_kms_drivers); ++i) {
-   struct device_driver *drv = _drm_kms_drivers[i]->driver;
-   struct device *p = NULL, *d;
-
-   while ((d = bus_find_device(_bus_type, p, drv,
-   (void *)platform_bus_type.match))) {
-   put_device(p);
-   component_match_add(dev, , compare_dev, d);
-   p = d;
-   }
-   put_device(p);
-   }
-
-   return match ?: ERR_PTR(-ENODEV);
-}
-
 static int exynos_drm_bind(struct device *dev)
 {
return drm_platform_init(_drm_driver, to_platform_device(dev));
@@ -609,14 +583,17 @@ static const struct component_master_ops exynos_drm_ops = 
{

 static int exynos_drm_platform_probe(struct platform_device *pdev)
 {
-   struct component_match *match;
+   struct component_match *match = NULL;

pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls);

-   match = exynos_drm_match_add(>dev);
-   if (IS_ERR(match))
-   return PTR_ERR(match);
+   component_match_add_platform_drivers(>dev, ,
+exynos_drm_kms_drivers,
+
ARRAY_SIZE(exynos_drm_kms_drivers));
+
+   if (!match)
+   return -ENODEV;

return component_master_add_with_match(>dev, _drm_ops,
   match);
-- 
2.1.4

[PATCH 1/2] component: Make a "match_add all devices matching my drivers" helper.

[Eric Anholt]

The body of the loop is taken from the exynos driver.  It appears to
also be useful in msm, and I've used it in vc4.

Signed-off-by: Eric Anholt 
---

This is separated from converting exynos to use it, to let it land
separately and not have to sync between trees.

 drivers/base/component.c  | 40 
 include/linux/component.h |  5 +
 2 files changed, 45 insertions(+)

diff --git a/drivers/base/component.c b/drivers/base/component.c
index f748430..08167a3 100644
--- a/drivers/base/component.c
+++ b/drivers/base/component.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 struct component_match {
@@ -283,6 +284,45 @@ void component_match_add(struct device *dev, struct 
component_match **matchptr,
 }
 EXPORT_SYMBOL(component_match_add);

+static int compare_dev(struct device *dev, void *data)
+{
+   return dev == (struct device *)data;
+}
+
+/**
+ * component_match_add_platform_drivers - For each driver passed in,
+ * finds each device that probed with it and adds it as a component
+ * driver to the match list.
+ * @dev: master device for the components
+ * @match:   pointer to the match structure pointer.  For the first
+ *   component_match_add(), this should be a pointer to a NULL
+ *   pointer, which will get filled in by the call.
+ * @drivers: array of platform drivers whose devices should all be
+ *   added to the match
+ * @count:   number of platform drivers to match
+ */
+void component_match_add_platform_drivers(struct device *dev,
+ struct component_match **match,
+ struct platform_driver *const 
*drivers,
+ int count)
+{
+   int i;
+
+   for (i = 0; i < count; i++) {
+   struct device_driver *drv = [i]->driver;
+   struct device *p = NULL, *d;
+
+   while ((d = bus_find_device(_bus_type, p, drv,
+   (void *)platform_bus_type.match))) {
+   put_device(p);
+   component_match_add(dev, match, compare_dev, d);
+   p = d;
+   }
+   put_device(p);
+   }
+}
+EXPORT_SYMBOL_GPL(component_match_add_platform_drivers);
+
 int component_master_add_with_match(struct device *dev,
const struct component_master_ops *ops,
struct component_match *match)
diff --git a/include/linux/component.h b/include/linux/component.h
index c00dcc3..2d74420 100644
--- a/include/linux/component.h
+++ b/include/linux/component.h
@@ -2,6 +2,7 @@
 #define COMPONENT_H

 struct device;
+struct platform_driver;

 struct component_ops {
int (*bind)(struct device *, struct device *, void *);
@@ -35,5 +36,9 @@ int component_master_add_with_match(struct device *,
const struct component_master_ops *, struct component_match *);
 void component_match_add(struct device *, struct component_match **,
int (*compare)(struct device *, void *), void *compare_data);
+void component_match_add_platform_drivers(struct device *dev,
+ struct component_match **match,
+ struct platform_driver *const 
*drivers,
+ int count);

 #endif
-- 
2.1.4

[PATCH v4 2/2] drm/dp: Add a drm_aux-dev module for reading/writing dpcd registers.

[Rafael Antognolli]

This module is heavily based on i2c-dev. Once loaded, it provides one
dev node per DP AUX channel, named drm_dp_auxN, where N is an integer.

It's possible to know which connector owns this aux channel by looking
at the respective sysfs /sys/class/drm_aux_dev/drm_dp_auxN/connector, if
the connector device pointer was correctly set in the aux helper struct.

Two main operations are provided on the registers read and write. The
address of the register to be read or written is given using lseek. The
seek position is updated upon read or write.

Signed-off-by: Rafael Antognolli 
---
 drivers/gpu/drm/Kconfig  |   8 +
 drivers/gpu/drm/Makefile |   1 +
 drivers/gpu/drm/drm_dp_aux_dev.c | 357 +++
 drivers/gpu/drm/drm_dp_helper.c  |   5 +
 include/drm/drm_dp_aux_dev.h |  50 ++
 5 files changed, 421 insertions(+)
 create mode 100644 drivers/gpu/drm/drm_dp_aux_dev.c
 create mode 100644 include/drm/drm_dp_aux_dev.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 1a0a8df..64fa0f4 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -25,6 +25,14 @@ config DRM_MIPI_DSI
bool
depends on DRM

+config DRM_DP_AUX_CHARDEV
+   bool "DRM DP AUX Interface"
+   depends on DRM
+   help
+ Choose this option to enable a /dev/drm_dp_auxN node that allows to
+ read and write values to arbitrary DPCD registers on the DP aux
+ channel.
+
 config DRM_KMS_HELPER
tristate
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 45e7719..e5ae7f0 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -25,6 +25,7 @@ drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o 
drm_probe_helper.o \
 drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
 drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o
 drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
+drm_kms_helper-$(CONFIG_DRM_DP_AUX_CHARDEV) += drm_dp_aux_dev.o

 obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o

diff --git a/drivers/gpu/drm/drm_dp_aux_dev.c b/drivers/gpu/drm/drm_dp_aux_dev.c
new file mode 100644
index 000..e337081
--- /dev/null
+++ b/drivers/gpu/drm/drm_dp_aux_dev.c
@@ -0,0 +1,357 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * 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 without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Rafael Antognolli 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct drm_dp_aux_dev {
+   struct list_head list;
+   unsigned index;
+   struct drm_dp_aux *aux;
+   struct device *dev;
+};
+
+#define DRM_AUX_MINORS 256
+static int aux_max_offset = 1 << 20;
+static int drm_dp_aux_dev_count = 0;
+static LIST_HEAD(drm_dp_aux_dev_list);
+static DEFINE_SPINLOCK(drm_dp_aux_dev_list_lock);
+
+static struct drm_dp_aux_dev *drm_dp_aux_dev_get_by_minor(unsigned index)
+{
+   struct drm_dp_aux_dev *aux_dev;
+
+   spin_lock(_dp_aux_dev_list_lock);
+   list_for_each_entry(aux_dev, _dp_aux_dev_list, list) {
+   if (aux_dev->index == index)
+   goto found;
+   }
+
+   aux_dev = NULL;
+found:
+   spin_unlock(_dp_aux_dev_list_lock);
+   return aux_dev;
+}
+
+static struct drm_dp_aux_dev *drm_dp_aux_dev_get_by_aux(struct drm_dp_aux *aux)
+{
+   struct drm_dp_aux_dev *aux_dev;
+
+   spin_lock(_dp_aux_dev_list_lock);
+   list_for_each_entry(aux_dev, _dp_aux_dev_list, list) {
+   if (aux_dev->aux == aux)
+   goto found;
+   }
+
+   aux_dev = NULL;
+found:
+   spin_unlock(_dp_aux_dev_list_lock);
+   return aux_dev;
+}
+
+static struct drm_dp_aux_dev *get_free_drm_dp_aux_dev(struct drm_dp_aux *aux)
+{
+   struct drm_dp_aux_dev *aux_dev;
+   int index;
+
+   

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

[Rafael Antognolli]

This is useful to determine which connector owns this AUX channel.

Signed-off-by: Rafael Antognolli 
---
 drivers/gpu/drm/i915/intel_dp.c | 1 +
 include/drm/drm_dp_helper.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 77f7330..f90439d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1079,6 +1079,7 @@ intel_dp_aux_init(struct intel_dp *intel_dp, struct 
intel_connector *connector)

intel_dp->aux.name = name;
intel_dp->aux.dev = dev->dev;
+   intel_dp->aux.connector = connector->base.kdev;
intel_dp->aux.transfer = intel_dp_aux_transfer;

DRM_DEBUG_KMS("registering %s bus for %s\n", name,
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 9ec4716..e009b5d 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -702,6 +702,7 @@ struct drm_dp_aux {
const char *name;
struct i2c_adapter ddc;
struct device *dev;
+   struct device *connector;
struct mutex hw_mutex;
ssize_t (*transfer)(struct drm_dp_aux *aux,
struct drm_dp_aux_msg *msg);
-- 
2.4.3

[PATCH v4 0/2] Add drm_dp_aux chardev support.

[Rafael Antognolli]

This series implement support to a drm_dp_aux chardev that allows reading and
writing an arbitrary amount of bytes to arbitrary dpcd register addresses using
regular read, write and lseek operations.

v2:
 - lseek is used to select the register to read/write
 - read/write are used instead of ioctl
 - no blocking_notifier is used, just a direct callback

v3:
 - use drm_dp_aux_dev prefix for public functions
 - chardev is named drm_dp_auxN
 - read/write don't allocate a buffer anymore, and transfer up to 16 bytes a
 time
 - remove notifier list from the implementation
 - option on menuconfig is now a boolean
 - add inline stub functions to avoid breakage when this option is disabled

v4:
 - fix build system changes - actually disable this module when not selected.

Rafael Antognolli (2):
  drm/dp: Store the drm_connector device pointer on the helper.
  drm/dp: Add a drm_aux-dev module for reading/writing dpcd registers.

 drivers/gpu/drm/Kconfig  |   8 +
 drivers/gpu/drm/Makefile |   1 +
 drivers/gpu/drm/drm_dp_aux_dev.c | 357 +++
 drivers/gpu/drm/drm_dp_helper.c  |   5 +
 drivers/gpu/drm/i915/intel_dp.c  |   1 +
 include/drm/drm_dp_aux_dev.h |  50 ++
 include/drm/drm_dp_helper.h  |   1 +
 7 files changed, 423 insertions(+)
 create mode 100644 drivers/gpu/drm/drm_dp_aux_dev.c
 create mode 100644 include/drm/drm_dp_aux_dev.h

-- 
2.4.3

[Bug 105051] Radeon sets max_brightness to -1, breaking GNOME backlight control on Macbook Pro mid-2015 11,5

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

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

Robert Abraham  changed:

   What|Removed |Added

 CC||robert.abraham86 at googlemail
   ||.com

--- Comment #2 from Robert Abraham  ---
I have a similar problem. gmux_backlight/max_brightness is set to -1.
But i also have a radeon_bl entry in /sys/class/backlight which has the correct
values.
But no matter which value i echo into /sys/class/backlight/radeon_bl/brightness
i am on max brightness, except i echo 0. in this case the backlight turns off.

so i can only choose between backlight off or on max brightness.
it works perfectly fine on 4.0.x kernel though.

i will happily provide any information you need.

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

[Bug 105111] amdgpu 0000:00:01.0: Invalid ROM contents (with A8-7600)

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

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

--- Comment #3 from fin4478 at hotmail.com ---
Created attachment 188771
  --> https://bugzilla.kernel.org/attachment.cgi?id=188771=edit
Amd Catalyst bios information with kernel 4.1.6

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

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

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

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

--- Comment #12 from Mathias Tillman  ---
(In reply to Michel Dänzer from comment #10)
> Mathias, so you can reliably reproduce the hang by replaying that apitrace?

Okay, I have been able to replay the trace by compiling apitrace from source,
and renaming glretrace to valley_x64.
I can reproduce the hang by replaying, but not in a very useful way as the hang
happens on different frames on each replay, so I wouldn't really call it
reproducible at this point.
I will see what different options glretrace gives me, to see if I can find some
kind of common denominator between the hangs.

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

[PATCH 1/4] qcom-scm: add ocmem support

[Stephen Boyd]

On 09/28, Bjorn Andersson wrote:
> On Mon 28 Sep 14:08 PDT 2015, Rob Clark wrote:
> 
> > On Mon, Sep 28, 2015 at 4:51 PM, Stephen Boyd  
> > wrote:
> > > On 09/28, Rob Clark wrote:
> > >> +bool qcom_scm_ocmem_secure_available(void)
> > >> +{
> > >> + int ret = qcom_scm_clk_enable();
> > >
> > > I doubt we need to enable clocks to figure out if a call is
> > > available. Please drop clk stuff here.
> > 
> > hmm, hdcp did, but pas didn't..  otoh it looks like the call to
> > __qcom_scm_pas_supported() *should* be wrapped in clk enable/disable..
> > 
> > And __qcom_scm_is_call_available() does call qcom_scm_call().  Which
> > is, I assume, what needs the clk's..  so not entirely sure if *all*
> > the clk enable/disable stuff should be stripped out, or if missing clk
> > stuff should be added in qcom_scm_pas_supported()..
> > 
> 
> The scm clocks here are the crypto engine clocks, they are not needed to
> check if TZ implements PAS for a given processor or not.
> 
> But it could be argued that this is simply an assumption I make of the
> black box we're calling into...

Let's not make assumptions. They're not needed to check if it has
support for something.

> 
> > 
> > >> +
> > >> + if (ret)
> > >> + goto clk_err;
> > >> +
> > >> + ret = __qcom_scm_is_call_available(QCOM_SCM_OCMEM_SECURE_SVC,
> > >> + QCOM_SCM_OCMEM_SECURE_CFG);
> > >> +
> > >> + qcom_scm_clk_disable();
> > >> +
> > >> +clk_err:
> > >> + return (ret > 0) ? true : false;
> > >> +}
> > >> +EXPORT_SYMBOL(qcom_scm_ocmem_secure_available);
> > >> +
> [..]
> > >> +int qcom_scm_ocmem_unlock(uint32_t id, uint32_t offset, uint32_t size)
> > >> +{
> > >> + int ret = qcom_scm_clk_enable();
> > >> +
> > >> + if (ret)
> > >> + return ret;
> > >> +
> > >> + ret = __qcom_scm_ocmem_unlock(id, offset, size);
> > >> + qcom_scm_clk_disable();
> > >> +
> > >> + return ret;
> > >> +}
> > >> +EXPORT_SYMBOL(qcom_scm_ocmem_unlock);
> > >
> > > I don't think we need any clocks for lock/unlock/cfg either. The
> > > scm clocks are some crypto clocks that the secure side isn't able
> > > to enable and we don't have a device in DT for them. In the ocmem
> > > case, we should rely on the ocmem device to get the clocks and
> > > turn them on before calling any scm APIs that may require those
> > > clocks.
> > 
> > Hmm, if that is true then we should probably drop the clks for hdcp
> > fxns too, and maybe add a comment somewhere since it isn't really
> > clear what the clks are for (and when it is unclear, folks will just
> > cargo-cult what the existing fxns are doing).  As-is it is hard to
> > tell what is required and what is luck..
> > 
> 
> I would expect hdcp to use the crypto engines in some way and we don't
> want people to feel that they should add the random clocks here, so
> commenting them is probably the way to go.

Yes HDCP uses crypto for something so those clock calls should
stay. If the clocks were used by a HDCP device then it would be
like the ocmem case, but it isn't.

> 
> > >> diff --git a/include/linux/qcom_scm.h b/include/linux/qcom_scm.h
> > >> index 46d41e4..a934457 100644
> > >> --- a/include/linux/qcom_scm.h
> > >> +++ b/include/linux/qcom_scm.h
> > >> @@ -23,10 +23,20 @@ struct qcom_scm_hdcp_req {
> > >>   u32 val;
> > >>  };
> > >>
> > >> +extern bool qcom_scm_is_available(void);
> > >
> > > Is this used? Looks like noise.
> > 
> > perhaps should be split out into a separate patch..  but I am using
> > this, and it seems like a good idea to avoid null ptr deref's of
> > __scm.  Probably some of the scm callers should call this first..
> > either that or we should make other scm entry points behave better if
> > __scm is null..
> > 
> 
> This is part of Andy's platformication, didn't he export it properly?
> I use it as well from the remoteproc.

Do we probe defer ocmem if scm isn't ready? Maybe we should name
it qcom_scm_is_probed() and have it return -EPROBE_DEFER if it
isn't probed and 0 if it is probed. Then drivers just call that
function and return the error if there is one. I'd rather not
litter scm_*() APIs with checks to see if the driver has probed
yet. Just let those crash the system. Of course, this probably
doesn't matter because we don't need to do any clock stuff here
anyway.

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

[Bug 105111] amdgpu 0000:00:01.0: Invalid ROM contents (with A8-7600)

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

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

--- Comment #2 from fin4478 at hotmail.com ---
(In reply to Alex Deucher from comment #1)
> Is this a regression?  If so, can you bisect?

Same bug is in kernel 4.3-rc1 that i try before rc3. Amd Catalyst 15.201 works
ok with kernel 4.1.6 and can found bios information.

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

[Bug 76490] Hang during boot when DPM is on (R9 270X)

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

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

--- Comment #57 from Alex Deucher  ---
I don't think this has anything to do with the vbios.  I suspect the same pci
ids are just used in multiple board configurations (e.g., different clocks or
vram chip vendors or voltage configurations) so the pci ids are not enough as
is to differentiate.  I need to take a closer look at the vbioses.

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

[PATCH RFC v4 3/8] ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders

[Jyri Sarha]

On 09/28/15 12:01, Arnaud Pouliquen wrote:
> few questions/remarks
> BR,
> Arnaud
>
>> +static void hdmi_codec_abort(struct device *dev)
>> +{
>> +struct hdmi_codec_priv *hcp = dev_get_drvdata(dev);
>> +
>> +dev_dbg(dev, "%s()\n", __func__);
>> +
>> +mutex_lock(>current_stream_lock);
>> +if (hcp->current_stream && hcp->current_stream->runtime &&
>> +snd_pcm_running(hcp->current_stream)) {
>> +dev_info(dev, "HDMI audio playback aborted\n");
>> +snd_pcm_stream_lock_irq(hcp->current_stream);
>> +snd_pcm_stop(hcp->current_stream, SNDRV_PCM_STATE_DISCONNECTED);
>> +snd_pcm_stream_unlock_irq(hcp->current_stream);
>> +}
>> +mutex_unlock(>current_stream_lock);
>> +}
> Does driver should stop the stream in case of unplug?
> This could generate unexpected behavior at application level.
> Perhaps should be better if this part is managed in DRM driver. if HDMI
> master, I2S bus should be maintained ON to consume the audio stream
> until application action.
>

The whole point of this abort callback is to provide the means for the 
video side to stop the audio playback in a clean way.

The abort callback is given to the video side in startup() callback 
(ASoC side calls video side). If the video side sees that the playback 
can not go on it can call the abort callback and the audio playback will 
abort in standard ALSA way and a properly written applications should 
not get confused.

Nothing is forcing the video side to call the callback ever, if so 
decided. But if for instance power management stops the i2s clocks when 
connector is unplugged, then the audio can not go on any more and it 
should be aborted (actually it would abort in a moment when ALSA 
realizes that the DMA is not running).

>> +
>> +static int hdmi_codec_hw_params(struct snd_pcm_substream *substream,
>> +struct snd_pcm_hw_params *params,
>> +struct snd_soc_dai *dai)
>> +{
>> +struct hdmi_codec_priv *hcp = snd_soc_dai_get_drvdata(dai);
>> +struct hdmi_codec_params hp = {
>> +.iec = {
>> +.status = { 0 },
>> +.subcode = { 0 },
>> +.pad = 0,
>> +.dig_subframe = { 0 },
>> +}
>> +};
>> +int ret;
>> +
>> +dev_dbg(dai->dev, "%s() width %d rate %d channels %d\n", __func__,
>> +params_width(params), params_rate(params),
>> +params_channels(params));
>> +
>> +ret = snd_pcm_create_iec958_consumer_hw_params(params,
>> hp.iec.status,
>> +   sizeof(hp.iec.status));
> Tell me if i am wrong, but in case of SPDIF format, IEC status is
> managed by cpu_dai not by the codec.
> To manage IEC61937 a control should be needed to update IEC status bits...
>

AFAIK yes. However, the video side implementation is free to ignore 
status bits in the struct hdmi_codec_params and it should normally do so 
if the format is SPDIF. Of course I could save couple CPU cycles in the 
codec code if would not even produce the bits when the format is SPDIF.

Best regards,
Jyri

>> +if (ret < 0) {
>> +dev_err(dai->dev, "Creating IEC958 channel status failed %d\n",
>> +ret);
>> +return ret;
>> +}
>> +
>> +ret = hdmi_codec_new_stream(substream, dai);
>> +if (ret)
>> +return ret;
>> +
>> +hdmi_audio_infoframe_init();
>> +hp.cea.channels = params_channels(params);
>> +hp.cea.coding_type = HDMI_AUDIO_CODING_TYPE_STREAM;
>> +hp.cea.sample_size = HDMI_AUDIO_SAMPLE_SIZE_STREAM;
>> +hp.cea.sample_frequency = HDMI_AUDIO_SAMPLE_FREQUENCY_STREAM;
>> +
>> +hp.sample_width = params_width(params);
>> +hp.sample_rate = params_rate(params);
>> +hp.channels = params_channels(params);
>> +
>> +return hcp->hcd.ops->hw_params(dai->dev->parent,
>> >daifmt[dai->id],
>> +   );
>> +}
>> +

[Bug 90595] [drm:si_dpm_set_power_state [radeon]] *ERROR* si_set_sw_state failed

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

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

--- Comment #8 from Alex Deucher  ---
(In reply to JATothrim from comment #7)
> 
> I'm already using newest git mesa (Oibaf graphics drivers ppa). I also have
> tied self compiling the git mesa driver but no change to hibernate. However
> I disabled the radeon DPM power management with radeon.dpm=0 in kernel
> command-line and it fixed the hibernate! I still see awful lot of this
> '[drm:si_dpm_set_power_state [radeon]] *ERROR* si_set_sw_state failed' error
> in dmesg tough. Also bad is that I miss the automatic DPM..

If you set radeon.dpm=0, you shouldn't see any of the dpm error messages in
your log.  Make sure the parameter setting actually got picked up.

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

[PATCH 4/4] drm/msm: add OCMEM driver

[Stephen Boyd]

On 09/28, Rob Clark wrote:
> @@ -322,10 +319,8 @@ static void a3xx_destroy(struct msm_gpu *gpu)
>  
>   adreno_gpu_cleanup(adreno_gpu);
>  
> -#ifdef CONFIG_MSM_OCMEM
>   if (a3xx_gpu->ocmem_base)

Is this supposed to be ocmem_base or ocmem_hdl? Perhaps this
check could be put inside the ocmem_free() itself so that the
caller doesn't have to care.

>   ocmem_free(OCMEM_GRAPHICS, a3xx_gpu->ocmem_hdl);
> -#endif
>  
>   kfree(a3xx_gpu);
>  }
> @@ -289,10 +288,8 @@ static void a4xx_destroy(struct msm_gpu *gpu)
>  
>   adreno_gpu_cleanup(adreno_gpu);
>  
> -#ifdef CONFIG_MSM_OCMEM
> - if (a4xx_gpu->ocmem_base)
> + if (a4xx_gpu->ocmem_hdl)

This one changed, so a3xx above seems highly suspicious.

>   ocmem_free(OCMEM_GRAPHICS, a4xx_gpu->ocmem_hdl);
> -#endif
>  
>   kfree(a4xx_gpu);
>  }
> diff --git a/drivers/gpu/drm/msm/msm_gpu.h b/drivers/gpu/drm/msm/msm_gpu.h
> index 2bbe85a..f042ba8 100644
> --- a/drivers/gpu/drm/msm/msm_gpu.h
> +++ b/drivers/gpu/drm/msm/msm_gpu.h
> @@ -172,4 +172,7 @@ struct msm_gpu *adreno_load_gpu(struct drm_device *dev);
>  void __init adreno_register(void);
>  void __exit adreno_unregister(void);
>  
> +void __init ocmem_register(void);
> +void __exit ocmem_unregister(void);

__init and __exit in header files is useless

> +
>  #endif /* __MSM_GPU_H__ */
> diff --git a/drivers/gpu/drm/msm/ocmem/ocmem.c 
> b/drivers/gpu/drm/msm/ocmem/ocmem.c
> new file mode 100644
> index 000..d3cdd64
> --- /dev/null
> +++ b/drivers/gpu/drm/msm/ocmem/ocmem.c
> @@ -0,0 +1,396 @@
> +/*
> + * Copyright (C) 2015 Red Hat
> + * Author: Rob Clark 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published 
> by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but 
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +
> +#include 
> +#include 

What is this include for?

> +#include 
> +
> +#include "msm_drv.h"
> +#include "ocmem.h"
> +#include "ocmem.xml.h"
> +
> +enum region_mode {
> + WIDE_MODE = 0x0,
> + THIN_MODE,
> + MODE_DEFAULT = WIDE_MODE,
> +};
> +
> +enum ocmem_tz_client {
> + TZ_UNUSED = 0x0,
> + TZ_GRAPHICS,
> + TZ_VIDEO,
> + TZ_LP_AUDIO,
> + TZ_SENSORS,
> + TZ_OTHER_OS,
> + TZ_DEBUG,
> +};
> +
> +struct ocmem_region {
> + unsigned psgsc_ctrl;
> + bool interleaved;
> + enum region_mode mode;
> + unsigned int num_macros;
> + enum ocmem_macro_state macro_state[4];
> + unsigned long macro_size;
> + unsigned long region_size;
> +};
> +
> +struct ocmem_config {
> + uint8_t  num_regions;
> + uint32_t macro_size;
> +};
> +
> +struct ocmem {
> + struct device *dev;
> + const struct ocmem_config *config;
> + struct resource *ocmem_mem;
> + struct clk *core_clk;
> + struct clk *iface_clk;
> + void __iomem *mmio;
> +
> + unsigned num_ports;

Is this used after probe?

> + unsigned num_macros;
> + bool interleaved;

Is this used after probe?

> +
> + struct ocmem_region *regions;
> +};
> +
> +struct ocmem *ocmem;

static?

> +
> +static bool ocmem_exists(void);
> +
> +static inline void ocmem_write(struct ocmem *ocmem, u32 reg, u32 data)
> +{
> + msm_writel(data, ocmem->mmio + reg);
> +}
> +
> +static inline u32 ocmem_read(struct ocmem *ocmem, u32 reg)
> +{
> + return msm_readl(ocmem->mmio + reg);
> +}
> +
> +static int ocmem_clk_enable(struct ocmem *ocmem)
> +{
> + int ret;
> +
> + ret = clk_prepare_enable(ocmem->core_clk);
> + if (ret)
> + return ret;
> +
> + if (ocmem->iface_clk) {
> + ret = clk_prepare_enable(ocmem->iface_clk);

clk_prepare_enable() on NULL does nothing so it should be safe to
drop the if.

> + if (ret)
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static void update_ocmem(struct ocmem *ocmem)
> +{
> + uint32_t region_mode_ctrl = 0x0;
> + unsigned pos = 0;
> + unsigned i = 0;
> +
> + if (!qcom_scm_ocmem_lock_available()) {
> + for (i = 0; i < ocmem->config->num_regions; i++) {
> + struct ocmem_region *region = >regions[i];
> + pos = i << 2;
> + if (region->mode == THIN_MODE)
> + region_mode_ctrl |= BIT(pos);
> + }
> + dev_dbg(ocmem->dev, "ocmem_region_mode_control %x\n", 
> region_mode_ctrl);
> + ocmem_write(ocmem, REG_OCMEM_REGION_MODE_CTL, region_mode_ctrl);
> + /* Barrier to commit the region mode */
> + 

[Bug 105051] Radeon sets max_brightness to -1, breaking GNOME backlight control on Macbook Pro mid-2015 11,5

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

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

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #1 from Alex Deucher  ---
Radeon hardware supports 256 levels of brightness (0-255).  The backlight
integer property max_brightness is thus set to RADEON_MAX_BL_LEVEL (0xff).  It
sounds like GNOME is misinterpreting the value.

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

[Bug 90595] [drm:si_dpm_set_power_state [radeon]] *ERROR* si_set_sw_state failed

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

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

--- Comment #7 from JATothrim  ---
(In reply to Adam Flott from comment #6)
> (In reply to JATothrim from comment #5)
> > I am also a victim of this bug.
> > It freezes/soft bricks my machine every time while resuming from hibernate -
> > suspend to ram tough works kind of ok (tty dual monitor border corruption).
> > I'm running 4.2.0 vanilla kernel.
> 
> Try upgrading xf86-video-ati from git. You only need to cp the
> src/.libs/radeon_drv.so file to /usr/lib/xorg/modules/drivers/radeon_drv.so
> (or your distros equivalent). Beware that X will auto-restart afterwards. I
> found that doing so has squashed Bug91994. However I still see
> [drm:si_dpm_set_power_state [radeon]] *ERROR* si_set_sw_state failed in
> dmesg.

I'm already using newest git mesa (Oibaf graphics drivers ppa). I also have
tied self compiling the git mesa driver but no change to hibernate. However I
disabled the radeon DPM power management with radeon.dpm=0 in kernel
command-line and it fixed the hibernate! I still see awful lot of this
'[drm:si_dpm_set_power_state [radeon]] *ERROR* si_set_sw_state failed' error in
dmesg tough. Also bad is that I miss the automatic DPM..

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

[PATCH 1/4] qcom-scm: add ocmem support

[Bjorn Andersson]

On Mon 28 Sep 14:08 PDT 2015, Rob Clark wrote:

> On Mon, Sep 28, 2015 at 4:51 PM, Stephen Boyd  wrote:
> > On 09/28, Rob Clark wrote:
> >> Add interfaces needed for configuring OCMEM.
> >>
> >> Signed-off-by: Rob Clark 
> >> ---
> >>  drivers/firmware/qcom_scm-32.c |  57 ++
> >>  drivers/firmware/qcom_scm-64.c |  16 +++
> >>  drivers/firmware/qcom_scm.c| 106 
> >> +
> >>  drivers/firmware/qcom_scm.h|  13 +
> >>  include/linux/qcom_scm.h   |  10 
> >>  5 files changed, 202 insertions(+)
> >>
> >> diff --git a/drivers/firmware/qcom_scm-32.c 
> >> b/drivers/firmware/qcom_scm-32.c
[..]
> >> +bool qcom_scm_ocmem_secure_available(void)
> >> +{
> >> + int ret = qcom_scm_clk_enable();
> >
> > I doubt we need to enable clocks to figure out if a call is
> > available. Please drop clk stuff here.
> 
> hmm, hdcp did, but pas didn't..  otoh it looks like the call to
> __qcom_scm_pas_supported() *should* be wrapped in clk enable/disable..
> 
> And __qcom_scm_is_call_available() does call qcom_scm_call().  Which
> is, I assume, what needs the clk's..  so not entirely sure if *all*
> the clk enable/disable stuff should be stripped out, or if missing clk
> stuff should be added in qcom_scm_pas_supported()..
> 

The scm clocks here are the crypto engine clocks, they are not needed to
check if TZ implements PAS for a given processor or not.

But it could be argued that this is simply an assumption I make of the
black box we're calling into...

> 
> >> +
> >> + if (ret)
> >> + goto clk_err;
> >> +
> >> + ret = __qcom_scm_is_call_available(QCOM_SCM_OCMEM_SECURE_SVC,
> >> + QCOM_SCM_OCMEM_SECURE_CFG);
> >> +
> >> + qcom_scm_clk_disable();
> >> +
> >> +clk_err:
> >> + return (ret > 0) ? true : false;
> >> +}
> >> +EXPORT_SYMBOL(qcom_scm_ocmem_secure_available);
> >> +
[..]
> >> +int qcom_scm_ocmem_unlock(uint32_t id, uint32_t offset, uint32_t size)
> >> +{
> >> + int ret = qcom_scm_clk_enable();
> >> +
> >> + if (ret)
> >> + return ret;
> >> +
> >> + ret = __qcom_scm_ocmem_unlock(id, offset, size);
> >> + qcom_scm_clk_disable();
> >> +
> >> + return ret;
> >> +}
> >> +EXPORT_SYMBOL(qcom_scm_ocmem_unlock);
> >
> > I don't think we need any clocks for lock/unlock/cfg either. The
> > scm clocks are some crypto clocks that the secure side isn't able
> > to enable and we don't have a device in DT for them. In the ocmem
> > case, we should rely on the ocmem device to get the clocks and
> > turn them on before calling any scm APIs that may require those
> > clocks.
> 
> Hmm, if that is true then we should probably drop the clks for hdcp
> fxns too, and maybe add a comment somewhere since it isn't really
> clear what the clks are for (and when it is unclear, folks will just
> cargo-cult what the existing fxns are doing).  As-is it is hard to
> tell what is required and what is luck..
> 

I would expect hdcp to use the crypto engines in some way and we don't
want people to feel that they should add the random clocks here, so
commenting them is probably the way to go.

> >> diff --git a/include/linux/qcom_scm.h b/include/linux/qcom_scm.h
> >> index 46d41e4..a934457 100644
> >> --- a/include/linux/qcom_scm.h
> >> +++ b/include/linux/qcom_scm.h
> >> @@ -23,10 +23,20 @@ struct qcom_scm_hdcp_req {
> >>   u32 val;
> >>  };
> >>
> >> +extern bool qcom_scm_is_available(void);
> >
> > Is this used? Looks like noise.
> 
> perhaps should be split out into a separate patch..  but I am using
> this, and it seems like a good idea to avoid null ptr deref's of
> __scm.  Probably some of the scm callers should call this first..
> either that or we should make other scm entry points behave better if
> __scm is null..
> 

This is part of Andy's platformication, didn't he export it properly?
I use it as well from the remoteproc.

Regards,
Bjorn

[PATCH 4/4] drm/msm: add OCMEM driver

[Rob Clark]

For now, since the GPU is the only upstream consumer, just stuff this
into drm/msm.  Eventually if we have other consumers, we'll have to
split this out and make the allocation less hard coded.  But I'll punt
on that until I better understand the non-gpu uses-cases (and whether
the allocation *really* needs to be as complicated as it is in the
downstream driver).

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/Makefile  |   3 +-
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c |  17 +-
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c |  19 +-
 drivers/gpu/drm/msm/msm_drv.c |   2 +
 drivers/gpu/drm/msm/msm_gpu.h |   3 +
 drivers/gpu/drm/msm/ocmem/ocmem.c | 396 ++
 drivers/gpu/drm/msm/ocmem/ocmem.h |  46 
 7 files changed, 459 insertions(+), 27 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/ocmem/ocmem.c
 create mode 100644 drivers/gpu/drm/msm/ocmem/ocmem.h

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 0a543eb..8ddf6fa 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -48,7 +48,8 @@ msm-y := \
msm_iommu.o \
msm_perf.o \
msm_rd.o \
-   msm_ringbuffer.o
+   msm_ringbuffer.o \
+   ocmem/ocmem.o

 msm-$(CONFIG_DRM_MSM_FBDEV) += msm_fbdev.o
 msm-$(CONFIG_COMMON_CLK) += mdp/mdp4/mdp4_lvds_pll.o
diff --git a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
index ca29688..29bbb80 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a3xx_gpu.c
@@ -17,10 +17,7 @@
  * this program.  If not, see .
  */

-#ifdef CONFIG_MSM_OCMEM
-#  include 
-#endif
-
+#include "ocmem/ocmem.h"
 #include "a3xx_gpu.h"

 #define A3XX_INT0_MASK \
@@ -322,10 +319,8 @@ static void a3xx_destroy(struct msm_gpu *gpu)

adreno_gpu_cleanup(adreno_gpu);

-#ifdef CONFIG_MSM_OCMEM
if (a3xx_gpu->ocmem_base)
ocmem_free(OCMEM_GRAPHICS, a3xx_gpu->ocmem_hdl);
-#endif

kfree(a3xx_gpu);
 }
@@ -539,6 +534,7 @@ struct msm_gpu *a3xx_gpu_init(struct drm_device *dev)
struct msm_gpu *gpu;
struct msm_drm_private *priv = dev->dev_private;
struct platform_device *pdev = priv->gpu_pdev;
+   struct ocmem_buf *ocmem_hdl;
int ret;

if (!pdev) {
@@ -569,18 +565,13 @@ struct msm_gpu *a3xx_gpu_init(struct drm_device *dev)
goto fail;

/* if needed, allocate gmem: */
-   if (adreno_is_a330(adreno_gpu)) {
-#ifdef CONFIG_MSM_OCMEM
-   /* TODO this is different/missing upstream: */
-   struct ocmem_buf *ocmem_hdl =
-   ocmem_allocate(OCMEM_GRAPHICS, 
adreno_gpu->gmem);
-
+   ocmem_hdl = ocmem_allocate(OCMEM_GRAPHICS, adreno_gpu->gmem);
+   if (!IS_ERR(ocmem_hdl)) {
a3xx_gpu->ocmem_hdl = ocmem_hdl;
a3xx_gpu->ocmem_base = ocmem_hdl->addr;
adreno_gpu->gmem = ocmem_hdl->len;
DBG("using %dK of OCMEM at 0x%08x", adreno_gpu->gmem / 1024,
a3xx_gpu->ocmem_base);
-#endif
}

if (!gpu->mmu) {
diff --git a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c 
b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
index a53f1be..17f084d 100644
--- a/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a4xx_gpu.c
@@ -10,10 +10,9 @@
  * GNU General Public License for more details.
  *
  */
+
+#include "ocmem/ocmem.h"
 #include "a4xx_gpu.h"
-#ifdef CONFIG_MSM_OCMEM
-#  include 
-#endif

 #define A4XX_INT0_MASK \
(A4XX_INT0_RBBM_AHB_ERROR |\
@@ -289,10 +288,8 @@ static void a4xx_destroy(struct msm_gpu *gpu)

adreno_gpu_cleanup(adreno_gpu);

-#ifdef CONFIG_MSM_OCMEM
-   if (a4xx_gpu->ocmem_base)
+   if (a4xx_gpu->ocmem_hdl)
ocmem_free(OCMEM_GRAPHICS, a4xx_gpu->ocmem_hdl);
-#endif

kfree(a4xx_gpu);
 }
@@ -538,6 +535,7 @@ struct msm_gpu *a4xx_gpu_init(struct drm_device *dev)
struct msm_gpu *gpu;
struct msm_drm_private *priv = dev->dev_private;
struct platform_device *pdev = priv->gpu_pdev;
+   struct ocmem_buf *ocmem_hdl;
int ret;

if (!pdev) {
@@ -568,18 +566,13 @@ struct msm_gpu *a4xx_gpu_init(struct drm_device *dev)
goto fail;

/* if needed, allocate gmem: */
-   if (adreno_is_a4xx(adreno_gpu)) {
-#ifdef CONFIG_MSM_OCMEM
-   /* TODO this is different/missing upstream: */
-   struct ocmem_buf *ocmem_hdl =
-   ocmem_allocate(OCMEM_GRAPHICS, 
adreno_gpu->gmem);
-
+   ocmem_hdl = ocmem_allocate(OCMEM_GRAPHICS, adreno_gpu->gmem);
+   if (!IS_ERR(ocmem_hdl)) {
a4xx_gpu->ocmem_hdl = ocmem_hdl;
a4xx_gpu->ocmem_base = ocmem_hdl->addr;
adreno_gpu->gmem = ocmem_hdl->len;
DBG("using %dK of OCMEM at 0x%08x", adreno_gpu->gmem / 1024,
   

[PATCH 3/4] drm/msm: update generated headers

[Rob Clark]

Update generated headers to pull in OCMEM register definitions.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/adreno/a2xx.xml.h  |   9 +-
 drivers/gpu/drm/msm/adreno/a3xx.xml.h  |  27 --
 drivers/gpu/drm/msm/adreno/a4xx.xml.h  |  15 ++--
 drivers/gpu/drm/msm/adreno/adreno_common.xml.h |  13 ++-
 drivers/gpu/drm/msm/adreno/adreno_pm4.xml.h|   9 +-
 drivers/gpu/drm/msm/dsi/dsi.xml.h  |   4 +-
 drivers/gpu/drm/msm/dsi/mmss_cc.xml.h  |   4 +-
 drivers/gpu/drm/msm/dsi/sfpb.xml.h |   4 +-
 drivers/gpu/drm/msm/edp/edp.xml.h  |   4 +-
 drivers/gpu/drm/msm/hdmi/hdmi.xml.h|   4 +-
 drivers/gpu/drm/msm/hdmi/qfprom.xml.h  |   4 +-
 drivers/gpu/drm/msm/mdp/mdp4/mdp4.xml.h|   4 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h|  82 +-
 drivers/gpu/drm/msm/mdp/mdp_common.xml.h   |  11 ++-
 drivers/gpu/drm/msm/ocmem/ocmem.xml.h  | 113 +
 15 files changed, 267 insertions(+), 40 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/ocmem/ocmem.xml.h

diff --git a/drivers/gpu/drm/msm/adreno/a2xx.xml.h 
b/drivers/gpu/drm/msm/adreno/a2xx.xml.h
index 0261f0d..9e2aceb 100644
--- a/drivers/gpu/drm/msm/adreno/a2xx.xml.h
+++ b/drivers/gpu/drm/msm/adreno/a2xx.xml.h
@@ -8,13 +8,14 @@ http://github.com/freedreno/envytools/
 git clone https://github.com/freedreno/envytools.git

 The rules-ng-ng source files this header was generated from are:
-- /home/robclark/src/freedreno/envytools/rnndb/adreno.xml   (
364 bytes, from 2015-05-20 20:03:07)
+- /home/robclark/src/freedreno/envytools/rnndb/adreno.xml   (
398 bytes, from 2015-09-24 17:25:31)
 - /home/robclark/src/freedreno/envytools/rnndb/freedreno_copyright.xml  (   
1453 bytes, from 2015-05-20 20:03:07)
 - /home/robclark/src/freedreno/envytools/rnndb/adreno/a2xx.xml  (  
32901 bytes, from 2015-05-20 20:03:14)
-- /home/robclark/src/freedreno/envytools/rnndb/adreno/adreno_common.xml (  
10551 bytes, from 2015-05-20 20:03:14)
+- /home/robclark/src/freedreno/envytools/rnndb/adreno/adreno_common.xml (  
10755 bytes, from 2015-09-14 20:46:55)
 - /home/robclark/src/freedreno/envytools/rnndb/adreno/adreno_pm4.xml(  
14968 bytes, from 2015-05-20 20:12:27)
-- /home/robclark/src/freedreno/envytools/rnndb/adreno/a3xx.xml  (  
67120 bytes, from 2015-08-14 23:22:03)
-- /home/robclark/src/freedreno/envytools/rnndb/adreno/a4xx.xml  (  
63785 bytes, from 2015-08-14 18:27:06)
+- /home/robclark/src/freedreno/envytools/rnndb/adreno/a3xx.xml  (  
67771 bytes, from 2015-09-14 20:46:55)
+- /home/robclark/src/freedreno/envytools/rnndb/adreno/a4xx.xml  (  
63970 bytes, from 2015-09-14 20:50:12)
+- /home/robclark/src/freedreno/envytools/rnndb/adreno/ocmem.xml (   
1773 bytes, from 2015-09-24 17:30:00)

 Copyright (C) 2013-2015 by the following authors:
 - Rob Clark  (robclark)
diff --git a/drivers/gpu/drm/msm/adreno/a3xx.xml.h 
b/drivers/gpu/drm/msm/adreno/a3xx.xml.h
index 48d1337..97dc1c6 100644
--- a/drivers/gpu/drm/msm/adreno/a3xx.xml.h
+++ b/drivers/gpu/drm/msm/adreno/a3xx.xml.h
@@ -8,13 +8,14 @@ http://github.com/freedreno/envytools/
 git clone https://github.com/freedreno/envytools.git

 The rules-ng-ng source files this header was generated from are:
-- /home/robclark/src/freedreno/envytools/rnndb/adreno.xml   (
364 bytes, from 2015-05-20 20:03:07)
+- /home/robclark/src/freedreno/envytools/rnndb/adreno.xml   (
398 bytes, from 2015-09-24 17:25:31)
 - /home/robclark/src/freedreno/envytools/rnndb/freedreno_copyright.xml  (   
1453 bytes, from 2015-05-20 20:03:07)
 - /home/robclark/src/freedreno/envytools/rnndb/adreno/a2xx.xml  (  
32901 bytes, from 2015-05-20 20:03:14)
-- /home/robclark/src/freedreno/envytools/rnndb/adreno/adreno_common.xml (  
10551 bytes, from 2015-05-20 20:03:14)
+- /home/robclark/src/freedreno/envytools/rnndb/adreno/adreno_common.xml (  
10755 bytes, from 2015-09-14 20:46:55)
 - /home/robclark/src/freedreno/envytools/rnndb/adreno/adreno_pm4.xml(  
14968 bytes, from 2015-05-20 20:12:27)
-- /home/robclark/src/freedreno/envytools/rnndb/adreno/a3xx.xml  (  
67120 bytes, from 2015-08-14 23:22:03)
-- /home/robclark/src/freedreno/envytools/rnndb/adreno/a4xx.xml  (  
63785 bytes, from 2015-08-14 18:27:06)
+- /home/robclark/src/freedreno/envytools/rnndb/adreno/a3xx.xml  (  
67771 bytes, from 2015-09-14 20:46:55)
+- /home/robclark/src/freedreno/envytools/rnndb/adreno/a4xx.xml  (  
63970 bytes, from 2015-09-14 20:50:12)
+- /home/robclark/src/freedreno/envytools/rnndb/adreno/ocmem.xml (   
1773 bytes, from 2015-09-24 17:30:00)

 Copyright (C) 2013-2015 by the following authors:
 - Rob Clark  (robclark)
@@ -280,6 +281,8 @@ enum a3xx_rb_blend_opcode {
 enum a3xx_intp_mode {
SMOOTH = 0,
FLAT = 1,
+   ZERO = 2,
+   ONE = 3,
 };

 enum a3xx_repl_mode {
@@ 

[PATCH 2/4] WIP: qcom-scm: add ocmem dump support

[Rob Clark]

Seems so far not to be required, at least for gpu.  Just stuffing it in
a patch since I wrote the code and someone might want to resurrect this
at some later time.

Signed-off-by: Rob Clark 
---
 drivers/firmware/qcom_scm-32.c | 32 +
 drivers/firmware/qcom_scm-64.c | 10 
 drivers/firmware/qcom_scm.c| 54 ++
 drivers/firmware/qcom_scm.h|  4 
 include/linux/qcom_scm.h   |  4 
 5 files changed, 104 insertions(+)

diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
index 656d8fe..287041a 100644
--- a/drivers/firmware/qcom_scm-32.c
+++ b/drivers/firmware/qcom_scm-32.c
@@ -557,6 +557,38 @@ int __qcom_scm_ocmem_unlock(uint32_t id, uint32_t offset, 
uint32_t size)
, sizeof(request), NULL, 0);
 }

+int __qcom_scm_ocmem_enable_dump(uint32_t id, uint32_t offset, uint32_t size)
+{
+   struct ocmem_tz_en_dump {
+   u32 id;
+   u32 offset;
+   u32 size;
+   } request;
+
+   request.id = id;
+   request.offset = offset;
+   request.size = size;
+
+   return qcom_scm_call(QCOM_SCM_OCMEM_SVC, QCOM_SCM_OCMEM_ENABLE_DUMP_CMD,
+   , sizeof(request), NULL, 0);
+}
+
+int __qcom_scm_ocmem_disable_dump(uint32_t id, uint32_t offset, uint32_t size)
+{
+   struct ocmem_tz_dis_dump {
+   u32 id;
+   u32 offset;
+   u32 size;
+   } request;
+
+   request.id = id;
+   request.offset = offset;
+   request.size = size;
+
+   return qcom_scm_call(QCOM_SCM_OCMEM_SVC, 
QCOM_SCM_OCMEM_DISABLE_DUMP_CMD,
+   , sizeof(request), NULL, 0);
+}
+
 bool __qcom_scm_pas_supported(u32 peripheral)
 {
__le32 out;
diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c
index ef5c59e..fc02828 100644
--- a/drivers/firmware/qcom_scm-64.c
+++ b/drivers/firmware/qcom_scm-64.c
@@ -78,6 +78,16 @@ int __qcom_scm_ocmem_unlock(uint32_t id, uint32_t offset, 
uint32_t size)
return -ENOTSUPP;
 }

+int __qcom_scm_ocmem_enable_dump(uint32_t id, uint32_t offset, uint32_t size)
+{
+   return -ENOTSUPP;
+}
+
+int __qcom_scm_ocmem_disable_dump(uint32_t id, uint32_t offset, uint32_t size)
+{
+   return -ENOTSUPP;
+}
+
 bool __qcom_scm_pas_supported(u32 peripheral)
 {
return false;
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 59b1007..b15b0d8 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -260,6 +260,60 @@ int qcom_scm_ocmem_unlock(uint32_t id, uint32_t offset, 
uint32_t size)
 EXPORT_SYMBOL(qcom_scm_ocmem_unlock);

 /**
+ *
+ */
+bool qcom_scm_ocmem_dump_available(void)
+{
+   int ret = qcom_scm_clk_enable();
+
+   if (ret)
+   goto clk_err;
+
+   ret = __qcom_scm_is_call_available(QCOM_SCM_OCMEM_SVC,
+   QCOM_SCM_OCMEM_ENABLE_DUMP_CMD);
+
+   qcom_scm_clk_disable();
+
+clk_err:
+   return (ret > 0) ? true : false;
+}
+EXPORT_SYMBOL(qcom_scm_ocmem_dump_available);
+
+/**
+ *
+ */
+int qcom_scm_ocmem_enable_dump(uint32_t id, uint32_t offset, uint32_t size)
+{
+   int ret = qcom_scm_clk_enable();
+
+   if (ret)
+   return ret;
+
+   ret = __qcom_scm_ocmem_enable_dump(id, offset, size);
+   qcom_scm_clk_disable();
+
+   return ret;
+}
+EXPORT_SYMBOL(qcom_scm_ocmem_enable_dump);
+
+/**
+ *
+ */
+int qcom_scm_ocmem_disable_dump(uint32_t id, uint32_t offset, uint32_t size)
+{
+   int ret = qcom_scm_clk_enable();
+
+   if (ret)
+   return ret;
+
+   ret = __qcom_scm_ocmem_disable_dump(id, offset, size);
+   qcom_scm_clk_disable();
+
+   return ret;
+}
+EXPORT_SYMBOL(qcom_scm_ocmem_disable_dump);
+
+/**
  * qcom_scm_pas_supported() - Check if the peripheral authentication service is
  *   available for the given peripherial
  * @peripheral:peripheral id
diff --git a/drivers/firmware/qcom_scm.h b/drivers/firmware/qcom_scm.h
index e01656f3..a090236 100644
--- a/drivers/firmware/qcom_scm.h
+++ b/drivers/firmware/qcom_scm.h
@@ -44,10 +44,14 @@ extern int __qcom_scm_ocmem_secure_cfg(unsigned sec_id);
 #define QCOM_SCM_OCMEM_SVC 0xf
 #define QCOM_SCM_OCMEM_LOCK_CMD0x1
 #define QCOM_SCM_OCMEM_UNLOCK_CMD  0x2
+#define QCOM_SCM_OCMEM_ENABLE_DUMP_CMD 0x3
+#define QCOM_SCM_OCMEM_DISABLE_DUMP_CMD0x4

 extern int __qcom_scm_ocmem_lock(uint32_t id, uint32_t offset, uint32_t size,
uint32_t mode);
 extern int __qcom_scm_ocmem_unlock(uint32_t id, uint32_t offset, uint32_t 
size);
+extern int __qcom_scm_ocmem_enable_dump(uint32_t id, uint32_t offset, uint32_t 
size);
+extern int __qcom_scm_ocmem_disable_dump(uint32_t id, uint32_t offset, 
uint32_t size);

 #define QCOM_SCM_SVC_PIL   0x2
 #define QCOM_SCM_PAS_INIT_IMAGE_CMD0x1
diff --git 

[PATCH 1/4] qcom-scm: add ocmem support

[Rob Clark]

Add interfaces needed for configuring OCMEM.

Signed-off-by: Rob Clark 
---
 drivers/firmware/qcom_scm-32.c |  57 ++
 drivers/firmware/qcom_scm-64.c |  16 +++
 drivers/firmware/qcom_scm.c| 106 +
 drivers/firmware/qcom_scm.h|  13 +
 include/linux/qcom_scm.h   |  10 
 5 files changed, 202 insertions(+)

diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
index e9c306b..656d8fe 100644
--- a/drivers/firmware/qcom_scm-32.c
+++ b/drivers/firmware/qcom_scm-32.c
@@ -500,6 +500,63 @@ int __qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req, u32 
req_cnt, u32 *resp)
req, req_cnt * sizeof(*req), resp, sizeof(*resp));
 }

+int __qcom_scm_ocmem_secure_cfg(unsigned sec_id)
+{
+   int ret, scm_ret = 0;
+   struct msm_scm_sec_cfg {
+   unsigned int id;
+   unsigned int spare;
+   } cfg;
+
+   cfg.id = sec_id;
+
+
+   ret = qcom_scm_call(QCOM_SCM_OCMEM_SECURE_SVC, 
QCOM_SCM_OCMEM_SECURE_CFG,
+   , sizeof(cfg), _ret, sizeof(scm_ret));
+
+   if (ret || scm_ret) {
+   pr_err("ocmem: Failed to enable secure programming\n");
+   return ret ? ret : -EINVAL;
+   }
+
+   return 0;
+}
+
+int __qcom_scm_ocmem_lock(uint32_t id, uint32_t offset, uint32_t size,
+   uint32_t mode)
+{
+   struct ocmem_tz_lock {
+   u32 id;
+   u32 offset;
+   u32 size;
+   u32 mode;
+   } request;
+
+   request.id = id;
+   request.offset = offset;
+   request.size = size;
+   request.mode = mode;
+
+   return qcom_scm_call(QCOM_SCM_OCMEM_SVC, QCOM_SCM_OCMEM_LOCK_CMD,
+   , sizeof(request), NULL, 0);
+}
+
+int __qcom_scm_ocmem_unlock(uint32_t id, uint32_t offset, uint32_t size)
+{
+   struct ocmem_tz_unlock {
+   u32 id;
+   u32 offset;
+   u32 size;
+   } request;
+
+   request.id = id;
+   request.offset = offset;
+   request.size = size;
+
+   return qcom_scm_call(QCOM_SCM_OCMEM_SVC, QCOM_SCM_OCMEM_UNLOCK_CMD,
+   , sizeof(request), NULL, 0);
+}
+
 bool __qcom_scm_pas_supported(u32 peripheral)
 {
__le32 out;
diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c
index e64fd92..ef5c59e 100644
--- a/drivers/firmware/qcom_scm-64.c
+++ b/drivers/firmware/qcom_scm-64.c
@@ -62,6 +62,22 @@ int __qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req, u32 
req_cnt, u32 *resp)
return -ENOTSUPP;
 }

+int __qcom_scm_ocmem_secure_cfg(unsigned sec_id)
+{
+   return -ENOTSUPP;
+}
+
+int __qcom_scm_ocmem_lock(uint32_t id, uint32_t offset, uint32_t size,
+   uint32_t mode)
+{
+   return -ENOTSUPP;
+}
+
+int __qcom_scm_ocmem_unlock(uint32_t id, uint32_t offset, uint32_t size)
+{
+   return -ENOTSUPP;
+}
+
 bool __qcom_scm_pas_supported(u32 peripheral)
 {
return false;
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 118df0a..59b1007 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -154,6 +154,112 @@ int qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req, u32 
req_cnt, u32 *resp)
 EXPORT_SYMBOL(qcom_scm_hdcp_req);

 /**
+ * qcom_scm_ocmem_secure_available() - Check if secure environment supports
+ * OCMEM.
+ *
+ * Return true if OCMEM secure interface is supported, false if not.
+ */
+bool qcom_scm_ocmem_secure_available(void)
+{
+   int ret = qcom_scm_clk_enable();
+
+   if (ret)
+   goto clk_err;
+
+   ret = __qcom_scm_is_call_available(QCOM_SCM_OCMEM_SECURE_SVC,
+   QCOM_SCM_OCMEM_SECURE_CFG);
+
+   qcom_scm_clk_disable();
+
+clk_err:
+   return (ret > 0) ? true : false;
+}
+EXPORT_SYMBOL(qcom_scm_ocmem_secure_available);
+
+/**
+ * qcom_scm_ocmem_secure_cfg() - call OCMEM secure cfg interface
+ */
+int qcom_scm_ocmem_secure_cfg(unsigned sec_id)
+{
+   int ret = qcom_scm_clk_enable();
+
+   if (ret)
+   return ret;
+
+   ret = __qcom_scm_ocmem_secure_cfg(sec_id);
+   qcom_scm_clk_disable();
+
+   return ret;
+}
+EXPORT_SYMBOL(qcom_scm_ocmem_secure_cfg);
+
+/**
+ * qcom_scm_ocmem_lock_available() - is OCMEM lock/unlock interface available
+ */
+bool qcom_scm_ocmem_lock_available(void)
+{
+   int ret = qcom_scm_clk_enable();
+
+   if (ret)
+   goto clk_err;
+
+   ret = __qcom_scm_is_call_available(QCOM_SCM_OCMEM_SVC,
+   QCOM_SCM_OCMEM_LOCK_CMD);
+
+   qcom_scm_clk_disable();
+
+clk_err:
+   return (ret > 0) ? true : false;
+}
+EXPORT_SYMBOL(qcom_scm_ocmem_lock_available);
+
+/**
+ * qcom_scm_ocmem_lock() - call OCMEM lock interface to assign an OCMEM
+ * region to the specified initiator
+ *
+ * @id: tz initiator id
+ * @offset: OCMEM offset
+ * @size:   OCMEM size
+ * @mode:   access mode (WIDE/NARROW)
+ */

[PATCH 0/4] Add OCMEM support

[Rob Clark]

For devices such as 8x74 and 8084, which have a separate OCMEM block
used by the GPU (and some other devices), rather than an internal GMEM
block inside the GPU, we need a driver to power up and configure OCMEM
in order to get the GPU working.

This patchset implements a vastly simplified version of the downstream
vendor kernel's OCMEM driver.  Currently it is just enough to enable
the GPU.  But we can worry about other OCMEM users when they have up-
stream drivers.

The first patch adds support for the necessary scm interfaces, for the
parts of the OCMEM configuration that must be done from secure mode.
The second patch can be dropped, as so far this doesn't seem needed for
the GPU (I'm just sending the patch now so it can be found later if it
turns out to be needed).

The remaining two patches add the OCMEM driver inside drm/msm.  If we
eventually have other upstream OCMEM users, this would need to be split
out.  But that should not effect DT bindings, etc, so that is something
that can easily be done later when the need arises.

Rob Clark (4):
  qcom-scm: add ocmem support
  WIP: qcom-scm: add ocmem dump support
  drm/msm: update generated headers
  drm/msm: add OCMEM driver

 drivers/firmware/qcom_scm-32.c |  89 ++
 drivers/firmware/qcom_scm-64.c |  26 ++
 drivers/firmware/qcom_scm.c| 160 ++
 drivers/firmware/qcom_scm.h|  17 ++
 drivers/gpu/drm/msm/Makefile   |   3 +-
 drivers/gpu/drm/msm/adreno/a2xx.xml.h  |   9 +-
 drivers/gpu/drm/msm/adreno/a3xx.xml.h  |  27 +-
 drivers/gpu/drm/msm/adreno/a3xx_gpu.c  |  17 +-
 drivers/gpu/drm/msm/adreno/a4xx.xml.h  |  15 +-
 drivers/gpu/drm/msm/adreno/a4xx_gpu.c  |  19 +-
 drivers/gpu/drm/msm/adreno/adreno_common.xml.h |  13 +-
 drivers/gpu/drm/msm/adreno/adreno_pm4.xml.h|   9 +-
 drivers/gpu/drm/msm/dsi/dsi.xml.h  |   4 +-
 drivers/gpu/drm/msm/dsi/mmss_cc.xml.h  |   4 +-
 drivers/gpu/drm/msm/dsi/sfpb.xml.h |   4 +-
 drivers/gpu/drm/msm/edp/edp.xml.h  |   4 +-
 drivers/gpu/drm/msm/hdmi/hdmi.xml.h|   4 +-
 drivers/gpu/drm/msm/hdmi/qfprom.xml.h  |   4 +-
 drivers/gpu/drm/msm/mdp/mdp4/mdp4.xml.h|   4 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5.xml.h|  82 -
 drivers/gpu/drm/msm/mdp/mdp_common.xml.h   |  11 +-
 drivers/gpu/drm/msm/msm_drv.c  |   2 +
 drivers/gpu/drm/msm/msm_gpu.h  |   3 +
 drivers/gpu/drm/msm/ocmem/ocmem.c  | 396 +
 drivers/gpu/drm/msm/ocmem/ocmem.h  |  46 +++
 drivers/gpu/drm/msm/ocmem/ocmem.xml.h  | 113 +++
 include/linux/qcom_scm.h   |  14 +
 27 files changed, 1032 insertions(+), 67 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/ocmem/ocmem.c
 create mode 100644 drivers/gpu/drm/msm/ocmem/ocmem.h
 create mode 100644 drivers/gpu/drm/msm/ocmem/ocmem.xml.h

-- 
2.4.3

[RFC] Docs: drm: Move KMS properties table out to source files

[Daniel Vetter]

On Mon, Sep 28, 2015 at 10:36:59AM +0100, Graham Whaley wrote:
> On Tue, 2015-09-22 at 16:03 -0300, Danilo Cesar Lemes de Paula wrote:
> > On 09/22/2015 07:22 AM, Graham Whaley wrote:
> > > On Wed, Sep 02, 2015 at 02:50:52PM +0100, Graham Whaley wrote:
> > > > > (RFC/test - not for merging)
> > > > > The below is a test of moving the large HTML KMS properties
> > > > > table
> > > > > out
> > > > > to markdown style in the appropriate files.
> > > > > In the test we only use the first few rows of the existing KMS
> > > > > table
> > > > > an example.
> > > > > We use a fixed width table as the other styles of table
> > > > > supported
> > > > > by
> > > > > pandoc markdown do not support multi-column cells.
> > > > > 
> > > > > The test shows a couple of issues:
> > > > >  1) double quote characters are being expanded in the fixed
> > > > > width
> > > > > table
> > > > >  which then breaks the table alignment and leaves html style
> > > > >  tags
> > > > >  in the text
> > > 
> > > Further to this item:
> > >  Before I continue working on splitting the tables and converting
> > > to
> > > markdown (which btw Daniel does look feasible so far...), I thought
> > > we
> > > should understand what was going on with the markdown table quote
> > > breakage.
> > >  I think I know what is happenig.
> > >  The problem revolves around highlight expansion in the kenrel-doc
> > > script. In the output_highlight function we can see that first the
> > > script does highlight expansion (with the eval of @dohighlight),
> > > and
> > > then it invokes the markdown processing.
> > >  Done that way around what happens is:
> > >  - @dohighlight expands any "X" to html/xml quote tag sequences
> > >  - which can push the text beyond the table column widths,
> > >  - and then the markdown tries to split the text over columns, and
> > > manages to put the break in the middle of a tag, and thus breaks
> > > the
> > > tag formatting (see below)
> > > 
> > > At least that is what I think is happening.
> > > I had thought maybe we could swap the markdown and highlight
> > > processing
> > > order, but then that presents a different issue - the markdown
> > > table
> > > contains metadata with quoted items (such as cols="5"), which the
> > > highligh processing then expands into tags, and hence breaks the
> > > table
> > > format metadata.
> > > 
> > > As an example, using the following table !Pinclude'd into drm.tmpl:
> > > /**
> > >  * DOC: DRM generic
> > >  *
> > >  * : DRM generic properties
> > >  *
> > >  * +--+++-+
> > > 
> > > +
> > >  * |Property  |Type|Property Values |Object  
> > >  |Description/Restrictions|
> > >  *
> > > +==+++=+===
> > > 
> > > =+
> > >  * |"rotation"|BITMASK |{ 0, "rotate-0" }, {|CRTC,|rotate
> > > -(degrees)
> > > rotates|
> > >  * +--+++-+
> > > 
> > > +
> > >  *
> > >  */
> > > 
> > > The post-highlight pre-markdown text captured as the $orig_context
> > > in
> > > the markdown_to_docbook function is:
> > > 
> > > +--+++-+---
> > > 
> > > -+
> > > > Property  |Type|Property Values |Object  
> > >  |Description/Restrictions|
> > > +==+++=+===
> > > 
> > > =+
> > > > rotation|BITMASK |{ 0, rotate-0 },
> > > {|CRTC,|rotate-(degrees) rotates|
> > > +--+++-+---
> > > 
> > > -+
> > > 
> > > which when processed (and you can do this by hand with 'pandoc -
> > > -columns=80 -f markdown -t docbook ...' generates the broken tags
> > > example:
> > > 
> > > ...
> > > 
> > >  
> > >
> > >  
> > >rota
> > >  
> > >
> > >
> > >  
> > >tion/quo
> > >  
> > >
> > >
> > >  
> > >te|BITMASK |{ 0, qu
> > >  
> > >
> > >
> > >  
> > >oterotate
> > >  
> > >
> > >
> > >  
> > >-0 }, {|CRTC, |rotate-(degrees) rotates
> > >  
> > > ...
> > > 
> > > where you can see the quote tag processing has gone horribly wrong.
> > > 
> > > I believe we'll have the same problem for the other 'highlight'
> > > processed items from kern-doc as well, meaning:
> > >  funcname()
> > >  $ENVVAR
> > >  _name
> > >  @parameter
> > >  %CONST
> > >  
> > > As the kern-doc processing has no knowledge of when it is about to
> > > process a markdown table I can't think of an obvious way around
> > > this.
> > > At present I think the implicit rule is 'no highlight/expansion
> > > items
> > > allowed in markdown tables', which 

[Intel-gfx] [PATCH 10/23] drm/i915: Add gamma correction handlers

[Matt Roper]

Yep, Daniel's right; for properties that are not specific to the driver,
the core core should take care of stuffing the values provided by
userspace into the state structures so that every driver that wants to
use these doesn't need to replicate that logic.  My bad for not catching
this in my earlier reviews; sorry about that.  Basically the change
required is to add another else clause to
drm_atomic_crtc_{get,set}_property(), before the core tries to call into
the driver-specific handler.  You'll notice that what you're doing with
color management blobs here is actually very similar to what's already
done for the existing mode blob, so you can take a look at that case for
an example.

Also, the functions like intel_color_manager_set_pipe_gamma() will get
moved into the DRM core and the "intel_" prefix will switch to "drm_"
since there's really nothing Intel-specific about what they're doing.

Sorry again for not noticing this and bringing it up on the earlier
reviews.  Fortunately the changes required should be pretty small.


Matt

On Mon, Sep 28, 2015 at 01:19:13AM -0700, Sharma, Shashank wrote:
> Matt, your opinion about this ? 
> 
> Regards
> Shashank
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel 
> Vetter
> Sent: Monday, September 28, 2015 12:14 PM
> To: Sharma, Shashank
> Cc: Daniel Vetter; Roper, Matthew D; Bish, Jim; Bradford, Robert; Smith, Gary 
> K; dri-devel at lists.freedesktop.org; intel-gfx at lists.freedesktop.org; 
> Matheson, Annie J; kausalmalladi at gmail.com; Vetter, Daniel
> Subject: Re: [Intel-gfx] [PATCH 10/23] drm/i915: Add gamma correction handlers
> 
> On Sat, Sep 26, 2015 at 09:18:48PM +0530, Sharma, Shashank wrote:
> > On 9/23/2015 1:52 PM, Sharma, Shashank wrote:
> > >>Since color manager properties are meant as a new standardize KMS 
> > >>extension (we put them into the core drm_crtc_state) the get/set 
> > >>support should also be in the core. See e.g. how the rotation 
> > >>property is handled in drm_atomic_plane_get/set_property. So all 
> > >>this code should be added to drm_atomic_crtc_get/set_property.
> > >Thanks, sounds like a good one. Will move this.
> > Actually, while implementing this, I realized that this change is not 
> > required.
> > What we want to do in drm_atomic_crtc_get/set code is:
> > if (prop == config->cm_palette_after_ctm_property || prop ==
> > config->cm_palette_before_ctm_property) {
> > crtc->funcs->atomic_get_property();
> > }
> > 
> > Which is already being done in the current code:
> > else if (crtc->funcs->atomic_get_property)
> > return crtc->funcs->atomic_get_property(crtc, state, property, val);
> 
> This code is to pass any property unknown to the drm core into the driver.
> But since we want this to be a new drm core property set (that's why it's in 
> drm_crtc_state) the decoding should be done in the core too.
> 
> Note that atomic_get/set_property _only_ map between the property as seen by 
> userspace and the state structures. They're not allowed to do anything else 
> like compute derived state, check constraints or put the state into the hw. 
> That's for the atomic_check and atomic_commit callbacks. So for this patchset 
> here you should move all the code in the atomic_get/set_property callbacks 
> you add in i915 into the drm core. Like it is doen for the rotation property.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795

No more new fbdev drivers, please

[Daniel Vetter]

On Mon, Sep 28, 2015 at 09:39:13AM +0200, Gerd Hoffmann wrote:
>   Hi,
> 
> > As Daniel mentioned, the connector+encoder+crtc combination is one of
> > those simplifications that would make sense if more such drivers are
> > added.
> 
> Another one is memory management.  It's pretty complex because it can
> handle _way_ more than what simple drivers need, and the result is
> _alot_ of ttm boilerplate in the drivers.

ttm is pretty impressive overkill for most simplistic drm drivers. If you
just need contiguous framebuffers for display then the cma helpers should
take care of pretty much all the boilerplate for you. They have ready-made
simple gem and dumb framebuffer mmap support, which is all a basic kms
driver needs.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH RFC v4 3/8] ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders

[Daniel Vetter]

On Mon, Sep 28, 2015 at 12:26:28PM +0100, Russell King - ARM Linux wrote:
> On Mon, Sep 28, 2015 at 11:01:34AM +0200, Arnaud Pouliquen wrote:
> > few questions/remarks
> > BR,
> > Arnaud
> > 
> > >+static void hdmi_codec_abort(struct device *dev)
> > >+{
> > >+struct hdmi_codec_priv *hcp = dev_get_drvdata(dev);
> > >+
> > >+dev_dbg(dev, "%s()\n", __func__);
> > >+
> > >+mutex_lock(>current_stream_lock);
> > >+if (hcp->current_stream && hcp->current_stream->runtime &&
> > >+snd_pcm_running(hcp->current_stream)) {
> > >+dev_info(dev, "HDMI audio playback aborted\n");
> > >+snd_pcm_stream_lock_irq(hcp->current_stream);
> > >+snd_pcm_stop(hcp->current_stream, SNDRV_PCM_STATE_DISCONNECTED);
> > >+snd_pcm_stream_unlock_irq(hcp->current_stream);
> > >+}
> > >+mutex_unlock(>current_stream_lock);
> > >+}
> > Does driver should stop the stream in case of unplug?
> > This could generate unexpected behavior at application level.
> > Perhaps should be better if this part is managed in DRM driver. if HDMI
> > master, I2S bus should be maintained ON to consume the audio stream until
> > application action.
> 
> If it does, that's really horrid.

Atm the rule for display outputs is that nothing gets yanked until
userspace approves, since otherwise compositors get stuck (or fall over
with an unexpected -EINVAL from the kernel). The exception is DP MST
because the current implementation is a complete hack for DP MST sink
lifetimes and that's why we need to synchronously nuke them (which means
shutting down everything). I'm surprised not a hole lot more people
complain about this ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

No more new fbdev drivers, please

[Bernie Thompson]

On Sat, Sep 26, 2015 at 11:01 AM, Geert Uytterhoeven 
 wrote:
> The smallest of these (udl) still counts in at ca. 2800 LoC,

Note udlfb.c, the original fbdev driver that I helped write and that the
udl DRM driver was based on, is ~1800 LoC ... so we're actually talking in
the ballpark of 2x (rather than 10x) between fbdev and DRM in this case.
That said, the complexity difference is probably higher than the LoC
difference. I know I personally have struggled in the shift from
understanding fbdev to understanding DRM.

The fact that there's drivers of both types and USB hardware might make udl
may be a good driver to use as a base for any additional simplification /
helper work. David Airlie and David Herrmann both have this hardware. David
Airlie did the port from fbdev to DRM, so he's made it an exemplary
driver.  And if anyone needs any hardware which works with udlfb and udl,
we're happy to send free hardware to any programmers who are willing to
contribute in the form of code or testing:
http://plugable.com/projects/plugable-open-source-hardware-samples-program

More simplification and documentation would be great. In particular, the
optimization for the connector+encoder+crtc combination others have
mentioned seems like it would be worthwhile.

Cheers,
Bernie

>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150928/f43262cf/attachment.html>

[PATCH 1/4] qcom-scm: add ocmem support

[Stephen Boyd]

On 09/28, Rob Clark wrote:
> Add interfaces needed for configuring OCMEM.
> 
> Signed-off-by: Rob Clark 
> ---
>  drivers/firmware/qcom_scm-32.c |  57 ++
>  drivers/firmware/qcom_scm-64.c |  16 +++
>  drivers/firmware/qcom_scm.c| 106 
> +
>  drivers/firmware/qcom_scm.h|  13 +
>  include/linux/qcom_scm.h   |  10 
>  5 files changed, 202 insertions(+)
> 
> diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
> index e9c306b..656d8fe 100644
> --- a/drivers/firmware/qcom_scm-32.c
> +++ b/drivers/firmware/qcom_scm-32.c
> @@ -500,6 +500,63 @@ int __qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req, 
> u32 req_cnt, u32 *resp)
>   req, req_cnt * sizeof(*req), resp, sizeof(*resp));
>  }
>  
> +int __qcom_scm_ocmem_secure_cfg(unsigned sec_id)
> +{
> + int ret, scm_ret = 0;
> + struct msm_scm_sec_cfg {
> + unsigned int id;
> + unsigned int spare;


__le32 for both

> + } cfg;
> +
> + cfg.id = sec_id;
> +
> +

nitpick: drop double space

> + ret = qcom_scm_call(QCOM_SCM_OCMEM_SECURE_SVC, 
> QCOM_SCM_OCMEM_SECURE_CFG,
> + , sizeof(cfg), _ret, sizeof(scm_ret));
> +
> + if (ret || scm_ret) {
> + pr_err("ocmem: Failed to enable secure programming\n");

Maybe the caller should print something if they care instead of
burying it down here.

> + return ret ? ret : -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +int __qcom_scm_ocmem_lock(uint32_t id, uint32_t offset, uint32_t size,
> + uint32_t mode)

Please use u32 here instead of uint32_t. uint32_t is not for
kernel code.

> +{
> + struct ocmem_tz_lock {
> + u32 id;
> + u32 offset;
> + u32 size;
> + u32 mode;

All __le32

> + } request;
> +
> + request.id = id;
> + request.offset = offset;
> + request.size = size;
> + request.mode = mode;

And then do the cpu_to_le32() stuff here.

> +
> + return qcom_scm_call(QCOM_SCM_OCMEM_SVC, QCOM_SCM_OCMEM_LOCK_CMD,
> + , sizeof(request), NULL, 0);
> +}
> +
> +int __qcom_scm_ocmem_unlock(uint32_t id, uint32_t offset, uint32_t size)

u32

> +{
> + struct ocmem_tz_unlock {
> + u32 id;
> + u32 offset;
> + u32 size;

__le32

> + } request;
> +
> + request.id = id;
> + request.offset = offset;
> + request.size = size;
> +
> + return qcom_scm_call(QCOM_SCM_OCMEM_SVC, QCOM_SCM_OCMEM_UNLOCK_CMD,
> + , sizeof(request), NULL, 0);
> +}
> +
>  bool __qcom_scm_pas_supported(u32 peripheral)
>  {
>   __le32 out;
> diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
> index 118df0a..59b1007 100644
> --- a/drivers/firmware/qcom_scm.c
> +++ b/drivers/firmware/qcom_scm.c
> @@ -154,6 +154,112 @@ int qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req, 
> u32 req_cnt, u32 *resp)
>  EXPORT_SYMBOL(qcom_scm_hdcp_req);
>  
>  /**
> + * qcom_scm_ocmem_secure_available() - Check if secure environment supports
> + * OCMEM.
> + *
> + * Return true if OCMEM secure interface is supported, false if not.
> + */
> +bool qcom_scm_ocmem_secure_available(void)
> +{
> + int ret = qcom_scm_clk_enable();

I doubt we need to enable clocks to figure out if a call is
available. Please drop clk stuff here.

> +
> + if (ret)
> + goto clk_err;
> +
> + ret = __qcom_scm_is_call_available(QCOM_SCM_OCMEM_SECURE_SVC,
> + QCOM_SCM_OCMEM_SECURE_CFG);
> +
> + qcom_scm_clk_disable();
> +
> +clk_err:
> + return (ret > 0) ? true : false;
> +}
> +EXPORT_SYMBOL(qcom_scm_ocmem_secure_available);
> +
> +/**
> + * qcom_scm_ocmem_secure_cfg() - call OCMEM secure cfg interface
> + */
> +int qcom_scm_ocmem_secure_cfg(unsigned sec_id)
> +{
> + int ret = qcom_scm_clk_enable();
> +
> + if (ret)
> + return ret;
> +
> + ret = __qcom_scm_ocmem_secure_cfg(sec_id);
> + qcom_scm_clk_disable();
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(qcom_scm_ocmem_secure_cfg);
> +
> +/**
> + * qcom_scm_ocmem_lock_available() - is OCMEM lock/unlock interface available
> + */
> +bool qcom_scm_ocmem_lock_available(void)
> +{
> + int ret = qcom_scm_clk_enable();

No need for clocks?

> +
> + if (ret)
> + goto clk_err;
> +
> + ret = __qcom_scm_is_call_available(QCOM_SCM_OCMEM_SVC,
> + QCOM_SCM_OCMEM_LOCK_CMD);
> +
> + qcom_scm_clk_disable();
> +
> +clk_err:
> + return (ret > 0) ? true : false;
> +}
> +EXPORT_SYMBOL(qcom_scm_ocmem_lock_available);
> +
> +/**
> + * qcom_scm_ocmem_lock() - call OCMEM lock interface to assign an OCMEM
> + * region to the specified initiator
> + *
> + * @id: tz initiator id
> + * @offset: OCMEM offset
> + * @size:   OCMEM size
> + * @mode:   access mode (WIDE/NARROW)
> + */
> +int qcom_scm_ocmem_lock(uint32_t id, uint32_t offset, uint32_t size,
> + 

[Bug 105111] amdgpu 0000:00:01.0: Invalid ROM contents (with A8-7600)

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

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

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #1 from Alex Deucher  ---
Is this a regression?  If so, can you bisect?

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

[PATCH] drm: fix missing modeset lock from sysfs path

[Jens Axboe]

Hi,

Running 4.3-rc on a new laptop, and I notice that I get these whenever
powertop --auto-tune is run:

[14954.927920] [ cut here ]
[14954.927926] WARNING: CPU: 1 PID: 14297 at drivers/gpu/drm/drm_atomic.c:889 
drm_atomic_get_property+0x232/0x2b0()
[14954.927927] Modules linked in: msr drbg ctr ccm cmac uvcvideo hid_generic 
videobuf2_vmalloc videobuf2_memops videobuf2_core v4l2_common videodev usbhid 
btusb btintel arc4 iwlmvm mac80211 joydev snd_hda_codec_realtek 
snd_hda_codec_generic x86_pkg_temp_thermal snd_hda_codec_hdmi intel_powerclamp 
kvm_intel dell_laptop dell_wmi dcdbas snd_hda_intel hid_multitouch kvm 
sparse_keymap iwlwifi snd_hda_codec snd_hwdep snd_hda_core aesni_intel 
aes_x86_64 glue_helper ehci_pci lrw gf128mul xhci_pci ablk_helper cfg80211 
cryptd xhci_hcd ehci_hcd snd_pcm int3403_thermal snd_seq_midi bnep 
snd_seq_midi_event rfcomm snd_rawmidi bluetooth snd_seq snd_timer 
snd_seq_device processor_thermal_device snd intel_soc_dts_iosf iosf_mbi i2c_hid 
hid i2c_designware_platform i2c_designware_core int3402_thermal int3400_thermal 
int340x_thermal_zone acpi_thermal_rel soundcore binfmt_misc nls_iso8859_1 
nls_cp437 fuse vfat fat
[14954.927963] CPU: 1 PID: 14297 Comm: powertop Tainted: G U  W   
4.3.0-rc3+ #177
[14954.927964] Hardware name: Dell Inc. XPS 13 9343/0310JH, BIOS A05 07/14/2015
[14954.927965]  81a7c2db 8800032e3c88 812923a9 

[14954.927967]  8800032e3cc0 81050aa6 880215577028 
88021551df80
[14954.927968]  880215577000 880133e2ea80 88020ea59000 
8800032e3cd0
[14954.927970] Call Trace:
[14954.927974]  [] dump_stack+0x4b/0x72
[14954.927976]  [] warn_slowpath_common+0x86/0xc0
[14954.927978]  [] warn_slowpath_null+0x1a/0x20
[14954.927980]  [] drm_atomic_get_property+0x232/0x2b0
[14954.927982]  [] drm_object_property_get_value+0x6c/0x70
[14954.927984]  [] dpms_show+0x2f/0x70
[14954.927987]  [] dev_attr_show+0x20/0x50
[14954.927989]  [] sysfs_kf_seq_show+0xa3/0x140
[14954.927990]  [] kernfs_seq_show+0x20/0x30
[14954.927993]  [] seq_read+0xcd/0x370
[14954.927994]  [] kernfs_fop_read+0x107/0x160
[14954.927996]  [] __vfs_read+0x28/0xd0
[14954.927999]  [] ? security_file_permission+0xa3/0xc0
[14954.928001]  [] ? rw_verify_area+0x53/0xf0
[14954.928002]  [] vfs_read+0x86/0x130
[14954.928004]  [] SyS_read+0x46/0xa0
[14954.928007]  [] entry_SYSCALL_64_fastpath+0x12/0x6a
[14954.928008] ---[ end trace b1d297c2aeff3470 ]---

Looks like we're missing a modeset lock/unlock around the property
retrieval from the sysfs path. Below patch works for me.

Signed-off-by: Jens Axboe 

diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 0f6cd33b531f..2b62166f6b2a 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -239,9 +239,12 @@ static ssize_t dpms_show(struct device *device,
uint64_t dpms_status;
int ret;

+   drm_modeset_lock(>mode_config.connection_mutex, NULL);
ret = drm_object_property_get_value(>base,
dev->mode_config.dpms_property,
_status);
+   drm_modeset_unlock(>mode_config.connection_mutex);
+
if (ret)
return 0;


-- 
Jens Axboe

[patch] drm/mgag200: set an error code

[Dan Carpenter]

We need to set "ret" if vmalloc() fails.

Fixes: aec9e12953e7 ('drm/mgag200: Fix error handling paths in fbdev driver')
Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/mgag200/mgag200_fb.c 
b/drivers/gpu/drm/mgag200/mgag200_fb.c
index b35b5b2..2a1049e 100644
--- a/drivers/gpu/drm/mgag200/mgag200_fb.c
+++ b/drivers/gpu/drm/mgag200/mgag200_fb.c
@@ -185,8 +185,10 @@ static int mgag200fb_create(struct drm_fb_helper *helper,
}

sysram = vmalloc(size);
-   if (!sysram)
+   if (!sysram) {
+   ret = -ENOMEM;
goto err_sysram;
+   }

info = drm_fb_helper_alloc_fbi(helper);
if (IS_ERR(info)) {

[PATCH 00/48] Etnaviv changes RFCv1->RFCv2

[Lucas Stach]

Hi Christian,

Am Montag, den 28.09.2015, 11:46 +0200 schrieb Christian Gmeiner:
> Hi Lucas.
> 
> I think I have run into a cache flush / cache coherency issue. I will
> try to reproduce this issue with a small example and will
> keep you updated.

What are the symptoms of the issue you are hitting? Maybe I can
reproduce or see if I have an idea right away.

Regards,
Lucas
-- 
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

[PATCH RFC v4 3/8] ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders

[Russell King - ARM Linux]

On Mon, Sep 28, 2015 at 11:01:34AM +0200, Arnaud Pouliquen wrote:
> few questions/remarks
> BR,
> Arnaud
> 
> >+static void hdmi_codec_abort(struct device *dev)
> >+{
> >+struct hdmi_codec_priv *hcp = dev_get_drvdata(dev);
> >+
> >+dev_dbg(dev, "%s()\n", __func__);
> >+
> >+mutex_lock(>current_stream_lock);
> >+if (hcp->current_stream && hcp->current_stream->runtime &&
> >+snd_pcm_running(hcp->current_stream)) {
> >+dev_info(dev, "HDMI audio playback aborted\n");
> >+snd_pcm_stream_lock_irq(hcp->current_stream);
> >+snd_pcm_stop(hcp->current_stream, SNDRV_PCM_STATE_DISCONNECTED);
> >+snd_pcm_stream_unlock_irq(hcp->current_stream);
> >+}
> >+mutex_unlock(>current_stream_lock);
> >+}
> Does driver should stop the stream in case of unplug?
> This could generate unexpected behavior at application level.
> Perhaps should be better if this part is managed in DRM driver. if HDMI
> master, I2S bus should be maintained ON to consume the audio stream until
> application action.

If it does, that's really horrid.

Firstly, do you expect your video playback to stop just because you've
unplugged the TV?  Maybe you've got a dumb HDMI switch, and you've
switched from one input to another to momentarily check something on
another input - should the video playback suddenly end up with its
audio path being dumped on the floor because of that?

Also, as I've said before, there's hardware out there where the SPDIF
audio output is routed to more than just the HDMI interface, and the
capabilities of HDMI really don't apply in that situation - you may
have an AV receiver connected to the SPDIF output which is able to
accept much more than the basic audio that most TVs accept.  Having
stuff restricted to the union of the abilities is far too restrictive.
Stopping the audio output because the TV went away in this case is also
plain idiotic.

SPDIF is something that can be routed to multiple devices simultaneously,
and there's no capability or connection reporting involved in it.
Imposing the status of one "SPDIF listener" on the entire audio system is
unreasonable.

> >+
> >+static int hdmi_codec_hw_params(struct snd_pcm_substream *substream,
> >+struct snd_pcm_hw_params *params,
> >+struct snd_soc_dai *dai)
> >+{
> >+struct hdmi_codec_priv *hcp = snd_soc_dai_get_drvdata(dai);
> >+struct hdmi_codec_params hp = {
> >+.iec = {
> >+.status = { 0 },
> >+.subcode = { 0 },
> >+.pad = 0,
> >+.dig_subframe = { 0 },
> >+}
> >+};
> >+int ret;
> >+
> >+dev_dbg(dai->dev, "%s() width %d rate %d channels %d\n", __func__,
> >+params_width(params), params_rate(params),
> >+params_channels(params));
> >+
> >+ret = snd_pcm_create_iec958_consumer_hw_params(params, hp.iec.status,
> >+   sizeof(hp.iec.status));
> Tell me if i am wrong, but in case of SPDIF format, IEC status is managed by
> cpu_dai not by the codec.

Correct.  I2S needs the IEC958 status programmed into the HDMI interface
though, because HDMI is basically SPDIF.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH 1/6] driver-core: platform: Provide helpers for multi-driver modules

[Eric Anholt]

Daniel Vetter  writes:

> On Thu, Sep 24, 2015 at 7:02 PM, Thierry Reding
>  wrote:
>> From: Thierry Reding 
>>
>> Some modules register several sub-drivers. Provide a helper that makes
>> it easy to register and unregister a list of sub-drivers, as well as
>> unwind properly on error.
>>
>> Cc: Greg Kroah-Hartman 
>> Signed-off-by: Thierry Reding 
>
> I raised this already on irc but let's do it here too for the record:
> Eric Anholt has a very similar thing (but in drm only) with the
> addition of also integrating with the component framework:
>
> http://lists.freedesktop.org/archives/dri-devel/2015-September/090449.html
>
> Having something that works for everyone (so includes msm and can be
> used for vc4 too) would be great. Adding Eric.

I'm not sure if I should be providing a Reviewed-by here, but I like
this patch.  It obsoletes part of my patch series, and I look forward to
using it in my driver.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150928/bbbc580d/attachment.sig>

[Bug 90263] GPU card fans run full speed at all times

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

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

--- Comment #17 from Todd  ---
Problem remains in 4.2.1.

Is any attention being given to this bug?

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

[PATCH 10/11] drm: Use vblank timestamps to guesstimate how many vblanks were missed

[Michel Dänzer]

On 15.09.2015 04:43, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> When lacking am accurate hardware frame counter, we can fall back to
> using the vblank timestamps to guesstimagte how many vblanks have
> elapsed since the last time the vblank counter was updated.
> 
> Take the oppostunity to unify the vblank_disable_and_save() and
> drm_handle_vblank_events() to call the same function
> (drm_update_vblank_count()) to perform the vblank updates.

It would be nice to keep the drm_update_vblank_count unification
separate. As it is, it's very hard to keep track of which parts of the
patch are for each logical change.


BTW, I think the fact that I was hitting the problem fixed by 209e4dbc
("drm/vblank: Use u32 consistently for vblank counters") within a few
days indicates that there's another bug which causes the counter to jump
forward with drm_vblank_on/off(). It may not manifest itself with
current Intel hardware because that has a full 32-bit hardware frame
counter, turning the related calculations into no-ops. I haven't had
time to investigate this further yet.


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

[PATCH 00/48] Etnaviv changes RFCv1->RFCv2

[Christian Gmeiner]

Hi Lucas.

I think I have run into a cache flush / cache coherency issue. I will
try to reproduce this issue with a small example and will
keep you updated.

Greets
--
Christian Gmeiner, MSc

https://soundcloud.com/christian-gmeiner


2015-09-25 13:57 GMT+02:00 Lucas Stach :
> Hi Russell, Christian and whoever might be interested,
>
> This series contains the individual changes between RFCv1 and RFCv2
> of the etnaviv driver. This should make it easier to review the patches
> for people already familiar with the first round of etnaviv patches.
>
> Note that I opted to sort the patches a bit different than how they are
> laid out in the etnaviv-for-upstream git branch to make logical
> connections between patches a bit more clear and to not repeat patches
> with only trivial changes from RFCv1 in this series.
>
> Regards,
> Lucas
>
> Christian Gmeiner (5):
>   staging: etnaviv: quiten down kernel log output
>   staging: etnaviv: fix 'ret' may be used uninitialized in this function
>   staging: etnaviv: fix error: 'etnaviv_gpu_hw_resume' defined but not
> used
>   staging: etnaviv: debugfs: add possibility to dump kernel buffer
>   staging: etnaviv: change etnaviv_buffer_init() to return prefetch
>
> Lucas Stach (10):
>   staging: etnaviv: remove compat MMU code
>   staging: etnaviv: rename last remaining bits from msm to etnaviv
>   staging: etnaviv: add proper license header to all files
>   staging: etnaviv: implement simple hang recovery
>   staging: etnaviv: map all buffers to the GPU
>   staging: etnaviv: implement cache maintenance on cpu_(prep|fini)
>   staging: etnaviv: remove submit type
>   staging: etnaviv: rewrite submit interface to use copy from user
>   staging: etnaviv: don't use GEM buffer for internal ring buffer
>   staging: etnaviv: remove CMDSTREAM GEM allocation from UAPI
>
> Russell King (33):
>   staging: etnaviv: avoid holding struct_mutex over dma_alloc_coherent()
>   staging: etnaviv: restructure iommu handling
>   staging: etnaviv: clean up public API (part 2)
>   staging: etnaviv: rename last remaining msm_* symbols
>   staging: etnaviv: add Dove GPU subsystem compatible
>   staging: etnaviv: fix missing error cleanups in etnaviv_load()
>   staging: etnaviv: fix off-by-one for iommu aperture end
>   staging: etnaviv: avoid lockdep circular dependency warning
>   staging: etnaviv: fix gpu debugfs show implementation
>   staging: etnaviv: use vm_insert_page() rather than vm_insert_mixed()
>   staging: etnaviv: etnaviv_gem_fault: reduce struct_mutex exposure
>   staging: etnaviv: give etnaviv_gem_mmap_offset() a sane behaviour
>   staging: etnaviv: allow etnaviv_ioctl_gem_info() locking to be
> interruptible
>   staging: etnaviv: make context a per-GPU thing
>   staging: etnaviv: switch to per-GPU fence completion implementation
>   staging: etnaviv: provide etnaviv_queue_work()
>   staging: etnaviv: use standard kernel types rather than stdint.h types
>   staging: etnaviv: no need to initialise a list_head
>   staging: etnaviv: fix oops caused by scanning for free blocks
>   staging: etnaviv: clean up etnaviv_iommu_unmap_gem() signature
>   staging: etnaviv: increase page table size to maximum
>   staging: etnaviv: fix BUG_ON when removing module
>   staging: etnaviv: provide a helper to load the GPU clock field
>   staging: etnaviv: rename GPU clock functions
>   staging: etnaviv: fix runtime resume
>   staging: etnaviv: drop event ring buffer tracking
>   staging: etnaviv: improve efficiency of command parser
>   staging: etnaviv: no point looking up the mapping for cmdstream bos
>   staging: etnaviv: copy submit command and bos in one go
>   staging: etnaviv: remove cmd buffer offset validation in
> submit_reloc()
>   staging: etnaviv: move mapping teardown into etnaviv_gem_free_object()
>   staging: etnaviv: add support for GEM_WAIT ioctl
>   staging: etnaviv: avoid pinning pages in CMA
>
>  drivers/staging/etnaviv/etnaviv_buffer.c | 123 
>  drivers/staging/etnaviv/etnaviv_cmd_parser.c |  56 ++--
>  drivers/staging/etnaviv/etnaviv_drv.c| 217 ---
>  drivers/staging/etnaviv/etnaviv_drv.h|  54 ++--
>  drivers/staging/etnaviv/etnaviv_gem.c| 370 
>  drivers/staging/etnaviv/etnaviv_gem.h|  40 +--
>  drivers/staging/etnaviv/etnaviv_gem_prime.c  |  10 +-
>  drivers/staging/etnaviv/etnaviv_gem_submit.c | 219 +++
>  drivers/staging/etnaviv/etnaviv_gpu.c| 403 
> ---
>  drivers/staging/etnaviv/etnaviv_gpu.h| 107 ---
>  drivers/staging/etnaviv/etnaviv_iommu.c  | 113 
>  drivers/staging/etnaviv/etnaviv_iommu.h  |   2 +
>  drivers/staging/etnaviv/etnaviv_mmu.c|  75 ++---
>  drivers/staging/etnaviv/etnaviv_mmu.h|  15 +-
>  include/uapi/drm/etnaviv_drm.h   | 100 +++
>  15 files changed, 1086 insertions(+), 818 deletions(-)
>
> --
> 2.5.1
>

[RFC] Docs: drm: Move KMS properties table out to source files

[Jonathan Corbet]

On Mon, 28 Sep 2015 10:36:59 +0100
Graham Whaley  wrote:

> I've still not thought of a way of tweaking the kernel-doc and pandoc
> processing to work around this either, as they are done as different
> passes/phases that neither has knowledge about the others
> requirements.
> 
> As it stands, I'm failing to find a method to break out the DRM table
> into markdown tables that I believe works, fundamentally due to this
> 'incompatibility' between the kernel-doc and pandoc_markdown processing
> phases around the highlight processing.

This sort of thing is why I'm increasingly nervous about this one-off mix
of doc-generation tools we're putting together.  Sigh.

One possibility might be to have kernel-doc understand some sort of table
notation of its own and make it do the right thing.

Another might be to have kernel-doc format unconditionally to markdown
(or ReST, or something) all the time, then have the secondary processor
handle everything from there.  A bigger change, obviously.  Probably not
something anybody wants to face, but we may reach a point where we need
to consider having less than three independent formatting tools in the
mix.  I *may* get a chance to mess with this idea in the next week or so,
but no promises.

jon

[Bug 66977] get_num_groups not supported by libclc

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

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

Serge Martin <edb+freedesktop at sigluy.net> changed:

   What|Removed |Added

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

--- Comment #2 from Serge Martin <edb+freedesktop at sigluy.net> ---
see libclc r187059

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

[PATCH 1/6] driver-core: platform: Provide helpers for multi-driver modules

[Daniel Vetter]

On Thu, Sep 24, 2015 at 7:02 PM, Thierry Reding
 wrote:
> From: Thierry Reding 
>
> Some modules register several sub-drivers. Provide a helper that makes
> it easy to register and unregister a list of sub-drivers, as well as
> unwind properly on error.
>
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Thierry Reding 

I raised this already on irc but let's do it here too for the record:
Eric Anholt has a very similar thing (but in drm only) with the
addition of also integrating with the component framework:

http://lists.freedesktop.org/archives/dri-devel/2015-September/090449.html

Having something that works for everyone (so includes msm and can be
used for vc4 too) would be great. Adding Eric.
-Daniel

> ---
>  Documentation/driver-model/platform.txt | 11 ++
>  drivers/base/platform.c | 60 
> +
>  include/linux/platform_device.h |  5 +++
>  3 files changed, 76 insertions(+)
>
> diff --git a/Documentation/driver-model/platform.txt 
> b/Documentation/driver-model/platform.txt
> index 07795ec51cde..e80468738ba9 100644
> --- a/Documentation/driver-model/platform.txt
> +++ b/Documentation/driver-model/platform.txt
> @@ -63,6 +63,17 @@ runtime memory footprint:
> int platform_driver_probe(struct platform_driver *drv,
>   int (*probe)(struct platform_device *))
>
> +Kernel modules can be composed of several platform drivers. The platform core
> +provides helpers to register and unregister an array of drivers:
> +
> +   int platform_register_drivers(struct platform_driver * const *drivers,
> + unsigned int count);
> +   void platform_unregister_drivers(struct platform_driver * const 
> *drivers,
> +unsigned int count);
> +
> +If one of the drivers fails to register, all drivers registered up to that
> +point will be unregistered in reverse order.
> +
>
>  Device Enumeration
>  ~~
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index f80aaaf9f610..b7d7987fda97 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -711,6 +711,66 @@ err_out:
>  }
>  EXPORT_SYMBOL_GPL(__platform_create_bundle);
>
> +/**
> + * platform_register_drivers - register an array of platform drivers
> + * @drivers: an array of drivers to register
> + * @count: the number of drivers to register
> + *
> + * Registers platform drivers specified by an array. On failure to register a
> + * driver, all previously registered drivers will be unregistered. Callers of
> + * this API should use platform_unregister_drivers() to unregister drivers in
> + * the reverse order.
> + *
> + * Returns: 0 on success or a negative error code on failure.
> + */
> +int platform_register_drivers(struct platform_driver * const *drivers,
> + unsigned int count)
> +{
> +   unsigned int i;
> +   int err;
> +
> +   for (i = 0; i < count; i++) {
> +   pr_debug("registering platform driver %ps\n", drivers[i]);
> +
> +   err = platform_driver_register(drivers[i]);
> +   if (err < 0) {
> +   pr_err("failed to register platform driver %ps: %d\n",
> +  drivers[i], err);
> +   goto error;
> +   }
> +   }
> +
> +   return 0;
> +
> +error:
> +   while (i--) {
> +   pr_debug("unregistering platform driver %ps\n", drivers[i]);
> +   platform_driver_unregister(drivers[i]);
> +   }
> +
> +   return err;
> +}
> +EXPORT_SYMBOL_GPL(platform_register_drivers);
> +
> +/**
> + * platform_unregister_drivers - unregister an array of platform drivers
> + * @drivers: an array of drivers to unregister
> + * @count: the number of drivers to unregister
> + *
> + * Unegisters platform drivers specified by an array. This is typically used
> + * to complement an earlier call to platform_register_drivers(). Drivers are
> + * unregistered in the reverse order in which they were registered.
> + */
> +void platform_unregister_drivers(struct platform_driver * const *drivers,
> +unsigned int count)
> +{
> +   while (count--) {
> +   pr_debug("unregistering platform driver %ps\n", 
> drivers[count]);
> +   platform_driver_unregister(drivers[count]);
> +   }
> +}
> +EXPORT_SYMBOL_GPL(platform_unregister_drivers);
> +
>  /* modalias support enables more hands-off userspace setup:
>   * (a) environment variable lets new-style hotplug events work once system is
>   * fully running:  "modprobe $MODALIAS"
> diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
> index bba08f44cc97..0c9f16bfdd99 100644
> --- a/include/linux/platform_device.h
> +++ b/include/linux/platform_device.h
> @@ -270,6 +270,11 @@ extern struct platform_device *__platform_create_bundle(
> struct resource *res, unsigned 

[PATCH RFC v4 3/8] ASoC: hdmi-codec: Add hdmi-codec for external HDMI-encoders

[Arnaud Pouliquen]

few questions/remarks
BR,
Arnaud

> +static void hdmi_codec_abort(struct device *dev)
> +{
> +struct hdmi_codec_priv *hcp = dev_get_drvdata(dev);
> +
> +dev_dbg(dev, "%s()\n", __func__);
> +
> +mutex_lock(>current_stream_lock);
> +if (hcp->current_stream && hcp->current_stream->runtime &&
> +snd_pcm_running(hcp->current_stream)) {
> +dev_info(dev, "HDMI audio playback aborted\n");
> +snd_pcm_stream_lock_irq(hcp->current_stream);
> +snd_pcm_stop(hcp->current_stream, SNDRV_PCM_STATE_DISCONNECTED);
> +snd_pcm_stream_unlock_irq(hcp->current_stream);
> +}
> +mutex_unlock(>current_stream_lock);
> +}
Does driver should stop the stream in case of unplug?
This could generate unexpected behavior at application level.
Perhaps should be better if this part is managed in DRM driver. if HDMI 
master, I2S bus should be maintained ON to consume the audio stream 
until application action.

> +
> +static int hdmi_codec_hw_params(struct snd_pcm_substream *substream,
> +struct snd_pcm_hw_params *params,
> +struct snd_soc_dai *dai)
> +{
> +struct hdmi_codec_priv *hcp = snd_soc_dai_get_drvdata(dai);
> +struct hdmi_codec_params hp = {
> +.iec = {
> +.status = { 0 },
> +.subcode = { 0 },
> +.pad = 0,
> +.dig_subframe = { 0 },
> +}
> +};
> +int ret;
> +
> +dev_dbg(dai->dev, "%s() width %d rate %d channels %d\n", __func__,
> +params_width(params), params_rate(params),
> +params_channels(params));
> +
> +ret = snd_pcm_create_iec958_consumer_hw_params(params, hp.iec.status,
> +   sizeof(hp.iec.status));
Tell me if i am wrong, but in case of SPDIF format, IEC status is 
managed by cpu_dai not by the codec.
To manage IEC61937 a control should be needed to update IEC status bits...

> +if (ret < 0) {
> +dev_err(dai->dev, "Creating IEC958 channel status failed %d\n",
> +ret);
> +return ret;
> +}
> +
> +ret = hdmi_codec_new_stream(substream, dai);
> +if (ret)
> +return ret;
> +
> +hdmi_audio_infoframe_init();
> +hp.cea.channels = params_channels(params);
> +hp.cea.coding_type = HDMI_AUDIO_CODING_TYPE_STREAM;
> +hp.cea.sample_size = HDMI_AUDIO_SAMPLE_SIZE_STREAM;
> +hp.cea.sample_frequency = HDMI_AUDIO_SAMPLE_FREQUENCY_STREAM;
> +
> +hp.sample_width = params_width(params);
> +hp.sample_rate = params_rate(params);
> +hp.channels = params_channels(params);
> +
> +return hcp->hcd.ops->hw_params(dai->dev->parent,
> >daifmt[dai->id],
> +   );
> +}
> +

[RFC] Docs: drm: Move KMS properties table out to source files

[Graham Whaley]

On Tue, 2015-09-22 at 16:03 -0300, Danilo Cesar Lemes de Paula wrote:
> On 09/22/2015 07:22 AM, Graham Whaley wrote:
> > On Wed, Sep 02, 2015 at 02:50:52PM +0100, Graham Whaley wrote:
> > > > (RFC/test - not for merging)
> > > > The below is a test of moving the large HTML KMS properties
> > > > table
> > > > out
> > > > to markdown style in the appropriate files.
> > > > In the test we only use the first few rows of the existing KMS
> > > > table
> > > > an example.
> > > > We use a fixed width table as the other styles of table
> > > > supported
> > > > by
> > > > pandoc markdown do not support multi-column cells.
> > > > 
> > > > The test shows a couple of issues:
> > > >  1) double quote characters are being expanded in the fixed
> > > > width
> > > > table
> > > >  which then breaks the table alignment and leaves html style
> > > >  tags
> > > >  in the text
> > 
> > Further to this item:
> >  Before I continue working on splitting the tables and converting
> > to
> > markdown (which btw Daniel does look feasible so far...), I thought
> > we
> > should understand what was going on with the markdown table quote
> > breakage.
> >  I think I know what is happenig.
> >  The problem revolves around highlight expansion in the kenrel-doc
> > script. In the output_highlight function we can see that first the
> > script does highlight expansion (with the eval of @dohighlight),
> > and
> > then it invokes the markdown processing.
> >  Done that way around what happens is:
> >  - @dohighlight expands any "X" to html/xml quote tag sequences
> >  - which can push the text beyond the table column widths,
> >  - and then the markdown tries to split the text over columns, and
> > manages to put the break in the middle of a tag, and thus breaks
> > the
> > tag formatting (see below)
> > 
> > At least that is what I think is happening.
> > I had thought maybe we could swap the markdown and highlight
> > processing
> > order, but then that presents a different issue - the markdown
> > table
> > contains metadata with quoted items (such as cols="5"), which the
> > highligh processing then expands into tags, and hence breaks the
> > table
> > format metadata.
> > 
> > As an example, using the following table !Pinclude'd into drm.tmpl:
> > /**
> >  * DOC: DRM generic
> >  *
> >  * : DRM generic properties
> >  *
> >  * +--+++-+
> > 
> > +
> >  * |Property  |Type|Property Values |Object  
> >  |Description/Restrictions|
> >  *
> > +==+++=+===
> > 
> > =+
> >  * |"rotation"|BITMASK |{ 0, "rotate-0" }, {|CRTC,|rotate
> > -(degrees)
> > rotates|
> >  * +--+++-+
> > 
> > +
> >  *
> >  */
> > 
> > The post-highlight pre-markdown text captured as the $orig_context
> > in
> > the markdown_to_docbook function is:
> > 
> > +--+++-+---
> > 
> > -+
> > > Property  |Type|Property Values |Object  
> >  |Description/Restrictions|
> > +==+++=+===
> > 
> > =+
> > > rotation|BITMASK |{ 0, rotate-0 },
> > {|CRTC,|rotate-(degrees) rotates|
> > +--+++-+---
> > 
> > -+
> > 
> > which when processed (and you can do this by hand with 'pandoc -
> > -columns=80 -f markdown -t docbook ...' generates the broken tags
> > example:
> > 
> > ...
> > 
> >  
> >
> >  
> >rota
> >  
> >
> >
> >  
> >tion/quo
> >  
> >
> >
> >  
> >te|BITMASK |{ 0, qu
> >  
> >
> >
> >  
> >oterotate
> >  
> >
> >
> >  
> >-0 }, {|CRTC, |rotate-(degrees) rotates
> >  
> > ...
> > 
> > where you can see the quote tag processing has gone horribly wrong.
> > 
> > I believe we'll have the same problem for the other 'highlight'
> > processed items from kern-doc as well, meaning:
> >  funcname()
> >  $ENVVAR
> >  _name
> >  @parameter
> >  %CONST
> >  
> > As the kern-doc processing has no knowledge of when it is about to
> > process a markdown table I can't think of an obvious way around
> > this.
> > At present I think the implicit rule is 'no highlight/expansion
> > items
> > allowed in markdown tables', which means all those quoted strings
> > for
> > the DRM properties cannot currently be migrated to look like
> > strings.
> > 
> > Danilo, or anybody, any ideas?
> 
> Your debugging is pretty precise. The "+=+===" format is rigid. I
> don't know if it's a bug in pandoc or something from the spec itself.
> 
> May I suggest another format?
> 
> > Property  

[PATCH v2] driver-core: platform: Provide helpers for multi-driver modules

[Andy Shevchenko]

On Fri, Sep 25, 2015 at 6:29 PM, Thierry Reding
 wrote:
> From: Thierry Reding 
>
> Some modules register several sub-drivers. Provide a helper that makes
> it easy to register and unregister a list of sub-drivers, as well as
> unwind properly on error.
>
> Cc: Greg Kroah-Hartman 
> Signed-off-by: Thierry Reding 

> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index f80aaaf9f610..68c58c43e45a 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -711,6 +711,67 @@ err_out:
>  }
>  EXPORT_SYMBOL_GPL(__platform_create_bundle);
>
> +/**
> + * __platform_register_drivers - register an array of platform drivers
> + * @drivers: an array of drivers to register
> + * @count: the number of drivers to register
> + * @owner: module owning the drivers
> + *
> + * Registers platform drivers specified by an array. On failure to register a
> + * driver, all previously registered drivers will be unregistered. Callers of
> + * this API should use platform_unregister_drivers() to unregister drivers in
> + * the reverse order.
> + *
> + * Returns: 0 on success or a negative error code on failure.
> + */
> +int __platform_register_drivers(struct platform_driver * const *drivers,
> +   unsigned int count, struct module *owner)
> +{
> +   unsigned int i;
> +   int err;
> +
> +   for (i = 0; i < count; i++) {
> +   pr_debug("registering platform driver %ps\n", drivers[i]);
> +
> +   err = __platform_driver_register(drivers[i], owner);
> +   if (err < 0) {
> +   pr_err("failed to register platform driver %ps: %d\n",
> +  drivers[i], err);

Would
platform_unregister_drivers(drivers, i);
work?

> +   goto error;
> +   }
> +   }
> +
> +   return 0;
> +
> +error:
> +   while (i--) {

I think Jani was confused since often idiom is 'while (--i >=0)' is used.

> +   pr_debug("unregistering platform driver %ps\n", drivers[i]);
> +   platform_driver_unregister(drivers[i]);
> +   }
> +
> +   return err;
> +}
> +EXPORT_SYMBOL_GPL(__platform_register_drivers);
> +
> +/**
> + * platform_unregister_drivers - unregister an array of platform drivers
> + * @drivers: an array of drivers to unregister
> + * @count: the number of drivers to unregister
> + *
> + * Unegisters platform drivers specified by an array. This is typically used
> + * to complement an earlier call to platform_register_drivers(). Drivers are
> + * unregistered in the reverse order in which they were registered.
> + */
> +void platform_unregister_drivers(struct platform_driver * const *drivers,
> +unsigned int count)
> +{
> +   while (count--) {
> +   pr_debug("unregistering platform driver %ps\n", 
> drivers[count]);
> +   platform_driver_unregister(drivers[count]);
> +   }
> +}
> +EXPORT_SYMBOL_GPL(platform_unregister_drivers);

-- 
With Best Regards,
Andy Shevchenko

[Bug 91893] R100: GPU lockup: EQ overflowing

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

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

--- Comment #5 from macro at hotmail.com ---
Kernel arguments:

radeon.no_wb=1
radeon.dynclks=0
radeon.agpmode=-1
radeon.gartsize=32
radeon.msi=0
radeon.dpm=0
radeon.aspm=0
radeon.runpm=0
radeon.hard_reset=1
radeon.use_pflipirq=0
radeon.bapm=0

One or more (not sure exactly which) are required in order for X to start
without hanging the machine.

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

No more new fbdev drivers, please

[Gerd Hoffmann]

  Hi,

> As Daniel mentioned, the connector+encoder+crtc combination is one of
> those simplifications that would make sense if more such drivers are
> added.

Another one is memory management.  It's pretty complex because it can
handle _way_ more than what simple drivers need, and the result is
_alot_ of ttm boilerplate in the drivers.

cheers,
  Gerd

[PATCH 1/6] driver-core: platform: Provide helpers for multi-driver modules

[Jani Nikula]

On Fri, 25 Sep 2015, Thierry Reding  wrote:
> On Fri, Sep 25, 2015 at 01:27:28PM +0300, Jani Nikula wrote:
>> On Thu, 24 Sep 2015, Thierry Reding  wrote:
> [...]
>> > diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> [...]
>> > +/**
>> > + * platform_register_drivers - register an array of platform drivers
>> > + * @drivers: an array of drivers to register
>> > + * @count: the number of drivers to register
>> > + *
>> > + * Registers platform drivers specified by an array. On failure to 
>> > register a
>> > + * driver, all previously registered drivers will be unregistered. 
>> > Callers of
>> > + * this API should use platform_unregister_drivers() to unregister 
>> > drivers in
>> > + * the reverse order.
>> > + *
>> > + * Returns: 0 on success or a negative error code on failure.
>> > + */
>> > +int platform_register_drivers(struct platform_driver * const *drivers,
>> > +unsigned int count)
>> > +{
>> > +  unsigned int i;
>> > +  int err;
>> > +
>> > +  for (i = 0; i < count; i++) {
>> > +  pr_debug("registering platform driver %ps\n", drivers[i]);
>> > +
>> > +  err = platform_driver_register(drivers[i]);
>> > +  if (err < 0) {
>> > +  pr_err("failed to register platform driver %ps: %d\n",
>> > + drivers[i], err);
>> > +  goto error;
>> > +  }
>> > +  }
>> > +
>> > +  return 0;
>> > +
>> > +error:
>> > +  while (i--) {
>> > +  pr_debug("unregistering platform driver %ps\n", drivers[i]);
>> > +  platform_driver_unregister(drivers[i]);
>> > +  }
>> 
>> This will call platform_driver_unregister() on the driver that failed,
>> but not the first driver.
>> 
>> You should probably make i an int, and use while (--i >= 0).
>
> Actually it won't. I was especially careful and even tested this with
> one driver by instrumenting platform_driver_register() to return failure
> at various points in the sequence.
>
> This works fine.

You are right, of course. What was I thinking. My kingdom for an excuse!

BR,
Jani.




-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH v4] drm: bridge/dw_hdmi: add dw hdmi i2c bus adapter support

[Doug Anderson]

Vladimir,

On Mon, Sep 21, 2015 at 8:07 AM, Vladimir Zapolskiy
 wrote:
> - do I2C bus controller reinitialization on every data transfer,
>   this change hopefully solves some observed problems on RK3288 platform

My apologies, but this appears to be a bad idea...

We just discovered that this was the root cause of a bug.  If an HDCP
transfer is happening then the soft reset messes things up.  In our
tree we've moving things back to the way they were.  :(

-Doug

[Bug 91893] R100: GPU lockup: EQ overflowing

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

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

--- Comment #4 from macro at hotmail.com ---
Created attachment 118477
  --> https://bugs.freedesktop.org/attachment.cgi?id=118477=edit
radeontool registers dump after lockup

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

[Bug 91893] R100: GPU lockup: EQ overflowing

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

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

--- Comment #3 from macro at hotmail.com ---
Created attachment 118476
  --> https://bugs.freedesktop.org/attachment.cgi?id=118476=edit
radeontool registers dump before lockup

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

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

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

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

--- Comment #11 from Mathias Tillman  ---
(In reply to Michel Dänzer from comment #10)
> Mathias, so you can reliably reproduce the hang by replaying that apitrace?

Unfortunately I haven't been able to replay the apitrace properly - I just get
a black screen with a bunch of errors in the output about not supporting GLSL
1.50, program not supported etc.
I will keep trying though.

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

[Bug 91731] ATI RV250/M9 : screen needs to be refreshed after suspend/resume

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

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

--- Comment #1 from Michel Dänzer  ---
Please attach /var/log/Xorg.0.log and the output of dmesg captured after
suspend/resume.

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

[Bug 91965] pictures artefacts

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

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

Michel Dänzer  changed:

   What|Removed |Added

  Component|Driver/Radeon   |DRM/Radeon
   Assignee|xorg-driver-ati at lists.x.org |dri-devel at 
lists.freedesktop
   ||.org
Product|xorg|DRI
 QA Contact|xorg-team at lists.x.org   |

--- Comment #1 from Michel Dänzer  ---
Please attach the dmesg output.

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

[Bug 92039] glxinfo: Error: couldn't find RGB GLX visual or fbconfig; GetVisualConfigs returns 0 visuals; All fbconfigs have VisDepth = 0

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

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

--- Comment #8 from Michel Dänzer  ---
See bug 71789 and
http://lists.freedesktop.org/archives/mesa-dev/2015-September/095517.html for
some context.

Note that this is only the tip of an iceberg of issues for the radeonsi driver
on big endian hosts. Don't expect this to work anytime soon.

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

[Intel-gfx] [PATCH 10/23] drm/i915: Add gamma correction handlers

[Daniel Vetter]

On Sat, Sep 26, 2015 at 09:18:48PM +0530, Sharma, Shashank wrote:
> On 9/23/2015 1:52 PM, Sharma, Shashank wrote:
> >>Since color manager properties are meant as a new standardize KMS
> >>extension (we put them into the core drm_crtc_state) the get/set support
> >>should also be in the core. See e.g. how the rotation property is handled
> >>in drm_atomic_plane_get/set_property. So all this code should be added to
> >>drm_atomic_crtc_get/set_property.
> >Thanks, sounds like a good one. Will move this.
> Actually, while implementing this, I realized that this change is not
> required.
> What we want to do in drm_atomic_crtc_get/set code is:
> if (prop == config->cm_palette_after_ctm_property || prop ==  
>   config->cm_palette_before_ctm_property) {
>   crtc->funcs->atomic_get_property();
> }
> 
> Which is already being done in the current code:
> else if (crtc->funcs->atomic_get_property)
>   return crtc->funcs->atomic_get_property(crtc, state, property, val);

This code is to pass any property unknown to the drm core into the driver.
But since we want this to be a new drm core property set (that's why it's
in drm_crtc_state) the decoding should be done in the core too.

Note that atomic_get/set_property _only_ map between the property as seen
by userspace and the state structures. They're not allowed to do anything
else like compute derived state, check constraints or put the state into
the hw. That's for the atomic_check and atomic_commit callbacks. So for
this patchset here you should move all the code in the
atomic_get/set_property callbacks you add in i915 into the drm core. Like
it is doen for the rotation property.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Bug 105111] New: amdgpu 0000:00:01.0: Invalid ROM contents (with A8-7600)

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

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

Bug ID: 105111
   Summary: amdgpu :00:01.0: Invalid ROM contents (with
A8-7600)
   Product: Drivers
   Version: 2.5
Kernel Version: 4.3.0-rc3
  Hardware: IA-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: blocking
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: fin4478 at hotmail.com
Regression: No

Created attachment 188721
  --> https://bugzilla.kernel.org/attachment.cgi?id=188721=edit
dmesg output

amdgpu fails to find bios rom in Amd A8-7600 system. The following is a dmesg
capture after booting to linux rescue mode:

[1.629958] [drm] amdgpu kernel modesetting enabled.
[1.630360] [drm] initializing kernel modesetting (KAVERI 0x1002:0x1313
0x1043:0x85CB 0x00).
[1.630410] [drm] register mmio base: 0xFEB0
[1.630445] [drm] register mmio size: 262144
[1.630487] [drm] doorbell mmio base: 0xF000
[1.630523] [drm] doorbell mmio size: 8388608
[1.630582] amdgpu :00:01.0: Invalid ROM contents
[1.630652] [drm:amdgpu_get_bios [amdgpu]] *ERROR* Unable to locate a BIOS
ROM
[1.630695] amdgpu :00:01.0: Fatal error during GPU init
[1.630732] [drm] amdgpu: finishing device.
[1.630767] [TTM] Memory type 2 has not been initialized
[1.632024] amdgpu: probe of :00:01.0 failed with error -22

Problematic code is in the file: drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c

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

[Intel-gfx] [PATCH 10/23] drm/i915: Add gamma correction handlers

[Sharma, Shashank]

Matt, your opinion about this ? 

Regards
Shashank
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Monday, September 28, 2015 12:14 PM
To: Sharma, Shashank
Cc: Daniel Vetter; Roper, Matthew D; Bish, Jim; Bradford, Robert; Smith, Gary 
K; dri-devel at lists.freedesktop.org; intel-gfx at lists.freedesktop.org; 
Matheson, Annie J; kausalmalladi at gmail.com; Vetter, Daniel
Subject: Re: [Intel-gfx] [PATCH 10/23] drm/i915: Add gamma correction handlers

On Sat, Sep 26, 2015 at 09:18:48PM +0530, Sharma, Shashank wrote:
> On 9/23/2015 1:52 PM, Sharma, Shashank wrote:
> >>Since color manager properties are meant as a new standardize KMS 
> >>extension (we put them into the core drm_crtc_state) the get/set 
> >>support should also be in the core. See e.g. how the rotation 
> >>property is handled in drm_atomic_plane_get/set_property. So all 
> >>this code should be added to drm_atomic_crtc_get/set_property.
> >Thanks, sounds like a good one. Will move this.
> Actually, while implementing this, I realized that this change is not 
> required.
> What we want to do in drm_atomic_crtc_get/set code is:
> if (prop == config->cm_palette_after_ctm_property || prop ==  
>   config->cm_palette_before_ctm_property) {
>   crtc->funcs->atomic_get_property();
> }
> 
> Which is already being done in the current code:
> else if (crtc->funcs->atomic_get_property)
>   return crtc->funcs->atomic_get_property(crtc, state, property, val);

This code is to pass any property unknown to the drm core into the driver.
But since we want this to be a new drm core property set (that's why it's in 
drm_crtc_state) the decoding should be done in the core too.

Note that atomic_get/set_property _only_ map between the property as seen by 
userspace and the state structures. They're not allowed to do anything else 
like compute derived state, check constraints or put the state into the hw. 
That's for the atomic_check and atomic_commit callbacks. So for this patchset 
here you should move all the code in the atomic_get/set_property callbacks you 
add in i915 into the drm core. Like it is doen for the rotation property.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch