Re: [PATCH] drm/sun41: Fix incorrect return type

[Maxime Ripard]

Hi Sean,

On Thu, Jul 12, 2018 at 11:50:28AM -0400, Sean Paul wrote:
> We're returning -errno instead of ERR_PTR(-errno).
> 
> Fixes: af11942ee44e ("drm/sun4i: tcon-top: Cleanup clock handling")
> Cc: Chen-Yu Tsai 
> Cc: Jernej Skrabec 
> Cc: Maxime Ripard 
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-arm-ker...@lists.infradead.org
> Signed-off-by: Sean Paul 

I merged a similar patch yesterday, the warning should be gone now.

Thanks!
Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


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

[PATCH] ARM: dts: imx6sl: Add vivante gpu nodes

[Leonard Crestez]

The imx6sl soc has gpu_2d and gpu_vg, no 3d support:

etnaviv-gpu 220.gpu: model: GC320, revision: 5007
etnaviv-gpu 2204000.gpu: model: GC355, revision: 1215

The IP blocks are close enough to supported hardware that they "just
work" with etnaviv and x11.

Signed-off-by: Leonard Crestez 

---
 arch/arm/boot/dts/imx6sl.dtsi | 20 
 1 file changed, 20 insertions(+)

Tested by using yocto fsl community bsp built in "mainline" mode. This
patch makes x11 start up and turning on drm.debug shows that the etnaviv
driver is being used.

I don't know if such a patch requires much more testing: all it really
does is "describe the hardware".

Patch is against shawguo/imx/dt, it depends on newly accepted
commit 13211eec7b0e ("ARM: dts: imx6sl: Convert gpc to new bindings")
This is only because of the way it references the PU power domain.

diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index a6bc21433839..49a56b4fd393 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -130,10 +130,30 @@
cache-level = <2>;
arm,tag-latency = <4 2 3>;
arm,data-latency = <4 2 3>;
};
 
+   gpu_2d: gpu@220 {
+   compatible = "vivante,gc";
+   reg = <0x0220 0x4000>;
+   interrupts = <0 10 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&clks IMX6SL_CLK_MMDC_ROOT>,
+<&clks IMX6SL_CLK_GPU2D_OVG>;
+   clock-names = "bus", "core";
+   power-domains = <&pd_pu>;
+   };
+
+   gpu_vg: gpu@2204000 {
+   compatible = "vivante,gc";
+   reg = <0x02204000 0x4000>;
+   interrupts = <0 11 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = <&clks IMX6SL_CLK_MMDC_ROOT>,
+<&clks IMX6SL_CLK_GPU2D_OVG>;
+   clock-names = "bus", "core";
+   power-domains = <&pd_pu>;
+   };
+
aips1: aips-bus@200 {
compatible = "fsl,aips-bus", "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
reg = <0x0200 0x10>;
-- 
2.17.1

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

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Marek Vasut]

On 07/12/2018 03:03 PM, Leonard Crestez wrote:
> On Thu, 2018-07-12 at 11:21 +0200, Stefan Agner wrote:
>> On 10.07.2018 11:11, Marek Vasut wrote:
>>> On 07/10/2018 11:06 AM, Stefan Agner wrote:
 This is one of the situation where states quo is kinda the worst
 situation.

 Currently imx_v6_v7_defconfig and mxs_defconfig actually still uses
 CONFIG_FB_MXS.

 I understand that you'd rather prefer to move forward. I suggest we do
 it in steps.

 In 4.19:

 - Change DRM driver.name to mxsfb-drm so we avoid conflicts for now
>>>
>>> But this will break mesa if it depends on mxsfb name for ie. etnaviv
>>> binding.
>>
>> Does it? grep -r -e mxsfb in libdrm and mesa master returns nothing.
>>
>> There is also .name in struct drm_driver, which is already set to
>> mxsfb-drm... Is that the one exposed to user space?
> 
> Running etnaviv+x11 with a renamed mxsfb driver works fine on imx6sx-
> sdb.
> 
> Tools like modetest already need -M mxsfb-drm, the drm_driver.name
> seems to be what matters.
> 
>> - Remove CONFIG_FB_MXS from imx_v6_v7_defconfig/mxs_defconfig now, and
>> only enable CONFIG_DRM_MXSFB=y
> 
> If one of the drivers is renamed then they can coexist: since the
> bindings are distinct one driver will return a probe error and the
> other will bind successfully. This can even be adjusted so that it
> doesn't even print ugly scary errors.
> 
> This can last until somebody implements support for old bindings in the
> drm driver and then FB_MXS can just be deleted.

So why don't we just convert the DT bindings on boards supported
upstream and zap the old driver ? What is the problem with that?

Realistically, how many MXS boards in the field use old DT and new kernel ?

-- 
Best regards,
Marek Vasut
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 03/18] drm_property: change strncpy+truncation to strlcpy

[Dominique Martinet]

Using strlcpy fixes this new gcc warning:
drivers/gpu/drm/drm_property.c: In function ‘drm_property_create’:
drivers/gpu/drm/drm_property.c:125:2: warning: ‘strncpy’ specified bound 32 
equals destination size [-Wstringop-truncation]
  strncpy(property->name, name, DRM_PROP_NAME_LEN);
  ^~~~

Generated by scripts/coccinelle/misc/strncpy_truncation.cocci

Signed-off-by: Dominique Martinet 
---

Please see https://marc.info/?l=linux-kernel&m=153144450722324&w=2 (the
first patch of the serie) for the motivation behind this patch

 drivers/gpu/drm/drm_property.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_property.c b/drivers/gpu/drm/drm_property.c
index cdb10f885a4f..8f0ccfa91f8b 100644
--- a/drivers/gpu/drm/drm_property.c
+++ b/drivers/gpu/drm/drm_property.c
@@ -122,8 +122,7 @@ struct drm_property *drm_property_create(struct drm_device 
*dev,
property->num_values = num_values;
INIT_LIST_HEAD(&property->enum_list);
 
-   strncpy(property->name, name, DRM_PROP_NAME_LEN);
-   property->name[DRM_PROP_NAME_LEN-1] = '\0';
+   strlcpy(property->name, name, DRM_PROP_NAME_LEN);
 
list_add_tail(&property->head, &dev->mode_config.property_list);
 
@@ -416,8 +415,7 @@ int drm_property_add_enum(struct drm_property *property,
if (!prop_enum)
return -ENOMEM;
 
-   strncpy(prop_enum->name, name, DRM_PROP_NAME_LEN);
-   prop_enum->name[DRM_PROP_NAME_LEN-1] = '\0';
+   strlcpy(prop_enum->name, name, DRM_PROP_NAME_LEN);
prop_enum->value = value;
 
property->values[index] = value;
-- 
2.17.1

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

Re: AMD graphics performance regression in 4.15 and later

[Jean-Marc Valin]

Hi Christian,

Sorry for the delayed response, but I just thought I'd confirm that
kernel 4.17 (4.17.3-100.fc27.x86_64 to be more precise) seems to be
working fine for me, with no performance issue.

Cheers,

Jean-Marc

On 04/09/2018 07:48 AM, Christian König wrote:
> Am 06.04.2018 um 17:30 schrieb Jean-Marc Valin:
>> Hi Christian,
>>
>> Is there a way to turn off these huge pages at boot-time/run-time?
> 
> Only at compile time by not setting CONFIG_TRANSPARENT_HUGEPAGE.
> 
> Alternatively you can avoid enabling CONFIG_SWIOTLB which will avoid the
> slow DMA path as well.
> 
>> Right now the recent kernels are making Firefox pretty much unusable
>> for me.
>> I've been able to revert the patch from 4.15 but it's not really a
>> long-term solution.
>>
>> You mention that the purpose of the patch is to improve performance, but
>> I haven't actually noticed anything running faster on my system. Is
>> there any particular test where I'm supposed to see an improvement
>> compared to 4.14?
> 
> Mostly crypto mining, maybe some games as well.
> 
>> I'm not sure what you mean by "We mitigated the problem by avoiding the
>> slow coherent DMA code path on almost all platforms on newer kernels". I
>> tested up to 4.16 and the performance regression is just as bad as it is
>> for 4.15.
> 
> Indeed 4.16 still doesn't have that. You could use the
> amd-staging-drm-next branch or wait for 4.17.
> 
>> Unlike the older hardware reported on kernel bug 198511, the hardware I
>> have is quite recent (RX 560) and still being sold.
> 
> That isn't related to the GFX hardware, but to your CPU/motherboard and
> whatever else you have in the system.
> 
> Some part of your system needs SWIOTLB and that makes allocating memory
> much slower.
> 
>> I've also confirmed that neither nvidia (on the same machine) nor
>> intel GPUs (on a less
>> powerful machine) are affected, so it seems like there's a way to avoid
>> that slow performance.
> 
> Intel doesn't use TTM because they don't have dedicated VRAM, but the
> open source nvidia driver should be affected as well.
> 
>> I'm not saying that what Firefox is doing is
>> ideal (I don't know what it does and why), but it still seems like
>> something that should still be avoided in the kernel.
> 
> We already mitigated that problem and I don't see any solution which
> will arrive faster than 4.17.
> 
> The only quick workaround I can see is to avoid firefox, chrome for
> example is reported to work perfectly fine.
> 
> Christian.
> 
>>
>> Cheers,
>>
>> Jean-Marc
>>
>> On 04/06/2018 04:03 AM, Christian König wrote:
>>> Hi Jean,
>>>
>>> yeah, that is a known problem. Using huge pages improves the performance
>>> because of better TLB usage, but for the cost of higher allocation
>>> overhead.
>>>
>>> What we found is that firefox is doing something rather strange by
>>> allocating large textures and then just trowing them away again
>>> immediately.
>>>
>>> We mitigated the problem by avoiding the slow coherent DMA code path on
>>> almost all platforms on newer kernels, but essentially somebody needs to
>>> figure out why firefox and/or the user space stack is doing this
>>> constant allocation/freeing of memory.
>>>
>>> There is also a bug tracker on bugs.kernel.org about this, but I can't
>>> find it any more of hand.
>>>
>>> Regards,
>>> Christian.
>>>
>>> Am 06.04.2018 um 02:30 schrieb Jean-Marc Valin:
 Hi,

 I noticed a serious graphics performance regression between 4.14 and
 4.15. It is most noticeable with Firefox (tried FF57 through FF60) and
 causes scrolling to be really choppy/sluggish. I've confirmed that the
 problem is also there on 4.16, while 4.13 works fine.

 After a bisection, I've narrowed the regression down to this commit:

 commit 648bc3574716400acc06f99915815f80d9563783
 Author: Christian König 
 Date:   Thu Jul 6 09:59:43 2017 +0200

   drm/ttm: add transparent huge page support for DMA allocations v2


 Some details about my system:
 Distro: Fedora 27 (up-to-date)
 Video: MSI Radeon RX 560 AERO
 CPU: Dual-socket Xeon E5-2640 v4 (20 cores total)
 RAM: 128 GB ECC


 As a comparison, when running Firefox with 4.15 on a Lenovo W540 laptop
 (with Intel graphics only) the responsiveness is much better then what
 I'm getting on the Xeon machine above with the Radeon card, so this
 really seems to be an AMD-only issue.

 Any way to fix the issue?

 Thanks,

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

Re: [PATCH v2] console: Replace #if 1 with a bool to ignore

[Petr Mladek]

On Thu 2018-07-12 09:30:49, Steven Rostedt wrote:
> On Thu, 12 Jul 2018 09:29:38 -0400
> Steven Rostedt  wrote:
> 
> > From: Steven Rostedt (VMware) 
> > 
> > There's been discussion on the fb list about the addition of
> > WARN_CONSOLE_UNLOCKED() inside the fb code. The complaint is that when
> > the fb module is loaded with lockless_register_fb the console lock is
> > not taken for debugging reasons. With the addition of
> > WARN_CONSOLE_UNLOCK() within the fb code, this causes the console to
> > fill up with warnings when trying to debug the fb driver.
> > 
> > There's also a #if 1 that enables the warning which was added before
> > git history, and we look down on constant #if's in the kernel nowadays
> > anyway.
> > 
> > Remove the #if 1 and add a ignore_console_lock_warning boolean that can
> > be set by drivers to ignore the warning in order to do debugging.
> > 
> > Link: http://lkml.kernel.org/r/717e6337-e7a6-7a92-1c1b-8929a2569...@suse.de
> > Reviewed-by: Hans de Goede 
> > Acked-by: Sergey Senozhatsky 
> > Signed-off-by: Steven Rostedt (VMware) 
> 
> Petr,
> 
> If you want this to go by way of fbdev tree, then can you Ack it?

Sure.

Acked-by: Petr Mladek 

I assume that it will go via fbdev tree with the other changes
unless I hear otherwise.

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

Re: [PATCH 02/12] blk: use for_each_if

[Jens Axboe]

On 7/12/18 12:45 AM, Joe Perches wrote:
> On Wed, 2018-07-11 at 20:50 +0200, Daniel Vetter wrote:
>> On Wed, Jul 11, 2018 at 8:30 PM, Jens Axboe  wrote:
>>> On 7/11/18 10:45 AM, Tejun Heo wrote:
 On Wed, Jul 11, 2018 at 09:40:58AM -0700, Tejun Heo wrote:
> On Mon, Jul 09, 2018 at 10:36:40AM +0200, Daniel Vetter wrote:
>> Makes the macros resilient against if {} else {} blocks right
>> afterwards.
>>
>> Signed-off-by: Daniel Vetter 
>> Cc: Tejun Heo 
>> Cc: Jens Axboe 
>> Cc: Shaohua Li 
>> Cc: Kate Stewart 
>> Cc: Greg Kroah-Hartman 
>> Cc: Joseph Qi 
>> Cc: Daniel Vetter 
>> Cc: Arnd Bergmann 
>
> Acked-by: Tejun Heo 
>
> Jens, it'd probably be best to route this through block tree.

 Oops, this requires an earlier patch to move the for_each_if def to a
 common header and should be routed together.
>>>
>>> Yeah, this is a problem with the submission.
>>>
>>> Always (ALWAYS) CC folks on at least the cover letter and generic
>>> earlier patches. Getting just one patch sent like this is mostly
>>> useless, and causes more harm than good.
>>
>> Ime sending a patch with more than 20 or so recipients means it gets
>> stuck everywhere in moderation queues. Or outright spam filters. I
>> thought the correct way to do this is to cc: mailing lists (lkml has
>> them all), but apparently that's not how it's done. Despite that all
>> the patch series I get never have the cover letter addressed to me
>> either.
>>
>> So what's the magic way to make this possible?
> 
> Jens' advice is crap.
> 
> There is no generic way to make this possible.

Nobody claimed there was. And the advice is perfectly fine,
sending out patches to folks that have hidden dependencies on other
patches is a no-go.

> BCC's don't work, series that touch multiple subsystems
> get rejected when the recipient list is too large.
> 
> I think you did it correctly.

Clearly that's not the case, regardless of what you think.

Thanks for your invaluable and useful feedback, sharing your vast
experience in patchsets with dependencies.

-- 
Jens Axboe

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

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Leonard Crestez]

On Thu, 2018-07-12 at 11:21 +0200, Stefan Agner wrote:
> On 10.07.2018 11:11, Marek Vasut wrote:
> > On 07/10/2018 11:06 AM, Stefan Agner wrote:
> > > This is one of the situation where states quo is kinda the worst
> > > situation.
> > > 
> > > Currently imx_v6_v7_defconfig and mxs_defconfig actually still uses
> > > CONFIG_FB_MXS.
> > > 
> > > I understand that you'd rather prefer to move forward. I suggest we do
> > > it in steps.
> > > 
> > > In 4.19:
> > > 
> > > - Change DRM driver.name to mxsfb-drm so we avoid conflicts for now
> > 
> > But this will break mesa if it depends on mxsfb name for ie. etnaviv
> > binding.
> 
> Does it? grep -r -e mxsfb in libdrm and mesa master returns nothing.
> 
> There is also .name in struct drm_driver, which is already set to
> mxsfb-drm... Is that the one exposed to user space?

Running etnaviv+x11 with a renamed mxsfb driver works fine on imx6sx-
sdb.

Tools like modetest already need -M mxsfb-drm, the drm_driver.name
seems to be what matters.

> - Remove CONFIG_FB_MXS from imx_v6_v7_defconfig/mxs_defconfig now, and
> only enable CONFIG_DRM_MXSFB=y

If one of the drivers is renamed then they can coexist: since the
bindings are distinct one driver will return a probe error and the
other will bind successfully. This can even be adjusted so that it
doesn't even print ugly scary errors.

This can last until somebody implements support for old bindings in the
drm driver and then FB_MXS can just be deleted.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 04/18] nouveau: change strncpy+truncation to strlcpy

[Dominique Martinet]

Generated by scripts/coccinelle/misc/strncpy_truncation.cocci

Signed-off-by: Dominique Martinet 
---

Please see https://marc.info/?l=linux-kernel&m=153144450722324&w=2 (the
first patch of the serie) for the motivation behind this patch

 drivers/gpu/drm/nouveau/nvkm/core/firmware.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c 
b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
index 058ff46b5f16..579eb17db9f4 100644
--- a/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
+++ b/drivers/gpu/drm/nouveau/nvkm/core/firmware.c
@@ -40,8 +40,7 @@ nvkm_firmware_get(struct nvkm_device *device, const char 
*fwname,
int i;
 
/* Convert device name to lowercase */
-   strncpy(cname, device->chip->name, sizeof(cname));
-   cname[sizeof(cname) - 1] = '\0';
+   strlcpy(cname, device->chip->name, sizeof(cname));
i = strlen(cname);
while (i) {
--i;
-- 
2.17.1

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

Re: [Intel-gfx] [PATCH] i915/intel_tv_get_modes: fix strncpy truncation warning

[Dominique Martinet]

Ville Syrjälä wrote on Thu, Jul 12, 2018:
> On Wed, Jul 11, 2018 at 09:46:15AM +0200, Dominique Martinet wrote:
> > This is effectively no-op as the next line writes a nul at the final
> 
> What is "This". Please write self contained commit messages.

This could either be 'this commit' as a whole or if you look only at the
commit message 'this strncpy fix' from the title (which is arguably the
same), and both interpretations sound fairly understandable in the
context of the title line without seeing the patch to me... Although
I'll admit this is difficult to judge of that as the author.

Thanksfully, the v2 of the patch didn't use this wording but while I
agree the message could be better I do not think it was horrible.


> > drivers/gpu/drm/i915/intel_tv.c: In function ‘intel_tv_get_modes’:
> > drivers/gpu/drm/i915/intel_tv.c:1358:3: error: ‘strncpy’ specified bound 32 
> > equals destination size [-Werror=stringop-truncation]
> >strncpy(mode_ptr->name, input->name, DRM_DISPLAY_MODE_LEN);
> >^~
> > cc1: all warnings being treated as errors
> 
> That warning should be in the actual commit message.

Yes and no, I gave it for referrence but when you update to gcc 8 you
will literally see it all over the place.
The words "strncpy truncation warning" is really precise once you've
seen them a few times and there are litteraly hundred of these warnings
in the kernel, some have already been fixed taking a glance at the git
log, some with and without the warning message.
I don't think it's worth polluting the git log with this many
warnings... Which leads to...

> This same pattern is used all over drm. Can you go and fix them all up?
> One might even consider writing a cocci patch for it ;)

Now this is something I can agree with.
This patch really was just a stop-gap measure because I could not build
the kernel at all without it, but yes I did consider having a look at
others.

Unfortunately coccinelle does not run on fedora 28 (and doesn't look
like it will fix itself any time soon, there is a bug report[1] open
since February that didn't get much love lately - I was just looking at
it a few days ago)

I think in this case it might actually be faster to look at gcc warnings
and s/strncpy/strlcpy/, but I am curious about Coccinelle so this is a
good excuse to look at it, I'll report back in a bit after poking at
that bug report and figuring out how coccinelle works.

I do not guarantee speed however, if anyone sees this and feels put off
from donig it themselves, please go ahead and just drop me a word.


[1] https://bugzilla.redhat.com/show_bug.cgi?id=1544204

Thanks, and sorry for the mail longer than I originally intended,
-- 
Dominique Martinet
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 1/1] drm/panel: Add support for Olimex LCD-OLinuXino panel

[Stefan Mavrodiev]

This patch adds Olimex Ltd. LCD-OLinuXino bridge panel driver. The
panel is used with different LCDs (currently from 480x272 to 1280x800).
Small EEPROM chip is used for identification, which holds some
factory data and timing requirements.

Signed-off-by: Stefan Mavrodiev 
---
Changes for v3:
  - Change module license from "GPL v2" to "GPL"
  - Make use of backlight_enable()/backlight_disable() helpers
  - Rework backlight device request
  - Remove drm_panel_detach()
  - Use module_i2c_driver() for initialization
  - Make the first mode preferred
  - If num_modes value is invalid, overwrite it with 4, which is the maximum
  - Some variable types optimizations

Changes for v2:
  - Changed lcd_olinuxino_funcs to static const

 .../display/panel/olimex,lcd-olinuxino.txt |  42 +++
 MAINTAINERS|   6 +
 drivers/gpu/drm/panel/Kconfig  |  10 +
 drivers/gpu/drm/panel/Makefile |   1 +
 drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.c | 331 +
 5 files changed, 390 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/olimex,lcd-olinuxino.txt
 create mode 100644 drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.c

diff --git 
a/Documentation/devicetree/bindings/display/panel/olimex,lcd-olinuxino.txt 
b/Documentation/devicetree/bindings/display/panel/olimex,lcd-olinuxino.txt
new file mode 100644
index 000..a89f9c8
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/olimex,lcd-olinuxino.txt
@@ -0,0 +1,42 @@
+Binding for Olimex Ltd. LCD-OLinuXino bridge panel.
+
+This device can be used as bridge between a host controller and LCD panels.
+Currently supported LCDs are:
+  - LCD-OLinuXino-4.3TS
+  - LCD-OLinuXino-5
+  - LCD-OLinuXino-7
+  - LCD-OLinuXino-10
+
+The panel itself contains:
+  - AT24C16C EEPROM holding panel identification and timing requirements
+  - AR1021 resistive touch screen controller (optional)
+  - FT5x6 capacitive touch screnn controller (optional)
+  - GT911/GT928 capacitive touch screen controller (optional)
+
+The above chips share same I2C bus. The EEPROM is factory preprogrammed with
+device information (id, serial, etc.) and timing requirements.
+
+Touchscreen bingings can be found in these files:
+  - input/touchscreen/goodix.txt
+  - input/touchscreen/edt-ft5x06.txt
+  - input/touchscreen/ar1021.txt
+
+Required properties:
+  - compatible: should be "olimex,lcd-olinuxino"
+  - reg: address of the configuration EEPROM, should be <0x50>
+  - power-supply: phandle of the regulator that provides the supply voltage
+
+Optional properties:
+  - enable-gpios: GPIO pin to enable or disable the panel
+  - backlight: phandle of the backlight device attacked to the panel
+
+Example:
+&i2c2 {
+   panel@50 {
+   compatible = "olimex,lcd-olinuxino";
+   reg = <0x50>;
+   power-supply = <®_vcc5v0>;
+   enable-gpios = <&pio 7 8 GPIO_ACTIVE_HIGH>;
+   backlight = <&backlight>;
+   };
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 624c3fd..30343f1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4557,6 +4557,12 @@ S:   Supported
 F: drivers/gpu/drm/nouveau/
 F: include/uapi/drm/nouveau_drm.h
 
+DRM DRIVER FOR OLIMEX LCD-OLINUXINO PANELS
+M: Stefan Mavrodiev 
+S: Maintained
+F: drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.c
+F: Documentation/devicetree/bindings/display/panel/olimex,lcd-olinuxino.txt
+
 DRM DRIVER FOR PERVASIVE DISPLAYS REPAPER PANELS
 M: Noralf Trønnes 
 S: Maintained
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 25682ff..0292994 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -81,6 +81,16 @@ config DRM_PANEL_LG_LG4573
  Say Y here if you want to enable support for LG4573 RGB panel.
  To compile this driver as a module, choose M here.
 
+config DRM_PANEL_OLIMEX_LCD_OLINUXINO
+   tristate "Olimex LCD-OLinuXino panel"
+   depends on OF
+   depends on I2C
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y here if you want to enable support for Olimex Ltd.
+ LCD-OLinuXino panel. The panel is used with different sizes LCDs,
+ from 480x272 to 1280x800, and 24 bit per pixel.
+
 config DRM_PANEL_ORISETECH_OTM8009A
tristate "Orise Technology otm8009a 480x800 dsi 2dl panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index f26efc1..185027f 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
 obj-$(CONFIG_DRM_PANEL_INNOLUX_P079ZCA) += panel-innolux-p079zca.o
 obj-$(CONFIG_DRM_PANEL_JDI_LT070ME05000) += panel-jdi-lt070me05000.o
 obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
+obj-$(CONFIG_DRM_PANEL_OLIMEX_LCD_OLINUXINO) += panel-olimex-lc

Re: [Intel-gfx] [PATCH] i915/intel_tv_get_modes: fix strncpy truncation warning

[Dominique Martinet]

Ville Syrjälä wrote on Thu, Jul 12, 2018:
> On Thu, Jul 12, 2018 at 03:55:26PM +0200, Dominique Martinet wrote:
> > This could either be 'this commit' as a whole or if you look only at the
> > commit message 'this strncpy fix' from the title (which is arguably the
> > same), and both interpretations sound fairly understandable in the
> > context of the title line without seeing the patch to me... Although
> > I'll admit this is difficult to judge of that as the author.
> 
> The patch subject is not part of the commit message body though. This is
> made all the more clear when I'm editing the response in vim that doesn't
> even show the mail subject to me. Hence I'm always left in the dark by
> commit messages that aren't fully self contained.

Ah, that is a fair point - I thought you were referring to the patch
itself, not the subject. My mail client does include the subject in the
editor so I hadn't considered that, but I understand where you come from
now and agree.
I will be more mindful of that as the v2 has the same problem.


> > Yes and no, I gave it for referrence but when you update to gcc 8 you
> > will literally see it all over the place.
> > The words "strncpy truncation warning" is really precise once you've
> > seen them a few times and there are litteraly hundred of these warnings
> > in the kernel, some have already been fixed taking a glance at the git
> > log, some with and without the warning message.
> > I don't think it's worth polluting the git log with this many
> > warnings... Which leads to...
> 
> I disagree. Without knowing what exactly is fixed how can you judge 
> whether the patch even makes sense? And later you may get another
> report of the same warning and then you would want to look through
> the git log to see if there's a patch that already fixed it. Quite
> hard to do without the exact warning in the log.

I might just be tired of this specific warning; I've fixed it countless
times in different projects these past few months and it's coming out of
my eyes at this point.

I definitely agree in general, just -Wstringop-truncation has been
showing up everywhere and it's always the same, with many occurences I
don't consider to be bugs (like here because we forcefully terminate the
last byte of the string afterwards), so it's really lost value to me.

I included it as a comment precisely for your first point (so you can tell
the patch makes sense now) but I do not feel any regret not recording
it, and I still stand by what I said: if all you want is examples of
patches that already fix it, I've just had a look at git log in drm
trees and there already have been many fixes, most of which provided a
warning similar to the one I got.

Attaching the full warning messages makes sense if the warning is
new/rare but if it's the same as 5 other commits in semi-recent history
I do not see much point.

Anyway, I would be enclined to add it just to comply now but it looks
like Chris already picked the v2 up, so there is not much point in
arguing, sorry for disagreeing.

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

[PULL] drm-intel-fixes

[Rodrigo Vivi]

Hi Dave,

Things are still calm, but I'd like to add the GVT fix to this week
pull for 4.18.

Here goes drm-intel-fixes-2018-07-12:
- GVT fix for KBL vGPU hang to update virtual register from LRI.
- Fix hotplug irq ack on i965/g4x (Ville)

There's a silent conflict with gvt-fixes and gvt-next, which I'm
sending soon to you as well.

I'm not sure this will hit you now or later, but anyways in summary here
the issue is a compilation error
drivers/gpu/drm/i915/gvt/kvmgt.c:188:17: error: 'pfn' undeclared

And the solution Acked-by: Zhenyu Wang is:

--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -185,12 +185,6 @@ static int gvt_dma_map_page(struct intel_vgpu *vgpu, 
unsigned long gfn,
if (ret)
return ret;

-   if (!pfn_valid(pfn)) {
-   gvt_vgpu_err("pfn 0x%lx is not mem backed\n", pfn);
-   vfio_unpin_pages(mdev_dev(vgpu->vdev.mdev), &gfn, 1);
-   return -EINVAL;
-   }

Thanks,
Rodrigo.

The following changes since commit 1e4b044d22517cae7047c99038abb23243ca:

  Linux 4.18-rc4 (2018-07-08 16:34:02 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2018-07-12

for you to fetch changes up to 09d2da310d61c4bfae33ea05b88e7a8f31350d9e:

  Merge tag 'gvt-fixes-2018-07-11' of https://github.com/intel/gvt-linux into 
drm-intel-fixes (2018-07-12 00:15:53 -0700)


- GVT fix for KBL vGPU hang to update virtual register from LRI.
- Fix hotplug irq ack on i965/g4x (Ville)


Hang Yuan (1):
  drm/i915/gvt: update vreg on inhibit context lri command

Rodrigo Vivi (1):
  Merge tag 'gvt-fixes-2018-07-11' of https://github.com/intel/gvt-linux 
into drm-intel-fixes

Ville Syrjälä (1):
  drm/i915: Fix hotplug irq ack on i965/g4x

 drivers/gpu/drm/i915/gvt/cmd_parser.c   | 23 +++
 drivers/gpu/drm/i915/gvt/gvt.h  | 29 +
 drivers/gpu/drm/i915/gvt/handlers.c | 24 
 drivers/gpu/drm/i915/gvt/mmio.h |  2 ++
 drivers/gpu/drm/i915/gvt/mmio_context.c |  4 +++-
 drivers/gpu/drm/i915/i915_irq.c | 32 ++--
 6 files changed, 111 insertions(+), 3 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3] drm/scheduler: modify args of drm_sched_entity_init

[Christian König]

Am 12.07.2018 um 08:36 schrieb Nayan Deshmukh:

replace run queue by a list of run queues and remove the
sched arg as that is part of run queue itself

Signed-off-by: Nayan Deshmukh 


Going over this I've found one more thing which needs to be fixed:

[SNIP]

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c 
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 45bfdf4cc107..121c53e04603 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -49,12 +49,12 @@ static int etnaviv_open(struct drm_device *dev, struct 
drm_file *file)
  
  	for (i = 0; i < ETNA_MAX_PIPES; i++) {

struct etnaviv_gpu *gpu = priv->gpu[i];
+   struct drm_sched_rq *rq;
  
+		rq = &gpu->sched.sched_rq[DRM_SCHED_PRIORITY_NORMAL];

if (gpu) {


Here you use gpu right before the NULL check. It's only an address 
calculation, but still a bit ugly.


Just move the assignment under the "if (gpu) {".


-   drm_sched_entity_init(&gpu->sched,
-   &ctx->sched_entity[i],
-   &gpu->sched.sched_rq[DRM_SCHED_PRIORITY_NORMAL],
-   NULL);
+   drm_sched_entity_init(&ctx->sched_entity[i],
+ &rq, 1, NULL);


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

Re: [PATCH 3/3] drm/scheduler: modify args of drm_sched_entity_init

[Nayan Deshmukh]

On Thu, Jul 12, 2018 at 11:21 PM Eric Anholt  wrote:
>
> Nayan Deshmukh  writes:
> > diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c 
> > b/drivers/gpu/drm/scheduler/gpu_scheduler.c
> > index 3dc1a4f07e3f..b2dbd1c1ba69 100644
> > --- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
> > +++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
> > @@ -162,26 +162,32 @@ drm_sched_rq_select_entity(struct drm_sched_rq *rq)
> >   * drm_sched_entity_init - Init a context entity used by scheduler when
> >   * submit to HW ring.
> >   *
> > - * @sched: scheduler instance
> >   * @entity: scheduler entity to init
> > - * @rq: the run queue this entity belongs
> > + * @rq_list: the list of run queue on which jobs from this
> > + *   entity can be submitted
> > + * @num_rq_list: number of run queue in rq_list
> >   * @guilty: atomic_t set to 1 when a job on this queue
> >   *  is found to be guilty causing a timeout
> >   *
> > + * Note: the rq_list should have atleast one element to schedule
> > + *   the entity
> > + *
> >   * Returns 0 on success or a negative error code on failure.
> >  */
> > -int drm_sched_entity_init(struct drm_gpu_scheduler *sched,
> > -   struct drm_sched_entity *entity,
> > -   struct drm_sched_rq *rq,
> > +int drm_sched_entity_init(struct drm_sched_entity *entity,
> > +   struct drm_sched_rq **rq_list,
> > +   unsigned int num_rq_list,
> > atomic_t *guilty)
> >  {
> > - if (!(sched && entity && rq))
> > + if (!(entity && rq_list && num_rq_list > 0 && rq_list[0]))
> >   return -EINVAL;
> >
> >   memset(entity, 0, sizeof(struct drm_sched_entity));
> >   INIT_LIST_HEAD(&entity->list);
> > - entity->rq = rq;
> > - entity->sched = sched;
> > + entity->rq_list = NULL;
> > + entity->rq = rq_list[0];
> > + entity->sched = rq_list[0]->sched;
> > + entity->num_rq_list = num_rq_list;
>
> The API change makes sense as prep work, but I don't really like adding
> the field to the struct (and changing the struct's docs for the existing
> rq field) if it's going to always be NULL until a future change.
>
> Similarly, I'd rather see patch 2 as part of a series that uses the
> value.
I agree with you. I am fine with dropping the patch 2 for now and
modifying patch 3. I am fine either way.

What are your thoughts on this Christian?
>
> That said, while I don't currently have a usecase for load-balancing
> between entities, I may in the future, so thanks for working on this!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3] drm/scheduler: modify args of drm_sched_entity_init

[Christian König]

Am 13.07.2018 um 09:20 schrieb Nayan Deshmukh:

On Thu, Jul 12, 2018 at 11:21 PM Eric Anholt  wrote:

Nayan Deshmukh  writes:

diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c 
b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index 3dc1a4f07e3f..b2dbd1c1ba69 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -162,26 +162,32 @@ drm_sched_rq_select_entity(struct drm_sched_rq *rq)
   * drm_sched_entity_init - Init a context entity used by scheduler when
   * submit to HW ring.
   *
- * @sched: scheduler instance
   * @entity: scheduler entity to init
- * @rq: the run queue this entity belongs
+ * @rq_list: the list of run queue on which jobs from this
+ *   entity can be submitted
+ * @num_rq_list: number of run queue in rq_list
   * @guilty: atomic_t set to 1 when a job on this queue
   *  is found to be guilty causing a timeout
   *
+ * Note: the rq_list should have atleast one element to schedule
+ *   the entity
+ *
   * Returns 0 on success or a negative error code on failure.
  */
-int drm_sched_entity_init(struct drm_gpu_scheduler *sched,
-   struct drm_sched_entity *entity,
-   struct drm_sched_rq *rq,
+int drm_sched_entity_init(struct drm_sched_entity *entity,
+   struct drm_sched_rq **rq_list,
+   unsigned int num_rq_list,
 atomic_t *guilty)
  {
- if (!(sched && entity && rq))
+ if (!(entity && rq_list && num_rq_list > 0 && rq_list[0]))
   return -EINVAL;

   memset(entity, 0, sizeof(struct drm_sched_entity));
   INIT_LIST_HEAD(&entity->list);
- entity->rq = rq;
- entity->sched = sched;
+ entity->rq_list = NULL;
+ entity->rq = rq_list[0];
+ entity->sched = rq_list[0]->sched;
+ entity->num_rq_list = num_rq_list;

The API change makes sense as prep work, but I don't really like adding
the field to the struct (and changing the struct's docs for the existing
rq field) if it's going to always be NULL until a future change.

Similarly, I'd rather see patch 2 as part of a series that uses the
value.

I agree with you. I am fine with dropping the patch 2 for now and
modifying patch 3. I am fine either way.

What are your thoughts on this Christian?


Ok with me as well. In this case just send out the two patches with the 
API change.


Christian.


That said, while I don't currently have a usecase for load-balancing
between entities, I may in the future, so thanks for working on this!


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

Re: [PATCH 1/3] drm: mxsfb: Change driver.name to mxsfb-drm

[Daniel Vetter]

On Thu, Jul 12, 2018 at 03:14:57PM +0200, Marek Vasut wrote:
> On 07/12/2018 03:03 PM, Leonard Crestez wrote:
> > On Thu, 2018-07-12 at 11:21 +0200, Stefan Agner wrote:
> >> On 10.07.2018 11:11, Marek Vasut wrote:
> >>> On 07/10/2018 11:06 AM, Stefan Agner wrote:
>  This is one of the situation where states quo is kinda the worst
>  situation.
> 
>  Currently imx_v6_v7_defconfig and mxs_defconfig actually still uses
>  CONFIG_FB_MXS.
> 
>  I understand that you'd rather prefer to move forward. I suggest we do
>  it in steps.
> 
>  In 4.19:
> 
>  - Change DRM driver.name to mxsfb-drm so we avoid conflicts for now
> >>>
> >>> But this will break mesa if it depends on mxsfb name for ie. etnaviv
> >>> binding.
> >>
> >> Does it? grep -r -e mxsfb in libdrm and mesa master returns nothing.
> >>
> >> There is also .name in struct drm_driver, which is already set to
> >> mxsfb-drm... Is that the one exposed to user space?
> > 
> > Running etnaviv+x11 with a renamed mxsfb driver works fine on imx6sx-
> > sdb.
> > 
> > Tools like modetest already need -M mxsfb-drm, the drm_driver.name
> > seems to be what matters.
> > 
> >> - Remove CONFIG_FB_MXS from imx_v6_v7_defconfig/mxs_defconfig now, and
> >> only enable CONFIG_DRM_MXSFB=y
> > 
> > If one of the drivers is renamed then they can coexist: since the
> > bindings are distinct one driver will return a probe error and the
> > other will bind successfully. This can even be adjusted so that it
> > doesn't even print ugly scary errors.
> > 
> > This can last until somebody implements support for old bindings in the
> > drm driver and then FB_MXS can just be deleted.
> 
> So why don't we just convert the DT bindings on boards supported
> upstream and zap the old driver ? What is the problem with that?

+1 on zapping drivers :-)

> Realistically, how many MXS boards in the field use old DT and new kernel ?

Yeah I think occasionally that entire "DT is API, can't ever change it"
song is overblown. The rule with regressions isn't that you're never
allowed to break anything, but that you're only allowed to break stuff no
one will notice and report.

If there's realistically no users, go ahead and break (instead of huge and
drawn-out compat plan).

If there's a solid (and automatic enough) fallback like the drm driver,
go ahead and break.

We're doing this all the time in graphics with userspace ABI, I don't
think DT is any different. Every once in a while there's a bit of regrets
and a revert because we missed something, but overal it's much less effort
than always trying to do a perfect job with backwards compat.

Is it really a regression if no one reports it? No.

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

[PULL] drm-misc-fixes

[Maarten Lankhorst]

Hi Dave,

A single fix for building sun4i for v4.18-rc5.

drm-misc-fixes-2018-07-13:
Fixes for v4.18-rc5:
- Single fix for a build error when the driver is builtin,
  but the backend is a loadable module.

The following changes since commit 44f9a4b0dc7563669772198e5b226cab58a00167:

  drm/bridge/sii8620: Fix link mode selection (2018-07-04 16:27:51 +0200)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2018-07-13

for you to fetch changes up to 3156b53c2e2fadafa1a16412a8791b38f94b5bdc:

  drm/sun4i: link in front-end code if needed (2018-07-09 09:54:33 +0200)


Fixes for v4.18-rc5:
- Single fix for a build error when the driver is builtin,
  but the backend is a loadable module.


Arnd Bergmann (1):
  drm/sun4i: link in front-end code if needed

 drivers/gpu/drm/sun4i/Makefile | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: More drm-panel help volunteers?

[Daniel Vetter]

On Wed, Jul 11, 2018 at 08:07:26PM +0200, Daniel Vetter wrote:
> Hi all,
> 
> I chatted a bit with Thierry about drm-panel, and state of things
> still seems to be that when Thierry's on vacations/leave/busy patches
> don't move. So I looked at people with a few patches who could be
> volunteered to sometimes help out with review&merging:
> 
> 31  Thierry Reding
> 16  Philipp Zabel
> 11  Lucas Stach
>  9  Ajay Kumar
>  9  Alexandre Courbot
>  8  Philippe CORNU
>  6  Boris Brezillon
>  6  Maxime Ripard
>  6  Stefan Agner
>  5  Arnd Bergmann
>  5  Dave Airlie
>  5  Yakir Yang
> 
> There's fairly little patch activity going on in drm/panel, main goal
> would be just to reduce the occasional long waits (recently a
> contributor pinged 3 times or so every few weeks for feedback).
> 
> Philipp Z and Lucas, either of you interested in drm-misc commit
> rights and occasionally scanning for drm-panel patches?
> 
> We also have a pile of people here who already are drm-misc
> committers. Phillippe C., Boris, Maxime, would be awesome if you could
> help out occsasionally? I'd say anyone with drm-misc committer
> experience has more than sufficient judgement to figure out whether to
> push a patch or not.
> 
> Any other ideas?

No one volunteering to help out?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] backlight: adp8860: Mark expected switch fall-through

[Lee Jones]

On Mon, 09 Jul 2018, Gustavo A. R. Silva wrote:

> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
> 
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/video/backlight/adp8860_bl.c | 1 +
>  1 file changed, 1 insertion(+)

Applied, thanks.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[GIT PULL] Immutable branch between MFD and DRM/i915, Media and Platform due for the v4.19 merge window

[Lee Jones]

Enjoy!

The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:

  Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git 
ib-mfd-i915-media-platform-v4.19

for you to fetch changes up to cd70de2d356ee692477276bd5d6bc88c71a48733:

  media: platform: Add ChromeOS EC CEC driver (2018-07-13 08:44:46 +0100)


Immutable branch between MFD and DRM/i915, Media and Platform due for the v4.19 
merge window


Neil Armstrong (6):
  media: cec-notifier: Get notifier by device and connector name
  drm/i915: hdmi: add CEC notifier to intel_hdmi
  mfd: cros-ec: Increase maximum mkbp event size
  mfd: cros-ec: Introduce CEC commands and events definitions.
  mfd: cros_ec_dev: Add CEC sub-device registration
  media: platform: Add ChromeOS EC CEC driver

 drivers/gpu/drm/i915/Kconfig |   1 +
 drivers/gpu/drm/i915/intel_display.h |  24 ++
 drivers/gpu/drm/i915/intel_drv.h |   2 +
 drivers/gpu/drm/i915/intel_hdmi.c|  13 +
 drivers/media/cec/cec-notifier.c |  11 +-
 drivers/media/platform/Kconfig   |  11 +
 drivers/media/platform/Makefile  |   2 +
 drivers/media/platform/cros-ec-cec/Makefile  |   1 +
 drivers/media/platform/cros-ec-cec/cros-ec-cec.c | 347 +++
 drivers/mfd/cros_ec_dev.c|  16 ++
 drivers/platform/chrome/cros_ec_proto.c  |  40 ++-
 include/linux/mfd/cros_ec.h  |   2 +-
 include/linux/mfd/cros_ec_commands.h |  97 +++
 include/media/cec-notifier.h |  27 +-
 14 files changed, 578 insertions(+), 16 deletions(-)
 create mode 100644 drivers/media/platform/cros-ec-cec/Makefile
 create mode 100644 drivers/media/platform/cros-ec-cec/cros-ec-cec.c

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 107082] With 4.18 rc kernel stop working video output on AMD GPU Vega 56

[bugzilla-daemon]

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

--- Comment #5 from Michel Dänzer  ---
(In reply to mikhail.v.gavrilov from comment #4)
> The first that I did not like was that on the first monitor which was
> connected via DisplayPort, the scaling setting was reset from 200% to 100%.

Sounds like a GNOME issue. The kernel driver doesn't do any implicit scaling,
it's all up to userspace.

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

[Bug 107213] [amdgpu/DisplayPort] KDE Wayland session is segfaulting right after login

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 CC||harry.wentl...@amd.com

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

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

[PATCH 1/2] ALSA: HDA: use PCI_BASE_CLASS_DISPLAY to cover more display adapters

[Jim Qu]

Signed-off-by: Jim Qu 
---
 sound/pci/hda/hda_intel.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 1ae1850..e0064567 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -31,7 +31,7 @@
  *  CHANGES:
  *
  *  2004.12.01 Major rewrite by tiwai, merged the work of pshou
- * 
+ *
  */
 
 #include 
@@ -390,8 +390,8 @@ static char *driver_short_names[] = {
[AZX_DRIVER_SIS] = "HDA SIS966",
[AZX_DRIVER_ULI] = "HDA ULI M5461",
[AZX_DRIVER_NVIDIA] = "HDA NVidia",
-   [AZX_DRIVER_TERA] = "HDA Teradici", 
-   [AZX_DRIVER_CTX] = "HDA Creative", 
+   [AZX_DRIVER_TERA] = "HDA Teradici",
+   [AZX_DRIVER_CTX] = "HDA Creative",
[AZX_DRIVER_CTHDA] = "HDA Creative",
[AZX_DRIVER_CMEDIA] = "HDA C-Media",
[AZX_DRIVER_GENERIC] = "HD-Audio Generic",
@@ -1429,7 +1429,7 @@ static struct pci_dev *get_bound_vga(struct pci_dev *pci)
p = pci_get_domain_bus_and_slot(pci_domain_nr(pci->bus),
pci->bus->number, 0);
if (p) {
-   if ((p->class >> 8) == PCI_CLASS_DISPLAY_VGA)
+   if ((p->class >> 16) == PCI_BASE_CLASS_DISPLAY)
return p;
pci_dev_put(p);
}
-- 
2.7.4

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

[PATCH 2/2] vgaswitchreoo: set audio client id in vgaswitchreoo enable function

[Jim Qu]

On modern laptop, there are more and more platforms
have two GPUs, and each of them maybe have audio codec
for HDMP/DP output. For some dGPU which is no output,
audio codec usually is disabled.

In currect HDA audio driver, it will set all codec as
VGA_SWITCHEROO_DIS, the audio which is binded to UMA
will be suspended if user use debugfs to contorl power

In HDA driver side, it is difficult to know which GPU
the audio has binded to. So set the bound gpu pci dev
to vgaswitchroo, the correct audio id will be set in
vgaswitchreoo enable function.

Signed-off-by: Jim Qu 
---
 drivers/gpu/vga/vga_switcheroo.c | 37 +++--
 include/linux/vga_switcheroo.h   |  8 
 sound/pci/hda/hda_intel.c| 11 ++-
 3 files changed, 37 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/vga/vga_switcheroo.c b/drivers/gpu/vga/vga_switcheroo.c
index fc4adf3..a6fd4f5 100644
--- a/drivers/gpu/vga/vga_switcheroo.c
+++ b/drivers/gpu/vga/vga_switcheroo.c
@@ -103,6 +103,7 @@
  * runtime pm. If true, writing ON and OFF to the vga_switcheroo debugfs
  * interface is a no-op so as not to interfere with runtime pm
  * @list: client list
+ * @vga_dev: pci device, indicate which GPU is bound to current audio client
  *
  * Registered client. A client can be either a GPU or an audio device on a GPU.
  * For audio clients, the @fb_info and @active members are bogus.
@@ -116,6 +117,7 @@ struct vga_switcheroo_client {
bool active;
bool driver_power_control;
struct list_head list;
+   struct pci_dev *vga_dev;
 };
 
 /*
@@ -161,9 +163,8 @@ struct vgasr_priv {
 };
 
 #define ID_BIT_AUDIO   0x100
-#define client_is_audio(c) ((c)->id & ID_BIT_AUDIO)
-#define client_is_vga(c)   ((c)->id == VGA_SWITCHEROO_UNKNOWN_ID || \
-!client_is_audio(c))
+#define client_is_audio(c) ((c)->id & ID_BIT_AUDIO)
+#define client_is_vga(c)   (!client_is_audio(c))
 #define client_id(c)   ((c)->id & ~ID_BIT_AUDIO)
 
 static int vga_switcheroo_debugfs_init(struct vgasr_priv *priv);
@@ -192,14 +193,28 @@ static void vga_switcheroo_enable(void)
vgasr_priv.handler->init();
 
list_for_each_entry(client, &vgasr_priv.clients, list) {
-   if (client->id != VGA_SWITCHEROO_UNKNOWN_ID)
+   if (!client_is_vga(client) || client_id(client) !=
+   VGA_SWITCHEROO_UNKNOWN_ID)
continue;
+
ret = vgasr_priv.handler->get_client_id(client->pdev);
if (ret < 0)
return;
-
client->id = ret;
}
+
+   list_for_each_entry(client, &vgasr_priv.clients, list) {
+   if (!client_is_audio(client) || client_id(client) !=
+   VGA_SWITCHEROO_UNKNOWN_ID)
+   continue;
+
+   ret = vgasr_priv.handler->get_client_id(client->vga_dev);
+   if (ret < 0)
+   return;
+
+   client->id = ret |ID_BIT_AUDIO;
+   }
+
vga_switcheroo_debugfs_init(&vgasr_priv);
vgasr_priv.active = true;
 }
@@ -272,7 +287,8 @@ EXPORT_SYMBOL(vga_switcheroo_handler_flags);
 
 static int register_client(struct pci_dev *pdev,
   const struct vga_switcheroo_client_ops *ops,
-  enum vga_switcheroo_client_id id, bool active,
+  enum vga_switcheroo_client_id id, struct pci_dev 
*vga_dev,
+  bool active,
   bool driver_power_control)
 {
struct vga_switcheroo_client *client;
@@ -287,6 +303,7 @@ static int register_client(struct pci_dev *pdev,
client->id = id;
client->active = active;
client->driver_power_control = driver_power_control;
+   client->vga_dev = vga_dev;
 
mutex_lock(&vgasr_mutex);
list_add_tail(&client->list, &vgasr_priv.clients);
@@ -319,7 +336,7 @@ int vga_switcheroo_register_client(struct pci_dev *pdev,
   const struct vga_switcheroo_client_ops *ops,
   bool driver_power_control)
 {
-   return register_client(pdev, ops, VGA_SWITCHEROO_UNKNOWN_ID,
+   return register_client(pdev, ops, VGA_SWITCHEROO_UNKNOWN_ID, NULL,
   pdev == vga_default_device(),
   driver_power_control);
 }
@@ -329,7 +346,7 @@ EXPORT_SYMBOL(vga_switcheroo_register_client);
  * vga_switcheroo_register_audio_client - register audio client
  * @pdev: client pci device
  * @ops: client callbacks
- * @id: client identifier
+ * @vga_dev:  pci device which is bound to current audio client
  *
  * Register audio client (audio device on a GPU). The client is assumed
  * to use runtime PM. Beforehand, vga_switcheroo_client_probe_defer()
@@ -339,9 +356,10 @@ EXPORT_SYMBOL(vga_switcheroo_register_client);
  */
 int vga_sw

[PATCH] drm/stm: Replace drm_dev_unref with drm_dev_put

[Thomas Zimmermann]

This patch unifies the naming of DRM functions for reference counting
of struct drm_device. The resulting code is more aligned with the rest
of the Linux kernel interfaces.

Signed-off-by: Thomas Zimmermann 
Acked-by: Philippe Cornu 
---
 drivers/gpu/drm/stm/drv.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
index 8698e08313e1..f2021b23554d 100644
--- a/drivers/gpu/drm/stm/drv.c
+++ b/drivers/gpu/drm/stm/drv.c
@@ -148,16 +148,16 @@ static int stm_drm_platform_probe(struct platform_device 
*pdev)
 
ret = drv_load(ddev);
if (ret)
-   goto err_unref;
+   goto err_put;
 
ret = drm_dev_register(ddev, 0);
if (ret)
-   goto err_unref;
+   goto err_put;
 
return 0;
 
-err_unref:
-   drm_dev_unref(ddev);
+err_put:
+   drm_dev_put(ddev);
 
return ret;
 }
@@ -170,7 +170,7 @@ static int stm_drm_platform_remove(struct platform_device 
*pdev)
 
drm_dev_unregister(ddev);
drv_unload(ddev);
-   drm_dev_unref(ddev);
+   drm_dev_put(ddev);
 
return 0;
 }
-- 
2.18.0

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

Re: More drm-panel help volunteers?

[Lucas Stach]

Hi Daniel,

Am Mittwoch, den 11.07.2018, 20:07 +0200 schrieb Daniel Vetter:
> Hi all,
> 
> I chatted a bit with Thierry about drm-panel, and state of things
> still seems to be that when Thierry's on vacations/leave/busy patches
> don't move. So I looked at people with a few patches who could be
> volunteered to sometimes help out with review&merging:
> 
> 31  Thierry Reding
> 16  Philipp Zabel
> 11  Lucas Stach
>  9  Ajay Kumar
>  9  Alexandre Courbot
>  8  Philippe CORNU
>  6  Boris Brezillon
>  6  Maxime Ripard
>  6  Stefan Agner
>  5  Arnd Bergmann
>  5  Dave Airlie
>  5  Yakir Yang
> 
> There's fairly little patch activity going on in drm/panel, main goal
> would be just to reduce the occasional long waits (recently a
> contributor pinged 3 times or so every few weeks for feedback).
> 
> Philipp Z and Lucas, either of you interested in drm-misc commit
> rights and occasionally scanning for drm-panel patches?

Philipp is on vacation right now, so don't expect an quick answer.

I for one already have commit rights to drm-misc (though I haven't used
them yet, as the initial setup overhead has kept me from trying), so if
Thierry needs a hand I could certainly help out a bit.

I don't feel fully qualified to look at the more complex panel stuff,
but at least making sure that simple panel patches don't get stuck
should be okay.

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

Re: [PATCH] drm/sti: Replace drm_dev_unref with drm_dev_put

[Benjamin Gaignard]

2018-07-12 17:26 GMT+02:00 Thomas Zimmermann :
> This patch unifies the naming of DRM functions for reference counting
> of struct drm_device. The resulting code is more aligned with the rest
> of the Linux kernel interfaces.
>
> Signed-off-by: Thomas Zimmermann 
> Acked-by: Benjamin Gaignard 

Applied on drm-misc-next.
Thanks,
Benjamin

> ---
>  drivers/gpu/drm/sti/sti_drv.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
> index 90c46b49c931..832fc43960ee 100644
> --- a/drivers/gpu/drm/sti/sti_drv.c
> +++ b/drivers/gpu/drm/sti/sti_drv.c
> @@ -224,7 +224,7 @@ static int sti_bind(struct device *dev)
>
> ret = sti_init(ddev);
> if (ret)
> -   goto err_drm_dev_unref;
> +   goto err_drm_dev_put;
>
> ret = component_bind_all(ddev->dev, ddev);
> if (ret)
> @@ -248,8 +248,8 @@ static int sti_bind(struct device *dev)
> drm_mode_config_cleanup(ddev);
>  err_cleanup:
> sti_cleanup(ddev);
> -err_drm_dev_unref:
> -   drm_dev_unref(ddev);
> +err_drm_dev_put:
> +   drm_dev_put(ddev);
> return ret;
>  }
>
> @@ -259,7 +259,7 @@ static void sti_unbind(struct device *dev)
>
> drm_dev_unregister(ddev);
> sti_cleanup(ddev);
> -   drm_dev_unref(ddev);
> +   drm_dev_put(ddev);
>  }
>
>  static const struct component_master_ops sti_ops = {
> --
> 2.18.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/stm: Replace drm_dev_unref with drm_dev_put

[Benjamin Gaignard]

2018-07-13 10:06 GMT+02:00 Thomas Zimmermann :
> This patch unifies the naming of DRM functions for reference counting
> of struct drm_device. The resulting code is more aligned with the rest
> of the Linux kernel interfaces.
>
> Signed-off-by: Thomas Zimmermann 
> Acked-by: Philippe Cornu 

Applied on drm-misc-next.
Thanks,
Benjamin

> ---
>  drivers/gpu/drm/stm/drv.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c
> index 8698e08313e1..f2021b23554d 100644
> --- a/drivers/gpu/drm/stm/drv.c
> +++ b/drivers/gpu/drm/stm/drv.c
> @@ -148,16 +148,16 @@ static int stm_drm_platform_probe(struct 
> platform_device *pdev)
>
> ret = drv_load(ddev);
> if (ret)
> -   goto err_unref;
> +   goto err_put;
>
> ret = drm_dev_register(ddev, 0);
> if (ret)
> -   goto err_unref;
> +   goto err_put;
>
> return 0;
>
> -err_unref:
> -   drm_dev_unref(ddev);
> +err_put:
> +   drm_dev_put(ddev);
>
> return ret;
>  }
> @@ -170,7 +170,7 @@ static int stm_drm_platform_remove(struct platform_device 
> *pdev)
>
> drm_dev_unregister(ddev);
> drv_unload(ddev);
> -   drm_dev_unref(ddev);
> +   drm_dev_put(ddev);
>
> return 0;
>  }
> --
> 2.18.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/2] ALSA: HDA: use PCI_BASE_CLASS_DISPLAY to cover more display adapters

[Lukas Wunner]

On Fri, Jul 13, 2018 at 04:06:01PM +0800, Jim Qu wrote:
> Signed-off-by: Jim Qu 

Empty commit message.  Please add an explanation why the change is
necessary so folks browsing the git history understand it's motivation.
I think here the motivation is that the PCI class is sometimes
PCI_CLASS_DISPLAY_3D or PCI_CLASS_DISPLAY_OTHER.


> --- a/sound/pci/hda/hda_intel.c
> +++ b/sound/pci/hda/hda_intel.c
> @@ -31,7 +31,7 @@
>   *  CHANGES:
>   *
>   *  2004.12.01   Major rewrite by tiwai, merged the work of pshou
> - * 
> + *

Spurious unrelated change, please get rid of it, this clutters up
the git history unnecessarily.


> @@ -390,8 +390,8 @@ static char *driver_short_names[] = {
>   [AZX_DRIVER_SIS] = "HDA SIS966",
>   [AZX_DRIVER_ULI] = "HDA ULI M5461",
>   [AZX_DRIVER_NVIDIA] = "HDA NVidia",
> - [AZX_DRIVER_TERA] = "HDA Teradici", 
> - [AZX_DRIVER_CTX] = "HDA Creative", 
> + [AZX_DRIVER_TERA] = "HDA Teradici",
> + [AZX_DRIVER_CTX] = "HDA Creative",

Ditto.

Thanks,

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

Re: [alsa-devel] [PATCH 1/2] ALSA: HDA: use PCI_BASE_CLASS_DISPLAY to cover more display adapters

[Takashi Iwai]

On Fri, 13 Jul 2018 10:06:01 +0200,
Jim Qu wrote:
> 
> Signed-off-by: Jim Qu 

More explanations please.  e.g. why is this needed?

The code change itself looks good, but ...

> @@ -31,7 +31,7 @@
>   *  CHANGES:
>   *
>   *  2004.12.01   Major rewrite by tiwai, merged the work of pshou
> - * 
> + *
>   */
>  
>  #include 
> @@ -390,8 +390,8 @@ static char *driver_short_names[] = {
>   [AZX_DRIVER_SIS] = "HDA SIS966",
>   [AZX_DRIVER_ULI] = "HDA ULI M5461",
>   [AZX_DRIVER_NVIDIA] = "HDA NVidia",
> - [AZX_DRIVER_TERA] = "HDA Teradici", 
> - [AZX_DRIVER_CTX] = "HDA Creative", 
> + [AZX_DRIVER_TERA] = "HDA Teradici",
> + [AZX_DRIVER_CTX] = "HDA Creative",
>   [AZX_DRIVER_CTHDA] = "HDA Creative",
>   [AZX_DRIVER_CMEDIA] = "HDA C-Media",
>   [AZX_DRIVER_GENERIC] = "HD-Audio Generic",

These two hunks are utterly irrelevant with the fix.  Please drop
them.


thanks,

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

Re: More drm-panel help volunteers?

[Daniel Vetter]

On Fri, Jul 13, 2018 at 10:09 AM, Lucas Stach  wrote:
> Hi Daniel,
>
> Am Mittwoch, den 11.07.2018, 20:07 +0200 schrieb Daniel Vetter:
>> Hi all,
>>
>> I chatted a bit with Thierry about drm-panel, and state of things
>> still seems to be that when Thierry's on vacations/leave/busy patches
>> don't move. So I looked at people with a few patches who could be
>> volunteered to sometimes help out with review&merging:
>>
>> 31  Thierry Reding
>> 16  Philipp Zabel
>> 11  Lucas Stach
>>  9  Ajay Kumar
>>  9  Alexandre Courbot
>>  8  Philippe CORNU
>>  6  Boris Brezillon
>>  6  Maxime Ripard
>>  6  Stefan Agner
>>  5  Arnd Bergmann
>>  5  Dave Airlie
>>  5  Yakir Yang
>>
>> There's fairly little patch activity going on in drm/panel, main goal
>> would be just to reduce the occasional long waits (recently a
>> contributor pinged 3 times or so every few weeks for feedback).
>>
>> Philipp Z and Lucas, either of you interested in drm-misc commit
>> rights and occasionally scanning for drm-panel patches?
>
> Philipp is on vacation right now, so don't expect an quick answer.
>
> I for one already have commit rights to drm-misc (though I haven't used
> them yet, as the initial setup overhead has kept me from trying), so if
> Thierry needs a hand I could certainly help out a bit.

Oh right, somehow didn't find you in the committer list when I wrote
this mail ... must have been blind :-)

> I don't feel fully qualified to look at the more complex panel stuff,
> but at least making sure that simple panel patches don't get stuck
> should be okay.

Yes I think just taking care of the simpler panel patches (after they
have the DT ack from Rob Herring or some other DT expert) would be
great. And if Philipp wants to help to too when he's back we can fix
him up with commit rights. I'll be away for the next 3 weeks, but
Sean/Maarten/Gustavo should be around ...

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

Re: [alsa-devel] [PATCH 2/2] vgaswitchreoo: set audio client id in vgaswitchreoo enable function

[Takashi Iwai]

On Fri, 13 Jul 2018 10:06:02 +0200,
Jim Qu wrote:
> 
> On modern laptop, there are more and more platforms
> have two GPUs, and each of them maybe have audio codec
> for HDMP/DP output. For some dGPU which is no output,
> audio codec usually is disabled.
> 
> In currect HDA audio driver, it will set all codec as
> VGA_SWITCHEROO_DIS, the audio which is binded to UMA
> will be suspended if user use debugfs to contorl power
> 
> In HDA driver side, it is difficult to know which GPU
> the audio has binded to. So set the bound gpu pci dev
> to vgaswitchroo, the correct audio id will be set in
> vgaswitchreoo enable function.
> 
> Signed-off-by: Jim Qu 

The idea looks good to me.  Just a nitpick:

> @@ -1319,15 +1319,16 @@ static const struct vga_switcheroo_client_ops 
> azx_vs_ops = {
>  static int register_vga_switcheroo(struct azx *chip)
>  {
>   struct hda_intel *hda = container_of(chip, struct hda_intel, chip);
> + struct pci_dev * p;
>   int err;
>  
>   if (!hda->use_vga_switcheroo)
>   return 0;
> - /* FIXME: currently only handling DIS controller
> -  * is there any machine with two switchable HDMI audio controllers?
> -  */
> - err = vga_switcheroo_register_audio_client(chip->pci, &azx_vs_ops,
> -VGA_SWITCHEROO_DIS);
> +
> + p  = get_bound_vga(chip->pci);
> + err = vga_switcheroo_register_audio_client(chip->pci, &azx_vs_ops, p);
> + if (p)
> + pci_dev_put(p);

Passing a NULL vga_dev won't work, so the NULL check after calling
vga_switcheroo_register_audio_client() is moot.  If any, it should be
checked before that.


thanks,

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

[PATCH] drm/hisilicon: Replace drm_dev_unref with drm_dev_put

[Thomas Zimmermann]

This patch unifies the naming of DRM functions for reference counting
of struct drm_device. The resulting code is more aligned with the rest
of the Linux kernel interfaces.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 4 ++--
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 8 
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c 
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
index d4f6f1f9df5b..ec878c7e3f75 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
@@ -387,7 +387,7 @@ static int hibmc_pci_probe(struct pci_dev *pdev,
 err_disable:
pci_disable_device(pdev);
 err_free:
-   drm_dev_unref(dev);
+   drm_dev_put(dev);
 
return ret;
 }
@@ -398,7 +398,7 @@ static void hibmc_pci_remove(struct pci_dev *pdev)
 
drm_dev_unregister(dev);
hibmc_unload(dev);
-   drm_dev_unref(dev);
+   drm_dev_put(dev);
 }
 
 static struct pci_device_id hibmc_pci_table[] = {
diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c 
b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
index ddb0403f1975..e6a62d5a00a3 100644
--- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
+++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
@@ -193,7 +193,7 @@ static int kirin_drm_bind(struct device *dev)
 
ret = kirin_drm_kms_init(drm_dev);
if (ret)
-   goto err_drm_dev_unref;
+   goto err_drm_dev_put;
 
ret = drm_dev_register(drm_dev, 0);
if (ret)
@@ -203,8 +203,8 @@ static int kirin_drm_bind(struct device *dev)
 
 err_kms_cleanup:
kirin_drm_kms_cleanup(drm_dev);
-err_drm_dev_unref:
-   drm_dev_unref(drm_dev);
+err_drm_dev_put:
+   drm_dev_put(drm_dev);
 
return ret;
 }
@@ -215,7 +215,7 @@ static void kirin_drm_unbind(struct device *dev)
 
drm_dev_unregister(drm_dev);
kirin_drm_kms_cleanup(drm_dev);
-   drm_dev_unref(drm_dev);
+   drm_dev_put(drm_dev);
 }
 
 static const struct component_master_ops kirin_drm_ops = {
-- 
2.18.0

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

[Bug 107082] With 4.18 rc kernel stop working video output on AMD GPU Vega 56

[bugzilla-daemon]

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

--- Comment #6 from mikhail.v.gavri...@gmail.com ---
(In reply to Michel Dänzer from comment #5)
> 
> Sounds like a GNOME issue. The kernel driver doesn't do any implicit
> scaling, it's all up to userspace.

I don't believe that sshd can hang because of gnome-shell bug.

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

[Bug 107082] With 4.18 rc kernel stop working video output on AMD GPU Vega 56

[bugzilla-daemon]

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

--- Comment #7 from Michel Dänzer  ---
(In reply to mikhail.v.gavrilov from comment #6)
> I don't believe that sshd can hang because of gnome-shell bug.

Sure, I'm only talking about the scaling reset.

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

Re: [PATCH 2/2] vgaswitchreoo: set audio client id in vgaswitchreoo enable function

[Lukas Wunner]

On Fri, Jul 13, 2018 at 04:06:02PM +0800, Jim Qu wrote:
> On modern laptop, there are more and more platforms
> have two GPUs, and each of them maybe have audio codec
> for HDMP/DP output. For some dGPU which is no output,
> audio codec usually is disabled.
> 
> In currect HDA audio driver, it will set all codec as
> VGA_SWITCHEROO_DIS, the audio which is binded to UMA
> will be suspended if user use debugfs to contorl power
> 
> In HDA driver side, it is difficult to know which GPU
> the audio has binded to. So set the bound gpu pci dev
> to vgaswitchroo, the correct audio id will be set in
> vgaswitchreoo enable function.
> 
> Signed-off-by: Jim Qu 

The approach you've taken in this patch won't work if the HDA controller
is bound to a driver after both GPUs have already been bound to a driver
and the handler has already been registered.

That's because vga_switcheroo_enable() is run when two GPUs have registered
as clients and the handler has also registered.  If the HDA controller is
probed afterwards, its ID will be stuck at VGA_SWITCHEROO_UNKNOWN_ID.

Before resubmitting this patch, please run it through scripts/checkpatch.pl,
there are multiple trivial issues here.

Also, please use scripts/get_maintainers.pl on all files you're touching
and cc the patch to the listed maintainers and reviewers.


> @@ -161,9 +163,8 @@ struct vgasr_priv {
>  };
>  
>  #define ID_BIT_AUDIO 0x100
> -#define client_is_audio(c)   ((c)->id & ID_BIT_AUDIO)
> -#define client_is_vga(c) ((c)->id == VGA_SWITCHEROO_UNKNOWN_ID || \
> -  !client_is_audio(c))
> +#define client_is_audio(c)   ((c)->id & ID_BIT_AUDIO)
> +#define client_is_vga(c) (!client_is_audio(c))
>  #define client_id(c) ((c)->id & ~ID_BIT_AUDIO)

There's a spurious whitespace change in the client_is_audio() line,
please get rid of it.


> --- a/include/linux/vga_switcheroo.h
> +++ b/include/linux/vga_switcheroo.h
> @@ -84,8 +84,8 @@ enum vga_switcheroo_state {
>   * Client identifier. Audio clients use the same identifier & 0x100.
>   */
>  enum vga_switcheroo_client_id {
> - VGA_SWITCHEROO_UNKNOWN_ID = -1,
> - VGA_SWITCHEROO_IGD,
> + VGA_SWITCHEROO_UNKNOWN_ID = 0x1000,
> + VGA_SWITCHEROO_IGD = 0,

Hm, why is this change necessary?


Thanks,

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

Re: [alsa-devel] [PATCH 1/2] ALSA: HDA: use PCI_BASE_CLASS_DISPLAY to cover more display adapters

[Qu, Jim]

See comments in line

thanks
JimQu

获取 Outlook for Android



发件人: Takashi Iwai
发送时间: 7月13日星期五 16:33
主题: Re: [alsa-devel] [PATCH 1/2] ALSA: HDA: use PCI_BASE_CLASS_DISPLAY tocover 
more display adapters
收件人: Qu, Jim
抄送: alsa-de...@alsa-project.org, dri-devel@lists.freedesktop.org, 
amd-...@lists.freedesktop.org


On Fri, 13 Jul 2018 10:06:01 +0200, Jim Qu wrote: > > Signed-off-by: Jim Qu 
More explanations please. e.g. why is this needed? The code change itself looks 
good, but ... > @@ -31,7 +31,7 @@ > * CHANGES: > * > * 2004.12.01 Major rewrite 
by tiwai, merged the work of pshou > - * > + * > */ > > #include > @@ -390,8 
+390,8 @@ static char *driver_short_names[] = { > [AZX_DRIVER_SIS] = "HDA 
SIS966", > [AZX_DRIVER_ULI] = "HDA ULI M5461", > [AZX_DRIVER_NVIDIA] = "HDA 
NVidia", > - [AZX_DRIVER_TERA] = "HDA Teradici", > - [AZX_DRIVER_CTX] = "HDA 
Creative", > + [AZX_DRIVER_TERA] = "HDA Teradici", > + [AZX_DRIVER_CTX] = "HDA 
Creative", > [AZX_DRIVER_CTHDA] = "HDA Creative", > [AZX_DRIVER_CMEDIA] = "HDA 
C-Media", > [AZX_DRIVER_GENERIC] = "HD-Audio Generic", These two hunks are 
utterly irrelevant with the fix. Please drop them.

Jim: Yeah, I forget to generate a new one. I will delete them when push the 
patch.

thanks, Takashi

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

[Bug 87738] [OpenCL] Please add Image support

[bugzilla-daemon]

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

--- Comment #4 from Vasilis LIaskovitis  ---
I see there are clover patches for image support already upstream e.g.

f2c52e392 clover: Implement CL1.2 clCreateImage().
2518645f6 clover: Implement clCreateImage?D w/ clCreateImage.

What is missing? Driver-specific patches for radeonsi / r600? Any
pointers/guidance would be welcome.

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

Re: [PATCH 02/12] blk: use for_each_if

[Vlastimil Babka]

On 07/12/2018 08:45 AM, Joe Perches wrote:
> On Wed, 2018-07-11 at 20:50 +0200, Daniel Vetter wrote:
>> On Wed, Jul 11, 2018 at 8:30 PM, Jens Axboe  wrote:
>>> On 7/11/18 10:45 AM, Tejun Heo wrote:
 On Wed, Jul 11, 2018 at 09:40:58AM -0700, Tejun Heo wrote:
> On Mon, Jul 09, 2018 at 10:36:40AM +0200, Daniel Vetter wrote:
>> Makes the macros resilient against if {} else {} blocks right
>> afterwards.
>>
>> Signed-off-by: Daniel Vetter 
>> Cc: Tejun Heo 
>> Cc: Jens Axboe 
>> Cc: Shaohua Li 
>> Cc: Kate Stewart 
>> Cc: Greg Kroah-Hartman 
>> Cc: Joseph Qi 
>> Cc: Daniel Vetter 
>> Cc: Arnd Bergmann 
>
> Acked-by: Tejun Heo 
>
> Jens, it'd probably be best to route this through block tree.

 Oops, this requires an earlier patch to move the for_each_if def to a
 common header and should be routed together.
>>>
>>> Yeah, this is a problem with the submission.
>>>
>>> Always (ALWAYS) CC folks on at least the cover letter and generic
>>> earlier patches. Getting just one patch sent like this is mostly
>>> useless, and causes more harm than good.
>>
>> Ime sending a patch with more than 20 or so recipients means it gets
>> stuck everywhere in moderation queues. Or outright spam filters. I
>> thought the correct way to do this is to cc: mailing lists (lkml has
>> them all), but apparently that's not how it's done. Despite that all
>> the patch series I get never have the cover letter addressed to me
>> either.
>>
>> So what's the magic way to make this possible?
> 
> Jens' advice is crap.

This statement was rather offensive and totally uncalled for, AFAICS.
Why did you write it like that?

> There is no generic way to make this possible.
> 
> BCC's don't work, series that touch multiple subsystems
> get rejected when the recipient list is too large.

I don't know what's the usual limit for recipient list, probably never
hit it myself, but for series that are not so large, I use this approach
to make sure the cover letter is CC'd to everyone that's CC'd in any
patch in the series:

- add per-patch Cc:'s to the git commit logs
- clear out *.patch from the working dir
- git format-patch --cover-letter ...
- edit cover letter
- git send-email ... --cc-cmd=./cc.sh ...

where cc.sh contains this:

#/bin/sh
if [[ $1 == *cover-letter* ]]; then
grep '<.*@.*>' -h *.patch | sed 's/^.*: //' | sort | uniq
else
grep '<.*@.*>' -h $1 | sed 's/^.*: //' | sort | uniq
fi

That proceses all tags besides Cc (acked-by, reported-by etc) and turns
them to Cc's for each patch (or does git now do that by itself as well?)
and for cover letter, it accumulates that from all the patches.

Vlastimil

> I think you did it correctly.
> 

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

[Bug 107183] Enabling Glamor takes half a second

[bugzilla-daemon]

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

Paul Menzel  changed:

   What|Removed |Added

Product|DRI |xorg
Version|XOrg git|git
 QA Contact||xorg-t...@lists.x.org
   Assignee|dri-devel@lists.freedesktop |xorg-t...@lists.x.org
   |.org|
  Component|DRM/Radeon  |Server/General

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

[PATCH v2 2/2] drm/scheduler: modify args of drm_sched_entity_init

[Nayan Deshmukh]

replace run queue by a list of run queues and remove the
sched arg as that is part of run queue itself

Signed-off-by: Nayan Deshmukh 
Reviewed-by: Christian König 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c   |  4 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c   |  3 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c   |  4 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c   |  3 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c|  3 +--
 drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c |  4 ++--
 drivers/gpu/drm/amd/amdgpu/uvd_v7_0.c |  4 ++--
 drivers/gpu/drm/etnaviv/etnaviv_drv.c |  8 
 drivers/gpu/drm/scheduler/gpu_scheduler.c | 20 
 drivers/gpu/drm/v3d/v3d_drv.c |  7 +++
 include/drm/gpu_scheduler.h   |  6 +++---
 11 files changed, 33 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
index 0120b24fae1b..83e3b320a793 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c
@@ -90,8 +90,8 @@ static int amdgpu_ctx_init(struct amdgpu_device *adev,
if (ring == &adev->gfx.kiq.ring)
continue;
 
-   r = drm_sched_entity_init(&ring->sched, &ctx->rings[i].entity,
- rq, &ctx->guilty);
+   r = drm_sched_entity_init(&ctx->rings[i].entity,
+ &rq, 1, &ctx->guilty);
if (r)
goto failed;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 0246cb87d9e4..360d6b82c3c7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -140,8 +140,7 @@ static int amdgpu_ttm_global_init(struct amdgpu_device 
*adev)
 
ring = adev->mman.buffer_funcs_ring;
rq = &ring->sched.sched_rq[DRM_SCHED_PRIORITY_KERNEL];
-   r = drm_sched_entity_init(&ring->sched, &adev->mman.entity,
- rq, NULL);
+   r = drm_sched_entity_init(&adev->mman.entity, &rq, 1, NULL);
if (r) {
DRM_ERROR("Failed setting up TTM BO move run queue.\n");
goto error_entity;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
index 0b46ea1c6290..0d8c57fc3d09 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c
@@ -266,8 +266,8 @@ int amdgpu_uvd_sw_init(struct amdgpu_device *adev)
 
ring = &adev->uvd.inst[j].ring;
rq = &ring->sched.sched_rq[DRM_SCHED_PRIORITY_NORMAL];
-   r = drm_sched_entity_init(&ring->sched, 
&adev->uvd.inst[j].entity,
- rq, NULL);
+   r = drm_sched_entity_init(&adev->uvd.inst[j].entity, &rq,
+ 1, NULL);
if (r != 0) {
DRM_ERROR("Failed setting up UVD(%d) run queue.\n", j);
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
index b0dcdfd85f5b..c0790e4c5454 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c
@@ -190,8 +190,7 @@ int amdgpu_vce_sw_init(struct amdgpu_device *adev, unsigned 
long size)
 
ring = &adev->vce.ring[0];
rq = &ring->sched.sched_rq[DRM_SCHED_PRIORITY_NORMAL];
-   r = drm_sched_entity_init(&ring->sched, &adev->vce.entity,
- rq, NULL);
+   r = drm_sched_entity_init(&adev->vce.entity, &rq, 1, NULL);
if (r != 0) {
DRM_ERROR("Failed setting up VCE run queue.\n");
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 712af5c1a5d6..fb7da0740ad8 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -2562,8 +2562,7 @@ int amdgpu_vm_init(struct amdgpu_device *adev, struct 
amdgpu_vm *vm,
ring_instance %= adev->vm_manager.vm_pte_num_rings;
ring = adev->vm_manager.vm_pte_rings[ring_instance];
rq = &ring->sched.sched_rq[DRM_SCHED_PRIORITY_KERNEL];
-   r = drm_sched_entity_init(&ring->sched, &vm->entity,
- rq, NULL);
+   r = drm_sched_entity_init(&vm->entity, &rq, 1, NULL);
if (r)
return r;
 
diff --git a/drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c 
b/drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c
index 8ee1c2eaaa14..da38aa2f3d13 100644
--- a/drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c
@@ -429,8 +429,8 @@ static int uvd_v6_0_sw_init(void *handle)
struct drm_sched_rq *rq;
ring = &adev->uvd.inst->ring_enc[0];
rq = &ring->sched.sched_rq[DRM_SCHED_PRIORITY_NORMAL];
-   r =

[PATCH v2 1/2] drm/scheduler: add a pointer to scheduler in the rq

[Nayan Deshmukh]

This patch is in preparation for a better load balancing in
scheduler. It allows us to associate entities with the
run queues instead of binding them to a scheduler.

Signed-off-by: Nayan Deshmukh 
---
 drivers/gpu/drm/scheduler/gpu_scheduler.c | 6 --
 include/drm/gpu_scheduler.h   | 2 ++
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c 
b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index 7d2560699b84..429b1328653a 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -69,11 +69,13 @@ static void drm_sched_process_job(struct dma_fence *f, 
struct dma_fence_cb *cb);
  *
  * Initializes a scheduler runqueue.
  */
-static void drm_sched_rq_init(struct drm_sched_rq *rq)
+static void drm_sched_rq_init(struct drm_gpu_scheduler *sched,
+ struct drm_sched_rq *rq)
 {
spin_lock_init(&rq->lock);
INIT_LIST_HEAD(&rq->entities);
rq->current_entity = NULL;
+   rq->sched = sched;
 }
 
 /**
@@ -926,7 +928,7 @@ int drm_sched_init(struct drm_gpu_scheduler *sched,
sched->timeout = timeout;
sched->hang_limit = hang_limit;
for (i = DRM_SCHED_PRIORITY_MIN; i < DRM_SCHED_PRIORITY_MAX; i++)
-   drm_sched_rq_init(&sched->sched_rq[i]);
+   drm_sched_rq_init(sched, &sched->sched_rq[i]);
 
init_waitqueue_head(&sched->wake_up_worker);
init_waitqueue_head(&sched->job_scheduled);
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index 4214ceb71c05..43e93d6077cf 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -93,6 +93,7 @@ struct drm_sched_entity {
  * struct drm_sched_rq - queue of entities to be scheduled.
  *
  * @lock: to modify the entities list.
+ * @sched: the scheduler to which this rq belongs to.
  * @entities: list of the entities to be scheduled.
  * @current_entity: the entity which is to be scheduled.
  *
@@ -102,6 +103,7 @@ struct drm_sched_entity {
  */
 struct drm_sched_rq {
spinlock_t  lock;
+   struct drm_gpu_scheduler*sched;
struct list_headentities;
struct drm_sched_entity *current_entity;
 };
-- 
2.14.3

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

Re: [PATCH v2] drm/client: Fix double free in error path

[Noralf Trønnes]

Den 12.07.2018 17.04, skrev Noralf Trønnes:

This fixes a static checker warning:

drivers/gpu/drm/drm_client.c:289 drm_client_buffer_create()
error: double free of 'buffer'

Extend drm_client_buffer_delete() to handle the case when there's no
dumb buffer attached and drop the extra kfree.

Fixes: c76f0f7cb546 ("drm: Begin an API for in-kernel clients")
Reported-by: Dan Carpenter 
Cc: Daniel Vetter 
Signed-off-by: Noralf Trønnes 
Reviewed-by: Daniel Vetter 
---

Changes since version 1:
- Let drm_client_buffer_delete() handle all freeing (Daniel Vetter)


Applied, thanks for review and an improved solution.

Noralf.


  drivers/gpu/drm/drm_client.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index 9b142f58d489..baff50a4c234 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -218,7 +218,9 @@ static void drm_client_buffer_delete(struct 
drm_client_buffer *buffer)
if (buffer->gem)
drm_gem_object_put_unlocked(buffer->gem);
  
-	drm_mode_destroy_dumb(dev, buffer->handle, buffer->client->file);

+   if (buffer->handle)
+   drm_mode_destroy_dumb(dev, buffer->handle, 
buffer->client->file);
+
kfree(buffer);
  }
  
@@ -243,7 +245,7 @@ drm_client_buffer_create(struct drm_client_dev *client, u32 width, u32 height, u

dumb_args.bpp = drm_format_plane_cpp(format, 0) * 8;
ret = drm_mode_create_dumb(dev, &dumb_args, client->file);
if (ret)
-   goto err_free;
+   goto err_delete;
  
  	buffer->handle = dumb_args.handle;

buffer->pitch = dumb_args.pitch;
@@ -276,8 +278,6 @@ drm_client_buffer_create(struct drm_client_dev *client, u32 
width, u32 height, u
  
  err_delete:

drm_client_buffer_delete(buffer);
-err_free:
-   kfree(buffer);
  
  	return ERR_PTR(ret);

  }


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

Re: [PATCH v4 02/11] media: vsp1: Remove packed attributes from aligned structures

[Kieran Bingham]

Hi Laurent,

On 24/05/18 11:47, Laurent Pinchart wrote:
> Hi Kieran,
> 
> Thank you for the patch.
> 
> On Thursday, 3 May 2018 16:36:13 EEST Kieran Bingham wrote:
>> The use of the packed attribute can cause a performance penalty for
>> all accesses to the struct members, as the compiler will assume that the
>> structure has the potential to have an unaligned base.
>>
>> These structures are all correctly aligned and contain no holes, thus
>> the attribute is redundant and negatively impacts performance, so we
>> remove the attributes entirely.
> 
> With gcc 6.4.0 this patch makes no difference on the generated object. Is it 
> worth it ?

This patch has certainly either enlightened me, or confused me about
this topic - as I had in the past used the packed attribute as here to
define that we don't want holes. (just as this existing code does)

As the documentation seems to determine that this isn't the effect of
this attribute, and removing it has no effect - I suspect removing it is
the right thing to do, as otherwise we are simply mis-using the
construct for no purpose.

It's up to though. Drop or accept as you feel is right.

> 
>> Signed-off-by: Kieran Bingham 
> 
> You forget to pick Geert's review tag.

Ah yes, Collected thanks

--
Regards

Kieran


> 
>> ---
>> v2
>>  - Remove attributes entirely
>> ---
>>  drivers/media/platform/vsp1/vsp1_dl.c | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
>> b/drivers/media/platform/vsp1/vsp1_dl.c index c7fa1cb088cd..f4cede9b9b43
>> 100644
>> --- a/drivers/media/platform/vsp1/vsp1_dl.c
>> +++ b/drivers/media/platform/vsp1/vsp1_dl.c
>> @@ -25,19 +25,19 @@
>>  struct vsp1_dl_header_list {
>>  u32 num_bytes;
>>  u32 addr;
>> -} __attribute__((__packed__));
>> +};
>>
>>  struct vsp1_dl_header {
>>  u32 num_lists;
>>  struct vsp1_dl_header_list lists[8];
>>  u32 next_header;
>>  u32 flags;
>> -} __attribute__((__packed__));
>> +};
>>
>>  struct vsp1_dl_entry {
>>  u32 addr;
>>  u32 data;
>> -} __attribute__((__packed__));
>> +};
>>
>>  /**
>>   * struct vsp1_dl_body - Display list body
> 

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

Re: [PATCH] drm: mxsfb: fix runtime PM handling

[Stefan Agner]

On 13.07.2018 11:12, Marek Vasut wrote:
> On 07/13/2018 11:06 AM, Anson Huang wrote:
> [...]
>>>
>>> On 07/13/2018 10:54 AM, Anson Huang wrote:
 As display power domain is combined with lcdif node on some i.MX
 platforms like i.MX6SL, when lcdif driver is enabled, the mxsfb_load
 is called to enable runtime pm, and a pair of pm_runtime_get_sync and
 pm_runtime_put_sync are also called, that will cause generic power
 domain driver to disable lcdif power domain and lcdif is no longer
 working, the lcdif power should ONLY be turned off when display is
 disabled, so move the pm_runtime_put_sync to mxsfb_unload and remove
 the pm_runtime_get_sync in mxsfb_unload as well, in this way, when
 display is enabled, the lcdif power will be always ON until the
 display is disabled.

 Signed-off-by: Anson Huang 
>>>
>>> Doesn't this also mean the block will always be on, thus wasting power ?
>>
>> I think drm driver should have somewhere to implement the display
>> disable case, like when fb0 is blank (echo 1 > 
>> /sys/class/graphics/fb0/blank),
> 
> Isn't this just the fbdev emulation on top of drm/kms ?
> I think this stuff can be compiled out completely.
> 
>> then lcdif can be powered gated, and
>> when display is back on (unblank), lcdif needs to be re-initialization and 
>> display will
>> be on, current implementation is incorrect, with kernel booting up, lcdif
>> is NOT working at all.
> 
> It works fine on MX6SX , so I think this is isolated to MX6SL ?
> I'm CCing Stefan, he might have some valuable feedback here.
> 

Yeah not sure, but putting it in mxsfb_load seems wrong.

MXSFB uses struct drm_simple_display_pipe_funcs which does have
enable/disable callbacks, probably closer to what we want...

--
Stefan

>> The runtime power gating case can be implemented later to save power,
>> need lcdif experts to do it. Thanks.
>>
>> Anson.
>>
>>>
 ---
  drivers/gpu/drm/mxsfb/mxsfb_drv.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

 diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
 b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
 index ffe5137..1ba179b 100644
 --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
 +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
 @@ -235,7 +235,6 @@ static int mxsfb_load(struct drm_device *drm,
 unsigned long flags)

pm_runtime_get_sync(drm->dev);
ret = drm_irq_install(drm, platform_get_irq(pdev, 0));
 -  pm_runtime_put_sync(drm->dev);

if (ret < 0) {
dev_err(drm->dev, "Failed to install IRQ handler\n"); @@ -264,6
 +263,7 @@ static int mxsfb_load(struct drm_device *drm, unsigned long
 flags)
  err_irq:
drm_panel_detach(mxsfb->panel);
  err_vblank:
 +  pm_runtime_put_sync(drm->dev);
pm_runtime_disable(drm->dev);

return ret;
 @@ -279,7 +279,6 @@ static void mxsfb_unload(struct drm_device *drm)
drm_kms_helper_poll_fini(drm);
drm_mode_config_cleanup(drm);

 -  pm_runtime_get_sync(drm->dev);
drm_irq_uninstall(drm);
pm_runtime_put_sync(drm->dev);


>>>
>>>
>>> --
>>> Best regards,
>>> Marek Vasut
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm: mxsfb: fix runtime PM handling

[Stefan Agner]

On 13.07.2018 12:36, Marek Vasut wrote:
> On 07/13/2018 12:33 PM, Stefan Agner wrote:
>> On 13.07.2018 11:12, Marek Vasut wrote:
>>> On 07/13/2018 11:06 AM, Anson Huang wrote:
>>> [...]
>
> On 07/13/2018 10:54 AM, Anson Huang wrote:
>> As display power domain is combined with lcdif node on some i.MX
>> platforms like i.MX6SL, when lcdif driver is enabled, the mxsfb_load
>> is called to enable runtime pm, and a pair of pm_runtime_get_sync and
>> pm_runtime_put_sync are also called, that will cause generic power
>> domain driver to disable lcdif power domain and lcdif is no longer
>> working, the lcdif power should ONLY be turned off when display is
>> disabled, so move the pm_runtime_put_sync to mxsfb_unload and remove
>> the pm_runtime_get_sync in mxsfb_unload as well, in this way, when
>> display is enabled, the lcdif power will be always ON until the
>> display is disabled.
>>
>> Signed-off-by: Anson Huang 
>
> Doesn't this also mean the block will always be on, thus wasting power ?

 I think drm driver should have somewhere to implement the display
 disable case, like when fb0 is blank (echo 1 > 
 /sys/class/graphics/fb0/blank),
>>>
>>> Isn't this just the fbdev emulation on top of drm/kms ?
>>> I think this stuff can be compiled out completely.
>>>
 then lcdif can be powered gated, and
 when display is back on (unblank), lcdif needs to be re-initialization and 
 display will
 be on, current implementation is incorrect, with kernel booting up, lcdif
 is NOT working at all.
>>>
>>> It works fine on MX6SX , so I think this is isolated to MX6SL ?
>>> I'm CCing Stefan, he might have some valuable feedback here.
>>>
>>
>> Yeah not sure, but putting it in mxsfb_load seems wrong.
>>
>> MXSFB uses struct drm_simple_display_pipe_funcs which does have
>> enable/disable callbacks, probably closer to what we want...
> 
> Seems to me like this is not something that should be hacked around in
> the mxsfb driver in the first place, but somewhere else.

By somewhere else you mean in the DRM stack?

Yeah not sure, currently pm seems to be handled on driver level only,
see
grep -r -e pm_runtime_get_sync drivers/gpu/drm

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

Re: [PATCH v4 07/11] media: vsp1: Use header display lists for all WPF outputs linked to the DU

[Kieran Bingham]

On 24/05/18 12:10, Laurent Pinchart wrote:
> Hi Kieran,
> 
> Thank you for the patch.
> 
> On Thursday, 3 May 2018 16:36:18 EEST Kieran Bingham wrote:
>> Header mode display lists are now supported on all WPF outputs. To
>> support extended headers and auto-fld capabilities for interlaced mode
>> handling only header mode display lists can be used.
>>
>> Disable the headerless display list configuration, and remove the dead
>> code.
>>
>> Signed-off-by: Kieran Bingham 
>> ---
>>  drivers/media/platform/vsp1/vsp1_dl.c | 107 ++-
>>  1 file changed, 27 insertions(+), 80 deletions(-)
> 
> I like the diffstat.
> 
>> diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
>> b/drivers/media/platform/vsp1/vsp1_dl.c index fbffbd407b29..56514cd51c51
>> 100644
>> --- a/drivers/media/platform/vsp1/vsp1_dl.c
>> +++ b/drivers/media/platform/vsp1/vsp1_dl.c
>> @@ -94,7 +94,7 @@ struct vsp1_dl_body_pool {
>>   * struct vsp1_dl_list - Display list
>>   * @list: entry in the display list manager lists
>>   * @dlm: the display list manager
>> - * @header: display list header, NULL for headerless lists
>> + * @header: display list header
>>   * @dma: DMA address for the header
>>   * @body0: first display list body
>>   * @bodies: list of extra display list bodies
>> @@ -118,15 +118,9 @@ struct vsp1_dl_list {
>>  bool internal;
>>  };
>>
>> -enum vsp1_dl_mode {
>> -VSP1_DL_MODE_HEADER,
>> -VSP1_DL_MODE_HEADERLESS,
>> -};
>> -
>>  /**
>>   * struct vsp1_dl_manager - Display List manager
>>   * @index: index of the related WPF
>> - * @mode: display list operation mode (header or headerless)
>>   * @singleshot: execute the display list in single-shot mode
>>   * @vsp1: the VSP1 device
>>   * @lock: protects the free, active, queued, and pending lists
>> @@ -138,7 +132,6 @@ enum vsp1_dl_mode {
>>   */
>>  struct vsp1_dl_manager {
>>  unsigned int index;
>> -enum vsp1_dl_mode mode;
>>  bool singleshot;
>>  struct vsp1_device *vsp1;
>>
>> @@ -318,6 +311,7 @@ void vsp1_dl_body_write(struct vsp1_dl_body *dlb, u32
>> reg, u32 data) static struct vsp1_dl_list *vsp1_dl_list_alloc(struct
>> vsp1_dl_manager *dlm) {
>>  struct vsp1_dl_list *dl;
>> +size_t header_offset;
>>
>>  dl = kzalloc(sizeof(*dl), GFP_KERNEL);
>>  if (!dl)
>> @@ -330,16 +324,15 @@ static struct vsp1_dl_list *vsp1_dl_list_alloc(struct
>> vsp1_dl_manager *dlm) dl->body0 = vsp1_dl_body_get(dlm->pool);
>>  if (!dl->body0)
>>  return NULL;
>> -if (dlm->mode == VSP1_DL_MODE_HEADER) {
>> -size_t header_offset = dl->body0->max_entries
>> - * sizeof(*dl->body0->entries);
>>
>> -dl->header = ((void *)dl->body0->entries) + header_offset;
>> -dl->dma = dl->body0->dma + header_offset;
>> +header_offset = dl->body0->max_entries
>> + * sizeof(*dl->body0->entries);
> 
> Nitpicking, please align * under =.

This fits on one line. Moved to a single line instead.

> 
>>
>> -memset(dl->header, 0, sizeof(*dl->header));
>> -dl->header->lists[0].addr = dl->body0->dma;
>> -}
>> +dl->header = ((void *)dl->body0->entries) + header_offset;
>> +dl->dma = dl->body0->dma + header_offset;
>> +
>> +memset(dl->header, 0, sizeof(*dl->header));
>> +dl->header->lists[0].addr = dl->body0->dma;
>>
>>  return dl;
>>  }
>> @@ -471,16 +464,9 @@ struct vsp1_dl_body *vsp1_dl_list_get_body0(struct
>> vsp1_dl_list *dl) *
>>   * The reference must be explicitly released by a call to
>> vsp1_dl_body_put() * when the body isn't needed anymore.
>> - *
>> - * Additional bodies are only usable for display lists in header mode.
>> - * Attempting to add a body to a header-less display list will return an
>> error. */
>>  int vsp1_dl_list_add_body(struct vsp1_dl_list *dl, struct vsp1_dl_body
>> *dlb) {
>> -/* Multi-body lists are only available in header mode. */
>> -if (dl->dlm->mode != VSP1_DL_MODE_HEADER)
>> -return -EINVAL;
>> -
>>  refcount_inc(&dlb->refcnt);
>>
>>  list_add_tail(&dlb->list, &dl->bodies);
>> @@ -501,17 +487,10 @@ int vsp1_dl_list_add_body(struct vsp1_dl_list *dl,
>> struct vsp1_dl_body *dlb) * Adding a display list to a chain passes
>> ownership of the display list to * the head display list item. The chain is
>> released when the head dl item is * put back with __vsp1_dl_list_put().
>> - *
>> - * Chained display lists are only usable in header mode. Attempts to add a
>> - * display list to a chain in header-less mode will return an error.
>>   */
>>  int vsp1_dl_list_add_chain(struct vsp1_dl_list *head,
>> struct vsp1_dl_list *dl)
>>  {
>> -/* Chained lists are only available in header mode. */
>> -if (head->dlm->mode != VSP1_DL_MODE_HEADER)
>> -return -EINVAL;
>> -
>>  head->has_chain = true;
>>  list_add_tail(&dl->chain, &head->chain);
>>  return 0;
>> @@ -579,17 +558,10 @@ static bool vsp1_

Re: [PATCH 1/2] drm/mxsfb: Fix runtime PM for unpowering lcdif block

[Stefan Agner]

On 05.06.2018 19:11, Leonard Crestez wrote:
> Adding imx6sl/sx lcdif nodes in a power domain currently does work, it
> results in black/corrupted screens or hangs. While the driver does
> enable runtime pm it does not deal correctly with the block being
> unpowered.
> 
> Fix by adding pm_runtime_get/put_sync to mxsfb_pipe_enable/disable.
> 
> The mxsfb_plane_atomic_update function can get called before
> mxsfb_pipe_enable while the block is not powered. When this happens the
> write to LCDIF_NEXT_BUF is lost causing random corrupted pixels on
> unblank.
> 
> Fix this by splitting the writing of gem->paddr to nextbuf into a
> mxsfb_update_hw_next_buf functiona and also calling it from
> mxsfb_crtc_mode_set_nofb.
> 
> Also add fields to mxsfb_drv to keep track of enabled/suspended states.
> 
> Signed-off-by: Robert Chiras 
> Signed-off-by: Leonard Crestez 

That patch seems to go in the right direction.

One comment below.

> 
> ---
>  drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 38 +++-
>  drivers/gpu/drm/mxsfb/mxsfb_drv.c  | 72 +-
>  drivers/gpu/drm/mxsfb/mxsfb_drv.h  |  3 ++
>  3 files changed, 100 insertions(+), 13 deletions(-)
> 
> This was initially written by Robert for imx8m but I tested it also
> works on imx6sx/imx6sl to DISPMIX power domain.
> 
> Tested on imx6sl-evk and imx6sx-sdb with SEIKO 43WVF1G panel by
> blanking and unblanking via sysfs and suspend/resume
> 
> Testing requires a modified config (to enable MXFSB_DRM):
> CONFIG_DRM_MXSFB=y
> CONFIG_DRM_PANEL_SEIKO_43WVF1G=y
> CONFIG_FB_MXS=n
> 
> It also requires dts changes to enable the DISPMIX power domain.  The
> dts changes might break drivers so this patch attempts to fix the lcdif
> driver first.
> 
> Patch 2 is a RFC of imx6sl changes, imx6sx is a bit more complicated
> and it also interacts with PCI.
> 
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> index 0abe77675b76..cce2ec1c80ae 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> @@ -194,10 +194,25 @@ static int mxsfb_reset_block(void __iomem *reset_addr)
>   return ret;
>  
>   return clear_poll_bit(reset_addr, MODULE_CLKGATE);
>  }
>  
> +static void mxsfb_update_hw_next_buf(struct mxsfb_drm_private *mxsfb)
> +{
> + struct drm_framebuffer *fb = mxsfb->pipe.plane.state->fb;
> + struct drm_gem_cma_object *gem;
> +
> + if (!fb)
> + return;
> +
> + gem = drm_fb_cma_get_gem_obj(fb, 0);
> + if (!gem)
> + return;
> +
> + writel(gem->paddr, mxsfb->base + mxsfb->devdata->next_buf);
> +}
> +
>  static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb)
>  {
>   struct drm_display_mode *m = &mxsfb->pipe.crtc.state->adjusted_mode;
>   const u32 bus_flags = mxsfb->connector.display_info.bus_flags;
>   u32 vdctrl0, vsync_pulse_len, hsync_pulse_len;
> @@ -268,35 +283,41 @@ static void mxsfb_crtc_mode_set_nofb(struct
> mxsfb_drm_private *mxsfb)
>  mxsfb->base + LCDC_VDCTRL3);
>  
>   writel(SET_DOTCLK_H_VALID_DATA_CNT(m->hdisplay),
>  mxsfb->base + LCDC_VDCTRL4);
>  
> + mxsfb_update_hw_next_buf(mxsfb);
>   mxsfb_disable_axi_clk(mxsfb);
>  }
>  
>  void mxsfb_crtc_enable(struct mxsfb_drm_private *mxsfb)
>  {
> + if (mxsfb->enabled)
> + return;
> +
>   mxsfb_crtc_mode_set_nofb(mxsfb);
>   mxsfb_enable_controller(mxsfb);
> +
> + mxsfb->enabled = true;

Is this state keeping really necessary?

--
Stefan

>  }
>  
>  void mxsfb_crtc_disable(struct mxsfb_drm_private *mxsfb)
>  {
> + if (!mxsfb->enabled)
> + return;
> +
>   mxsfb_disable_controller(mxsfb);
> +
> + mxsfb->enabled = false;
>  }
>  
>  void mxsfb_plane_atomic_update(struct mxsfb_drm_private *mxsfb,
>  struct drm_plane_state *state)
>  {
>   struct drm_simple_display_pipe *pipe = &mxsfb->pipe;
>   struct drm_crtc *crtc = &pipe->crtc;
> - struct drm_framebuffer *fb = pipe->plane.state->fb;
>   struct drm_pending_vblank_event *event;
> - struct drm_gem_cma_object *gem;
> -
> - if (!crtc)
> - return;
>  
>   spin_lock_irq(&crtc->dev->event_lock);
>   event = crtc->state->event;
>   if (event) {
>   crtc->state->event = NULL;
> @@ -307,14 +328,9 @@ void mxsfb_plane_atomic_update(struct
> mxsfb_drm_private *mxsfb,
>   drm_crtc_send_vblank_event(crtc, event);
>   }
>   }
>   spin_unlock_irq(&crtc->dev->event_lock);
>  
> - if (!fb)
> - return;
> -
> - gem = drm_fb_cma_get_gem_obj(fb, 0);
> -
>   mxsfb_enable_axi_clk(mxsfb);
> - writel(gem->paddr, mxsfb->base + mxsfb->devdata->next_buf);
> + mxsfb_update_hw_next_buf(mxsfb);
>   mxsfb_disable_axi_clk(mxsfb);
>  }
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> index 5cae8db9dcd4..c889cac2e275 100644
> ---

Re: [PATCH 1/3 v4] ARM: dts: Modernize the Vexpress PL111 integration

[Robin Murphy]

On 13/07/18 10:50, Sudeep Holla wrote:

It doesn't work. This change is breaking the working CLCD on the models.
I just tested and CLCD driver returns



It even fails to initialize CLCD on my TC2.

clcd-pl11x 1c1f.clcd: PL111 designer 41 rev1 at 0x1c1f
clcd-pl11x: probe of 1c1f.clcd failed with error -2


FWIW the same happens on PB-A8; looks like converting to OF graph 
bindings falls foul of the "panel-dpi" check in clcdfb_of_get_mode().


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

[PATCH] drm/mxsfb: Replace drm_dev_unref with drm_dev_put

[Thomas Zimmermann]

This patch unifies the naming of DRM functions for reference counting
of struct drm_device. The resulting code is more aligned with the rest
of the Linux kernel interfaces.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/mxsfb/mxsfb_drv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c 
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index ffe5137ccaf8..4039f11b2b7b 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -398,7 +398,7 @@ static int mxsfb_probe(struct platform_device *pdev)
 err_unload:
mxsfb_unload(drm);
 err_free:
-   drm_dev_unref(drm);
+   drm_dev_put(drm);
 
return ret;
 }
@@ -409,7 +409,7 @@ static int mxsfb_remove(struct platform_device *pdev)
 
drm_dev_unregister(drm);
mxsfb_unload(drm);
-   drm_dev_unref(drm);
+   drm_dev_put(drm);
 
return 0;
 }
-- 
2.18.0

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

[PATCH] drm/qxl: Replace drm_dev_unref with drm_dev_put

[Thomas Zimmermann]

This patch unifies the naming of DRM functions for reference counting
of struct drm_device. The resulting code is more aligned with the rest
of the Linux kernel interfaces.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/qxl/qxl_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index 2445e75cf7ea..86bd42dca09c 100644
--- a/drivers/gpu/drm/qxl/qxl_drv.c
+++ b/drivers/gpu/drm/qxl/qxl_drv.c
@@ -119,7 +119,7 @@ qxl_pci_remove(struct pci_dev *pdev)
 
dev->dev_private = NULL;
kfree(qdev);
-   drm_dev_unref(dev);
+   drm_dev_put(dev);
 }
 
 static const struct file_operations qxl_fops = {
-- 
2.18.0

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

[Bug 107221] [Intel GFX CI] Plenty of "*ERROR* VCE not responding, trying to reset the ECPU!!!" in dmesg

[bugzilla-daemon]

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

Bug ID: 107221
   Summary: [Intel GFX CI] Plenty of "*ERROR* VCE not responding,
trying to reset the ECPU!!!" in dmesg
   Product: DRI
   Version: DRI git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: martin.pe...@free.fr

Hi,

While running IGT tests on an Intel KBL-g based platform (which apparently has
a VEGAm AMD GPU), we get the following messages in dmesg:

[  225.881278] [drm:vce_v3_0_set_powergating_state [amdgpu]] *ERROR* VCE not
responding, trying to reset the ECPU!!![  22

Here is an example of full logs:
 - boot logs:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_4437/fi-kbl-8809g/boot0.log
 - logs during the execution:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_4437/fi-kbl-8809g/dmesg0.log

Here are more examples of issues:
 -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_4437/fi-kbl-8809g/igt@gem_mmap_...@basic-small-copy-xy.html
 -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_4437/fi-kbl-8809g/igt@gem_mmap_...@basic-wc.html
 -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_4437/fi-kbl-8809g/igt@gem_mmap_...@basic-write-no-prefault.html
 -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_4437/fi-kbl-8809g/igt@gem_pr...@basic.html
 -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_4437/fi-kbl-8809g/igt@gem_ringf...@basic-default-interruptible.html
 -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_4437/fi-kbl-8809g/igt@gem_ringf...@basic-default-forked.html
 -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_4437/fi-kbl-8809g/igt@gem_ringf...@basic-default-hang.html
 -
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_4437/fi-kbl-8809g/igt@gem_mmap_...@basic-small-bo-tiledx.html

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

[Bug 107222] [Intel GFX CI] Many "*ERROR* amdgpu: IB test timed out." messages in dmesg

[bugzilla-daemon]

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

Bug ID: 107222
   Summary: [Intel GFX CI] Many "*ERROR* amdgpu: IB test timed
out." messages in dmesg
   Product: DRI
   Version: DRI git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: martin.pe...@free.fr

On an Intel KBL-g NUC, the AMDGPU driver generates the following error messages
in dmesg while executing some IGT tests:

[  217.635908] [drm:uvd_v6_0_enc_ring_test_ib [amdgpu]] *ERROR* amdgpu: IB test
timed out.
[  217.635962] [drm:amdgpu_ib_ring_tests [amdgpu]] *ERROR* amdgpu: failed
testing IB on ring 14 (-110).

Some links:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_4437/fi-kbl-8809g/igt@gem_mmap_...@basic-copy.html

https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_4441/fi-kbl-8809g/igt@gem_flink_ba...@bad-open.html

https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_4441/fi-kbl-8809g/igt@gem_mmap_...@basic-copy.html

https://intel-gfx-ci.01.org/tree/drm-tip/IGT_4545/fi-kbl-8809g/igt@gem_mmap_...@basic-copy.html

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

[PATCH] drm/msm: rework vblank event handling in dpu_crtc

[Rajesh Yadav]

The vblank on/off calls were missing in dpu_crtc
leading to "driver forgot to call drm_crtc_vblank_off()"
warning while entering suspend state.
Also handle the state update completion event for
a crtc being disabled in current atomic commit.

This patch depends on https://www.spinics.net/lists/dri-devel/msg182402.html

Signed-off-by: Rajesh Yadav 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index d171282..24715e4 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
@@ -1617,6 +1617,7 @@ static void dpu_crtc_disable(struct drm_crtc *crtc)
struct drm_encoder *encoder;
struct msm_drm_private *priv;
int ret;
+   unsigned long flags;
 
if (!crtc || !crtc->dev || !crtc->dev->dev_private || !crtc->state) {
DPU_ERROR("invalid crtc\n");
@@ -1632,6 +1633,9 @@ static void dpu_crtc_disable(struct drm_crtc *crtc)
if (dpu_kms_is_suspend_state(crtc->dev))
_dpu_crtc_set_suspend(crtc, true);
 
+   /* Disable/save vblank irq handling */
+   drm_crtc_vblank_off(crtc);
+
mutex_lock(&dpu_crtc->crtc_lock);
 
/* wait for frame_event_done completion */
@@ -1669,7 +1673,6 @@ static void dpu_crtc_disable(struct drm_crtc *crtc)
dpu_power_handle_unregister_event(dpu_crtc->phandle,
dpu_crtc->power_event);
 
-
memset(dpu_crtc->mixers, 0, sizeof(dpu_crtc->mixers));
dpu_crtc->num_mixers = 0;
dpu_crtc->mixers_swapped = false;
@@ -1679,6 +1682,13 @@ static void dpu_crtc_disable(struct drm_crtc *crtc)
cstate->bw_split_vote = false;
 
mutex_unlock(&dpu_crtc->crtc_lock);
+
+   if (crtc->state->event && !crtc->state->active) {
+   spin_lock_irqsave(&crtc->dev->event_lock, flags);
+   drm_crtc_send_vblank_event(crtc, crtc->state->event);
+   crtc->state->event = NULL;
+   spin_unlock_irqrestore(&crtc->dev->event_lock, flags);
+   }
 }
 
 static void dpu_crtc_enable(struct drm_crtc *crtc,
@@ -1718,6 +1728,9 @@ static void dpu_crtc_enable(struct drm_crtc *crtc,
 
mutex_unlock(&dpu_crtc->crtc_lock);
 
+   /* Enable/restore vblank irq handling */
+   drm_crtc_vblank_on(crtc);
+
dpu_crtc->power_event = dpu_power_handle_register_event(
dpu_crtc->phandle,
DPU_POWER_EVENT_POST_ENABLE | DPU_POWER_EVENT_POST_DISABLE |
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

Re: [PATCH v2 1/2] drm/scheduler: add a pointer to scheduler in the rq

[Nayan Deshmukh]

I forgot to add these:
On Fri, Jul 13, 2018 at 3:21 PM Nayan Deshmukh
 wrote:
>
> This patch is in preparation for a better load balancing in
> scheduler. It allows us to associate entities with the
> run queues instead of binding them to a scheduler.
>
> Signed-off-by: Nayan Deshmukh 
Reviewed-by: Christian König 
Acked-by: Eric Anholt 

> ---
>  drivers/gpu/drm/scheduler/gpu_scheduler.c | 6 --
>  include/drm/gpu_scheduler.h   | 2 ++
>  2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c 
> b/drivers/gpu/drm/scheduler/gpu_scheduler.c
> index 7d2560699b84..429b1328653a 100644
> --- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
> +++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
> @@ -69,11 +69,13 @@ static void drm_sched_process_job(struct dma_fence *f, 
> struct dma_fence_cb *cb);
>   *
>   * Initializes a scheduler runqueue.
>   */
> -static void drm_sched_rq_init(struct drm_sched_rq *rq)
> +static void drm_sched_rq_init(struct drm_gpu_scheduler *sched,
> + struct drm_sched_rq *rq)
>  {
> spin_lock_init(&rq->lock);
> INIT_LIST_HEAD(&rq->entities);
> rq->current_entity = NULL;
> +   rq->sched = sched;
>  }
>
>  /**
> @@ -926,7 +928,7 @@ int drm_sched_init(struct drm_gpu_scheduler *sched,
> sched->timeout = timeout;
> sched->hang_limit = hang_limit;
> for (i = DRM_SCHED_PRIORITY_MIN; i < DRM_SCHED_PRIORITY_MAX; i++)
> -   drm_sched_rq_init(&sched->sched_rq[i]);
> +   drm_sched_rq_init(sched, &sched->sched_rq[i]);
>
> init_waitqueue_head(&sched->wake_up_worker);
> init_waitqueue_head(&sched->job_scheduled);
> diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
> index 4214ceb71c05..43e93d6077cf 100644
> --- a/include/drm/gpu_scheduler.h
> +++ b/include/drm/gpu_scheduler.h
> @@ -93,6 +93,7 @@ struct drm_sched_entity {
>   * struct drm_sched_rq - queue of entities to be scheduled.
>   *
>   * @lock: to modify the entities list.
> + * @sched: the scheduler to which this rq belongs to.
>   * @entities: list of the entities to be scheduled.
>   * @current_entity: the entity which is to be scheduled.
>   *
> @@ -102,6 +103,7 @@ struct drm_sched_entity {
>   */
>  struct drm_sched_rq {
> spinlock_t  lock;
> +   struct drm_gpu_scheduler*sched;
> struct list_headentities;
> struct drm_sched_entity *current_entity;
>  };
> --
> 2.14.3
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/2] drm/scheduler: add a pointer to scheduler in the rq

[Christian König]

Am 13.07.2018 um 15:40 schrieb Nayan Deshmukh:

I forgot to add these:


Not a problem at all. It is actually my job to do this while committing 
the patches.


BTW: I've pushed you patches to amd-staging-drm-next just a few minutes 
ago. Thanks for the help.


I'm preparing quite a cleanup for amdgpu which should make your live 
easier, but still no idea why the scheduler hangs when we try to load 
balance jobs.


Regards,
Christian.


On Fri, Jul 13, 2018 at 3:21 PM Nayan Deshmukh
 wrote:

This patch is in preparation for a better load balancing in
scheduler. It allows us to associate entities with the
run queues instead of binding them to a scheduler.

Signed-off-by: Nayan Deshmukh 

Reviewed-by: Christian König 
Acked-by: Eric Anholt 


---
  drivers/gpu/drm/scheduler/gpu_scheduler.c | 6 --
  include/drm/gpu_scheduler.h   | 2 ++
  2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c 
b/drivers/gpu/drm/scheduler/gpu_scheduler.c
index 7d2560699b84..429b1328653a 100644
--- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
+++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
@@ -69,11 +69,13 @@ static void drm_sched_process_job(struct dma_fence *f, 
struct dma_fence_cb *cb);
   *
   * Initializes a scheduler runqueue.
   */
-static void drm_sched_rq_init(struct drm_sched_rq *rq)
+static void drm_sched_rq_init(struct drm_gpu_scheduler *sched,
+ struct drm_sched_rq *rq)
  {
 spin_lock_init(&rq->lock);
 INIT_LIST_HEAD(&rq->entities);
 rq->current_entity = NULL;
+   rq->sched = sched;
  }

  /**
@@ -926,7 +928,7 @@ int drm_sched_init(struct drm_gpu_scheduler *sched,
 sched->timeout = timeout;
 sched->hang_limit = hang_limit;
 for (i = DRM_SCHED_PRIORITY_MIN; i < DRM_SCHED_PRIORITY_MAX; i++)
-   drm_sched_rq_init(&sched->sched_rq[i]);
+   drm_sched_rq_init(sched, &sched->sched_rq[i]);

 init_waitqueue_head(&sched->wake_up_worker);
 init_waitqueue_head(&sched->job_scheduled);
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index 4214ceb71c05..43e93d6077cf 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -93,6 +93,7 @@ struct drm_sched_entity {
   * struct drm_sched_rq - queue of entities to be scheduled.
   *
   * @lock: to modify the entities list.
+ * @sched: the scheduler to which this rq belongs to.
   * @entities: list of the entities to be scheduled.
   * @current_entity: the entity which is to be scheduled.
   *
@@ -102,6 +103,7 @@ struct drm_sched_entity {
   */
  struct drm_sched_rq {
 spinlock_t  lock;
+   struct drm_gpu_scheduler*sched;
 struct list_headentities;
 struct drm_sched_entity *current_entity;
  };
--
2.14.3



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

Re: [Freedreno] [PATCH 05/13] drm: Add put callback for the coredump printer

[Rob Clark]

On Thu, Jul 12, 2018 at 2:59 PM, Jordan Crouse  wrote:
> Add a put function for the coredump printer to bypass printf()
> for constant strings for a speed boost.

s/put/puts/ (and in the $subject)

BR,
-R

>
> v2: Add EXPORT_SYMBOL for _drm_puts_coredump
> Signed-off-by: Jordan Crouse 
> ---
>  drivers/gpu/drm/drm_print.c | 43 +
>  include/drm/drm_print.h |  2 ++
>  2 files changed, 45 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
> index bef8f0ec5d73..ff20f4a764c8 100644
> --- a/drivers/gpu/drm/drm_print.c
> +++ b/drivers/gpu/drm/drm_print.c
> @@ -30,6 +30,49 @@
>  #include 
>  #include 
>
> +void __drm_puts_coredump(struct drm_printer *p, const char *str)
> +{
> +   struct drm_print_iterator *iterator = p->arg;
> +
> +   ssize_t len;
> +
> +   if (!iterator->remain)
> +   return;
> +
> +   if (iterator->offset < iterator->start) {
> +   ssize_t copy;
> +
> +   len = strlen(str);
> +
> +   if (iterator->offset + len <= iterator->start) {
> +   iterator->offset += len;
> +   return;
> +   }
> +
> +   copy = len - (iterator->start - iterator->offset);
> +
> +   if (copy > iterator->remain)
> +   copy = iterator->remain;
> +
> +   /* Copy out the bit of the string that we need */
> +   memcpy(iterator->data,
> +   str + (iterator->start - iterator->offset), copy);
> +
> +   iterator->offset = iterator->start + copy;
> +   iterator->remain -= copy;
> +   } else {
> +   ssize_t pos = iterator->offset - iterator->start;
> +
> +   len = min_t(ssize_t, strlen(str), iterator->remain);
> +
> +   memcpy(iterator->data + pos, str, len);
> +
> +   iterator->offset += len;
> +   iterator->remain -= len;
> +   }
> +}
> +EXPORT_SYMBOL(__drm_puts_coredump);
> +
>  void __drm_printfn_coredump(struct drm_printer *p, struct va_format *vaf)
>  {
> struct drm_print_iterator *iterator = p->arg;
> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> index 3bc6ba4b7b2c..2a903ee7b428 100644
> --- a/include/drm/drm_print.h
> +++ b/include/drm/drm_print.h
> @@ -75,6 +75,7 @@ struct drm_printer {
>  };
>
>  void __drm_printfn_coredump(struct drm_printer *p, struct va_format *vaf);
> +void __drm_puts_coredump(struct drm_printer *p, const char *str);
>  void __drm_printfn_seq_file(struct drm_printer *p, struct va_format *vaf);
>  void __drm_puts_seq_file(struct drm_printer *p, const char *str);
>  void __drm_printfn_info(struct drm_printer *p, struct va_format *vaf);
> @@ -129,6 +130,7 @@ drm_coredump_printer(struct drm_print_iterator *iter)
>  {
> struct drm_printer p = {
> .printfn = __drm_printfn_coredump,
> +   .puts = __drm_puts_coredump,
> .arg = iter,
> };
> return p;
> --
> 2.17.1
>
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/tinydrm: Replace drm_dev_unref with drm_dev_put

[Thomas Zimmermann]

This patch unifies the naming of DRM functions for reference counting
of struct drm_device. The resulting code is more aligned with the rest
of the Linux kernel interfaces.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c 
b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
index 19c7f70adfa5..255341ee4eb9 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-core.c
@@ -135,7 +135,7 @@ static int tinydrm_init(struct device *parent, struct 
tinydrm_device *tdev,
/*
 * We don't embed drm_device, because that prevent us from using
 * devm_kzalloc() to allocate tinydrm_device in the driver since
-* drm_dev_unref() frees the structure. The devm_ functions provide
+* drm_dev_put() frees the structure. The devm_ functions provide
 * for easy error handling.
 */
drm = drm_dev_alloc(driver, parent);
@@ -155,7 +155,7 @@ static void tinydrm_fini(struct tinydrm_device *tdev)
drm_mode_config_cleanup(tdev->drm);
mutex_destroy(&tdev->dirty_lock);
tdev->drm->dev_private = NULL;
-   drm_dev_unref(tdev->drm);
+   drm_dev_put(tdev->drm);
 }
 
 static void devm_tinydrm_release(void *data)
@@ -172,7 +172,7 @@ static void devm_tinydrm_release(void *data)
  *
  * This function initializes @tdev, the underlying DRM device and it's
  * mode_config. Resources will be automatically freed on driver detach (devres)
- * using drm_mode_config_cleanup() and drm_dev_unref().
+ * using drm_mode_config_cleanup() and drm_dev_put().
  *
  * Returns:
  * Zero on success, negative error code on failure.
-- 
2.18.0

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

[PATCH v4 02/10] drm: crc: Introduce get_crc_sources callback

[Mahesh Kumar]

This patch introduce a callback function "get_crc_sources" which
will be called during read of control node. It is an optional
callback function and if driver implements this callback, driver
should return a constant pointer to an array of crc sources list
and update count according to the number of source in the list.

Changes Since V1: (Daniel)
 - return const pointer to an array of crc sources list
 - do validation of sources in CRC-core
Changes Since V2:
 - update commit message
 - update callback documentation
 - print one source name per line

Signed-off-by: Mahesh Kumar 
Cc: dri-devel@lists.freedesktop.org
Cc: Laurent Pinchart 
Reviewed-by: Maarten Lankhorst 
Reviewed-by: Laurent Pinchart 
---
 drivers/gpu/drm/drm_debugfs_crc.c | 23 ++-
 include/drm/drm_crtc.h| 22 ++
 2 files changed, 44 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_debugfs_crc.c 
b/drivers/gpu/drm/drm_debugfs_crc.c
index 72bfd8af3f7a..d7e626331eca 100644
--- a/drivers/gpu/drm/drm_debugfs_crc.c
+++ b/drivers/gpu/drm/drm_debugfs_crc.c
@@ -68,8 +68,29 @@ static int crc_control_show(struct seq_file *m, void *data)
 {
struct drm_crtc *crtc = m->private;
 
-   seq_printf(m, "%s\n", crtc->crc.source);
+   if (crtc->funcs->get_crc_sources) {
+   size_t count;
+   const char *const *sources = crtc->funcs->get_crc_sources(crtc,
+   &count);
+   size_t values_cnt;
+   int i;
+
+   if (count == 0 || !sources)
+   goto out;
+
+   for (i = 0; i < count; i++)
+   if (!crtc->funcs->verify_crc_source(crtc, sources[i],
+   &values_cnt)) {
+   if (strcmp(sources[i], crtc->crc.source))
+   seq_printf(m, "%s\n", sources[i]);
+   else
+   seq_printf(m, "%s*\n", sources[i]);
+   }
+   }
+   return 0;
 
+out:
+   seq_printf(m, "%s*\n", crtc->crc.source);
return 0;
 }
 
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 664be20b763f..c309f371853d 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -700,6 +700,28 @@ struct drm_crtc_funcs {
 */
int (*verify_crc_source)(struct drm_crtc *crtc, const char *source,
 size_t *values_cnt);
+   /**
+* @get_crc_sources:
+*
+* Driver callback for getting a list of all the available sources for
+* CRC generation. This callback depends upon verify_crc_source, So
+* verify_crc_source callback should be implemented before implementing
+* this. Driver can pass full list of available crc sources, this
+* callback does the verification on each crc-source before passing it
+* to userspace.
+*
+* This callback is optional if the driver does not support exporting of
+* possible CRC sources list.
+*
+* RETURNS:
+*
+* a constant character pointer to the list of all the available CRC
+* sources. On failure driver should return NULL. count should be
+* updated with number of sources in list. if zero we don't process any
+* source from the list.
+*/
+   const char *const *(*get_crc_sources)(struct drm_crtc *crtc,
+ size_t *count);
 
/**
 * @atomic_print_state:
-- 
2.16.2

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

[PATCH v4 03/10] drm/rockchip/crc: Implement verify_crc_source callback

[Mahesh Kumar]

This patch implements "verify_crc_source" callback function for
rockchip drm driver.

Changes since V1:
 - simplify the verification (Jani N)

Signed-off-by: Mahesh Kumar 
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Maarten Lankhorst 
Acked-by: Heiko Stuebner 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index effecbed2d11..77e91b15ddb4 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1138,12 +1138,31 @@ static int vop_crtc_set_crc_source(struct drm_crtc 
*crtc,
 
return ret;
 }
+
+static int
+vop_crtc_verify_crc_source(struct drm_crtc *crtc, const char *source_name,
+  size_t *values_cnt)
+{
+   if (source_name && strcmp(source_name, "auto") != 0)
+   return -EINVAL;
+
+   *values_cnt = 3;
+   return 0;
+}
+
 #else
 static int vop_crtc_set_crc_source(struct drm_crtc *crtc,
   const char *source_name, size_t *values_cnt)
 {
return -ENODEV;
 }
+
+static int
+vop_crtc_verify_crc_source(struct drm_crtc *crtc, const char *source_name,
+  size_t *values_cnt)
+{
+   return -ENODEV;
+}
 #endif
 
 static const struct drm_crtc_funcs vop_crtc_funcs = {
@@ -1156,6 +1175,7 @@ static const struct drm_crtc_funcs vop_crtc_funcs = {
.enable_vblank = vop_crtc_enable_vblank,
.disable_vblank = vop_crtc_disable_vblank,
.set_crc_source = vop_crtc_set_crc_source,
+   .verify_crc_source = vop_crtc_verify_crc_source,
 };
 
 static void vop_fb_unref_worker(struct drm_flip_work *work, void *val)
-- 
2.16.2

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

[PATCH 00/10] Improve crc-core driver interface

[Mahesh Kumar]

This series improves crc-core <-> driver interface.
This series adds following functionality in the crc-core
 - Now control node will print all the available sources if
   implemented by driver along with current source.
 - Setting of sorce will fail if provided source is not supported
 - cleanup of crtc_crc_open function first allocate memory before
   enabling CRC generation
 - Don't block open() call instead wait in crc read call.

Following IGT will fail due to crc-core <-> driver interface change
igt@kms_pipe_crc_basic@bad-source 
ig@kms_pipe_crc_basic@nonblocking-crc-pipe-X 
ig@kms_pipe_crc_basic@nonblocking-crc-pipe-X-frame-sequence
In nonblocking crc tests we'll get lesser crc's due to skipping crc

AMD/Rockchip/rcar code path is not validated and may need inputs

Cc: dri-devel@lists.freedesktop.org

Mahesh Kumar (10):
  drm: crc: Introduce verify_crc_source callback
  drm: crc: Introduce get_crc_sources callback
  drm/rockchip/crc: Implement verify_crc_source callback
  drm/amdgpu_dm/crc: Implement verify_crc_source callback
  drm/rcar-du/crc: Implement verify_crc_source callback
  drm/i915/crc: implement verify_crc_source callback
  drm/i915/crc: implement get_crc_sources callback
  drm/crc: Cleanup crtc_crc_open function
  Revert "drm: crc: Wait for a frame before returning from open()"
  drm/rcar-du/crc: Implement get_crc_sources callback

 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  |   1 +
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h  |   7 +-
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c  |  20 ++-
 drivers/gpu/drm/drm_debugfs_crc.c  |  92 +++-
 drivers/gpu/drm/i915/intel_display.c   |   2 +
 drivers/gpu/drm/i915/intel_drv.h   |   9 +-
 drivers/gpu/drm/i915/intel_pipe_crc.c  | 119 ++-
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 165 ++---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h |   3 +
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c|  26 +++-
 include/drm/drm_crtc.h |  41 -
 11 files changed, 407 insertions(+), 78 deletions(-)

-- 
2.16.2

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

[PATCH v4 04/10] drm/amdgpu_dm/crc: Implement verify_crc_source callback

[Mahesh Kumar]

This patch implements "verify_crc_source" callback function for
AMD drm driver.

Signed-off-by: Mahesh Kumar 
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Maarten Lankhorst 
Acked-by: Leo Li 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c |  1 +
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |  4 
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c | 16 
 3 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index ca017c1dd4da..2ab2030a97d7 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -2611,6 +2611,7 @@ static const struct drm_crtc_funcs amdgpu_dm_crtc_funcs = 
{
.atomic_duplicate_state = dm_crtc_duplicate_state,
.atomic_destroy_state = dm_crtc_destroy_state,
.set_crc_source = amdgpu_dm_crtc_set_crc_source,
+   .verify_crc_source = amdgpu_dm_crtc_verify_crc_source,
.enable_vblank = dm_enable_vblank,
.disable_vblank = dm_disable_vblank,
 };
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index a29dc35954c9..e43ed064dc46 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -260,9 +260,13 @@ amdgpu_dm_remove_sink_from_freesync_module(struct 
drm_connector *connector);
 #ifdef CONFIG_DEBUG_FS
 int amdgpu_dm_crtc_set_crc_source(struct drm_crtc *crtc, const char *src_name,
  size_t *values_cnt);
+int amdgpu_dm_crtc_verify_crc_source(struct drm_crtc *crtc,
+const char *src_name,
+size_t *values_cnt);
 void amdgpu_dm_crtc_handle_crc_irq(struct drm_crtc *crtc);
 #else
 #define amdgpu_dm_crtc_set_crc_source NULL
+#define amdgpu_dm_crtc_verify_crc_source NULL
 #define amdgpu_dm_crtc_handle_crc_irq(x)
 #endif
 
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
index 52f2c01349e3..dfcca594d52a 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
@@ -46,6 +46,22 @@ static enum amdgpu_dm_pipe_crc_source 
dm_parse_crc_source(const char *source)
return AMDGPU_DM_PIPE_CRC_SOURCE_INVALID;
 }
 
+int
+amdgpu_dm_crtc_verify_crc_source(struct drm_crtc *crtc, const char *src_name,
+size_t *values_cnt)
+{
+   enum amdgpu_dm_pipe_crc_source source = dm_parse_crc_source(src_name);
+
+   if (source < 0) {
+   DRM_DEBUG_DRIVER("Unknown CRC source %s for CRTC%d\n",
+src_name, crtc->index);
+   return -EINVAL;
+   }
+
+   *values_cnt = 3;
+   return 0;
+}
+
 int amdgpu_dm_crtc_set_crc_source(struct drm_crtc *crtc, const char *src_name,
   size_t *values_cnt)
 {
-- 
2.16.2

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

[PATCH v4 07/10] drm/i915/crc: implement get_crc_sources callback

[Mahesh Kumar]

This patch implements get_crc_sources callback, which returns list of
all the valid crc sources supported by driver in current platform.

Changes since V1:
 - Return array of crc sources

Signed-off-by: Mahesh Kumar 
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c  | 1 +
 drivers/gpu/drm/i915/intel_drv.h  | 3 +++
 drivers/gpu/drm/i915/intel_pipe_crc.c | 7 +++
 3 files changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index cb29789586e1..30491d4cb010 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12896,6 +12896,7 @@ static const struct drm_crtc_funcs intel_crtc_funcs = {
.atomic_destroy_state = intel_crtc_destroy_state,
.set_crc_source = intel_crtc_set_crc_source,
.verify_crc_source = intel_crtc_verify_crc_source,
+   .get_crc_sources = intel_crtc_get_crc_sources,
 };
 
 struct wait_rps_boost {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index eaea10a7a600..29b054de9e13 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -2159,11 +2159,14 @@ int intel_crtc_set_crc_source(struct drm_crtc *crtc, 
const char *source_name,
  size_t *values_cnt);
 int intel_crtc_verify_crc_source(struct drm_crtc *crtc,
 const char *source_name, size_t *values_cnt);
+const char *const *intel_crtc_get_crc_sources(struct drm_crtc *crtc,
+ size_t *count);
 void intel_crtc_disable_pipe_crc(struct intel_crtc *crtc);
 void intel_crtc_enable_pipe_crc(struct intel_crtc *crtc);
 #else
 #define intel_crtc_set_crc_source NULL
 #define intel_crtc_verify_crc_source NULL
+#define intel_crtc_get_crc_sources NULL
 static inline void intel_crtc_disable_pipe_crc(struct intel_crtc *crtc)
 {
 }
diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c 
b/drivers/gpu/drm/i915/intel_pipe_crc.c
index 03025c50cb38..83f9ade0cd81 100644
--- a/drivers/gpu/drm/i915/intel_pipe_crc.c
+++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
@@ -556,6 +556,13 @@ intel_is_valid_crc_source(struct drm_i915_private 
*dev_priv,
return ivb_crc_source_valid(dev_priv, source);
 }
 
+const char *const *intel_crtc_get_crc_sources(struct drm_crtc *crtc,
+ size_t *count)
+{
+   *count = ARRAY_SIZE(pipe_crc_sources);
+   return pipe_crc_sources;
+}
+
 int intel_crtc_verify_crc_source(struct drm_crtc *crtc, const char 
*source_name,
 size_t *values_cnt)
 {
-- 
2.16.2

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

[PATCH v4 01/10] drm: crc: Introduce verify_crc_source callback

[Mahesh Kumar]

This patch adds a new callback function "verify_crc_source" which will
be used during setting the crc source in control node. This will help
in avoiding setting of wrong string for source.

Changes since V1:
 - do not yet verify_crc_source during open.
Changes since V1:
 - improve callback description

Signed-off-by: Mahesh Kumar 
Cc: dri-devel@lists.freedesktop.org
Cc: Laurent Pinchart 
Reviewed-by: Maarten Lankhorst 
Reviewed-by: Laurent Pinchart 
---
 drivers/gpu/drm/drm_debugfs_crc.c |  8 
 include/drm/drm_crtc.h| 16 
 2 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/drm_debugfs_crc.c 
b/drivers/gpu/drm/drm_debugfs_crc.c
index 99961192bf03..72bfd8af3f7a 100644
--- a/drivers/gpu/drm/drm_debugfs_crc.c
+++ b/drivers/gpu/drm/drm_debugfs_crc.c
@@ -87,6 +87,8 @@ static ssize_t crc_control_write(struct file *file, const 
char __user *ubuf,
struct drm_crtc *crtc = m->private;
struct drm_crtc_crc *crc = &crtc->crc;
char *source;
+   size_t values_cnt;
+   int ret;
 
if (len == 0)
return 0;
@@ -104,6 +106,12 @@ static ssize_t crc_control_write(struct file *file, const 
char __user *ubuf,
if (source[len] == '\n')
source[len] = '\0';
 
+   if (crtc->funcs->verify_crc_source) {
+   ret = crtc->funcs->verify_crc_source(crtc, source, &values_cnt);
+   if (ret)
+   return ret;
+   }
+
spin_lock_irq(&crc->lock);
 
if (crc->opened) {
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 17f4f93340b8..664be20b763f 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -684,6 +684,22 @@ struct drm_crtc_funcs {
 */
int (*set_crc_source)(struct drm_crtc *crtc, const char *source,
  size_t *values_cnt);
+   /**
+* @verify_crc_source:
+*
+* verifies the source of CRC checksums of frames before setting the
+* source for CRC and during crc open. Source parameter can be NULL
+* while disabling crc source.
+*
+* This callback is optional if the driver does not support any CRC
+* generation functionality.
+*
+* RETURNS:
+*
+* 0 on success or a negative error code on failure.
+*/
+   int (*verify_crc_source)(struct drm_crtc *crtc, const char *source,
+size_t *values_cnt);
 
/**
 * @atomic_print_state:
-- 
2.16.2

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

[PATCH v4 08/10] drm/crc: Cleanup crtc_crc_open function

[Mahesh Kumar]

This patch make changes to allocate crc-entries buffer before
enabling CRC generation.
It moves all the failure check early in the function before setting
the source or memory allocation.
Now set_crc_source takes only two variable inputs, values_cnt we
already gets as part of verify_crc_source.

Changes since V1:
 - refactor code to use single spin lock
Changes since V2:
 - rebase

Signed-off-by: Mahesh Kumar 
Cc: dri-devel@lists.freedesktop.org
Cc: Laurent Pinchart 
Reviewed-by: Maarten Lankhorst 
Acked-by: Leo Li 
Reviewed-by: Laurent Pinchart 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h  |  3 +-
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c  |  4 +-
 drivers/gpu/drm/drm_debugfs_crc.c  | 61 ++
 drivers/gpu/drm/i915/intel_drv.h   |  3 +-
 drivers/gpu/drm/i915/intel_pipe_crc.c  |  4 +-
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c |  4 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c|  6 +--
 include/drm/drm_crtc.h |  3 +-
 8 files changed, 37 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
index e43ed064dc46..54056d180003 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h
@@ -258,8 +258,7 @@ amdgpu_dm_remove_sink_from_freesync_module(struct 
drm_connector *connector);
 
 /* amdgpu_dm_crc.c */
 #ifdef CONFIG_DEBUG_FS
-int amdgpu_dm_crtc_set_crc_source(struct drm_crtc *crtc, const char *src_name,
- size_t *values_cnt);
+int amdgpu_dm_crtc_set_crc_source(struct drm_crtc *crtc, const char *src_name);
 int amdgpu_dm_crtc_verify_crc_source(struct drm_crtc *crtc,
 const char *src_name,
 size_t *values_cnt);
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
index dfcca594d52a..e7ad528f5853 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crc.c
@@ -62,8 +62,7 @@ amdgpu_dm_crtc_verify_crc_source(struct drm_crtc *crtc, const 
char *src_name,
return 0;
 }
 
-int amdgpu_dm_crtc_set_crc_source(struct drm_crtc *crtc, const char *src_name,
-  size_t *values_cnt)
+int amdgpu_dm_crtc_set_crc_source(struct drm_crtc *crtc, const char *src_name)
 {
struct dm_crtc_state *crtc_state = to_dm_crtc_state(crtc->state);
struct dc_stream_state *stream_state = crtc_state->stream;
@@ -99,7 +98,6 @@ int amdgpu_dm_crtc_set_crc_source(struct drm_crtc *crtc, 
const char *src_name,
return -EINVAL;
}
 
-   *values_cnt = 3;
/* Reset crc_skipped on dm state */
crtc_state->crc_skip_count = 0;
return 0;
diff --git a/drivers/gpu/drm/drm_debugfs_crc.c 
b/drivers/gpu/drm/drm_debugfs_crc.c
index d7e626331eca..3e0a2cfaa35c 100644
--- a/drivers/gpu/drm/drm_debugfs_crc.c
+++ b/drivers/gpu/drm/drm_debugfs_crc.c
@@ -127,11 +127,9 @@ static ssize_t crc_control_write(struct file *file, const 
char __user *ubuf,
if (source[len] == '\n')
source[len] = '\0';
 
-   if (crtc->funcs->verify_crc_source) {
-   ret = crtc->funcs->verify_crc_source(crtc, source, &values_cnt);
-   if (ret)
-   return ret;
-   }
+   ret = crtc->funcs->verify_crc_source(crtc, source, &values_cnt);
+   if (ret)
+   return ret;
 
spin_lock_irq(&crc->lock);
 
@@ -197,40 +195,40 @@ static int crtc_crc_open(struct inode *inode, struct file 
*filep)
return ret;
}
 
+   ret = crtc->funcs->verify_crc_source(crtc, crc->source, &values_cnt);
+   if (ret)
+   return ret;
+
+   if (WARN_ON(values_cnt > DRM_MAX_CRC_NR))
+   return -EINVAL;
+
+   if (WARN_ON(values_cnt == 0))
+   return -EINVAL;
+
+   entries = kcalloc(DRM_CRC_ENTRIES_NR, sizeof(*entries), GFP_KERNEL);
+   if (!entries)
+   return -ENOMEM;
+
spin_lock_irq(&crc->lock);
-   if (!crc->opened)
+   if (!crc->opened) {
crc->opened = true;
-   else
+   crc->entries = entries;
+   crc->values_cnt = values_cnt;
+   } else {
ret = -EBUSY;
+   }
spin_unlock_irq(&crc->lock);
 
-   if (ret)
+   if (ret) {
+   kfree(entries);
return ret;
+   }
 
-   ret = crtc->funcs->set_crc_source(crtc, crc->source, &values_cnt);
+   ret = crtc->funcs->set_crc_source(crtc, crc->source);
if (ret)
goto err;
 
-   if (WARN_ON(values_cnt > DRM_MAX_CRC_NR)) {
-   ret = -EINVAL;
-   goto err_disable;
-   }
-
-   if (WARN_ON(values_c

[PATCH v4 06/10] drm/i915/crc: implement verify_crc_source callback

[Mahesh Kumar]

This patch implements verify_crc_source callback function introduced
earlier in this series.

Signed-off-by: Mahesh Kumar 
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c  |   1 +
 drivers/gpu/drm/i915/intel_drv.h  |   3 +
 drivers/gpu/drm/i915/intel_pipe_crc.c | 108 ++
 3 files changed, 112 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 7998e70a3174..cb29789586e1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12895,6 +12895,7 @@ static const struct drm_crtc_funcs intel_crtc_funcs = {
.atomic_duplicate_state = intel_crtc_duplicate_state,
.atomic_destroy_state = intel_crtc_destroy_state,
.set_crc_source = intel_crtc_set_crc_source,
+   .verify_crc_source = intel_crtc_verify_crc_source,
 };
 
 struct wait_rps_boost {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 61e715ddd0d5..eaea10a7a600 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -2157,10 +2157,13 @@ void lspcon_wait_pcon_mode(struct intel_lspcon *lspcon);
 #ifdef CONFIG_DEBUG_FS
 int intel_crtc_set_crc_source(struct drm_crtc *crtc, const char *source_name,
  size_t *values_cnt);
+int intel_crtc_verify_crc_source(struct drm_crtc *crtc,
+const char *source_name, size_t *values_cnt);
 void intel_crtc_disable_pipe_crc(struct intel_crtc *crtc);
 void intel_crtc_enable_pipe_crc(struct intel_crtc *crtc);
 #else
 #define intel_crtc_set_crc_source NULL
+#define intel_crtc_verify_crc_source NULL
 static inline void intel_crtc_disable_pipe_crc(struct intel_crtc *crtc)
 {
 }
diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c 
b/drivers/gpu/drm/i915/intel_pipe_crc.c
index 849e1b69ba73..03025c50cb38 100644
--- a/drivers/gpu/drm/i915/intel_pipe_crc.c
+++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
@@ -468,6 +468,114 @@ void intel_display_crc_init(struct drm_i915_private 
*dev_priv)
}
 }
 
+static int i8xx_crc_source_valid(struct drm_i915_private *dev_priv,
+const enum intel_pipe_crc_source source)
+{
+   switch (source) {
+   case INTEL_PIPE_CRC_SOURCE_PIPE:
+   case INTEL_PIPE_CRC_SOURCE_NONE:
+   return 0;
+   default:
+   return -EINVAL;
+   }
+}
+
+static int i9xx_crc_source_valid(struct drm_i915_private *dev_priv,
+const enum intel_pipe_crc_source source)
+{
+   switch (source) {
+   case INTEL_PIPE_CRC_SOURCE_PIPE:
+   case INTEL_PIPE_CRC_SOURCE_TV:
+   case INTEL_PIPE_CRC_SOURCE_DP_B:
+   case INTEL_PIPE_CRC_SOURCE_DP_C:
+   case INTEL_PIPE_CRC_SOURCE_DP_D:
+   case INTEL_PIPE_CRC_SOURCE_NONE:
+   return 0;
+   default:
+   return -EINVAL;
+   }
+}
+
+static int vlv_crc_source_valid(struct drm_i915_private *dev_priv,
+   const enum intel_pipe_crc_source source)
+{
+   switch (source) {
+   case INTEL_PIPE_CRC_SOURCE_PIPE:
+   case INTEL_PIPE_CRC_SOURCE_DP_B:
+   case INTEL_PIPE_CRC_SOURCE_DP_C:
+   case INTEL_PIPE_CRC_SOURCE_DP_D:
+   case INTEL_PIPE_CRC_SOURCE_NONE:
+   return 0;
+   default:
+   return -EINVAL;
+   }
+}
+
+static int ilk_crc_source_valid(struct drm_i915_private *dev_priv,
+   const enum intel_pipe_crc_source source)
+{
+   switch (source) {
+   case INTEL_PIPE_CRC_SOURCE_PIPE:
+   case INTEL_PIPE_CRC_SOURCE_PLANE1:
+   case INTEL_PIPE_CRC_SOURCE_PLANE2:
+   case INTEL_PIPE_CRC_SOURCE_NONE:
+   return 0;
+   default:
+   return -EINVAL;
+   }
+}
+
+static int ivb_crc_source_valid(struct drm_i915_private *dev_priv,
+   const enum intel_pipe_crc_source source)
+{
+   switch (source) {
+   case INTEL_PIPE_CRC_SOURCE_PIPE:
+   case INTEL_PIPE_CRC_SOURCE_PLANE1:
+   case INTEL_PIPE_CRC_SOURCE_PLANE2:
+   case INTEL_PIPE_CRC_SOURCE_PF:
+   case INTEL_PIPE_CRC_SOURCE_NONE:
+   return 0;
+   default:
+   return -EINVAL;
+   }
+}
+
+static int
+intel_is_valid_crc_source(struct drm_i915_private *dev_priv,
+ const enum intel_pipe_crc_source source)
+{
+   if (IS_GEN2(dev_priv))
+   return i8xx_crc_source_valid(dev_priv, source);
+   else if (INTEL_GEN(dev_priv) < 5)
+   return i9xx_crc_source_valid(dev_priv, source);
+   else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
+   return vlv_crc_source_valid(dev_priv, source);
+   else if (IS_GEN5(dev_priv) || IS_GEN6(dev_priv))
+   return ilk_crc_source_valid(dev_priv, source);
+   else
+   return ivb_crc_sour

[PATCH v4 09/10] Revert "drm: crc: Wait for a frame before returning from open()"

[Mahesh Kumar]

This reverts commit e8fa5671183c80342d520ad81d14fa79a9d4a680.

Don't wait for first CRC during crtc_crc_open. It avoids one frame wait
during open. If application want to wait after read call, it can use
poll/read blocking read() call.

Suggested-by: Ville Syrjälä 
Signed-off-by: Mahesh Kumar 
Cc: dri-devel@lists.freedesktop.org
Cc: Tomeu Vizoso 
Reviewed-by: Laurent Pinchart 
---
 drivers/gpu/drm/drm_debugfs_crc.c | 16 
 1 file changed, 16 deletions(-)

diff --git a/drivers/gpu/drm/drm_debugfs_crc.c 
b/drivers/gpu/drm/drm_debugfs_crc.c
index 3e0a2cfaa35c..00e743153e94 100644
--- a/drivers/gpu/drm/drm_debugfs_crc.c
+++ b/drivers/gpu/drm/drm_debugfs_crc.c
@@ -228,24 +228,8 @@ static int crtc_crc_open(struct inode *inode, struct file 
*filep)
if (ret)
goto err;
 
-   spin_lock_irq(&crc->lock);
-   /*
-* Only return once we got a first frame, so userspace doesn't have to
-* guess when this particular piece of HW will be ready to start
-* generating CRCs.
-*/
-   ret = wait_event_interruptible_lock_irq(crc->wq,
-   crtc_crc_data_count(crc),
-   crc->lock);
-   spin_unlock_irq(&crc->lock);
-
-   if (ret)
-   goto err_disable;
-
return 0;
 
-err_disable:
-   crtc->funcs->set_crc_source(crtc, NULL);
 err:
spin_lock_irq(&crc->lock);
crtc_crc_cleanup(crc);
-- 
2.16.2

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

[PATCH v4 05/10] drm/rcar-du/crc: Implement verify_crc_source callback

[Mahesh Kumar]

This patch implements "verify_crc_source" callback function for
rcar drm driver.

Changes Since V1:
 - avoid duplication of code
Changes Since V2:
 - further optimize the code

Signed-off-by: Mahesh Kumar 
Cc: dri-devel@lists.freedesktop.org
Cc: Laurent Pinchart 
Reviewed-by: Maarten Lankhorst 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 71 --
 1 file changed, 51 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 15dc9caa128b..dfbba1acc31f 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -756,17 +756,11 @@ static void rcar_du_crtc_disable_vblank(struct drm_crtc 
*crtc)
rcrtc->vblank_enable = false;
 }
 
-static int rcar_du_crtc_set_crc_source(struct drm_crtc *crtc,
-  const char *source_name,
-  size_t *values_cnt)
+static int rcar_du_crtc_parse_crc_source(struct rcar_du_crtc *rcrtc,
+const char *source_name,
+enum vsp1_du_crc_source *s)
 {
-   struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
-   struct drm_modeset_acquire_ctx ctx;
-   struct drm_crtc_state *crtc_state;
-   struct drm_atomic_state *state;
-   enum vsp1_du_crc_source source;
-   unsigned int index = 0;
-   unsigned int i;
+   unsigned int index;
int ret;
 
/*
@@ -774,30 +768,66 @@ static int rcar_du_crtc_set_crc_source(struct drm_crtc 
*crtc,
 * CRC on an input plane (%u is the plane ID), and "auto" to compute the
 * CRC on the composer (VSP) output.
 */
+
if (!source_name) {
-   source = VSP1_DU_CRC_NONE;
+   *s = VSP1_DU_CRC_NONE;
+   return 0;
} else if (!strcmp(source_name, "auto")) {
-   source = VSP1_DU_CRC_OUTPUT;
+   *s = VSP1_DU_CRC_OUTPUT;
+   return 0;
} else if (strstarts(source_name, "plane")) {
-   source = VSP1_DU_CRC_PLANE;
+   unsigned int i;
+
+   *s = VSP1_DU_CRC_PLANE;
 
ret = kstrtouint(source_name + strlen("plane"), 10, &index);
if (ret < 0)
return ret;
 
-   for (i = 0; i < rcrtc->vsp->num_planes; ++i) {
-   if (index == rcrtc->vsp->planes[i].plane.base.id) {
-   index = i;
-   break;
-   }
-   }
+   for (i = 0; i < rcrtc->vsp->num_planes; ++i)
+   if (index == rcrtc->vsp->planes[i].plane.base.id)
+   return i;
 
if (i >= rcrtc->vsp->num_planes)
return -EINVAL;
-   } else {
+   }
+
+   return -EINVAL;
+}
+
+static int rcar_du_crtc_verify_crc_source(struct drm_crtc *crtc,
+ const char *source_name,
+ size_t *values_cnt)
+{
+   struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
+   enum vsp1_du_crc_source source;
+
+   if (rcar_du_crtc_parse_crc_source(rcrtc, source_name, &source) < 0) {
+   DRM_DEBUG_DRIVER("unknown source %s\n", source_name);
return -EINVAL;
}
 
+   *values_cnt = 1;
+   return 0;
+}
+
+static int rcar_du_crtc_set_crc_source(struct drm_crtc *crtc,
+  const char *source_name,
+  size_t *values_cnt)
+{
+   struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
+   struct drm_modeset_acquire_ctx ctx;
+   struct drm_crtc_state *crtc_state;
+   struct drm_atomic_state *state;
+   enum vsp1_du_crc_source source;
+   unsigned int index = 0;
+   int ret;
+
+   ret = rcar_du_crtc_parse_crc_source(rcrtc, source_name, &source);
+   if (ret < 0)
+   return ret;
+
+   index = ret;
*values_cnt = 1;
 
/* Perform an atomic commit to set the CRC source. */
@@ -861,6 +891,7 @@ static const struct drm_crtc_funcs crtc_funcs_gen3 = {
.enable_vblank = rcar_du_crtc_enable_vblank,
.disable_vblank = rcar_du_crtc_disable_vblank,
.set_crc_source = rcar_du_crtc_set_crc_source,
+   .verify_crc_source = rcar_du_crtc_verify_crc_source,
 };
 
 /* 
-
-- 
2.16.2

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

[Bug 107213] [amdgpu/DisplayPort] KDE Wayland session is segfaulting right after login

[bugzilla-daemon]

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

--- Comment #2 from Shmerl  ---
Created attachment 140624
  --> https://bugs.freedesktop.org/attachment.cgi?id=140624&action=edit
dmesg output

See attached dmesg output. Once thing to note, I consistently get a black
screen after boot (the monitor goes into a sleep mode). I need to turn monitor
off, turn it back on, switch to tty1 (then monitor turns on), then log in there
and restart sddm. Only then sddm appears on tty7. After that, Wayland session
log-in fails (I tried a couple of times which is reflected in dmesg).

First try didn't result in segfault in dmesg, just in *ERROR* REG_WAIT, but
second attempt also added as segfault.

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

[Bug 107153] 4.18-rc3 crash on hdmi (0010:dm_update_crtcs_state+0x41e/0x4a0)

[bugzilla-daemon]

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

--- Comment #9 from Patrik Kullman  ---
That's amazing! I'll try it out in a few hours! Thanks!

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

[PATCH] fbdev: omapfb: off by one in omapfb_register_client()

[Dan Carpenter]

The omapfb_register_client[] array has OMAPFB_PLANE_NUM elements so the
> should be >= or we are one element beyond the end of the array.

Fixes: 8b08cf2b64f5 ("OMAP: add TI OMAP framebuffer driver")
Signed-off-by: Dan Carpenter 

diff --git a/drivers/video/fbdev/omap/omapfb_main.c 
b/drivers/video/fbdev/omap/omapfb_main.c
index 585f39efcff6..1c75f4806ed3 100644
--- a/drivers/video/fbdev/omap/omapfb_main.c
+++ b/drivers/video/fbdev/omap/omapfb_main.c
@@ -958,7 +958,7 @@ int omapfb_register_client(struct omapfb_notifier_block 
*omapfb_nb,
 {
int r;
 
-   if ((unsigned)omapfb_nb->plane_idx > OMAPFB_PLANE_NUM)
+   if ((unsigned)omapfb_nb->plane_idx >= OMAPFB_PLANE_NUM)
return -EINVAL;
 
if (!notifier_inited) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 05/15] drm: drop _mode_ from update_edit_property()

[Sean Paul]

On Mon, Jul 09, 2018 at 10:40:06AM +0200, Daniel Vetter wrote:
> Just makes it longer, and for most things in drm_connector.[hc] we
> just use the drm_connector_ prefix. Done with sed + a bit of manual
> fixup for the indenting.
> 
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c| 4 ++--
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++--
>  .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c   | 4 ++--
>  drivers/gpu/drm/ast/ast_mode.c| 4 ++--
>  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c  | 2 +-
>  drivers/gpu/drm/bridge/analogix-anx78xx.c | 4 ++--
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c| 4 ++--
>  drivers/gpu/drm/bridge/dumb-vga-dac.c | 2 +-
>  drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c  | 2 +-
>  drivers/gpu/drm/bridge/nxp-ptn3460.c  | 2 +-
>  drivers/gpu/drm/bridge/sii902x.c  | 2 +-
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
>  drivers/gpu/drm/bridge/tc358767.c | 2 +-
>  drivers/gpu/drm/bridge/ti-tfp410.c| 2 +-
>  drivers/gpu/drm/drm_connector.c   | 8 
>  drivers/gpu/drm/drm_debugfs.c | 4 ++--
>  drivers/gpu/drm/drm_probe_helper.c| 2 +-
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c  | 2 +-
>  drivers/gpu/drm/exynos/exynos_hdmi.c  | 2 +-
>  drivers/gpu/drm/gma500/cdv_intel_dp.c | 2 +-
>  drivers/gpu/drm/gma500/cdv_intel_hdmi.c   | 2 +-
>  drivers/gpu/drm/gma500/oaktrail_hdmi.c| 2 +-
>  drivers/gpu/drm/gma500/oaktrail_lvds.c| 2 +-
>  drivers/gpu/drm/gma500/psb_intel_modes.c  | 2 +-
>  drivers/gpu/drm/gma500/psb_intel_sdvo.c   | 2 +-
>  drivers/gpu/drm/i2c/tda998x_drv.c | 2 +-
>  drivers/gpu/drm/i915/intel_dp.c   | 2 +-
>  drivers/gpu/drm/i915/intel_lvds.c | 2 +-
>  drivers/gpu/drm/i915/intel_modes.c| 2 +-
>  drivers/gpu/drm/i915/intel_sdvo.c | 2 +-
>  drivers/gpu/drm/imx/imx-ldb.c | 2 +-
>  drivers/gpu/drm/imx/imx-tve.c | 2 +-
>  drivers/gpu/drm/imx/parallel-display.c| 2 +-
>  drivers/gpu/drm/mediatek/mtk_hdmi.c   | 2 +-
>  drivers/gpu/drm/mgag200/mgag200_mode.c| 2 +-
>  drivers/gpu/drm/msm/edp/edp_connector.c   | 2 +-
>  drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 2 +-
>  drivers/gpu/drm/nouveau/dispnv50/disp.c   | 2 +-
>  drivers/gpu/drm/nouveau/nouveau_connector.c   | 8 
>  drivers/gpu/drm/omapdrm/omap_connector.c  | 4 ++--
>  drivers/gpu/drm/panel/panel-simple.c  | 2 +-
>  drivers/gpu/drm/radeon/radeon_connectors.c| 4 ++--
>  drivers/gpu/drm/radeon/radeon_dp_mst.c| 4 ++--
>  drivers/gpu/drm/rockchip/cdn-dp-core.c| 2 +-
>  drivers/gpu/drm/rockchip/inno_hdmi.c  | 2 +-
>  drivers/gpu/drm/sti/sti_hdmi.c| 2 +-
>  drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c| 2 +-
>  drivers/gpu/drm/tegra/output.c| 2 +-
>  drivers/gpu/drm/tilcdc/tilcdc_tfp410.c| 2 +-
>  drivers/gpu/drm/udl/udl_connector.c   | 2 +-
>  drivers/gpu/drm/vc4/vc4_hdmi.c| 2 +-
>  drivers/gpu/drm/zte/zx_hdmi.c | 2 +-
>  drivers/gpu/drm/zte/zx_vga.c  | 2 +-
>  drivers/staging/vboxvideo/vbox_mode.c | 2 +-

Is this any closer to graduating from staging? From a glance at the history, it
doesn't seem like it's moved closer in a very long time.

Anyways, 

Reviewed-by: Sean Paul 


>  include/drm/drm_connector.h   | 6 +++---
>  include/drm/drm_modeset_helper_vtables.h  | 2 +-
>  56 files changed, 74 insertions(+), 74 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> index 881f7cb7ae6e..c770d73352a7 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> @@ -334,11 +334,11 @@ static int amdgpu_connector_ddc_get_modes(struct 
> drm_connector *connector)
>   int ret;
>  
>   if (amdgpu_connector->edid) {
> - drm_mode_connector_update_edid_property(connector, 
> amdgpu_connector->edid);
> + drm_connector_update_edid_property(connector, 
> amdgpu_connector->edid);
>   ret = drm_add_edid_mode

[PATCH] drm/etnaviv: fix some off by one bugs

[Dan Carpenter]

The ->nr_signal is the supposed to be the number of elements in the
->signal array.  There was one place where it was 5 but it was supposed
to be 4.  That looks like a copy and paste bug.  There were also two
checks that were off by one.

Fixes: 9e2c2e273012 ("drm/etnaviv: add infrastructure to query perf counter")
Signed-off-by: Dan Carpenter 
---
Not tested.

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c 
b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
index 9980d81a26e3..4227a4006c34 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
@@ -113,7 +113,7 @@ static const struct etnaviv_pm_domain doms_3d[] = {
.name = "PE",
.profile_read = VIVS_MC_PROFILE_PE_READ,
.profile_config = VIVS_MC_PROFILE_CONFIG0,
-   .nr_signals = 5,
+   .nr_signals = 4,
.signal = (const struct etnaviv_pm_signal[]) {
{
"PIXEL_COUNT_KILLED_BY_COLOR_PIPE",
@@ -435,7 +435,7 @@ int etnaviv_pm_query_sig(struct etnaviv_gpu *gpu,
 
dom = meta->domains + signal->domain;
 
-   if (signal->iter > dom->nr_signals)
+   if (signal->iter >= dom->nr_signals)
return -EINVAL;
 
sig = &dom->signal[signal->iter];
@@ -461,7 +461,7 @@ int etnaviv_pm_req_validate(const struct 
drm_etnaviv_gem_submit_pmr *r,
 
dom = meta->domains + r->domain;
 
-   if (r->signal > dom->nr_signals)
+   if (r->signal >= dom->nr_signals)
return -EINVAL;
 
return 0;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 06/15] drm: drop _mode_ from drm_mode_connector_attach_encoder

[Sean Paul]

On Mon, Jul 09, 2018 at 10:40:07AM +0200, Daniel Vetter wrote:
> Again to align with the usual prefix of just drm_connector_. Again
> done with sed + manual fixup for indent issues.
> 
> Signed-off-by: Daniel Vetter 

Reviewed-by: Sean Paul 

> ---
>  Documentation/gpu/drm-kms.rst  |  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_encoders.c   |  2 +-
>  drivers/gpu/drm/amd/amdgpu/dce_virtual.c   |  2 +-
>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  |  2 +-
>  drivers/gpu/drm/arc/arcpgu_sim.c   |  2 +-
>  drivers/gpu/drm/ast/ast_mode.c |  2 +-
>  drivers/gpu/drm/bochs/bochs_kms.c  |  2 +-
>  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   |  2 +-
>  drivers/gpu/drm/bridge/analogix-anx78xx.c  |  4 ++--
>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  2 +-
>  drivers/gpu/drm/bridge/dumb-vga-dac.c  |  2 +-
>  .../gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c   |  2 +-
>  drivers/gpu/drm/bridge/nxp-ptn3460.c   |  2 +-
>  drivers/gpu/drm/bridge/panel.c |  2 +-
>  drivers/gpu/drm/bridge/parade-ps8622.c |  2 +-
>  drivers/gpu/drm/bridge/sii902x.c   |  2 +-
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c  |  2 +-
>  drivers/gpu/drm/bridge/tc358767.c  |  2 +-
>  drivers/gpu/drm/bridge/ti-tfp410.c |  2 +-
>  drivers/gpu/drm/cirrus/cirrus_mode.c   |  2 +-
>  drivers/gpu/drm/drm_connector.c| 10 +-
>  drivers/gpu/drm/drm_simple_kms_helper.c|  2 +-
>  drivers/gpu/drm/drm_writeback.c|  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_dpi.c|  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c|  2 +-
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c   |  2 +-
>  drivers/gpu/drm/exynos/exynos_hdmi.c   |  2 +-
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c  |  2 +-
>  drivers/gpu/drm/gma500/gma_display.c   |  2 +-
>  drivers/gpu/drm/gma500/mdfld_dsi_dpi.c |  2 +-
>  drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c   |  2 +-
>  drivers/gpu/drm/i2c/tda998x_drv.c  |  2 +-
>  drivers/gpu/drm/i915/intel_display.c   |  3 +--
>  drivers/gpu/drm/i915/intel_dp_mst.c|  3 +--
>  drivers/gpu/drm/imx/imx-ldb.c  |  3 +--
>  drivers/gpu/drm/imx/imx-tve.c  |  2 +-
>  drivers/gpu/drm/imx/parallel-display.c |  2 +-
>  drivers/gpu/drm/mediatek/mtk_dsi.c |  2 +-
>  drivers/gpu/drm/mediatek/mtk_hdmi.c|  2 +-
>  drivers/gpu/drm/meson/meson_venc_cvbs.c|  2 +-
>  drivers/gpu/drm/mgag200/mgag200_mode.c |  2 +-
>  drivers/gpu/drm/msm/disp/mdp4/mdp4_lvds_connector.c|  2 +-
>  drivers/gpu/drm/msm/dsi/dsi_manager.c  |  2 +-
>  drivers/gpu/drm/msm/edp/edp_connector.c|  2 +-
>  drivers/gpu/drm/msm/hdmi/hdmi_connector.c  |  2 +-
>  drivers/gpu/drm/nouveau/dispnv04/dac.c |  2 +-
>  drivers/gpu/drm/nouveau/dispnv04/dfp.c |  2 +-
>  drivers/gpu/drm/nouveau/dispnv04/tvnv04.c  |  2 +-
>  drivers/gpu/drm/nouveau/dispnv04/tvnv17.c  |  2 +-
>  drivers/gpu/drm/nouveau/dispnv50/disp.c|  8 
>  drivers/gpu/drm/omapdrm/omap_drv.c |  2 +-
>  drivers/gpu/drm/qxl/qxl_display.c  |  2 +-
>  drivers/gpu/drm/radeon/radeon_encoders.c   |  2 +-
>  drivers/gpu/drm/rcar-du/rcar_lvds.c|  2 +-
>  drivers/gpu/drm/rockchip/cdn-dp-core.c |  2 +-
>  drivers/gpu/drm/rockchip/dw-mipi-dsi.c |  2 +-
>  drivers/gpu/drm/rockchip/inno_hdmi.c   |  2 +-
>  drivers/gpu/drm/rockchip/rockchip_lvds.c   |  2 +-
>  drivers/gpu/drm/shmobile/shmob_drm_crtc.c  |  2 +-
>  drivers/gpu/drm/sti/sti_dvo.c  |  2 +-
>  drivers/gpu/drm/sti/sti_hda.c  |  2 +-
>  drivers/gpu/drm/sti/sti_hdmi.c |  2 +-
>  drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c |  2 +-
>  drivers/gpu/drm/sun4i/sun4i_lvds.c |  2 +-
>  drivers/gpu/drm/sun4i/sun4i_rgb.c  |  2 +-
>  drivers/gpu/drm/sun4i/sun4i_tv.c   |  2 +-
>  drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c |  2 +-
>  drivers/gpu/drm/tegra/dsi.c|  2 +-
>  drivers/gpu/drm/tegra/hdmi.c   |  2 +-
>  drivers/gpu/drm/tegra/rgb.c|  2 +-
>  drivers/gpu/drm/tegra/sor.c|  2 +-
>  drivers/gpu/drm/tilcdc/tilcdc_panel.c 

[PATCH] fbdev: omapfb: off by one in omapfb_register_client()

[Dan Carpenter]

The omapfb_register_client[] array has OMAPFB_PLANE_NUM elements so the
> should be >= or we are one element beyond the end of the array.

Fixes: 8b08cf2b64f5 ("OMAP: add TI OMAP framebuffer driver")
Signed-off-by: Dan Carpenter 

diff --git a/drivers/video/fbdev/omap/omapfb_main.c 
b/drivers/video/fbdev/omap/omapfb_main.c
index 585f39efcff6..1c75f4806ed3 100644
--- a/drivers/video/fbdev/omap/omapfb_main.c
+++ b/drivers/video/fbdev/omap/omapfb_main.c
@@ -958,7 +958,7 @@ int omapfb_register_client(struct omapfb_notifier_block 
*omapfb_nb,
 {
int r;
 
-   if ((unsigned)omapfb_nb->plane_idx > OMAPFB_PLANE_NUM)
+   if ((unsigned)omapfb_nb->plane_idx >= OMAPFB_PLANE_NUM)
return -EINVAL;
 
if (!notifier_inited) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 07/15] drm: drop _mode_ from remaining connector functions

[Sean Paul]

On Mon, Jul 09, 2018 at 10:40:08AM +0200, Daniel Vetter wrote:
> Since there's very few callers of these I've decided to do them all in
> one patch. With this the unecessarily long drm_mode_connector_ prefix
> is gone from the codebase! The only exception being struct
> drm_mode_connector_set_property, which is part of the uapi so can't be
> renamed.
> 
> Again done with sed+some manual fixups for indent issues.
> 
> Signed-off-by: Daniel Vetter 

LGTM. There's an unrelated indent change in the arguments of
drm_connector_update_edid_property(), but it's an improvement, so I won't
nitpick it :-)

Reviewed-by: Sean Paul 


> ---
>  .../display/amdgpu_dm/amdgpu_dm_mst_types.c   |  6 ++--
>  drivers/gpu/drm/drm_atomic_helper.c   |  2 +-
>  drivers/gpu/drm/drm_connector.c   | 36 +--
>  drivers/gpu/drm/drm_crtc_internal.h   |  6 ++--
>  drivers/gpu/drm/drm_dp_mst_topology.c |  4 +--
>  drivers/gpu/drm/drm_ioctl.c   |  2 +-
>  drivers/gpu/drm/drm_mode_object.c |  3 +-
>  drivers/gpu/drm/drm_modes.c   |  6 ++--
>  drivers/gpu/drm/drm_probe_helper.c|  4 +--
>  drivers/gpu/drm/i915/intel_dp.c   |  4 +--
>  drivers/gpu/drm/i915/intel_dp_mst.c   |  2 +-
>  drivers/gpu/drm/msm/dsi/dsi_manager.c |  2 +-
>  drivers/gpu/drm/nouveau/dispnv50/disp.c   |  2 +-
>  drivers/gpu/drm/radeon/radeon_dp_mst.c|  2 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c   |  2 +-
>  include/drm/drm_connector.h   | 14 
>  include/drm/drm_modes.h   |  2 +-
>  17 files changed, 49 insertions(+), 50 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c 
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> index 581bb75d08eb..65f210d3497b 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> @@ -345,7 +345,7 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr 
> *mgr,
>   aconnector, connector->base.id, 
> aconnector->mst_port);
>  
>   aconnector->port = port;
> - drm_mode_connector_set_path_property(connector, 
> pathprop);
> + drm_connector_set_path_property(connector, pathprop);
>  
>   drm_connector_list_iter_end(&conn_iter);
>   aconnector->mst_connected = true;
> @@ -393,7 +393,7 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr 
> *mgr,
>   dev->mode_config.tile_property,
>   0);
>  
> - drm_mode_connector_set_path_property(connector, pathprop);
> + drm_connector_set_path_property(connector, pathprop);
>  
>   /*
>* Initialize connector state before adding the connectror to drm and
> @@ -441,7 +441,7 @@ static void dm_dp_mst_hotplug(struct 
> drm_dp_mst_topology_mgr *mgr)
>  static void dm_dp_mst_link_status_reset(struct drm_connector *connector)
>  {
>   mutex_lock(&connector->dev->mode_config.mutex);
> - drm_mode_connector_set_link_status_property(connector, 
> DRM_MODE_LINK_STATUS_BAD);
> + drm_connector_set_link_status_property(connector, 
> DRM_MODE_LINK_STATUS_BAD);
>   mutex_unlock(&connector->dev->mode_config.mutex);
>  }
>  
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 5bc88f361fef..acf9dbd9fed2 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2809,7 +2809,7 @@ static int update_output_state(struct drm_atomic_state 
> *state,
>   * resets the "link-status" property to GOOD, to force any link
>   * re-training. The SETCRTC ioctl does not define whether an update does
>   * need a full modeset or just a plane update, hence we're allowed to do
> - * that. See also drm_mode_connector_set_link_status_property().
> + * that. See also drm_connector_set_link_status_property().
>   *
>   * Returns:
>   * Returns 0 on success, negative errno numbers on failure.
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 43cd636d83b5..93647161f9e6 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -856,7 +856,7 @@ DRM_ENUM_NAME_FN(drm_get_content_protection_name, 
> drm_cp_enum_list)
>   * PATH:
>   *   Connector path property to identify how this sink is physically
>   *   connected. Used by DP MST. This should be set by calling
> - *   drm_mode_connector_set_path_property(), in the case of DP MST with the
> + *   drm_connector_set_path_property(), in the case of DP MST with the
>   *   path property the MST manager created. Userspace cannot change this
>   *   property.
>   * TILE:
> @@ -867,14 +867,14 @@ DRM_ENUM_NAME_FN(drm_get_content_protection_name, 
> drm_cp_enum_list)
>   *   are not gen-locked. Note that for tiled p

no handling of fbdev patches till 23.07

[Bartlomiej Zolnierkiewicz]

Hi,

I will be traveling / busy with other things / without access to my
development setup till 23.07. When I'm back I will handle the rest of
pending v4.19 changes, sorry for the inconvenience.
 
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics

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

Re: 答复: 答复: [alsa-devel] 答复: [PATCH] vgaswitchroo: set audio client id according to bound gpu client id

[Takashi Iwai]

On Wed, 11 Jul 2018 13:12:01 +0200,
Takashi Iwai wrote:
> 
> And the forced runtime PM is still an issue, and this would need the
> other notification mechanism than the HD-audio unsolicited event as
> AMD HDMI controller doesn't honor the HD-audio WAKEEN bit.

Since we had a nice "hack week" in this week at SUSE, I spent some
time to write some patches for the support of the direct hotplug
notification / ELD query between HD-audio and radeon/amdgpu.  It
re-utilizes the audio component framework for i915 but in a slightly
more flexible way.

The patches are found in topic/hda-acomp branch of my sound.git tree:
  git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git

The following commits are relevant:
  drm/i915: Split audio component to a generic type
  ALSA: hda/i915: Allow delayed i915 audio component binding
  ALSA: hda/i915: Associate audio component with devres
  ALSA: hda: Make audio component support more generic
  ALSA: hda/hdmi: Allow audio component for AMD/ATI HDMI
  ALSA: hda/hdmi: Use single mutex unlock in error paths
  drm/radeon: Add audio component support
  drm/amdgpu: Add audio component support

The branch should be cleanly pullable onto the latest 4.18-rc.

I couldn't test amdgpu but the test with a radeon driver on an old
laptop seemed working through a very quick test.

Please give it a try.


thanks,

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

Re: [PATCH 08/15] drm: Switch drm_plane_state to inline kerneldoc style

[Sean Paul]

On Mon, Jul 09, 2018 at 10:40:09AM +0200, Daniel Vetter wrote:
> For consistency and to encourage more detailed documentation. While
> doing this also beefed up a few of the comments, linking at least to
> the setup function. Plus fixed all the hyperlinks.
> 
> Signed-off-by: Daniel Vetter 

Reviewed-by: Sean Paul 

> ---
>  include/drm/drm_plane.h | 86 +++--
>  1 file changed, 56 insertions(+), 30 deletions(-)
> 
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index cee9dfaaa740..1a647f8f5661 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -34,31 +34,15 @@ struct drm_modeset_acquire_ctx;
>  
>  /**
>   * struct drm_plane_state - mutable plane state
> - * @plane: backpointer to the plane
> - * @crtc_w: width of visible portion of plane on crtc
> - * @crtc_h: height of visible portion of plane on crtc
> - * @src_x: left position of visible portion of plane within
> - *   plane (in 16.16)
> - * @src_y: upper position of visible portion of plane within
> - *   plane (in 16.16)
> - * @src_w: width of visible portion of plane (in 16.16)
> - * @src_h: height of visible portion of plane (in 16.16)
> - * @alpha: opacity of the plane
> - * @rotation: rotation of the plane
> - * @zpos: priority of the given plane on crtc (optional)
> - *   Note that multiple active planes on the same crtc can have an identical
> - *   zpos value. The rule to solving the conflict is to compare the plane
> - *   object IDs; the plane with a higher ID must be stacked on top of a
> - *   plane with a lower ID.
> - * @normalized_zpos: normalized value of zpos: unique, range from 0 to N-1
> - *   where N is the number of active planes for given crtc. Note that
> - *   the driver must set drm_mode_config.normalize_zpos or call
> - *   drm_atomic_normalize_zpos() to update this before it can be trusted.
> - * @src: clipped source coordinates of the plane (in 16.16)
> - * @dst: clipped destination coordinates of the plane
> - * @state: backpointer to global drm_atomic_state
> + *
> + * Please not that the destination coordinates @crtc_x, @crtc_y, @crtc_h and
> + * @crtc_w and the source coordinates @src_x, @src_y, @src_h and @src_w are 
> the
> + * raw coordinates provided by userspace. Drivers should use
> + * drm_atomic_helper_check_plane_state() and only use the derived rectangles 
> in
> + * @src and @dst to program the hardware.
>   */
>  struct drm_plane_state {
> + /** @plane: backpointer to the plane */
>   struct drm_plane *plane;
>  
>   /**
> @@ -87,7 +71,7 @@ struct drm_plane_state {
>* preserved.
>*
>* Drivers should store any implicit fence in this from their
> -  * &drm_plane_helper.prepare_fb callback. See drm_gem_fb_prepare_fb()
> +  * &drm_plane_helper_funcs.prepare_fb callback. See 
> drm_gem_fb_prepare_fb()
>* and drm_gem_fb_simple_display_pipe_prepare_fb() for suitable helpers.
>*/
>   struct dma_fence *fence;
> @@ -108,20 +92,60 @@ struct drm_plane_state {
>*/
>   int32_t crtc_y;
>  
> + /** @crtc_w: width of visible portion of plane on crtc */
> + /** @crtc_h: height of visible portion of plane on crtc */
>   uint32_t crtc_w, crtc_h;
>  
> - /* Source values are 16.16 fixed point */
> - uint32_t src_x, src_y;
> + /**
> +  * @src_x: left position of visible portion of plane within plane (in
> +  * 16.16 fixed point).
> +  */
> + uint32_t src_x;
> + /**
> +  * @src_y: upper position of visible portion of plane within plane (in
> +  * 16.16 fixed point).
> +  */
> + uint32_t src_y;
> + /** @src_w: width of visible portion of plane (in 16.16) */
> + /** @src_h: height of visible portion of plane (in 16.16) */
>   uint32_t src_h, src_w;
>  
> - /* Plane opacity */
> + /**
> +  * @alpha:
> +  * Opacity of the plane with 0 as completely transparent and 0x as
> +  * completely opaque. See drm_plane_create_alpha_property() for more
> +  * details.
> +  */
>   u16 alpha;
>  
> - /* Plane rotation */
> + /**
> +  * @rotation:
> +  * Rotation of the plane. See drm_plane_create_rotation_property() for
> +  * more details.
> +  */
>   unsigned int rotation;
>  
> - /* Plane zpos */
> + /**
> +  * @zpos:
> +  * Priority of the given plane on crtc (optional).
> +  *
> +  * Note that multiple active planes on the same crtc can have an
> +  * identical zpos value. The rule to solving the conflict is to compare
> +  * the plane object IDs; the plane with a higher ID must be stacked on
> +  * top of a plane with a lower ID.
> +  *
> +  * See drm_plane_create_zpos_property() and
> +  * drm_plane_create_zpos_immutable_property() for more details.
> +  */
>   unsigned int zpos;
> +
> + /**
> +  * @normalized_zpos:
> +  * Normalized value of zpos: unique, range from 0 to N-1 where N is 

[PATCH v2 1/3] drm: writeback: Fix doc that says connector should be disconnected

[Alexandru Gheorghe]

During iteration process one of the proposed mechanism for not
breaking existing userspace was to report writeback connectors as
disconnected, however the final version used
DRM_CLIENT_CAP_WRITEBACK_CONNECTORS for that purpose.

Signed-off-by: Alexandru Gheorghe 
---
 drivers/gpu/drm/drm_writeback.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
index 8273950..e7b6e5e 100644
--- a/drivers/gpu/drm/drm_writeback.c
+++ b/drivers/gpu/drm/drm_writeback.c
@@ -23,8 +23,8 @@
  * from a CRTC to a memory buffer. They are used and act similarly to other
  * types of connectors, with some important differences:
  *  - Writeback connectors don't provide a way to output visually to the user.
- *  - Writeback connectors should always report as "disconnected" (so that
- *clients which don't understand them will ignore them).
+ *  - Writeback connectors are visible to userspace only when the client sets
+ *DRM_CLIENT_CAP_WRITEBACK_CONNECTORS.
  *  - Writeback connectors don't have EDID.
  *
  * A framebuffer may only be attached to a writeback connector when the
-- 
2.7.4

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

[PATCH v2 2/3] drm: mali-dp: Report writeback connector as connected

[Alexandru Gheorghe]

Older version of this patch series reported writeback as disconnected
to avoid confusing userspace not aware of writeback connectors.
However, the version that got merged uses a special cap
(DRM_CLIENT_CAP_WRITEBACK_CONNECTORS) for this purpose.

This helps us avoid some special handling of writeback connector
in drm_helper_probe_single_connector_modes, see [1].

https://lists.freedesktop.org/archives/dri-devel/2018-July/183144.html

Signed-off-by: Alexandru Gheorghe 
---
 drivers/gpu/drm/arm/malidp_mw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
index cfd718e..ba6ae66 100644
--- a/drivers/gpu/drm/arm/malidp_mw.c
+++ b/drivers/gpu/drm/arm/malidp_mw.c
@@ -73,7 +73,7 @@ static void malidp_mw_connector_reset(struct drm_connector 
*connector)
 static enum drm_connector_status
 malidp_mw_connector_detect(struct drm_connector *connector, bool force)
 {
-   return connector_status_disconnected;
+   return connector_status_connected;
 }
 
 static void malidp_mw_connector_destroy(struct drm_connector *connector)
-- 
2.7.4

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

[PATCH v2 3/3] drm: mali-dp: Set encoder possible_clones

[Alexandru Gheorghe]

Set possible_clones field to report that the writeback connector and
the one driving the display could be enabled at the same time.

Signed-off-by: Alexandru Gheorghe 
---
 drivers/gpu/drm/arm/malidp_drv.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 5b72605..08b5bb2 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -616,6 +616,7 @@ static int malidp_bind(struct device *dev)
struct malidp_hw_device *hwdev;
struct platform_device *pdev = to_platform_device(dev);
struct of_device_id const *dev_id;
+   struct drm_encoder *encoder;
/* number of lines for the R, G and B output */
u8 output_width[MAX_OUTPUT_CHANNELS];
int ret = 0, i;
@@ -737,6 +738,15 @@ static int malidp_bind(struct device *dev)
goto bind_fail;
}
 
+   /* We expect to have a maximum of two encoders one for the actual
+* display and a virtual one for the writeback connector
+*/
+   WARN_ON(drm->mode_config.num_encoder > 2);
+   list_for_each_entry(encoder, &drm->mode_config.encoder_list, head) {
+   encoder->possible_clones =
+   (1 << drm->mode_config.num_encoder) -  1;
+   }
+
ret = malidp_irq_init(pdev);
if (ret < 0)
goto irq_init_fail;
-- 
2.7.4

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

Re: [PATCH 09/15] drm: switch drm_plane to inline comments

[Sean Paul]

On Mon, Jul 09, 2018 at 10:40:10AM +0200, Daniel Vetter wrote:
> And use that opportunity to polish the kernel doc all around:
> - Beef up some of the documentation.
> - Intro text for drm_plane and better links
> - Fix all the hyperlinks!
> 
> v2: Fix linebreaks.
> 
> Signed-off-by: Daniel Vetter 

Reviewed-by: Sean Paul 

> ---
>  Documentation/gpu/drm-kms.rst | 11 +++--
>  include/drm/drm_crtc.h|  4 +-
>  include/drm/drm_plane.h   | 88 +--
>  3 files changed, 72 insertions(+), 31 deletions(-)
> 
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 58eed08fbe31..5dee6b8a4c12 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -56,11 +56,12 @@ Overview
>  
>  The basic object structure KMS presents to userspace is fairly simple.
>  Framebuffers (represented by :c:type:`struct drm_framebuffer 
> `,
> -see `Frame Buffer Abstraction`_) feed into planes. One or more (or even no)
> -planes feed their pixel data into a CRTC (represented by :c:type:`struct
> -drm_crtc `, see `CRTC Abstraction`_) for blending. The precise
> -blending step is explained in more detail in `Plane Composition Properties`_ 
> and
> -related chapters.
> +see `Frame Buffer Abstraction`_) feed into planes. Planes are represented by
> +:c:type:`struct drm_plane `, see `Plane Abstraction`_ for more
> +details. One or more (or even no) planes feed their pixel data into a CRTC
> +(represented by :c:type:`struct drm_crtc `, see `CRTC 
> Abstraction`_)
> +for blending. The precise blending step is explained in more detail in `Plane
> +Composition Properties`_ and related chapters.
>  
>  For the output routing the first step is encoders (represented by
>  :c:type:`struct drm_encoder `, see `Encoder Abstraction`_). 
> Those
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 23eddbccab10..5afe2deb76b7 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -942,8 +942,8 @@ static inline unsigned int drm_crtc_index(const struct 
> drm_crtc *crtc)
>   * drm_crtc_mask - find the mask of a registered CRTC
>   * @crtc: CRTC to find mask for
>   *
> - * Given a registered CRTC, return the mask bit of that CRTC for an
> - * encoder's possible_crtcs field.
> + * Given a registered CRTC, return the mask bit of that CRTC for the
> + * &drm_encoder.possible_crtcs and &drm_plane.possible_crtcs fields.
>   */
>  static inline uint32_t drm_crtc_mask(const struct drm_crtc *crtc)
>  {
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index 1a647f8f5661..8a152dc16ea5 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -525,30 +525,27 @@ enum drm_plane_type {
>  
>  /**
>   * struct drm_plane - central DRM plane control structure
> - * @dev: DRM device this plane belongs to
> - * @head: for list management
> - * @name: human readable name, can be overwritten by the driver
> - * @base: base mode object
> - * @possible_crtcs: pipes this plane can be bound to
> - * @format_types: array of formats supported by this plane
> - * @format_count: number of formats supported
> - * @format_default: driver hasn't supplied supported formats for the plane
> - * @modifiers: array of modifiers supported by this plane
> - * @modifier_count: number of modifiers supported
> - * @old_fb: Temporary tracking of the old fb while a modeset is ongoing. 
> Used by
> - *   drm_mode_set_config_internal() to implement correct refcounting.
> - * @funcs: helper functions
> - * @properties: property tracking for this plane
> - * @type: type of plane (overlay, primary, cursor)
> - * @alpha_property: alpha property for this plane
> - * @zpos_property: zpos property for this plane
> - * @rotation_property: rotation property for this plane
> - * @helper_private: mid-layer private data
> + *
> + * Planes represent the scanout hardware of a display block. They receive 
> their
> + * input data from a &drm_framebuffer and feed it to a &drm_crtc. Planes 
> control
> + * the color conversion, see `Plane Composition Properties`_ for more 
> details,
> + * and are also involved in the color conversion of input pixels, see `Color
> + * Management Properties`_ for details on that.
>   */
>  struct drm_plane {
> + /** @dev: DRM device this plane belongs to */
>   struct drm_device *dev;
> +
> + /**
> +  * @head:
> +  *
> +  * List of all planes on @dev, linked from &drm_mode_config.plane_list.
> +  * Invariant over the lifetime of @dev and therefore does not need
> +  * locking.
> +  */
>   struct list_head head;
>  
> + /** @name: human readable name, can be overwritten by the driver */
>   char *name;
>  
>   /**
> @@ -562,35 +559,62 @@ struct drm_plane {
>*/
>   struct drm_modeset_lock mutex;
>  
> + /** @base: base mode object */
>   struct drm_mode_object base;
>  
> + /**
> +  * @possible_crtcs: pipes this plane can be bound to construct

Re: [PATCH 10/15] drm: drop drmP.h include from drm_plane.c

[Sean Paul]

On Mon, Jul 09, 2018 at 10:40:11AM +0200, Daniel Vetter wrote:
> Just a bit of missing includes and pre declarations.
> 
> Note: This needs the patch to move for_each_if from drmP.h to kernel.h
> or it won't compile.
> 
> Signed-off-by: Daniel Vetter 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/drm_crtc_internal.h |  8 
>  drivers/gpu/drm/drm_plane.c | 11 ++-
>  include/drm/drm_color_mgmt.h|  1 +
>  include/drm/drm_plane.h |  2 ++
>  include/drm/drm_property.h  |  2 ++
>  5 files changed, 23 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc_internal.h 
> b/drivers/gpu/drm/drm_crtc_internal.h
> index b61322763394..ff5e0d521c21 100644
> --- a/drivers/gpu/drm/drm_crtc_internal.h
> +++ b/drivers/gpu/drm/drm_crtc_internal.h
> @@ -31,6 +31,14 @@
>   * and are not exported to drivers.
>   */
>  
> +enum drm_mode_status;
> +enum drm_connector_force;
> +
> +struct drm_display_mode;
> +struct work_struct;
> +struct drm_connector;
> +struct drm_bridge;
> +struct edid;
>  
>  /* drm_crtc.c */
>  int drm_mode_crtc_set_obj_prop(struct drm_mode_object *obj,
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index df0b4ebbedbf..a26a1b6c8f6a 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -20,8 +20,17 @@
>   * OF THIS SOFTWARE.
>   */
>  
> -#include 
> +#include 
> +#include 
> +
>  #include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
>  
>  #include "drm_crtc_internal.h"
>  
> diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
> index 44f04233e3db..90ef9996d9a4 100644
> --- a/include/drm/drm_color_mgmt.h
> +++ b/include/drm/drm_color_mgmt.h
> @@ -24,6 +24,7 @@
>  #define __DRM_COLOR_MGMT_H__
>  
>  #include 
> +#include 
>  
>  struct drm_crtc;
>  struct drm_plane;
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index 8a152dc16ea5..311c31714c15 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -27,6 +27,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  struct drm_crtc;
>  struct drm_printer;
> diff --git a/include/drm/drm_property.h b/include/drm/drm_property.h
> index 1d5c0b2a8956..350fb58f819c 100644
> --- a/include/drm/drm_property.h
> +++ b/include/drm/drm_property.h
> @@ -27,6 +27,8 @@
>  #include 
>  #include 
>  
> +#include 
> +
>  /**
>   * struct drm_property_enum - symbolic values for enumerations
>   * @value: numeric property value for this enum entry
> -- 
> 2.18.0
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 107066] [Regression] Tonga can't bring up > 1 display since DC enablement

[bugzilla-daemon]

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

--- Comment #8 from Mikita Lipski  ---
Created attachment 140625
  --> https://bugs.freedesktop.org/attachment.cgi?id=140625&action=edit
Don't share clk source between DP and other connectors

Hi Paul,
sorry for the previous comment that was a part of the message for another bug.
Anyways, I was able to reproduce a similar issue as yours with 4 connectors
plugged and only 2 would light up.
But in my case it was caused by DP and HDMI sharing the same clock source, but
since you're not using DP I wonder, what could have caused an issue for you.
I'm attaching 3 experimental patches:
1. 0001-drm-amdgpu-display-Don-t-share-clk-source-between-DP-an.patch
   This patch should fix the issue for DP connection with Tonga
2.0001-drm-amdgpu-display-update-clk-for-various-HDMI-color.patch
   Allows programming of HDMI2.0 and later on Tonga
3. 0001-Disable-source-clock-sharing-between-multiple-connec.patch
   Disable clock sharing by an early return 

Can you try if any of them work for you? 
Thanks

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

[Bug 107066] [Regression] Tonga can't bring up > 1 display since DC enablement

[bugzilla-daemon]

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

--- Comment #9 from Mikita Lipski  ---
Created attachment 140626
  --> https://bugs.freedesktop.org/attachment.cgi?id=140626&action=edit
Update pix clk for HDMI connector with deep color

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

[Bug 107066] [Regression] Tonga can't bring up > 1 display since DC enablement

[bugzilla-daemon]

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

--- Comment #10 from Mikita Lipski  ---
Created attachment 140627
  --> https://bugs.freedesktop.org/attachment.cgi?id=140627&action=edit
Disable clock source sharing

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

Re: [alsa-devel] [PATCH 2/2] vgaswitchreoo: set audio client id in vgaswitchreoo enable function

[jimqu]

在 2018/7/13 16:46, Takashi Iwai 写道:

On Fri, 13 Jul 2018 10:06:02 +0200,
Jim Qu wrote:

On modern laptop, there are more and more platforms
have two GPUs, and each of them maybe have audio codec
for HDMP/DP output. For some dGPU which is no output,
audio codec usually is disabled.

In currect HDA audio driver, it will set all codec as
VGA_SWITCHEROO_DIS, the audio which is binded to UMA
will be suspended if user use debugfs to contorl power

In HDA driver side, it is difficult to know which GPU
the audio has binded to. So set the bound gpu pci dev
to vgaswitchroo, the correct audio id will be set in
vgaswitchreoo enable function.

Signed-off-by: Jim Qu 

The idea looks good to me.  Just a nitpick:


@@ -1319,15 +1319,16 @@ static const struct vga_switcheroo_client_ops 
azx_vs_ops = {
  static int register_vga_switcheroo(struct azx *chip)
  {
struct hda_intel *hda = container_of(chip, struct hda_intel, chip);
+   struct pci_dev * p;
int err;
  
  	if (!hda->use_vga_switcheroo)

return 0;
-   /* FIXME: currently only handling DIS controller
-* is there any machine with two switchable HDMI audio controllers?
-*/
-   err = vga_switcheroo_register_audio_client(chip->pci, &azx_vs_ops,
-  VGA_SWITCHEROO_DIS);
+
+   p  = get_bound_vga(chip->pci);
+   err = vga_switcheroo_register_audio_client(chip->pci, &azx_vs_ops, p);
+   if (p)
+   pci_dev_put(p);

Passing a NULL vga_dev won't work, so the NULL check after calling
vga_switcheroo_register_audio_client() is moot.  If any, it should be
checked before that.



 The hda->use_vga_switcheroo is set to 1 in init_vga_switcheroo() if 
bound vga pci dev is not NULL. Since the hda->use_vga_switcheroo is 
checked at beginning of the function. so the p which pass into 
vga_switcheroo_register_audio_client() is constant valid value.


Thanks
JimQu

thanks,

Takashi


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

Re: [PATCH 11/15] drm/doc: move struct drm_crtc to in-line comments

[Sean Paul]

On Mon, Jul 09, 2018 at 10:40:12AM +0200, Daniel Vetter wrote:
> And clean them up a bit, as usual.
> 
> Signed-off-by: Daniel Vetter 
> ---
>  include/drm/drm_crtc.h | 126 +++--
>  1 file changed, 97 insertions(+), 29 deletions(-)
> 
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 5afe2deb76b7..0cfc098f31d3 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h

/snip

> +
> + /**
> +  * @gamma_store: Gamma ramp values used by the legacy SETGAMME and

SETGAMMA

> +  * GET_GAMMA IOCTls. Set up by calling drm_mode_crtc_set_gamma_size().

GETGAMMA


With the nits fixed,

Reviewed-by: Sean Paul 

> +  */
>   uint16_t *gamma_store;
>  
> - /* if you are using the helper */
> + /** @helper_private: mid-layer private data */
>   const struct drm_crtc_helper_funcs *helper_private;
>  
> + /** @properties: property tracking for this CRTC */
>   struct drm_object_properties properties;
>  
>   /**
> @@ -872,7 +941,6 @@ struct drm_crtc {
>*
>* spinlock to protect the fences in the fence_context.
>*/
> -
>   spinlock_t fence_lock;
>   /**
>* @fence_seqno:
> -- 
> 2.18.0
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 13/15] drm/doc: Includ drm_of.c helpers

[Sean Paul]

On Mon, Jul 09, 2018 at 10:40:14AM +0200, Daniel Vetter wrote:
> Fixes a dead link I spotted in the struct drm_crtc docs. Comments
> themselves are in a surprisingly good state.
> 
> Signed-off-by: Daniel Vetter 

In subject, s/Includ/Include/. With that,

Reviewed-by: Sean Paul 


> ---
>  Documentation/gpu/drm-kms-helpers.rst | 9 +
>  drivers/gpu/drm/drm_of.c  | 9 -
>  2 files changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/gpu/drm-kms-helpers.rst 
> b/Documentation/gpu/drm-kms-helpers.rst
> index 8aece8605f4c..77e5398806a5 100644
> --- a/Documentation/gpu/drm-kms-helpers.rst
> +++ b/Documentation/gpu/drm-kms-helpers.rst
> @@ -291,6 +291,15 @@ Auxiliary Modeset Helpers
>  .. kernel-doc:: drivers/gpu/drm/drm_modeset_helper.c
> :export:
>  
> +OF/DT Helpers
> +=
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_of.c
> +   :doc: overview
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_of.c
> +   :export:
> +
>  Legacy Plane Helper Reference
>  =
>  
> diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
> index 3b8c7a6a5720..e11f91244593 100644
> --- a/drivers/gpu/drm/drm_of.c
> +++ b/drivers/gpu/drm/drm_of.c
> @@ -9,6 +9,13 @@
>  #include 
>  #include 
>  
> +/**
> + * DOC: overview
> + *
> + * A set of helper functions to aid DRM drivers in parsing standard DT
> + * properties.
> + */
> +
>  static void drm_release_of(struct device *dev, void *data)
>  {
>   of_node_put(data);
> @@ -94,7 +101,7 @@ EXPORT_SYMBOL_GPL(drm_of_component_match_add);
>   * drm_of_component_probe - Generic probe function for a component based 
> master
>   * @dev: master device containing the OF node
>   * @compare_of: compare function used for matching components
> - * @master_ops: component master ops to be used
> + * @m_ops: component master ops to be used
>   *
>   * Parse the platform device OF node and bind all the components associated
>   * with the master. Interface ports are added before the encoders in order to
> -- 
> 2.18.0
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 107066] [Regression] Tonga can't bring up > 1 display since DC enablement

[bugzilla-daemon]

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

--- Comment #11 from Lyude Paul  ---
(In reply to Mikita Lipski from comment #10)
> Created attachment 140627 [details] [review]
> Disable clock source sharing

Firing up an RPM build now, will have the results in a little bit

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

Re: [PATCH 14/15] drm/doc: use inline kerneldoc style for drm_crtc_state

[Sean Paul]

On Mon, Jul 09, 2018 at 10:40:15AM +0200, Daniel Vetter wrote:
> Lots of added text here since I think the various control flow bits
> are worth explaining a bit better.
> 
> Signed-off-by: Daniel Vetter 

The added docs surrounding enable/active will be most appreciated :-)

Reviewed-by: Sean Paul 


> ---
>  include/drm/drm_crtc.h | 110 -
>  1 file changed, 86 insertions(+), 24 deletions(-)
> 
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 0cfc098f31d3..3788e1235e24 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -77,21 +77,6 @@ struct drm_plane_helper_funcs;
>  
>  /**
>   * struct drm_crtc_state - mutable CRTC state
> - * @crtc: backpointer to the CRTC
> - * @enable: whether the CRTC should be enabled, gates all other state
> - * @active: whether the CRTC is actively displaying (used for DPMS)
> - * @planes_changed: planes on this crtc are updated
> - * @mode_changed: @mode or @enable has been changed
> - * @active_changed: @active has been toggled.
> - * @connectors_changed: connectors to this crtc have been updated
> - * @zpos_changed: zpos values of planes on this crtc have been updated
> - * @color_mgmt_changed: color management properties have changed (degamma or
> - *   gamma LUT or CSC matrix)
> - * @plane_mask: bitmask of (1 << drm_plane_index(plane)) of attached planes
> - * @connector_mask: bitmask of (1 << drm_connector_index(connector)) of 
> attached connectors
> - * @encoder_mask: bitmask of (1 << drm_encoder_index(encoder)) of attached 
> encoders
> - * @mode_blob: &drm_property_blob for @mode
> - * @state: backpointer to global drm_atomic_state
>   *
>   * Note that the distinction between @enable and @active is rather subtile:
>   * Flipping @active while @enable is set without changing anything else may
> @@ -102,31 +87,104 @@ struct drm_plane_helper_funcs;
>   *
>   * The three booleans active_changed, connectors_changed and mode_changed are
>   * intended to indicate whether a full modeset is needed, rather than 
> strictly
> - * describing what has changed in a commit.
> - * See also: drm_atomic_crtc_needs_modeset()
> + * describing what has changed in a commit. See also:
> + * drm_atomic_crtc_needs_modeset()
> + *
> + * WARNING: Transitional helpers (like drm_helper_crtc_mode_set() or
> + * drm_helper_crtc_mode_set_base()) do not maintain many of the derived 
> control
> + * state like @plane_mask so drivers not converted over to atomic helpers 
> should
> + * not rely on these being accurate!
>   */
>  struct drm_crtc_state {
> + /** @crtc: backpointer to the CRTC */
>   struct drm_crtc *crtc;
>  
> + /**
> +  * @enable: Whether the CRTC should be enabled, gates all other state.
> +  * This controls reservations of shared resources. Actual hardware state
> +  * is controlled by @active.
> +  */
>   bool enable;
> +
> + /**
> +  * @active: Whether the CRTC is actively displaying (used for DPMS).
> +  * Implies that @enable is set. The driver must not release any shared
> +  * resources if @active is set to false but @enable still true, because
> +  * userspace expects that a DPMS ON always succeeds.
> +  *
> +  * Hence drivers must not consult @active in their various
> +  * &drm_mode_config_funcs.atomic_check callback to reject an atomic
> +  * commit. They can consult it to aid in the computation of derived
> +  * hardware state, since even in the DPMS OFF state the display hardware
> +  * should be as much powered down as when the CRTC is completely
> +  * disabled through setting @enable to false.
> +  */
>   bool active;
>  
> - /* computed state bits used by helpers and drivers */
> + /**
> +  * @planes_changed: Planes on this crtc are updated. Used by the atomic
> +  * helpers and drivers to steer the atomic commit control flow.
> +  */
>   bool planes_changed : 1;
> +
> + /**
> +  * @mode_changed: @mode or @enable has been changed. Used by the atomic
> +  * helpers and drivers to steer the atomic commit control flow. See also
> +  * drm_atomic_crtc_needs_modeset().
> +  *
> +  * Drivers are supposed to set this for any CRTC state changes that
> +  * require a full modeset. They can also reset it to false if e.g. a
> +  * @mode change can be done without a full modeset by only changing
> +  * scaler settings.
> +  */
>   bool mode_changed : 1;
> +
> + /**
> +  * @active_changed: @active has been toggled. Used by the atomic
> +  * helpers and drivers to steer the atomic commit control flow. See also
> +  * drm_atomic_crtc_needs_modeset().
> +  */
>   bool active_changed : 1;
> +
> + /**
> +  * @connectors_changed: Connectors to this crtc have been updated,
> +  * either in their state or routing. Used by the atomic
> +  * helpers and drivers to steer the atomic commit control flow. See also
> +

[PATCH] drm: Fix kerneldoc for DRM_MODE_PROP_IMMUTABLE

[Sean Paul]

Noticed this while browsing the docs.

Signed-off-by: Sean Paul 
---
 include/drm/drm_property.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/drm/drm_property.h b/include/drm/drm_property.h
index 1d5c0b2a8956..c030f6ccab99 100644
--- a/include/drm/drm_property.h
+++ b/include/drm/drm_property.h
@@ -147,10 +147,10 @@ struct drm_property {
 * properties are not exposed to legacy userspace.
 *
 * DRM_MODE_PROP_IMMUTABLE
-* Set for properties where userspace cannot be changed by
+* Set for properties whose values cannot be changed by
 * userspace. The kernel is allowed to update the value of these
 * properties. This is generally used to expose probe state to
-* usersapce, e.g. the EDID, or the connector path property on DP
+* userspace, e.g. the EDID, or the connector path property on DP
 * MST sinks.
 */
uint32_t flags;
-- 
Sean Paul, Software Engineer, Google / Chromium OS

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

Re: [PATCH 2/2] vgaswitchreoo: set audio client id in vgaswitchreoo enable function

[jimqu]

在 2018/7/13 17:27, Lukas Wunner 写道:

On Fri, Jul 13, 2018 at 04:06:02PM +0800, Jim Qu wrote:

On modern laptop, there are more and more platforms
have two GPUs, and each of them maybe have audio codec
for HDMP/DP output. For some dGPU which is no output,
audio codec usually is disabled.

In currect HDA audio driver, it will set all codec as
VGA_SWITCHEROO_DIS, the audio which is binded to UMA
will be suspended if user use debugfs to contorl power

In HDA driver side, it is difficult to know which GPU
the audio has binded to. So set the bound gpu pci dev
to vgaswitchroo, the correct audio id will be set in
vgaswitchreoo enable function.

Signed-off-by: Jim Qu 

The approach you've taken in this patch won't work if the HDA controller
is bound to a driver after both GPUs have already been bound to a driver
and the handler has already been registered.

That's because vga_switcheroo_enable() is run when two GPUs have registered
as clients and the handler has also registered.  If the HDA controller is
probed afterwards, its ID will be stuck at VGA_SWITCHEROO_UNKNOWN_ID.

Before resubmitting this patch, please run it through scripts/checkpatch.pl,
there are multiple trivial issues here.

Also, please use scripts/get_maintainers.pl on all files you're touching
and cc the patch to the listed maintainers and reviewers.



@@ -161,9 +163,8 @@ struct vgasr_priv {
  };
  
  #define ID_BIT_AUDIO		0x100

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

There's a spurious whitespace change in the client_is_audio() line,
please get rid of it.



Yeah, I will correct it in later update.


--- a/include/linux/vga_switcheroo.h
+++ b/include/linux/vga_switcheroo.h
@@ -84,8 +84,8 @@ enum vga_switcheroo_state {
   * Client identifier. Audio clients use the same identifier & 0x100.
   */
  enum vga_switcheroo_client_id {
-   VGA_SWITCHEROO_UNKNOWN_ID = -1,
-   VGA_SWITCHEROO_IGD,
+   VGA_SWITCHEROO_UNKNOWN_ID = 0x1000,
+   VGA_SWITCHEROO_IGD = 0,

Hm, why is this change necessary?


Before, we suppose VGA_SWITCHEROO_UNKNOWN_ID can be only used for gpu 
client, but now we also use it on audio client. Because of -1 in memory 
is presented as 0x, so the 0x & 
ID_BIT_AUDIO = ID_BIT_AUDIO, this will confuse people if it used on gpu 
client. that audio identify bit is set.


Thanks
JimQu


Thanks,

Lukas


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

Re: [PATCH v2 1/3] drm: writeback: Fix doc that says connector should be disconnected

[Sean Paul]

On Fri, Jul 13, 2018 at 04:10:58PM +0100, Alexandru Gheorghe wrote:
> During iteration process one of the proposed mechanism for not
> breaking existing userspace was to report writeback connectors as
> disconnected, however the final version used
> DRM_CLIENT_CAP_WRITEBACK_CONNECTORS for that purpose.
> 
> Signed-off-by: Alexandru Gheorghe 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/drm_writeback.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
> index 8273950..e7b6e5e 100644
> --- a/drivers/gpu/drm/drm_writeback.c
> +++ b/drivers/gpu/drm/drm_writeback.c
> @@ -23,8 +23,8 @@
>   * from a CRTC to a memory buffer. They are used and act similarly to other
>   * types of connectors, with some important differences:
>   *  - Writeback connectors don't provide a way to output visually to the 
> user.
> - *  - Writeback connectors should always report as "disconnected" (so that
> - *clients which don't understand them will ignore them).
> + *  - Writeback connectors are visible to userspace only when the client sets
> + *DRM_CLIENT_CAP_WRITEBACK_CONNECTORS.
>   *  - Writeback connectors don't have EDID.
>   *
>   * A framebuffer may only be attached to a writeback connector when the
> -- 
> 2.7.4
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/3] drm: mali-dp: Report writeback connector as connected

[Sean Paul]

On Fri, Jul 13, 2018 at 04:10:59PM +0100, Alexandru Gheorghe wrote:
> Older version of this patch series reported writeback as disconnected
> to avoid confusing userspace not aware of writeback connectors.
> However, the version that got merged uses a special cap
> (DRM_CLIENT_CAP_WRITEBACK_CONNECTORS) for this purpose.
> 
> This helps us avoid some special handling of writeback connector
> in drm_helper_probe_single_connector_modes, see [1].
> 
> https://lists.freedesktop.org/archives/dri-devel/2018-July/183144.html
> 
> Signed-off-by: Alexandru Gheorghe 

Reviewed-by: Sean Paul 

> ---
>  drivers/gpu/drm/arm/malidp_mw.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
> index cfd718e..ba6ae66 100644
> --- a/drivers/gpu/drm/arm/malidp_mw.c
> +++ b/drivers/gpu/drm/arm/malidp_mw.c
> @@ -73,7 +73,7 @@ static void malidp_mw_connector_reset(struct drm_connector 
> *connector)
>  static enum drm_connector_status
>  malidp_mw_connector_detect(struct drm_connector *connector, bool force)
>  {
> - return connector_status_disconnected;
> + return connector_status_connected;
>  }
>  
>  static void malidp_mw_connector_destroy(struct drm_connector *connector)
> -- 
> 2.7.4
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 3/3] drm: mali-dp: Set encoder possible_clones

[Sean Paul]

On Fri, Jul 13, 2018 at 04:11:00PM +0100, Alexandru Gheorghe wrote:
> Set possible_clones field to report that the writeback connector and
> the one driving the display could be enabled at the same time.
> 

In future, please include a "Changes in vX" section so it's easier to tell
what's changed.

> Signed-off-by: Alexandru Gheorghe 
> ---
>  drivers/gpu/drm/arm/malidp_drv.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> b/drivers/gpu/drm/arm/malidp_drv.c
> index 5b72605..08b5bb2 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -616,6 +616,7 @@ static int malidp_bind(struct device *dev)
>   struct malidp_hw_device *hwdev;
>   struct platform_device *pdev = to_platform_device(dev);
>   struct of_device_id const *dev_id;
> + struct drm_encoder *encoder;
>   /* number of lines for the R, G and B output */
>   u8 output_width[MAX_OUTPUT_CHANNELS];
>   int ret = 0, i;
> @@ -737,6 +738,15 @@ static int malidp_bind(struct device *dev)
>   goto bind_fail;
>   }
>  
> + /* We expect to have a maximum of two encoders one for the actual
> +  * display and a virtual one for the writeback connector
> +  */
> + WARN_ON(drm->mode_config.num_encoder > 2);
> + list_for_each_entry(encoder, &drm->mode_config.encoder_list, head) {
> + encoder->possible_clones =
> + (1 << drm->mode_config.num_encoder) -  1;
> + }

This loop isn't necessary, you can just do the assignment once instead of
num_encoder times :-)

Sean

> +
>   ret = malidp_irq_init(pdev);
>   if (ret < 0)
>   goto irq_init_fail;
> -- 
> 2.7.4
> 

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 3/3] drm: mali-dp: Set encoder possible_clones

[Sean Paul]

On Fri, Jul 13, 2018 at 11:40:13AM -0400, Sean Paul wrote:
> On Fri, Jul 13, 2018 at 04:11:00PM +0100, Alexandru Gheorghe wrote:
> > Set possible_clones field to report that the writeback connector and
> > the one driving the display could be enabled at the same time.
> > 
> 
> In future, please include a "Changes in vX" section so it's easier to tell
> what's changed.
> 
> > Signed-off-by: Alexandru Gheorghe 
> > ---
> >  drivers/gpu/drm/arm/malidp_drv.c | 10 ++
> >  1 file changed, 10 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/arm/malidp_drv.c 
> > b/drivers/gpu/drm/arm/malidp_drv.c
> > index 5b72605..08b5bb2 100644
> > --- a/drivers/gpu/drm/arm/malidp_drv.c
> > +++ b/drivers/gpu/drm/arm/malidp_drv.c
> > @@ -616,6 +616,7 @@ static int malidp_bind(struct device *dev)
> > struct malidp_hw_device *hwdev;
> > struct platform_device *pdev = to_platform_device(dev);
> > struct of_device_id const *dev_id;
> > +   struct drm_encoder *encoder;
> > /* number of lines for the R, G and B output */
> > u8 output_width[MAX_OUTPUT_CHANNELS];
> > int ret = 0, i;
> > @@ -737,6 +738,15 @@ static int malidp_bind(struct device *dev)
> > goto bind_fail;
> > }
> >  
> > +   /* We expect to have a maximum of two encoders one for the actual

Also, while I'm here, drop the comment contents a line. ie:

/*
 * We expect...
 */

Ref: https://www.kernel.org/doc/html/v4.10/process/coding-style.html#commenting

Sean

> > +* display and a virtual one for the writeback connector
> > +*/
> > +   WARN_ON(drm->mode_config.num_encoder > 2);
> > +   list_for_each_entry(encoder, &drm->mode_config.encoder_list, head) {
> > +   encoder->possible_clones =
> > +   (1 << drm->mode_config.num_encoder) -  1;
> > +   }
> 
> This loop isn't necessary, you can just do the assignment once instead of
> num_encoder times :-)
> 
> Sean
> 
> > +
> > ret = malidp_irq_init(pdev);
> > if (ret < 0)
> > goto irq_init_fail;
> > -- 
> > 2.7.4
> > 
> 
> -- 
> Sean Paul, Software Engineer, Google / Chromium OS

-- 
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/4] drm: Move page_flip fb lookup earlier

[Ville Syrjala]

From: Ville Syrjälä 

No reason that I can see to delay the fb lookup this late. Moving it
earlier allows us to keep it outside of the lock retry loop. This
makes error handling and whatnot simpler.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/drm_plane.c | 29 +++--
 1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 6153cbda239f..924830071307 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -1009,7 +1009,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
struct drm_mode_crtc_page_flip_target *page_flip = data;
struct drm_crtc *crtc;
struct drm_plane *plane;
-   struct drm_framebuffer *fb = NULL, *old_fb;
+   struct drm_framebuffer *fb, *old_fb;
struct drm_pending_vblank_event *e = NULL;
u32 target_vblank = page_flip->sequence;
struct drm_modeset_acquire_ctx ctx;
@@ -1055,16 +1055,16 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
DRM_DEBUG("Invalid absolute flip target %u, "
  "must be <= %u\n", target_vblank,
  current_vblank + 1);
-   drm_crtc_vblank_put(crtc);
-   return -EINVAL;
+   ret = -EINVAL;
+   goto put_vblank;
}
break;
case DRM_MODE_PAGE_FLIP_TARGET_RELATIVE:
if (target_vblank != 0 && target_vblank != 1) {
DRM_DEBUG("Invalid relative flip target %u, "
  "must be 0 or 1\n", target_vblank);
-   drm_crtc_vblank_put(crtc);
-   return -EINVAL;
+   ret = -EINVAL;
+   goto put_vblank;
}
target_vblank += current_vblank;
break;
@@ -1075,7 +1075,14 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
}
} else if (crtc->funcs->page_flip == NULL ||
   (page_flip->flags & DRM_MODE_PAGE_FLIP_TARGET)) {
-   return -EINVAL;
+   ret = -EINVAL;
+   goto put_vblank;
+   }
+
+   fb = drm_framebuffer_lookup(dev, file_priv, page_flip->fb_id);
+   if (!fb) {
+   ret = -ENOENT;
+   goto put_vblank;
}
 
drm_modeset_acquire_init(&ctx, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
@@ -1101,12 +1108,6 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
goto out;
}
 
-   fb = drm_framebuffer_lookup(dev, file_priv, page_flip->fb_id);
-   if (!fb) {
-   ret = -ENOENT;
-   goto out;
-   }
-
if (plane->state) {
const struct drm_plane_state *state = plane->state;
 
@@ -1170,8 +1171,6 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
}
 
 out:
-   if (fb)
-   drm_framebuffer_put(fb);
if (plane->old_fb)
drm_framebuffer_put(plane->old_fb);
plane->old_fb = NULL;
@@ -1185,6 +1184,8 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
drm_modeset_drop_locks(&ctx);
drm_modeset_acquire_fini(&ctx);
 
+   drm_framebuffer_put(fb);
+put_vblank:
if (ret && crtc->funcs->page_flip_target)
drm_crtc_vblank_put(crtc);
 
-- 
2.16.4

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