Re: [Intel-gfx] [PATCH v4 1/8] cgroup: Allow registration and lookup of cgroup private data (v2)

[kbuild test robot]

Hi Matt,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on next-20180309]
[also build test WARNING on v4.16-rc6]
[cannot apply to v4.16-rc4 v4.16-rc3 v4.16-rc2]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Matt-Roper/cgroup-private-data-and-DRM-i915-integration/20180319-071752
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> kernel/cgroup/cgroup.c:94:1: sparse: symbol 'cgroup_idr_lock' was not 
>> declared. Should it be static?
>> kernel/cgroup/cgroup.c:4655:17: sparse: incorrect type in assignment 
>> (different address spaces) @@expected void **slot @@got void 
>> [noderef] **
>> kernel/cgroup/cgroup.c:4655:17: sparse: incorrect type in assignment 
>> (different address spaces) @@expected void **slot @@got void 
>> [noderef] **
>> kernel/cgroup/cgroup.c:4655:17: sparse: incorrect type in argument 1 
>> (different address spaces) @@expected void [noderef] **slot @@
>> got sn:4>**slot @@
   kernel/cgroup/cgroup.c:4655:17:expected void [noderef] **slot
   kernel/cgroup/cgroup.c:4655:17:got void **slot
>> kernel/cgroup/cgroup.c:4655:17: sparse: incorrect type in assignment 
>> (different address spaces) @@expected void **slot @@got void 
>> [noderef] **
   kernel/cgroup/cgroup.c:2648:20: sparse: context imbalance in 
'cgroup_procs_write_start' - wrong count at exit
   kernel/cgroup/cgroup.c:2704:9: sparse: context imbalance in 
'cgroup_procs_write_finish' - wrong count at exit
   kernel/cgroup/cgroup.c:2815:9: sparse: context imbalance in 
'cgroup_lock_and_drain_offline' - wrong count at exit
   kernel/cgroup/cgroup.c:4375:16: sparse: context imbalance in 
'cgroup_procs_write' - wrong count at exit
   kernel/cgroup/cgroup.c:4416:16: sparse: context imbalance in 
'cgroup_threads_write' - wrong count at exit

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[RFC PATCH] cgroup: cgroup_idr_lock can be static

[kbuild test robot]

Fixes: d6de4e7e9e60 ("cgroup: Allow registration and lookup of cgroup private 
data (v2)")
Signed-off-by: Fengguang Wu 
---
 cgroup.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index c778830..9af6086 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -91,7 +91,7 @@ static DEFINE_IDR(cgroup_priv_idr);
  * Protects cgroup_idr, css_idr, and cgroup_priv_idr so that IDs can be
  * released without grabbing cgroup_mutex.
  */
-DEFINE_SPINLOCK(cgroup_idr_lock);
+static DEFINE_SPINLOCK(cgroup_idr_lock);
 
 /*
  * Protects cgroup_file->kn for !self csses.  It synchronizes notifications
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] gpu: drm: Use list_{next/prev}_entry instead of list_entry

[Arushi Singhal]

This patch replace list_entry with list_{next/prev}_entry as it makes
the code more clear to read.
Done using coccinelle:

@@
expression e1;
identifier e3;
type t;
@@
(
- list_entry(e1->e3.next,t,e3)
+ list_next_entry(e1,e3)
|
- list_entry(e1->e3.prev,t,e3)
+ list_prev_entry(e1,e3)
)

Signed-off-by: Arushi Singhal 
---
 drivers/gpu/drm/drm_lease.c| 2 +-
 drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index 1402c0e..4dcfb5f 100644
--- a/drivers/gpu/drm/drm_lease.c
+++ b/drivers/gpu/drm/drm_lease.c
@@ -340,7 +340,7 @@ static void _drm_lease_revoke(struct drm_master *top)
break;
 
/* Over */
-   master = list_entry(master->lessee_list.next, struct 
drm_master, lessee_list);
+   master = list_next_entry(master, lessee_list);
}
}
 }
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
index e4c8d31..81c3567 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c
@@ -134,7 +134,7 @@ nvkm_cstate_find_best(struct nvkm_clk *clk, struct 
nvkm_pstate *pstate,
   nvkm_volt_map(volt, volt->max2_id, clk->temp));
 
for (cstate = start; >head != >list;
-cstate = list_entry(cstate->head.prev, typeof(*cstate), head)) {
+cstate = list_prev_entry(cstate, head)) {
if (nvkm_cstate_valid(clk, cstate, max_volt, clk->temp))
break;
}
-- 
2.7.4

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

Re: [PATCH 0/2] drm/sun4i: Fix some error handling paths in 'sun4i_hdmi_bind()'

[Chen-Yu Tsai]

On Mon, Mar 19, 2018 at 6:48 AM, Christophe JAILLET
 wrote:
> I've splitted these fixes into 2 patches becasue they do not fixe the same
> commit.
>
> Christophe JAILLET (2):
>   drm/sun4i: hdmi: Fix an error handling path in 'sun4i_hdmi_bind()'
>   drm/sun4i: hdmi: Fix another error handling path in
> 'sun4i_hdmi_bind()'

Reviewed-by: Chen-Yu Tsai 

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

linux-next: manual merge of the drm-misc tree with the drm tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-misc tree got a conflict in:

  drivers/gpu/drm/i915/intel_color.c

between commit:

  db61d160b3ed ("drm/i915: Remove the pointless 1:1 matrix copy")

from the drm tree and commit:

  d5517a39dce4 ("drm/i915: Remove the blob->data casts")

from the drm-misc tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/i915/intel_color.c
index 89ab0f70aa22,768f1c26080e..
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@@ -140,28 -140,20 +140,27 @@@ static void ilk_load_csc_matrix(struct 
int i, pipe = intel_crtc->pipe;
uint16_t coeffs[9] = { 0, };
struct intel_crtc_state *intel_crtc_state = 
to_intel_crtc_state(crtc_state);
 +  bool limited_color_range = false;
 +
 +  /*
 +   * FIXME if there's a gamma LUT after the CSC, we should
 +   * do the range compression using the gamma LUT instead.
 +   */
 +  if (INTEL_GEN(dev_priv) >= 8 || IS_HASWELL(dev_priv))
 +  limited_color_range = intel_crtc_state->limited_color_range;
  
if (intel_crtc_state->ycbcr420) {
 -  i9xx_load_ycbcr_conversion_matrix(intel_crtc);
 +  ilk_load_ycbcr_conversion_matrix(intel_crtc);
return;
} else if (crtc_state->ctm) {
-   struct drm_color_ctm *ctm =
-   (struct drm_color_ctm *)crtc_state->ctm->data;
+   struct drm_color_ctm *ctm = crtc_state->ctm->data;
 -  uint64_t input[9] = { 0, };
 +  const u64 *input;
 +  u64 temp[9];
  
 -  if (intel_crtc_state->limited_color_range) {
 -  ctm_mult_by_limited(input, ctm->matrix);
 -  } else {
 -  for (i = 0; i < ARRAY_SIZE(input); i++)
 -  input[i] = ctm->matrix[i];
 -  }
 +  if (limited_color_range)
 +  input = ctm_mult_by_limited(temp, ctm->matrix);
 +  else
 +  input = ctm->matrix;
  
/*
 * Convert fixed point S31.32 input to format supported by the


pgpa14aMEaCki.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Patch 2/4] dt-bindings: display/ti: Add plane binding to dispc node

[Rob Herring]

On Wed, Mar 14, 2018 at 6:23 AM, Tomi Valkeinen  wrote:
> On 09/03/18 20:27, Benoit Parrot wrote:
>
>>> Is logical plane a h/w concept?
>>
>> It does represent a hardware resource.
>
> Logical plane is not a hw concept, it just describes a group of one or
> two HW planes. Then again, in the context of 2k+ displays, two HW planes
> must always be used together, so that way it could be considered a
> single HW resource.
>
>>> Really, I'm skeptical that any of this belongs in DT. For example,
>>> can't you figure out you need 2 physical planes whenever your
>>> panel/timing width is greater than 2048?
>>
>> As stated in the description I added above, we cannot have resources
>> exposed to user-space which can "disappear" dynamically.
>> Doing so would break user-space applications which rely on these
>> resources.

Isn't this the point of atomic mode setting? If you have 2 planes
free, then you can support the mode, otherwise you fail. How would a
plane be in use if you are doing modesetting unless it is on another
display?

> The question is, if not in DT, then where? I agree that this is not
> exactly describing the HW. But it can't be done dynamically either (or
> at least we have not figured out a way). And it must be user configurable.

If you are plugging in a monitor, doesn't it have to be dynamic?

> Module parameters are an option, but it would be somewhat difficult to
> give all this information there. And also, if your board has a 2k+
> display, you must have these configurations given to the driver, it's
> not optional.

Can't you look at the panel size on boot or module load and determine
if you need to combine planes or not. The main difference I see is
that the driver would have to figure out which planes to use rather
than DT telling it what planes to use. Is deciding which planes a hard
problem?

>
> And while it's perhaps stretching the definitions a bit, I guess one
> could argue that this describes the HW in a way: it describes how the HW
> resources must be used if you have a display of 2k+ width, and is not as
> such related to Linux or DRM.
>
>  Tomi
>
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[GIT PULL] exynos-drm-fixes

[Inki Dae]

Hi Dave,

   Just adding a missed description, '#sound-dai-cells', which is a
   device tree propery of hdmi device node that Exynos SoC device
   tree files have already.

   Please kindly let me know if there is any problem.

Thanks,
Inki Dae


The following changes since commit 3a1b5de36fdf403d1b004e537dc13997633d65df:

  Merge tag 'drm-intel-fixes-2018-03-15' of 
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2018-03-16 12:51:35 
+1000)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos 
tags/exynos-drm-fixes-for-v4.16-rc6

for you to fetch changes up to c15619a88ad43f215bbfb6ee163aa26ba9cc2573:

  dt-bindings: exynos: Document #sound-dai-cells property of the HDMI node 
(2018-03-19 08:42:53 +0900)


Add a device tree property description for hdmi device node
. '#sound-dai-cells' property is required to describe link between
the HDMI IP block and the SoC's audio subsystem and Exynos SoC device
tree files already have this property but we missed its description.


Sylwester Nawrocki (1):
  dt-bindings: exynos: Document #sound-dai-cells property of the HDMI node

 Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt | 1 +
 1 file changed, 1 insertion(+)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 104602] [apitrace] Graphical artifacts in Civilization VI on RX Vega

[bugzilla-daemon]

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

--- Comment #5 from mato...@arcor.de ---
I have the same issue,
i captured a video showing the flickering triangles which i had posted in the
duplicate bug 105353
https://bugs.freedesktop.org/attachment.cgi?id=137806

-- 
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 105353] Textures flickering in Civilizations VI

[bugzilla-daemon]

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

mato...@arcor.de changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #1 from mato...@arcor.de ---
found out that someone had experienced the issue bevore

*** This bug has been marked as a duplicate of bug 104602 ***

-- 
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 104602] [apitrace] Graphical artifacts in Civilization VI on RX Vega

[bugzilla-daemon]

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

mato...@arcor.de changed:

   What|Removed |Added

 CC||mato...@arcor.de

--- Comment #4 from mato...@arcor.de ---
*** Bug 105353 has been marked as a duplicate of this 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

Re: [PATCH] ARM: dts: sun8i-h3: Add Mali node

[Maxime Ripard]

On Tue, Mar 13, 2018 at 11:16:45AM +0100, Giulio Benetti wrote:
> The H3 has an ARM Mali 400 GPU, so add binding to our DT.
> 
> Signed-off-by: Giulio Benetti 

Applied, 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] gpu: drm: Use list_first_entry instead of list_entry

[Arushi Singhal]

This patch replaces list_entry with list_first_entry as it makes the
code more clear.
Done using coccinelle:

@@
expression e;
@@
(
- list_entry(e->next,
+ list_first_entry(e,
  ...)
|
- list_entry(e->prev,
+ list_last_entry(e,
  ...)
)

Signed-off-by: Arushi Singhal 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c | 4 ++--
 drivers/gpu/drm/omapdrm/dss/display.c  | 4 ++--
 drivers/gpu/drm/radeon/radeon_sa.c | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c
index 3144400..646f593 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c
@@ -158,7 +158,7 @@ static void amdgpu_sa_bo_try_free(struct amdgpu_sa_manager 
*sa_manager)
if (sa_manager->hole->next == _manager->olist)
return;
 
-   sa_bo = list_entry(sa_manager->hole->next, struct amdgpu_sa_bo, olist);
+   sa_bo = list_first_entry(sa_manager->hole, struct amdgpu_sa_bo, olist);
list_for_each_entry_safe_from(sa_bo, tmp, _manager->olist, olist) {
if (sa_bo->fence == NULL ||
!dma_fence_is_signaled(sa_bo->fence)) {
@@ -183,7 +183,7 @@ static inline unsigned amdgpu_sa_bo_hole_eoffset(struct 
amdgpu_sa_manager *sa_ma
struct list_head *hole = sa_manager->hole;
 
if (hole->next != _manager->olist) {
-   return list_entry(hole->next, struct amdgpu_sa_bo, 
olist)->soffset;
+   return list_first_entry(hole, struct amdgpu_sa_bo, 
olist)->soffset;
}
return sa_manager->size;
 }
diff --git a/drivers/gpu/drm/omapdrm/dss/display.c 
b/drivers/gpu/drm/omapdrm/dss/display.c
index 0c9480b..fb9ecae 100644
--- a/drivers/gpu/drm/omapdrm/dss/display.c
+++ b/drivers/gpu/drm/omapdrm/dss/display.c
@@ -158,8 +158,8 @@ struct omap_dss_device *omap_dss_get_next_device(struct 
omap_dss_device *from)
goto out;
}
 
-   dssdev = list_entry(l->next, struct omap_dss_device,
-   panel_list);
+   dssdev = list_first_entry(l, struct omap_dss_device,
+ panel_list);
omap_dss_get_device(dssdev);
goto out;
}
diff --git a/drivers/gpu/drm/radeon/radeon_sa.c 
b/drivers/gpu/drm/radeon/radeon_sa.c
index 197b157..66c0482 100644
--- a/drivers/gpu/drm/radeon/radeon_sa.c
+++ b/drivers/gpu/drm/radeon/radeon_sa.c
@@ -158,7 +158,7 @@ static void radeon_sa_bo_try_free(struct radeon_sa_manager 
*sa_manager)
if (sa_manager->hole->next == _manager->olist)
return;
 
-   sa_bo = list_entry(sa_manager->hole->next, struct radeon_sa_bo, olist);
+   sa_bo = list_first_entry(sa_manager->hole, struct radeon_sa_bo, olist);
list_for_each_entry_safe_from(sa_bo, tmp, _manager->olist, olist) {
if (sa_bo->fence == NULL || 
!radeon_fence_signaled(sa_bo->fence)) {
return;
@@ -182,7 +182,7 @@ static inline unsigned radeon_sa_bo_hole_eoffset(struct 
radeon_sa_manager *sa_ma
struct list_head *hole = sa_manager->hole;
 
if (hole->next != _manager->olist) {
-   return list_entry(hole->next, struct radeon_sa_bo, 
olist)->soffset;
+   return list_first_entry(hole, struct radeon_sa_bo, 
olist)->soffset;
}
return sa_manager->size;
 }
-- 
2.7.4

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

[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

[bugzilla-daemon]

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

--- Comment #186 from Chris Heald  ---
I've been doing a lot of experimentation, and I've found a few more things that
I feel are probably related:

* I can force a system hard-lock by doing anything which disables a monitor.
Notably, going full-screen under KDE/Xorg does this, but I can trigger it just
as easily by disabling a monitor with xrandr. Fullscreen under gnome doesn't
seem to trigger the issue, which I suspect is due to gnome's using mutter for
screen management.

* Occassioanlly, the system boots up and gets stuck with a 150MHz memory clock,
rather than clocking up to the 1500MHz state. This causes the display
corruption even if the sclk is set to 500MHz+. Setting the mclk mask manually
fixes display corruption.

* I've been experimenting with different kernels ranging from 4.4 to 4.16rc5.
Earlier kernels feel more susceptible to hard-locking, though the later kernels
aren't immune to it.

* I tried a fresh Ubuntu 16.04 LTS install, and while it did NOT exhibit the
artifacting behavior, the system hard-locked within a few minutes of light
desktop usage.

I've had a few classes of exceptions show up in kern.log:

On 4.4, my kde/wayland session hard-froze when moving a window, and produced a
log like this:

kernel: [  116.904013] radeon :06:00.0: GPU fault detected: 146 0x0d8e040c
kernel: [  116.904017] radeon :06:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR
  0x0001776C
kernel: [  116.904019] radeon :06:00.0:  
VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0E10400C
kernel: [  116.904021] VM fault (0x0c, vmid 7) at page 96108, read from 'TC3'
(0x54433300) (260)
kernel: [  127.306156] radeon :06:00.0: ring 0 stalled for more than
10404msec
kernel: [  127.306164] radeon :06:00.0: GPU lockup (current fence id
0x2419 last fence id 0x2431 on ring 0)
kernel: [  127.357942] radeon :06:00.0: Saved 2200 dwords of commands on
ring 0.
kernel: [  127.357961] radeon :06:00.0: GPU softreset: 0x0009
kernel: [  127.357963] radeon :06:00.0:   GRBM_STATUS=0xF5D01028
kernel: [  127.357965] radeon :06:00.0:   GRBM_STATUS2=0x5008
kernel: [  127.357968] radeon :06:00.0:   GRBM_STATUS_SE0=0xEC42
kernel: [  127.357970] radeon :06:00.0:   GRBM_STATUS_SE1=0xEC42
kernel: [  127.357972] radeon :06:00.0:   GRBM_STATUS_SE2=0x0802
kernel: [  127.357974] radeon :06:00.0:   GRBM_STATUS_SE3=0xEC02
kernel: [  127.357976] radeon :06:00.0:   SRBM_STATUS=0x2040
kernel: [  127.357978] radeon :06:00.0:   SRBM_STATUS2=0x
kernel: [  127.357980] radeon :06:00.0:   SDMA0_STATUS_REG   = 0x46CEE557
kernel: [  127.357982] radeon :06:00.0:   SDMA1_STATUS_REG   = 0x46CEE557
kernel: [  127.357984] radeon :06:00.0:   CP_STAT = 0x84228600
kernel: [  127.357986] radeon :06:00.0:   CP_STALLED_STAT1 = 0x0c00
kernel: [  127.357988] radeon :06:00.0:   CP_STALLED_STAT2 = 0x4000
kernel: [  127.357991] radeon :06:00.0:   CP_STALLED_STAT3 = 0x0400
kernel: [  127.357993] radeon :06:00.0:   CP_CPF_BUSY_STAT = 0x0006
kernel: [  127.357995] radeon :06:00.0:   CP_CPF_STALLED_STAT1 = 0x0003
kernel: [  127.357997] radeon :06:00.0:   CP_CPF_STATUS = 0x8063
kernel: [  127.357999] radeon :06:00.0:   CP_CPC_BUSY_STAT = 0x
kernel: [  127.358001] radeon :06:00.0:   CP_CPC_STALLED_STAT1 = 0x
kernel: [  127.358003] radeon :06:00.0:   CP_CPC_STATUS = 0x
kernel: [  127.358005] radeon :06:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR
  0x
kernel: [  127.358007] radeon :06:00.0:  
VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x
kernel: [  127.404670] radeon :06:00.0: GRBM_SOFT_RESET=0x00010001
kernel: [  127.404725] radeon :06:00.0: SRBM_SOFT_RESET=0x0100
kernel: [  127.405874] radeon :06:00.0:   GRBM_STATUS=0x3028
kernel: [  127.405876] radeon :06:00.0:   GRBM_STATUS2=0x0008
kernel: [  127.405878] radeon :06:00.0:   GRBM_STATUS_SE0=0x0006
kernel: [  127.405880] radeon :06:00.0:   GRBM_STATUS_SE1=0x0006
kernel: [  127.405882] radeon :06:00.0:   GRBM_STATUS_SE2=0x0006
kernel: [  127.405884] radeon :06:00.0:   GRBM_STATUS_SE3=0x0006
kernel: [  127.405885] radeon :06:00.0:   SRBM_STATUS=0x2A40
kernel: [  127.405887] radeon :06:00.0:   SRBM_STATUS2=0x
kernel: [  127.405889] radeon :06:00.0:   SDMA0_STATUS_REG   = 0x46CEE557
kernel: [  127.405891] radeon :06:00.0:   SDMA1_STATUS_REG   = 0x46CEE557
kernel: [  127.405893] radeon :06:00.0:   CP_STAT = 0x
kernel: [  127.405893] radeon :06:00.0:   CP_STAT = 0x
kernel: [  127.405895] radeon :06:00.0:   CP_STALLED_STAT1 = 0x
kernel: [  127.405896] radeon :06:00.0:   CP_STALLED_STAT2 = 0x
kernel: [  127.405898] radeon :06:00.0:   CP_STALLED_STAT3 = 0x
kernel: [  127.405900] radeon :06:00.0:   

WARNING: CPU: 5 PID: 74 at ../drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h:170 nvkm_dp_enable+0xbe/0x140 [nouveau]

[Luis R. Rodriguez]

I have been getting the following splat for  while now, guess its time to
report, this is on 4.15.8-1-default (OpenSUSE Tumbleweed). I could try
a more up to date kernel if we think this can be fixed.

Mar 16 16:48:18 olga kernel: kvm: SMP vm created on host with unstable TSC; 
guest TSC will not be reliable
Mar 16 18:28:59 olga kernel: WARNING: CPU: 5 PID: 74 at 
../drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h:170 
nvkm_dp_enable+0xbe/0x140 [nouveau]
Mar 16 18:28:59 olga kernel: Modules linked in: ipt_MASQUERADE 
nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 
nf_nat nf_conntrack libcrc32c iptable_filter ip
Mar 16 18:28:59 olga kernel:  i2c_algo_bit drm_kms_helper syscopyarea 
sysfillrect sysimgblt fb_sys_fops xhci_hcd ehci_hcd sr_mod ttm cdrom usbcore 
ata_generic drm wmi button sg dm_multipath 
Mar 16 18:28:59 olga kernel: CPU: 5 PID: 74 Comm: kworker/5:1 Not tainted 
4.15.8-1-default #1
Mar 16 18:28:59 olga kernel: Hardware name: Dell Inc. Precision T3610/09M8Y8, 
BIOS A03 09/05/2013
Mar 16 18:28:59 olga kernel: Workqueue: events nvkm_notify_work [nouveau]
Mar 16 18:28:59 olga kernel: RIP: 0010:nvkm_dp_enable+0xbe/0x140 [nouveau]
Mar 16 18:28:59 olga kernel: RSP: 0018:bad4c1c27e30 EFLAGS: 00010287
Mar 16 18:28:59 olga kernel: RAX:  RBX: 92daf85fbc00 RCX: 
bad4c1c27e37
Mar 16 18:28:59 olga kernel: RDX: bad4c300e4e4 RSI: bad4c300e4e4 RDI: 
0100900f
Mar 16 18:28:59 olga kernel: RBP: 92daf85ae000 R08: 92daf85fbd11 R09: 
bad4c1c27e37
Mar 16 18:28:59 olga kernel: R10:  R11:  R12: 
92dc1a594620
Mar 16 18:28:59 olga kernel: R13: 92daf8831b40 R14: 092dc2fd6860 R15: 
92d94581cc00
Mar 16 18:28:59 olga kernel: FS:  () 
GS:92dc2fd4() knlGS:
Mar 16 18:28:59 olga kernel: CS:  0010 DS:  ES:  CR0: 80050033
Mar 16 18:28:59 olga kernel: CR2: 01895000 CR3: 00033800a004 CR4: 
001626e0
Mar 16 18:28:59 olga kernel: Call Trace:
Mar 16 18:28:59 olga kernel:  nvkm_dp_hpd+0x113/0x120 [nouveau]
Mar 16 18:28:59 olga kernel:  nvkm_notify_work+0x1e/0x70 [nouveau]
Mar 16 18:28:59 olga kernel:  process_one_work+0x1d1/0x400
Mar 16 18:28:59 olga kernel:  worker_thread+0x2b/0x3d0
Mar 16 18:28:59 olga kernel:  ? process_one_work+0x400/0x400
Mar 16 18:28:59 olga kernel:  kthread+0x113/0x130
Mar 16 18:28:59 olga kernel:  ? kthread_create_worker_on_cpu+0x50/0x50
Mar 16 18:28:59 olga kernel:  ret_from_fork+0x3a/0x50
Mar 16 18:28:59 olga kernel: Code: 4c 8d 4c 24 07 4c 8d 83 11 01 00 00 31 c9 ba 
09 00 00 00 be 01 00 00 00 48 89 ef e8 cd 31 fd ff 85 c0 75 75 80 7c 24 07 10 
74 02 <0f> 0b 48 89 ef e8 c8 2f 
Mar 16 18:28:59 olga kernel: ---[ end trace 86032f0cbd15 ]---

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

[Bug 105005] No image after downtime (RX460)

[bugzilla-daemon]

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

--- Comment #15 from Dmitry  ---
TearFree works, I did the configuration file wrong. Problems if the string is
entered after "EndSection".

P.S. But with the inclusion of regular V-sync xorg, still problems even with
the latest xf86-amgpu.

-- 
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

[AMD TAHITI XT][bisected] 83e3c46158720af39eef49e7066ee091e60e773a broke linux

[sylvain . bertrand]

Hi,

I bisected a commit which broke my amd tahiti xt support.

repo: git://people.freedesktop.org/~agd5f/linux
branch: amd-staging-drm-next

bad commit:83e3c46158720af39eef49e7066ee091e60e773a
last good commit:f97eb9dba72fadc7c3ee1ed585246450fa927127

regards,

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

[Bug 198123] Console is the wrong color at boot with radeon 6670

[bugzilla-daemon]

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

--- Comment #43 from Alex Deucher (alexdeuc...@gmail.com) ---
Please attach the full dump for each case.

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

Re: [PATCH 1/2] dt-bindings: analogix-dp: Add backlight-pwm-passthru

[Rob Herring]

On Fri, Mar 16, 2018 at 02:56:09PM +0530, Archit Taneja wrote:
> 
> 
> On Friday 16 March 2018 08:26 AM, Alexandru M Stan wrote:
> > Documentation for the optional backlight-pwm-passthru property.
> > Tells the EDP panel to folow the input pwm frequency instead
> 
> s/folow/follow
> 
> It would be nice if we could add the details you mentioned in
> patch #0 in either this or the next patch.
> 
> > of generating its own.
> 
> This is one of those bindings which is more a knob than a HW property,
> but I can't think of any easy way to figure this out in SW. So, I guess
> it's okay to have.
> 
> One thing I was wondering about was whether this prop should belong to
> the eDP controller or the eDP panel. I don't have any strong opinion
> about it, though.

Seems to me, it should be the panel. It's a setting in the panel, right?

Is this generic to DP panels or something specific to a certain panel? 
The naming (vendor prefix or not) and doc location should match 
whatever the answer to that is.

> 
> Reviewed-by: Archit Taneja 
> 
> Thanks,
> Archit
> 
> 
> > 
> > Signed-off-by: Alexandru M Stan 
> > ---
> > 
> >   Documentation/devicetree/bindings/display/bridge/analogix_dp.txt | 4 
> >   1 file changed, 4 insertions(+)
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt 
> > b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
> > index 0c7473dd0e51..3c15242f6ce3 100644
> > --- a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
> > +++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
> > @@ -23,6 +23,10 @@ Required properties for dp-controller:
> > from general PHY binding: Should be "dp".
> >   Optional properties for dp-controller:
> > +   -backlight-pwm-passthru:
> > +   Directly pass the PWM frequency applied to the BL_PWM_DIM
> > +   pin to the backlight current source. Done via
> > +   EDP_BACKLIGHT_MODE_SET_REGISTER on DPCD.
> > -force-hpd:
> > Indicate driver need force hpd when hpd detect failed, this
> > is used for some eDP screen which don't have hpd signal.
> > 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/8] drm/sun4i: Add compatible strings for A80 TCONs

[Rob Herring]

On Thu, Mar 15, 2018 at 07:41:29PM +0800, Chen-Yu Tsai wrote:
> The A80 has 2 or 3 TCONs. The documentation and vendor kernel are very
> vague about the third TCON, to the point that it might not exist.
> 
> In the documentation, the first TCON is missing channel 1, and the
> second is missing channel 0. However the vendor kernel seems to be
> able to use them regardless. Here we model them like the old TCONs.
> 
> An oddity is that TCON0 requires the reset control for the eDP block
> to be deasserted, for any register access to stick.
> 
> This patch adds compatible strings for TCON0 and TCON1, with TCON0
> requiring an extra "edp" reset control.
> 
> Signed-off-by: Chen-Yu Tsai 
> ---
>  Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 11 
> ---
>  1 file changed, 8 insertions(+), 3 deletions(-)

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

Re: [PATCH 2/8] drm/sun4i: Add DT binding for Detail Enhancement Unit in Allwinner A80 SoC

[Rob Herring]

On Thu, Mar 15, 2018 at 07:41:30PM +0800, Chen-Yu Tsai wrote:
> The display pipeline on the A80 SoC has what is called the Detail
> Enhancement Unit, or DEU for short, block in between the display
> frontend and backend. This unit can sharpen images in both luma
> and chroma channels. It seems to also do colorspace conversion.
> 
> This patch adds the device tree binding for this hardware block.
> 
> Signed-off-by: Chen-Yu Tsai 
> ---
>  .../bindings/display/sunxi/sun4i-drm.txt   | 22 
> ++
>  1 file changed, 22 insertions(+)

Reviewed-by: Rob Herring 

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

Re: [PATCH 4/8] drm/sun4i: Add compatible strings for the A80 display pipeline

[Rob Herring]

On Thu, Mar 15, 2018 at 07:41:32PM +0800, Chen-Yu Tsai wrote:
> This patch adds compatible strings for the remaining documented
> components of the Allwinner A80 display pipeline.
> 
> Signed-off-by: Chen-Yu Tsai 
> ---
>  Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)

Reviewed-by: Rob Herring 

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

Re: [DPU PATCH 1/2] dt-bindings: msm/disp: Remove hw block offset DT entries for SDM845

[Rob Herring]

On Wed, Mar 14, 2018 at 11:21:37AM +0530, Sravanthi Kollukuduru wrote:
> Remove DT entries of hw block offsets and other target specific catalog
> information for SDM845.

That is clear from the diff. The commit msg should answer why?

> 
> Signed-off-by: Sravanthi Kollukuduru 
> ---
>  .../devicetree/bindings/display/msm/dpu.txt| 530 
> -

This file is not upstream. What tree is this for?

>  1 file changed, 530 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] ARM: dts: sun8i-h3: Add Mali node

[Rob Herring]

On Tue, Mar 13, 2018 at 11:16:45AM +0100, Giulio Benetti wrote:
> The H3 has an ARM Mali 400 GPU, so add binding to our DT.
> 
> Signed-off-by: Giulio Benetti 
> ---
>  .../devicetree/bindings/gpu/arm,mali-utgard.txt|  1 +
>  arch/arm/boot/dts/sun8i-h3.dtsi| 27 
> ++
>  2 files changed, 28 insertions(+)

Reviewed-by: Rob Herring 

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

[Bug 105576] Random lockup on mode switch

[bugzilla-daemon]

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

Bug ID: 105576
   Summary: Random lockup on mode switch
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: denisgolo...@yandex.ru

Hi

I experience random lock-ups when X starts.
It appears as system freeze just after X switch to graphic mode.
/var/log/messages contains: 

Mar 17 23:33:24 desktop64 kernel: [drm:amdgpu_atombios_dp_link_train] *ERROR*
displayport link status failed
Mar 17 23:33:24 desktop64 kernel: [drm:amdgpu_atombios_dp_link_train] *ERROR*
clock recovery failed
Mar 17 23:33:24 desktop64 kernel: [drm:amdgpu_atombios_dp_link_train] *ERROR*
displayport link status failed
Mar 17 23:33:24 desktop64 kernel: [drm:amdgpu_atombios_dp_link_train] *ERROR*
clock recovery failed
Mar 17 23:33:25 desktop64 kernel: [drm:amdgpu_atombios_dp_link_train] *ERROR*
displayport link status failed
Mar 17 23:33:25 desktop64 kernel: [drm:amdgpu_atombios_dp_link_train] *ERROR*
clock recovery failed
Mar 17 23:33:25 desktop64 kernel: [drm:amdgpu_atombios_dp_link_train] *ERROR*
displayport link status failed
Mar 17 23:33:25 desktop64 kernel: [drm:amdgpu_atombios_dp_link_train] *ERROR*
clock recovery failed

Tested under https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.17-wip
with amddc disabled. Video card - Radeon RX580

-- 
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 199133] nouveau_mem_host+0x47/0x1b0 [nouveau]: NULL pointer dereference at 0000000000000040

[bugzilla-daemon]

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

Hector Cavalcanti Saavedra (hectorcavalcantisaave...@gmail.com) changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |PATCH_ALREADY_AVAILABLE

--- Comment #3 from Hector Cavalcanti Saavedra 
(hectorcavalcantisaave...@gmail.com) ---
(In reply to Pierre Moreau from comment #2)
> Could you please try with the patch mentioned in
> https://bugs.freedesktop.org/show_bug.cgi?id=105174 (which was submitted
> along other drm-fixes this week)?
> 
> Also, fyi, the Nouveau bugs are reported at https://bugs.freedesktop.org;
> see https://nouveau.freedesktop.org/wiki/Bugs/ for more details.

Oops, my bad. Thank you for the patch, I'm going to try it and close this bug.

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

[RFC PATCH 3/3] drm: bridge: lvds-encoder: on request, override the bus format

[Peter Rosin]

If the bridge changes the bus format, allow this to be described in
the bridge, instead of providing false information about the bus
format of the panel itself.

Signed-off-by: Peter Rosin 
---
 .../bindings/display/bridge/lvds-transmitter.txt   |  8 
 drivers/gpu/drm/bridge/lvds-encoder.c  | 18 ++
 2 files changed, 26 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt 
b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
index 9d09190d9210..c0fbe74272e7 100644
--- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
+++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
@@ -29,6 +29,14 @@ Required properties:
 
  "ti,ds90c185"
 
+Optional properties:
+
+- interface-pix-fmt:
+ Override the bus format of the panel, in case the bridge
+ converts the signals. Recognized formats include:
+
+ "rgb565"
+
 Required nodes:
 
 This device has two video ports. Their connections are modeled using the OF
diff --git a/drivers/gpu/drm/bridge/lvds-encoder.c 
b/drivers/gpu/drm/bridge/lvds-encoder.c
index 75b0d3f6e4de..acff3a5b0562 100644
--- a/drivers/gpu/drm/bridge/lvds-encoder.c
+++ b/drivers/gpu/drm/bridge/lvds-encoder.c
@@ -39,6 +39,9 @@ static int lvds_encoder_probe(struct platform_device *pdev)
struct device_node *panel_node;
struct drm_panel *panel;
struct lvds_encoder *lvds_encoder;
+   u32 bus_format = 0;
+   const char *fmt;
+   int ret;
 
lvds_encoder = devm_kzalloc(>dev, sizeof(*lvds_encoder),
GFP_KERNEL);
@@ -79,6 +82,21 @@ static int lvds_encoder_probe(struct platform_device *pdev)
if (IS_ERR(lvds_encoder->panel_bridge))
return PTR_ERR(lvds_encoder->panel_bridge);
 
+   ret = of_property_read_string(pdev->dev.of_node,
+ "interface-pix-fmt", );
+   if (!ret) {
+   if (!strcmp(fmt, "rgb565")) {
+   bus_format = MEDIA_BUS_FMT_RGB565_1X16;
+   } else {
+   dev_dbg(>dev,
+   "requested interface-pix-fmt not recognized\n");
+   return -EINVAL;
+   }
+   }
+   if (bus_format)
+   drm_panel_bridge_set_bus_format(lvds_encoder->panel_bridge,
+   bus_format);
+
/* The panel_bridge bridge is attached to the panel's of_node,
 * but we need a bridge attached to our of_node for our user
 * to look up.
-- 
2.11.0

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

[RFC PATCH 0/3] allow override of bus format in bridges

[Peter Rosin]

I'm trying to get something to work that I assumed would not
need patches, so I think I might be missing something completely
obvious...

I have an Atmel sama5d31 hooked up to an lvds encoder and then
on to an lvds panel. Which seems like something that has been
done one or two times before...

The problem (I think) is that the bus_format of the SoC and the
panel do not agree. The SoC driver (atmel-hlcdc) can handle the
rgb444, rgb565, rgb666 and rgb888 bus formats. The hardware is
wired for the rgb565 case. The lvds encoder supports rgb888 on
its input side with the LSB wires simply pulled down internally
in the encoder in my case. And the panel is expecting lvds
(vesa-24), which is what the encoder outputs.

The reason I "blame" the bus_format of the drm_connector is that
with the below DT snippet, things do not work *exactly* due to
that. At least, it starts to work if I hack the panel-lvds driver
to report the rgb565 bus_format instead of vesa-24.

panel: panel {
compatible = "panel-lvds";

width-mm = <476>;
height-mm = <268>;

data-mapping = "vesa-24";

panel-timing {
// 1024x768 @ 60Hz (typical)
clock-frequency = <5214 6500 7110>;
hactive = <1024>;
vactive = <768>;
hfront-porch = <59 107 107>;
hback-porch = <59 107 107>;
hsync-len = <59 106 106>;
vfront-porch = <8 13 14>;
vback-porch = <8 13 14>;
vsync-len = <8 12 14>;
};

port {
panel_input: endpoint {
remote-endpoint = <_encoder_output>;
};
};
};

lvds-encoder {
compatible = "ti,ds90c187", "lvds-encoder";

ports {
#address-cells = <1>;
#size-cells = <0>;

port@0 {
reg = <0>;

lvds_encoder_input: endpoint {
remote-endpoint = <_output>;
};
};

port@1 {
reg = <1>;

lvds_encoder_output: endpoint {
remote-endpoint = <_input>;
};
};
};
};

But, instead of perverting the panel-lvds driver with support
for a totally fake non-lvds bus_format, I came up with an optional
bus_format override in the lvds-encoder driver, which I trigger with
this addition to the lvds-encoder DT node:

interface-pix-fmt = "rgb565";

There are some issues with the interface-pix-fmt name. I copied it
from the freescale fsl-imx-drm binding, but a) I personally don't
like how that binding uses rgb24 instead of rgb888 and b) I don't
like how the implementation of that binding selects rgb666 when you
say bgr666 in the DT, but for parallel hardware interface the bit
order is not really relevant so I swallowed that. Anyway, it might
be better to use something else than interface-pix-fmt? Perhaps
reuse the "data-mapping" name from the panel-lvds binding? But that
seems somewhat lvds specific? Then there a couple of instances of
"bus-format-override" in some dtsi files, but that name is not
mentioned in any binding, nor in (upstream) code...

And maybe it should be fourcc codes or something instead of these
"rgb565" names?

I threw in the first patch, since that is the actual lvds encoder
I have in this case.

Suggestions welcome.

Cheers,
Peter

Peter Rosin (3):
  dt-bindings: display: bridge: lvds-transmitter: add ti,ds90c185
  drm: bridge: panel: allow override of the bus format
  drm: bridge: lvds-encoder: on request, override the bus format

 .../bindings/display/bridge/lvds-transmitter.txt   | 13 +
 drivers/gpu/drm/bridge/lvds-encoder.c  | 18 ++
 drivers/gpu/drm/bridge/panel.c | 22 +-
 include/drm/drm_bridge.h   |  1 +
 4 files changed, 53 insertions(+), 1 deletion(-)

-- 
2.11.0

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

[RFC PATCH 2/3] drm: bridge: panel: allow override of the bus format

[Peter Rosin]

Useful if the bridge does some kind of conversion of the bus format.

Signed-off-by: Peter Rosin 
---
 drivers/gpu/drm/bridge/panel.c | 22 +-
 include/drm/drm_bridge.h   |  1 +
 2 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
index 6d99d4a3beb3..ccef0283ff41 100644
--- a/drivers/gpu/drm/bridge/panel.c
+++ b/drivers/gpu/drm/bridge/panel.c
@@ -22,6 +22,7 @@ struct panel_bridge {
struct drm_connector connector;
struct drm_panel *panel;
u32 connector_type;
+   u32 bus_format;
 };
 
 static inline struct panel_bridge *
@@ -40,8 +41,15 @@ static int panel_bridge_connector_get_modes(struct 
drm_connector *connector)
 {
struct panel_bridge *panel_bridge =
drm_connector_to_panel_bridge(connector);
+   int ret;
+
+   ret = drm_panel_get_modes(panel_bridge->panel);
+
+   if (panel_bridge->bus_format)
+   drm_display_info_set_bus_formats(>display_info,
+_bridge->bus_format, 1);
 
-   return drm_panel_get_modes(panel_bridge->panel);
+   return ret;
 }
 
 static const struct drm_connector_helper_funcs
@@ -203,6 +211,18 @@ void drm_panel_bridge_remove(struct drm_bridge *bridge)
 }
 EXPORT_SYMBOL(drm_panel_bridge_remove);
 
+void drm_panel_bridge_set_bus_format(struct drm_bridge *bridge, u32 bus_format)
+{
+   struct panel_bridge *panel_bridge;
+
+   if (!bridge)
+   return;
+
+   panel_bridge = drm_bridge_to_panel_bridge(bridge);
+   panel_bridge->bus_format = bus_format;
+}
+EXPORT_SYMBOL(drm_panel_bridge_set_bus_format);
+
 static void devm_drm_panel_bridge_release(struct device *dev, void *res)
 {
struct drm_bridge **bridge = res;
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 682d01ba920c..81903b92f187 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -268,6 +268,7 @@ void drm_bridge_enable(struct drm_bridge *bridge);
 struct drm_bridge *drm_panel_bridge_add(struct drm_panel *panel,
u32 connector_type);
 void drm_panel_bridge_remove(struct drm_bridge *bridge);
+void drm_panel_bridge_set_bus_format(struct drm_bridge *bridge, u32 
bus_format);
 struct drm_bridge *devm_drm_panel_bridge_add(struct device *dev,
 struct drm_panel *panel,
 u32 connector_type);
-- 
2.11.0

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

[RFC PATCH 1/3] dt-bindings: display: bridge: lvds-transmitter: add ti, ds90c185

[Peter Rosin]

Start list of actual chips compatible with "lvds-encoder".

Signed-off-by: Peter Rosin 
---
 .../devicetree/bindings/display/bridge/lvds-transmitter.txt  | 5 +
 1 file changed, 5 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt 
b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
index fd39ad34c383..9d09190d9210 100644
--- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
+++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
@@ -24,6 +24,11 @@ Required properties:
 
 - compatible: Must be "lvds-encoder"
 
+ Known actual chips (these should still use "lvds-encoder" as a
+ fallback compatible) include:
+
+ "ti,ds90c185"
+
 Required nodes:
 
 This device has two video ports. Their connections are modeled using the OF
-- 
2.11.0

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

Re: [PATCH v1 3/3] drm/tegra: dc: Dedicate overlay plane to cursor on older Tegra's

[Dmitry Osipenko]

On 16.03.2018 10:36, Daniel Vetter wrote:
> On Thu, Mar 15, 2018 at 11:45 AM, Thierry Reding
>  wrote:
>> On Thu, Mar 15, 2018 at 04:00:25AM +0300, Dmitry Osipenko wrote:
>>> Older Tegra's do not support RGBA format for the cursor, but instead
>>> overlay plane could be used for it. Since there is no much use for the
>>> overlays on a regular desktop and HW-accelerated cursor is much better
>>> than a SW cursor, let's dedicate one overlay plane to the mouse cursor.
>>>
>>> Signed-off-by: Dmitry Osipenko 
>>> ---
>>>  drivers/gpu/drm/tegra/dc.c | 28 +++-
>>>  1 file changed, 23 insertions(+), 5 deletions(-)
>>
>> Applied. I'm not entirely happy that we need to sacrifice one of the
>> overlay windows for this, but you're right, it's probably okay given
>> how little planes are used on a regular desktop.
>>
>> We could always provide a module parameter to switch this on and off
>> if that's ever something we want.
> 
> The idea with universal planes is that you can (at least try to) use
> the cursor overlay plane as a normal plane. It is only a hint to
> userspace, there's no requirement anywhere in atomic that you only use
> it as a cursor. That way desktops get a good hint for what the cursor
> plane should be, everyone else can still use all the planes.

Indeed, thank you for pointing at it. That is a nice feature.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/3] drm/vc4: Add color transformation matrix (CTM) support

[kbuild test robot]

Hi Stefan,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on v4.16-rc4]
[also build test ERROR on next-20180316]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Stefan-Schake/drm-vc4-Atomic-color-management-support/20180318-120701
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

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

   drivers/gpu/drm/vc4/vc4_crtc.c: In function 'vc4_crtc_update_gamma_lut':
   drivers/gpu/drm/vc4/vc4_crtc.c:305:30: error: initialization from 
incompatible pointer type [-Werror=incompatible-pointer-types]
 struct drm_color_lut *lut = crtc->state->gamma_lut->data;
 ^~~~
   drivers/gpu/drm/vc4/vc4_crtc.c: In function 'vc4_crtc_update_ctm':
   drivers/gpu/drm/vc4/vc4_crtc.c:340:30: error: initialization from 
incompatible pointer type [-Werror=incompatible-pointer-types]
 struct drm_color_ctm *ctm = crtc->state->ctm->data;
 ^~~~
   In file included from drivers/gpu/drm/vc4/vc4_crtc.c:42:0:
>> drivers/gpu/drm/vc4/vc4_crtc.c:344:5: error: 'SCALER_OLEDCOEF2_R_TO_R_SHIFT' 
>> undeclared (first use in this function); did you mean 
>> 'SCALER_CSC0_COEF_CR_OFS_SHIFT'?
SCALER_OLEDCOEF2_R_TO_R) |
^
   drivers/gpu/drm/vc4/vc4_drv.h:301:39: note: in definition of macro 
'HVS_WRITE'
#define HVS_WRITE(offset, val) writel(val, vc4->hvs->regs + offset)
  ^~~
>> drivers/gpu/drm/vc4/vc4_crtc.c:343:5: note: in expansion of macro 
>> 'VC4_SET_FIELD'
VC4_SET_FIELD(vc4_crtc_s31_32_to_s0_9(ctm->matrix[0]),
^
   drivers/gpu/drm/vc4/vc4_crtc.c:344:5: note: each undeclared identifier is 
reported only once for each function it appears in
SCALER_OLEDCOEF2_R_TO_R) |
^
   drivers/gpu/drm/vc4/vc4_drv.h:301:39: note: in definition of macro 
'HVS_WRITE'
#define HVS_WRITE(offset, val) writel(val, vc4->hvs->regs + offset)
  ^~~
>> drivers/gpu/drm/vc4/vc4_crtc.c:343:5: note: in expansion of macro 
>> 'VC4_SET_FIELD'
VC4_SET_FIELD(vc4_crtc_s31_32_to_s0_9(ctm->matrix[0]),
^
>> drivers/gpu/drm/vc4/vc4_crtc.c:344:5: error: 'SCALER_OLEDCOEF2_R_TO_R_MASK' 
>> undeclared (first use in this function); did you mean 
>> 'SCALER_OLEDCOEF2_R_TO_R_SHIFT'?
SCALER_OLEDCOEF2_R_TO_R) |
^
   drivers/gpu/drm/vc4/vc4_drv.h:301:39: note: in definition of macro 
'HVS_WRITE'
#define HVS_WRITE(offset, val) writel(val, vc4->hvs->regs + offset)
  ^~~
>> drivers/gpu/drm/vc4/vc4_regs.h:19:3: note: in expansion of macro 'WARN_ON'
  WARN_ON((fieldval & ~field##_MASK) != 0);  \
  ^~~
>> drivers/gpu/drm/vc4/vc4_crtc.c:343:5: note: in expansion of macro 
>> 'VC4_SET_FIELD'
VC4_SET_FIELD(vc4_crtc_s31_32_to_s0_9(ctm->matrix[0]),
^
>> drivers/gpu/drm/vc4/vc4_crtc.c:346:5: error: 'SCALER_OLEDCOEF2_R_TO_G_SHIFT' 
>> undeclared (first use in this function); did you mean 
>> 'SCALER_OLEDCOEF2_R_TO_R_SHIFT'?
SCALER_OLEDCOEF2_R_TO_G) |
^
   drivers/gpu/drm/vc4/vc4_drv.h:301:39: note: in definition of macro 
'HVS_WRITE'
#define HVS_WRITE(offset, val) writel(val, vc4->hvs->regs + offset)
  ^~~
   drivers/gpu/drm/vc4/vc4_crtc.c:345:5: note: in expansion of macro 
'VC4_SET_FIELD'
VC4_SET_FIELD(vc4_crtc_s31_32_to_s0_9(ctm->matrix[3]),
^
>> drivers/gpu/drm/vc4/vc4_crtc.c:346:5: error: 'SCALER_OLEDCOEF2_R_TO_G_MASK' 
>> undeclared (first use in this function); did you mean 
>> 'SCALER_OLEDCOEF2_R_TO_R_MASK'?
SCALER_OLEDCOEF2_R_TO_G) |
^
   drivers/gpu/drm/vc4/vc4_drv.h:301:39: note: in definition of macro 
'HVS_WRITE'
#define HVS_WRITE(offset, val) writel(val, vc4->hvs->regs + offset)
  ^~~
>> drivers/gpu/drm/vc4/vc4_regs.h:19:3: note: in expansion of macro 'WARN_ON'
  WARN_ON((fieldval & ~field##_MASK) != 0);  \
  ^~~
   drivers/gpu/drm/vc4/vc4_crtc.c:345:5: note: in expansion of macro 
'VC4_SET_FIELD'
VC4_SET_FIELD(vc4_crtc_s31_32_to_s0_9(ctm->matrix[3]),
^
>> drivers/gpu/drm/vc4/vc4_crtc.c:348:5: error: 'SCALER_OLEDCOEF2_R_TO_B_SHIFT' 
>> undeclared (first use in this function); did you mean 
>> 'SCALER_OLEDCOEF2_R_TO_G_SHIFT'?
SCALER_OLEDCOEF2_R_TO_B));
^
   drivers/gpu/drm/vc4/vc4_drv.h:301:39: note: in definition of macro 
'HVS_WRITE'
#defin

Re: [PATCH] drm/amdkfd: fix uninitialized variable use

[Oded Gabbay]

On Thu, Mar 15, 2018 at 6:49 PM, Arnd Bergmann  wrote:
> When CONFIG_ACPI is disabled, we never initialize the acpi_table
> structure in kfd_create_crat_image_virtual:
>
> drivers/gpu/drm/amd/amdkfd/kfd_crat.c: In function 
> 'kfd_create_crat_image_virtual':
> drivers/gpu/drm/amd/amdkfd/kfd_crat.c:888:40: error: 'acpi_table' may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
>
> The undefined behavior also happens for any other acpi_get_table()
> failure, but then the compiler can't warn about it.
>
> This adds an error check that prevents the structure from
> being used in error, avoiding both the undefined behavior and
> the warning about it.
>
> Fixes: 520b8fb755cc ("drm/amdkfd: Add topology support for CPUs")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/gpu/drm/amd/amdkfd/kfd_crat.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c 
> b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> index 7493f47e7fe1..d85112224f1d 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_crat.c
> @@ -882,7 +882,7 @@ static int kfd_create_vcrat_image_cpu(void *pcrat_image, 
> size_t *size)
> crat_table->length = sizeof(struct crat_header);
>
> status = acpi_get_table("DSDT", 0, _table);
> -   if (status == AE_NOT_FOUND)
> +   if (status != AE_OK)
> pr_warn("DSDT table not found for OEM information\n");
> else {
> crat_table->oem_revision = acpi_table->revision;
> --
> 2.9.0
>

Thanks!
Applied to -next
Oded
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/vc4: Expose gamma as atomic property

[kbuild test robot]

Hi Stefan,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on v4.16-rc4]
[also build test ERROR on next-20180316]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Stefan-Schake/drm-vc4-Atomic-color-management-support/20180318-120701
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/vc4/vc4_crtc.c: In function 'vc4_crtc_update_gamma_lut':
>> drivers/gpu/drm/vc4/vc4_crtc.c:305:30: error: initialization from 
>> incompatible pointer type [-Werror=incompatible-pointer-types]
 struct drm_color_lut *lut = crtc->state->gamma_lut->data;
 ^~~~
   cc1: some warnings being treated as errors

vim +305 drivers/gpu/drm/vc4/vc4_crtc.c

   300  
   301  static void
   302  vc4_crtc_update_gamma_lut(struct drm_crtc *crtc)
   303  {
   304  struct vc4_crtc *vc4_crtc = to_vc4_crtc(crtc);
 > 305  struct drm_color_lut *lut = crtc->state->gamma_lut->data;
   306  u32 length = crtc->state->gamma_lut->length / sizeof(*lut);
   307  u32 i;
   308  
   309  for (i = 0; i < length; i++) {
   310  vc4_crtc->lut_r[i] = drm_color_lut_extract(lut[i].red, 
8);
   311  vc4_crtc->lut_g[i] = 
drm_color_lut_extract(lut[i].green, 8);
   312  vc4_crtc->lut_b[i] = drm_color_lut_extract(lut[i].blue, 
8);
   313  }
   314  
   315  vc4_crtc_lut_load(crtc);
   316  }
   317  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3] drm/vc4: Restrict active CTM to one CRTC

[kbuild test robot]

Hi Stefan,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on v4.16-rc4]
[also build test WARNING on next-20180316]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Stefan-Schake/drm-vc4-Atomic-color-management-support/20180318-120701
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sh 

All warnings (new ones prefixed by >>):

^
   drivers/gpu/drm/vc4/vc4_crtc.c:362:5: error: 'SCALER_OLEDCOEF0_B_TO_B_MASK' 
undeclared (first use in this function); did you mean 
'SCALER_OLEDCOEF0_B_TO_G_MASK'?
SCALER_OLEDCOEF0_B_TO_B));
^
   arch/sh/include/asm/io.h:31:77: note: in definition of macro '__raw_writel'
#define __raw_writel(v,a) (__chk_io_ptr(a), *(volatile u32 __force *)(a) = 
(v))

^
   arch/sh/include/asm/io.h:46:62: note: in expansion of macro 'ioswabl'
#define writel_relaxed(v,c) ((void)__raw_writel((__force u32)ioswabl(v),c))
 ^~~
   arch/sh/include/asm/io.h:56:32: note: in expansion of macro 'writel_relaxed'
#define writel(v,a)  ({ wmb(); writel_relaxed((v),(a)); })
   ^~
   drivers/gpu/drm/vc4/vc4_drv.h:301:32: note: in expansion of macro 'writel'
#define HVS_WRITE(offset, val) writel(val, vc4->hvs->regs + offset)
   ^~
   drivers/gpu/drm/vc4/vc4_crtc.c:356:2: note: in expansion of macro 'HVS_WRITE'
 HVS_WRITE(SCALER_OLEDCOEF0,
 ^
   drivers/gpu/drm/vc4/vc4_regs.h:19:3: note: in expansion of macro 'WARN_ON'
  WARN_ON((fieldval & ~field##_MASK) != 0);  \
  ^~~
   drivers/gpu/drm/vc4/vc4_crtc.c:361:5: note: in expansion of macro 
'VC4_SET_FIELD'
VC4_SET_FIELD(vc4_crtc_s31_32_to_s0_9(ctm->matrix[8]),
^
   drivers/gpu/drm/vc4/vc4_crtc.c:365:12: error: 'SCALER_OLEDOFFS' undeclared 
(first use in this function); did you mean 'SCALER_OLEDCOEF0'?
 HVS_WRITE(SCALER_OLEDOFFS, VC4_SET_FIELD(vc4_crtc->channel + 1,
   ^
   arch/sh/include/asm/io.h:31:71: note: in definition of macro '__raw_writel'
#define __raw_writel(v,a) (__chk_io_ptr(a), *(volatile u32 __force *)(a) = 
(v))
  ^
   arch/sh/include/asm/io.h:56:32: note: in expansion of macro 'writel_relaxed'
#define writel(v,a)  ({ wmb(); writel_relaxed((v),(a)); })
   ^~
   drivers/gpu/drm/vc4/vc4_drv.h:301:32: note: in expansion of macro 'writel'
#define HVS_WRITE(offset, val) writel(val, vc4->hvs->regs + offset)
   ^~
   drivers/gpu/drm/vc4/vc4_crtc.c:365:2: note: in expansion of macro 'HVS_WRITE'
 HVS_WRITE(SCALER_OLEDOFFS, VC4_SET_FIELD(vc4_crtc->channel + 1,
 ^
   drivers/gpu/drm/vc4/vc4_crtc.c:366:8: error: 
'SCALER_OLEDOFFS_DISPFIFO_SHIFT' undeclared (first use in this function); did 
you mean 'SCALER_OLEDCOEF0_B_TO_B_SHIFT'?
   SCALER_OLEDOFFS_DISPFIFO));
   ^
   arch/sh/include/asm/io.h:31:77: note: in definition of macro '__raw_writel'
#define __raw_writel(v,a) (__chk_io_ptr(a), *(volatile u32 __force *)(a) = 
(v))

^
   arch/sh/include/asm/io.h:46:62: note: in expansion of macro 'ioswabl'
#define writel_relaxed(v,c) ((void)__raw_writel((__force u32)ioswabl(v),c))
 ^~~
   arch/sh/include/asm/io.h:56:32: note: in expansion of macro 'writel_relaxed'
#define writel(v,a)  ({ wmb(); writel_relaxed((v),(a)); })
   ^~
   drivers/gpu/drm/vc4/vc4_drv.h:301:32: note: in expansion of macro 'writel'
#define HVS_WRITE(offset, val) writel(val, vc4->hvs->regs + offset)
   ^~
   drivers/gpu/drm/vc4/vc4_crtc.c:365:2: note: in expansion of macro 'HVS_WRITE'
 HVS_WRITE(SCALER_OLEDOFFS, VC4_SET_FIELD(vc4_crtc->channel + 1,
 ^
   drivers/gpu/drm/vc4/vc4_crtc.c:365:29: note: in expansion of macro 
'VC4_SET_FIELD'
 HVS_WRITE(SCALER_OLEDOFFS, VC4_SET_FIELD(vc4_crtc->channel + 1,
^
   drivers/gpu/drm/vc4/vc4_crtc.c:366:8: error: 'SCALER_OLEDOFFS_DISPFIFO_MASK' 
undeclared (first use in this function); did you mean 
'SCALER_OLEDOFFS_DISPFIFO_SHIFT'?
   SCALER_OLEDOFFS_DISPFIFO)

Re: [PATCH 2/2] drm/msm: Add A6XX device support

[kbuild test robot]

Hi Jordan,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on next-20180309]
[cannot apply to v4.16-rc4 v4.16-rc3 v4.16-rc2 v4.16-rc5]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Jordan-Crouse/drm-msm-Add-support-for-Adreno-a6xx/20180318-113345
config: arm-allmodconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

>> drivers/gpu/drm/msm/adreno/a6xx_gmu.c:7:10: fatal error: soc/qcom/cmd-db.h: 
>> No such file or directory
#include 
 ^~~
   compilation terminated.

vim +7 drivers/gpu/drm/msm/adreno/a6xx_gmu.c

 3  
 4  #include 
 5  #include 
 6  #include 
   > 7  #include 
 8  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/3] drm/vc4: Add color transformation matrix (CTM) support

[kbuild test robot]

Hi Stefan,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on v4.16-rc4]
[also build test WARNING on next-20180316]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Stefan-Schake/drm-vc4-Atomic-color-management-support/20180318-120701
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sh 

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/vc4/vc4_crtc.c: In function 'vc4_crtc_update_gamma_lut':
   drivers/gpu/drm/vc4/vc4_crtc.c:305:30: error: initialization from 
incompatible pointer type [-Werror=incompatible-pointer-types]
 struct drm_color_lut *lut = crtc->state->gamma_lut->data;
 ^~~~
   drivers/gpu/drm/vc4/vc4_crtc.c: In function 'vc4_crtc_update_ctm':
   drivers/gpu/drm/vc4/vc4_crtc.c:340:30: error: initialization from 
incompatible pointer type [-Werror=incompatible-pointer-types]
 struct drm_color_ctm *ctm = crtc->state->ctm->data;
 ^~~~
   In file included from include/linux/fb.h:17:0,
from include/drm/drm_crtc.h:31,
from include/drm/drm_atomic.h:31,
from drivers/gpu/drm/vc4/vc4_crtc.c:35:
   drivers/gpu/drm/vc4/vc4_crtc.c:342:12: error: 'SCALER_OLEDCOEF2' undeclared 
(first use in this function); did you mean 'SCALER_DISPCTRL2'?
 HVS_WRITE(SCALER_OLEDCOEF2,
   ^
   arch/sh/include/asm/io.h:31:71: note: in definition of macro '__raw_writel'
#define __raw_writel(v,a) (__chk_io_ptr(a), *(volatile u32 __force *)(a) = 
(v))
  ^
   arch/sh/include/asm/io.h:56:32: note: in expansion of macro 'writel_relaxed'
#define writel(v,a)  ({ wmb(); writel_relaxed((v),(a)); })
   ^~
>> drivers/gpu/drm/vc4/vc4_drv.h:301:32: note: in expansion of macro 'writel'
#define HVS_WRITE(offset, val) writel(val, vc4->hvs->regs + offset)
   ^~
>> drivers/gpu/drm/vc4/vc4_crtc.c:342:2: note: in expansion of macro 'HVS_WRITE'
 HVS_WRITE(SCALER_OLEDCOEF2,
 ^
   drivers/gpu/drm/vc4/vc4_crtc.c:342:12: note: each undeclared identifier is 
reported only once for each function it appears in
 HVS_WRITE(SCALER_OLEDCOEF2,
   ^
   arch/sh/include/asm/io.h:31:71: note: in definition of macro '__raw_writel'
#define __raw_writel(v,a) (__chk_io_ptr(a), *(volatile u32 __force *)(a) = 
(v))
  ^
   arch/sh/include/asm/io.h:56:32: note: in expansion of macro 'writel_relaxed'
#define writel(v,a)  ({ wmb(); writel_relaxed((v),(a)); })
   ^~
>> drivers/gpu/drm/vc4/vc4_drv.h:301:32: note: in expansion of macro 'writel'
#define HVS_WRITE(offset, val) writel(val, vc4->hvs->regs + offset)
   ^~
>> drivers/gpu/drm/vc4/vc4_crtc.c:342:2: note: in expansion of macro 'HVS_WRITE'
 HVS_WRITE(SCALER_OLEDCOEF2,
 ^
   drivers/gpu/drm/vc4/vc4_crtc.c:344:5: error: 'SCALER_OLEDCOEF2_R_TO_R_SHIFT' 
undeclared (first use in this function); did you mean 
'SCALER_CSC0_COEF_CR_OFS_SHIFT'?
SCALER_OLEDCOEF2_R_TO_R) |
^
   arch/sh/include/asm/io.h:31:77: note: in definition of macro '__raw_writel'
#define __raw_writel(v,a) (__chk_io_ptr(a), *(volatile u32 __force *)(a) = 
(v))

^
   arch/sh/include/asm/io.h:46:62: note: in expansion of macro 'ioswabl'
#define writel_relaxed(v,c) ((void)__raw_writel((__force u32)ioswabl(v),c))
 ^~~
   arch/sh/include/asm/io.h:56:32: note: in expansion of macro 'writel_relaxed'
#define writel(v,a)  ({ wmb(); writel_relaxed((v),(a)); })
   ^~
>> drivers/gpu/drm/vc4/vc4_drv.h:301:32: note: in expansion of macro 'writel'
#define HVS_WRITE(offset, val) writel(val, vc4->hvs->regs + offset)
   ^~
>> drivers/gpu/drm/vc4/vc4_crtc.c:342:2: note: in expansion of macro 'HVS_WRITE'
 HVS_WRITE(SCALER_OLEDCOEF2,
 ^
   drivers/gpu/drm/vc4/vc4_crtc.c:343:5: note: in expansion of macro 
'VC4_SET_FIELD'
VC4_SET_FIELD(vc4_crtc_s31_32_to_s0_9(ctm->matrix[0]),
^
   drivers/gpu/drm/vc4/vc4_crtc.c:344:5: error: 'SCALER_OLEDCOEF2_R_TO_R_MASK' 
unde