Re: [PATCH 1/3] drm/vc4: Expose gamma as atomic property
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
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));
^
arch/sh/include/asm/io.h:3
Re: [PATCH 2/2] drm/msm: Add A6XX device support
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
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'
undeclared (first use in this function); did you mean
'SCALER_OLEDCOEF2_R_TO_R_SHIFT'?
Re: [RFC][PATCH] drm_hwcomposer: Rework platformdrmgeneric.cpp to use libdrm's gralloc handle
Hey John, On Fri, Mar 16, 2018 at 10:48 PM, John Stultz wrote: > LOCAL_C_INCLUDES := \ > - external/drm_gralloc \ > + external/libdrm/android \ > system/core/libsync This shouldn't be necessary if libdrm correctly exports its headers, but it seems that it only did for the static variant of the library. I've sent a patch to fix that, then the explicit path here can be dropped. Thanks, Stefan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm] android: Add missing include exports
They were set for the static library but not the shared variant. Cc: John Stultz Signed-off-by: Stefan Schake --- Android.mk | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Android.mk b/Android.mk index 8611c5e..1b77c53 100644 --- a/Android.mk +++ b/Android.mk @@ -53,7 +53,9 @@ LOCAL_MODULE := libdrm LOCAL_SRC_FILES := $(LIBDRM_FILES) LOCAL_EXPORT_C_INCLUDE_DIRS := \ -$(LOCAL_PATH)/include/drm + $(LOCAL_PATH) \ + $(LOCAL_PATH)/include/drm \ + $(LOCAL_PATH)/android LOCAL_SHARED_LIBRARIES := \ libcutils -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199123] kernel 4.16rc5 doesnt boot on ryzen 5 2400g due to an amdgpu change
https://bugzilla.kernel.org/show_bug.cgi?id=199123 --- Comment #10 from david becerra (davidbecerrapor...@gmail.com) --- (In reply to Michel Dänzer from comment #9) > (In reply to david becerra from comment #8) > > but there is an issue in 4.16 the cursor is very choppy but in 4.15.9 is > > smooth > > Sounds like https://bugs.freedesktop.org/show_bug.cgi?id=105530 . it isnt, i didnt have tearfree set but i tried adding Option "TearFree" "off" to try and the cursor is still choppy -- 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
[Bug 101739] An issue with alpha-to-coverage handling is causing Arma 3 64-bit Linux port to render trees incorrectly
https://bugs.freedesktop.org/show_bug.cgi?id=101739 Jan Havran changed: What|Removed |Added CC||havran@email.cz --- Comment #9 from Jan Havran --- I can confirm this bug (and also other users are facing it, like [1]). My spec: Distribution: Antergos 64b Linux: 4.15.9 Mesa 17.3.6 Arma 1.80 Processor: Intel(R) Core(TM) i5-4210M CPU @ 2.60GHz GPU: AMD Radeon R7 M265 [1] https://www.gamingonlinux.com/articles/the-linux-beta-of-arma-3-has-been-updated-to-180-compatible-with-windows-again-for-a-time.11349/page=1#r115868 -- 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 199123] kernel 4.16rc5 doesnt boot on ryzen 5 2400g due to an amdgpu change
https://bugzilla.kernel.org/show_bug.cgi?id=199123 --- Comment #9 from Michel Dänzer (mic...@daenzer.net) --- (In reply to david becerra from comment #8) > but there is an issue in 4.16 the cursor is very choppy but in 4.15.9 is > smooth Sounds like https://bugs.freedesktop.org/show_bug.cgi?id=105530 . -- 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: [RFC][PATCH] libdrm: gralloc_handle.h: Fix build issue with Android
Hey John,
On Fri, Mar 16, 2018 at 10:48 PM, John Stultz wrote:
> In trying to integrate the new gralloc_handle.h with the
> drm_hwcomposer, I started seeing the following compilation
> errors:
>
> In file included from external/drm_hwcomposer/platformdrmgeneric.cpp:28:
> external/libdrm/android/gralloc_handle.h:108:9: error: cannot initialize
> return object of type 'native_handle_t *' (aka 'native_handle *') with an
> lvalue of type 'struct gralloc_handle_t *'
> return handle;
>^~
> 1 error generated.
>
> This seems to be due to the gralloc_handle_create() definition
> claiming to return a native_handle_t * type, rather then a
> gralloc_handle_t *, which is what the code actually returns.
>
> This function isn't actually used in the current drm_hwcomposer,
> so I'm not totally sure that this fix is correct (rather then
> returning the gralloc_handle_t's embadedded native_handle_t ptr).
This changed in 009634e49309 ("android: fix gralloc_handle_create() problems")
to make the return value from gralloc_handle_create opaque to its user.
Since the only one that would use gralloc_handle_create is the gralloc
implementation itself (and libdrm isn't one) and using getters/setters was
rejected (IIRC), I would think there is no reason to obscure the return type.
Since buffer_handle_t is native_handle_t* is gralloc_handle_t* it's also
correct. The alternative to changing the declaration here is returning
nhandle instead of handle.
Adding Rob Herring who authored 009634e49309.
Thanks,
Stefan
___
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
https://bugzilla.kernel.org/show_bug.cgi?id=198123 --- Comment #42 from sh...@tuta.io --- Some values from register dumps. All kernel modules are the same. Black background: 69FC0002 Grey background: 03D8 64C87F007F00 69FC 6BBC0001 6BCC 6D540001 Other values are either different between dumps of the same case or common to both cases. -- 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 v5 07/36] drm/bridge: analogix_dp: Move enable video into config_video()
Hi Archit,
Am Mittwoch, 14. März 2018, 06:59:59 CET schrieb Archit Taneja:
> On Saturday 10 March 2018 03:52 AM, Enric Balletbo i Serra wrote:
> > From: Lin Huang
> >
> > We need to enable video before analogix_dp_is_video_stream_on(), so
> > we can get the right video stream status.
> >
> > Cc: 征增 王
> > Cc: Stéphane Marchesin
> > Signed-off-by: Lin Huang
> > Signed-off-by: Sean Paul
> > Signed-off-by: Thierry Escande
> > Reviewed-by: Andrzej Hajda
> > Signed-off-by: Enric Balletbo i Serra
> > Tested-by: Marek Szyprowski
> > ---
> >
> > drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 11 +--
> > 1 file changed, 5 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> > b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> > index 5a2e35dc41e3..f9661b410cb9 100644
> > --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> > +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> > @@ -819,11 +819,10 @@ static int analogix_dp_config_video(struct
> > analogix_dp_device *dp)
> > if (analogix_dp_is_slave_video_stream_clock_on(dp) == 0)
> > break;
> > if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
> > - dev_err(dp->dev, "Timeout of video streamclk ok\n");
> > + dev_err(dp->dev, "Timeout of slave video streamclk
> > ok\n");
> > return -ETIMEDOUT;
> > }
> > -
> > - usleep_range(1, 2);
> > + usleep_range(1000, 1001);
>
> Could we briefly explain in the commit message why we need to increase
> the delay in the timeout loop? Is it a consequence of calling
> analogix_dp_start_video() earlier, or is this the preferred time
> mentioned in the specs?
I asked Lin, the original author of this patch, response quoted below:
"There is random "Timeout of video streamclk ok" message happen when
debug edp panel,
So we extend this time, this time do not define in the spec."
So it looks like it was working by chance before and this move triggered
some sort of timing issue.
Heiko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/11] drm/tinydrm: Support device unplug
Den 16.03.2018 09.03, skrev Daniel Vetter: On Fri, Sep 8, 2017 at 6:33 PM, Daniel Vetter wrote: Hi Noralf, On Fri, Sep 08, 2017 at 05:07:19PM +0200, Noralf Trønnes wrote: This adds device unplug support to drm_fb_helper, drm_fb_cma_helper (fbdev) and tinydrm. There are several changes in this version: I've used Daniel's idea of protecting drm_device.unplugged with srcu to provide race free drm_dev_unplug(). The fbdev helper unplug patch has become very small with Daniel's help. Ref is now taken and dropped in the existing helpers, so I could drop drm_fb_helper_simple_init(). I has annoyed me that fbdev is restored in drm_driver.last_close even if fbdev isn't used. I've added a patch to fix that. This means I can drop calling drm_atomic_helper_shutdown() in tinydrm_unregister(), since I now can easily disable the pipeline from userspace by just closing the users. Disabled pipeline means balanced regulator_enable/disable. The 'Embed drm_device in tinydrm_device' patch has gained drm_driver.release functions after a discussion with Laurent. My previous version relied on obscure freeing in tinydrm_release(). This means that I didn't retain the ack's. Laurent also caught an ugly devm_kmalloc() in tinydrm_display_pipe_init() that I've fixed. I'm practically packing for my 2 weeks of conference travel already, so only very cursory read of the initial patches for core&fb-helpers. I think this looks really splendid now. But I won't have time for review for the next few week, would be good if you could drag some others into this discussions. Iirc there's recently been a few different people interested in udl (even some patches I think), they might be able to help out with testing&review. Also, would be great if you can submit this to intel-gfx on the next round, so that our CI can pick it up and give it a solid beating. Touching critical core paths like in patch 1 is always a bit scary. While reviewing xen-front's hotunplug handling I just realized this never landed. Can you pls resend and nag me to review it properly? I'd really like to get the drm_dev_unplug stuff sorted out better. My plan was to pick this up after switching tinydrm over to vmalloc buffers, but that work is now waiting for the generic fbdev emulation to land. I'm currently wandering around inside drm_fb_helper looking for a way out, I can feel the draft so there has to be an exit somewhere. I hope that in a week or two I'm done with the next version of the RFC using the drm_fb_helper mode setting code instead of the ioctl's. At that point it will be a good thing to flush my "caches" of the drm_fb_helper code, since after looking at it for a long time, I really don't see the details anymore. So I'll pick up the unplug series then, at least the core patches should be trivial to review and get merged if the CI agrees. Noralf. Thanks, Daniel Thanks, Daniel Noralf. Noralf Trønnes (11): drm: Use srcu to protect drm_device.unplugged drm/fb-helper: Support device unplug drm/fb-helper: Ensure driver module is pinned in fb_open() drm/fb-helper: Don't restore if fbdev is not in use drm/fb-cma-helper: Make struct drm_fbdev_cma public drm/fb-cma-helper: Support device unplug drm/tinydrm: Drop driver registered message drm/tinydrm: Embed drm_device in tinydrm_device drm/tinydrm: Support device unplug in core drm/tinydrm/mi0283qt: Let the display pipe handle power drm/tinydrm: Support device unplug in drivers drivers/gpu/drm/drm_drv.c | 54 +-- drivers/gpu/drm/drm_fb_cma_helper.c | 13 +-- drivers/gpu/drm/drm_fb_helper.c | 108 -- drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 135 +++- drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c | 28 +++--- drivers/gpu/drm/tinydrm/mi0283qt.c | 81 + drivers/gpu/drm/tinydrm/mipi-dbi.c | 58 +--- drivers/gpu/drm/tinydrm/repaper.c | 62 - drivers/gpu/drm/tinydrm/st7586.c| 54 ++- include/drm/drm_device.h| 9 +- include/drm/drm_drv.h | 15 +++- include/drm/drm_fb_cma_helper.h | 11 ++- include/drm/drm_fb_helper.h | 28 ++ include/drm/tinydrm/mipi-dbi.h | 1 + include/drm/tinydrm/tinydrm.h | 10 ++- 15 files changed, 469 insertions(+), 198 deletions(-) -- 2.7.4 -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch -- 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
[Bug 199133] nouveau_mem_host+0x47/0x1b0 [nouveau]: NULL pointer dereference at 0000000000000040
https://bugzilla.kernel.org/show_bug.cgi?id=199133 Pierre Moreau (pierre.mor...@free.fr) changed: What|Removed |Added CC||pierre.mor...@free.fr --- Comment #2 from Pierre Moreau (pierre.mor...@free.fr) --- 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. -- 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
[Bug 199123] kernel 4.16rc5 doesnt boot on ryzen 5 2400g due to an amdgpu change
https://bugzilla.kernel.org/show_bug.cgi?id=199123 --- Comment #8 from david becerra (davidbecerrapor...@gmail.com) --- (In reply to david becerra from comment #7) > latest manjaro kernel update seems to have fixed the issue but there is an issue in 4.16 the cursor is very choppy but in 4.15.9 is smooth i dont know if it is related -- 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
[Bug 199123] kernel 4.16rc5 doesnt boot on ryzen 5 2400g due to an amdgpu change
https://bugzilla.kernel.org/show_bug.cgi?id=199123 --- Comment #7 from david becerra (davidbecerrapor...@gmail.com) --- latest manjaro kernel update seems to have fixed the issue -- 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
[Bug 105569] sw_init of IP block failed -2
https://bugs.freedesktop.org/show_bug.cgi?id=105569 Michel Dänzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Michel Dänzer --- (In reply to CthUlhUzzz from comment #0) > "radeon.si_support=0 radeon.cik_support=0 amdgpu.si_support=1 > amdgpu.cik_support=1". FWIW, you only need radeon.si_support=0 amdgpu.si_support=1, since Oland is from the SI family. > [ 592.579114] amdgpu :01:00.0: Direct firmware load for > radeon/oland_mc.bin failed with error -2 > [ 592.579124] amdgpu :01:00.0: si_mc: Failed to load firmware > "radeon/oland_mc.bin" > [ 592.579133] amdgpu :01:00.0: Failed to load mc firmware! The oland_mc.bin microcode is required. Make sure the package firmware-amd-graphics / firmware-linux-nonfree is installed, and maybe try re-generating the initrd. -- 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 105412] [OpenGL] [HD 7790] - VSYNC always ON in all videogames
https://bugs.freedesktop.org/show_bug.cgi?id=105412 Michel Dänzer changed: What|Removed |Added Component|Drivers/Vulkan/radeon |DRM/Radeon QA Contact|mesa-dev@lists.freedesktop. | |org | Product|Mesa|DRI Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop |org |.org --- Comment #8 from Michel Dänzer --- It seems clear that the problem you're seeing is not related to sync-to-vblank. Since you say the problem started after updating the kernel, it's probably best to isolate the kernel change which introduced the problem. Can you bisect, or at least narrow down the version which introduced the problem? -- 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 v6 0/3] drm: Add Thine THC63LVD1024 LVDS decoder bridge
Hi, (hopefully) last iteration, with Niklas' Reviewed-by tags. Simply drop an un-necessary #ifdef guard for CONFIG_OF in driver's code as suggested by Niklas. Time to talk how this series will go in? I assume bindings and driver through DRM tree, while Simon is to pick up the Eagle DTS update once the first two patches will get in. Is this ok for both DRM and Renesas side? Also I assume before bindings gets accepted someone from devicetree list should ack them, correct? Simon: as Niklas suggested, I have now listed the series dependencies below the commit message. It is my understanding that is not necessary to resend his series with that commit squashed on top (which I also prefer not to). Thanks j v5 -> v6: - Drop check for CONFIG_OF as it is a Kconfig dependency - Add Niklas Reviewed-by tags - List [3/3] depenencies below commit message to ease integration v4 -> v5: - Fix punctuation in bindings documentation - Add small statement to bindings document to clarify the chip has no control bus - Print regulator name in enable/disable routines error path - Add Andrzej Reviewed-by tag v3 -> v4: - Rename permutations of "pdwn" to just "pdwn" everywhere in the series - Improve power enable/disable routines as suggested by Andrzej and Sergei - Change "pdwn" gpio initialization to use the logical output level - Change Kconfig description v2 -> v3: - Drop support for "lvds-decoder" and make the driver THC63LVD1024 specific -- Rework bindings to describe multiple input/output ports -- Rename driver and remove "lvds-decoder" references -- Rework Eagle DTS to use new bindings v1 -> v2: - Drop support for THC63LVD1024 Jacopo Mondi (3): dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder drm: bridge: Add thc63lvd1024 LVDS decoder driver arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 ++ arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 33 ++- drivers/gpu/drm/bridge/Kconfig | 6 + drivers/gpu/drm/bridge/Makefile| 1 + drivers/gpu/drm/bridge/thc63lvd1024.c | 255 + 5 files changed, 358 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder
Document Thine THC63LVD1024 LVDS decoder device tree bindings.
Signed-off-by: Jacopo Mondi
Reviewed-by: Andrzej Hajda
Reviewed-by: Niklas Söderlund
---
.../bindings/display/bridge/thine,thc63lvd1024.txt | 66 ++
1 file changed, 66 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
diff --git
a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
new file mode 100644
index 000..8225c6a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
@@ -0,0 +1,66 @@
+Thine Electronics THC63LVD1024 LVDS decoder
+---
+
+The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS streams
+to parallel data outputs. The chip supports single/dual input/output modes,
+handling up to two two input LVDS stream and up to two digital CMOS/TTL
outputs.
+
+Single or dual operation modes, output data mapping and DDR output modes are
+configured through input signals and the chip does not expose any control bus.
+
+Required properties:
+- compatible: Shall be "thine,thc63lvd1024"
+
+Optional properties:
+- vcc-supply: Power supply for TTL output and digital circuitry
+- cvcc-supply: Power supply for TTL CLOCKOUT signal
+- lvcc-supply: Power supply for LVDS inputs
+- pvcc-supply: Power supply for PLL circuitry
+- pdwn-gpios: Power down GPIO signal. Active low
+- oe-gpios: Output enable GPIO signal. Active high
+
+The THC63LVD1024 video port connections are modeled according
+to OF graph bindings specified by Documentation/devicetree/bindings/graph.txt
+
+Required video port nodes:
+- Port@0: First LVDS input port
+- Port@2: First digital CMOS/TTL parallel output
+
+Optional video port nodes:
+- Port@1: Second LVDS input port
+- Port@3: Second digital CMOS/TTL parallel output
+
+Example:
+
+
+ thc63lvd1024: lvds-decoder {
+ compatible = "thine,thc63lvd1024";
+
+ vcc-supply = <®_lvds_vcc>;
+ lvcc-supply = <®_lvds_lvcc>;
+
+ pdwn-gpio = <&gpio4 15 GPIO_ACTIVE_LOW>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ lvds_dec_in_0: endpoint {
+ remote-endpoint = <&lvds_out>;
+ };
+ };
+
+ port@2{
+ reg = <2>;
+
+ lvds_dec_out_2: endpoint {
+ remote-endpoint = <&adv7511_in>;
+ };
+
+ };
+
+ };
+ };
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 3/3] arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle
On Fri, Mar 16, 2018 at 10:39:53AM +0100, jacopo mondi wrote: > Hi Niklas, >thanks for review, > > On Fri, Mar 16, 2018 at 01:00:04AM +0100, Niklas Söderlund wrote: > > Hi Jacopo, > > > > Thanks for your patch. > > > > This one must depend on '[PATCH v2 0/5] arm64: dts: renesas: r8a77970: > > enable HDMI output' or something similar not yet in renesas-drivers > > repository correct? > > Yes, I have listed dependencies of this series in my v1 cover letter: > > --- > The series is based on Laurent's drm/next/du branch with patches on top for: > - Sergei: Enable PFC, I2c, GPIOs for r8a77970 > - Sergei: Add support for r8a77970 in DU and add display device nodes in > r8a77970 DTSI > - Niklas: Connect DU LVDS output to HDMI bridge adv7511w in Eagle DTS > - Sergei: fix video output on R8A77970 > > A base branch with these patches applied is available at > git://jmondi.org/linux v3m/v4.16-rc3/base > --- > > My bad I have not reported this in all cover letters (and I have not > reported the full name of the series) > > PFC, GPIO and I2c support I have listed as dependencies seems to have > landed in renesas-drivers, while I don't see yet: > > Sergei: > [PATCH v2 0/5] Add R8A77970/V3MSK LVDS/HDMI support > > whose patches for r8a77970 dtsi are included in yours: > [PATCH v2 0/5] arm64: dts: renesas: r8a77970: enable HDMI output > > On top I also have Sergei's/Laurent's: > [PATCH v4] v4l: vsp1: Fix video output on R8A77970 I have marked this patch as Deferred pending acceptance of the dependencies. Please repost or otherwise ping me once the dependencies are in place. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] i915: Re-use DEFINE_SHOW_ATTRIBUTE() macro
...instead of open coding file operations followed by custom ->open()
callbacks per each attribute.
Reviewed-by: Chris Wilson
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/i915/gvt/debugfs.c | 13 +--
drivers/gpu/drm/i915/i915_debugfs.c | 76 ++---
2 files changed, 12 insertions(+), 77 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/debugfs.c
b/drivers/gpu/drm/i915/gvt/debugfs.c
index 32a66dfdf112..f7d0078eb61b 100644
--- a/drivers/gpu/drm/i915/gvt/debugfs.c
+++ b/drivers/gpu/drm/i915/gvt/debugfs.c
@@ -122,18 +122,7 @@ static int vgpu_mmio_diff_show(struct seq_file *s, void
*unused)
seq_printf(s, "Total: %d, Diff: %d\n", param.total, param.diff);
return 0;
}
-
-static int vgpu_mmio_diff_open(struct inode *inode, struct file *file)
-{
- return single_open(file, vgpu_mmio_diff_show, inode->i_private);
-}
-
-static const struct file_operations vgpu_mmio_diff_fops = {
- .open = vgpu_mmio_diff_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release= single_release,
-};
+DEFINE_SHOW_ATTRIBUTE(vgpu_mmio_diff);
/**
* intel_gvt_debugfs_add_vgpu - register debugfs entries for a vGPU
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 298a3aa9513b..5378863e3238 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3562,7 +3562,8 @@ static ssize_t i915_displayport_test_active_write(struct
file *file,
static int i915_displayport_test_active_show(struct seq_file *m, void *data)
{
- struct drm_device *dev = m->private;
+ struct drm_i915_private *dev_priv = m->private;
+ struct drm_device *dev = &dev_priv->drm;
struct drm_connector *connector;
struct drm_connector_list_iter conn_iter;
struct intel_dp *intel_dp;
@@ -3596,10 +3597,8 @@ static int i915_displayport_test_active_show(struct
seq_file *m, void *data)
static int i915_displayport_test_active_open(struct inode *inode,
struct file *file)
{
- struct drm_i915_private *dev_priv = inode->i_private;
-
return single_open(file, i915_displayport_test_active_show,
- &dev_priv->drm);
+ inode->i_private);
}
static const struct file_operations i915_displayport_test_active_fops = {
@@ -3613,7 +3612,8 @@ static const struct file_operations
i915_displayport_test_active_fops = {
static int i915_displayport_test_data_show(struct seq_file *m, void *data)
{
- struct drm_device *dev = m->private;
+ struct drm_i915_private *dev_priv = m->private;
+ struct drm_device *dev = &dev_priv->drm;
struct drm_connector *connector;
struct drm_connector_list_iter conn_iter;
struct intel_dp *intel_dp;
@@ -3652,26 +3652,12 @@ static int i915_displayport_test_data_show(struct
seq_file *m, void *data)
return 0;
}
-static int i915_displayport_test_data_open(struct inode *inode,
- struct file *file)
-{
- struct drm_i915_private *dev_priv = inode->i_private;
-
- return single_open(file, i915_displayport_test_data_show,
- &dev_priv->drm);
-}
-
-static const struct file_operations i915_displayport_test_data_fops = {
- .owner = THIS_MODULE,
- .open = i915_displayport_test_data_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release = single_release
-};
+DEFINE_SHOW_ATTRIBUTE(i915_displayport_test_data);
static int i915_displayport_test_type_show(struct seq_file *m, void *data)
{
- struct drm_device *dev = m->private;
+ struct drm_i915_private *dev_priv = m->private;
+ struct drm_device *dev = &dev_priv->drm;
struct drm_connector *connector;
struct drm_connector_list_iter conn_iter;
struct intel_dp *intel_dp;
@@ -3698,23 +3684,7 @@ static int i915_displayport_test_type_show(struct
seq_file *m, void *data)
return 0;
}
-
-static int i915_displayport_test_type_open(struct inode *inode,
- struct file *file)
-{
- struct drm_i915_private *dev_priv = inode->i_private;
-
- return single_open(file, i915_displayport_test_type_show,
- &dev_priv->drm);
-}
-
-static const struct file_operations i915_displayport_test_type_fops = {
- .owner = THIS_MODULE,
- .open = i915_displayport_test_type_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release = single_release
-};
+DEFINE_SHOW_ATTRIBUTE(i915_displayport_test_type);
static void wm_latency_show(struct seq_file *m, const uint16_t wm[8])
{
@@ -4875,19 +4845,7 @@ static int i915_dpcd_show(struct seq_file *m, void *data)
return 0;
}
-
-static int i915_dpcd_open(struct inode *inode, struct file *file)
-{
- return single_open(file, i915_dpcd_show
Re: [PATCH v1] drm/dp/mst: Fix off-by-one typo when dump payload table
On Thu, 2018-01-11 at 17:33 +0200, Andy Shevchenko wrote:
> It seems there is a classical off-by-one typo from the beginning
> when commit
>
> ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper
> (v0.6)")
>
> introduced a new helper.
>
> Fix a typo by introducing a macro constant.
Any comment on this?
>
> Cc: Dave Airlie
> Signed-off-by: Andy Shevchenko
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 70dcfa58d3c2..51c5fc11f852 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -2936,12 +2936,14 @@ static void drm_dp_mst_dump_mstb(struct
> seq_file *m,
> }
> }
>
> +#define DP_PAYLOAD_TABLE_SIZE64
> +
> static bool dump_dp_payload_table(struct drm_dp_mst_topology_mgr
> *mgr,
> char *buf)
> {
> int i;
>
> - for (i = 0; i < 64; i += 16) {
> + for (i = 0; i < DP_PAYLOAD_TABLE_SIZE; i += 16) {
> if (drm_dp_dpcd_read(mgr->aux,
>DP_PAYLOAD_TABLE_UPDATE_STATUS +
> i,
>&buf[i], 16) != 16)
> @@ -3028,8 +3030,7 @@ void drm_dp_mst_dump_topology(struct seq_file
> *m,
> seq_printf(m, " revision: hw: %x.%x sw: %x.%x\n",
> buf[0x9] >> 4, buf[0x9] & 0xf, buf[0xa],
> buf[0xb]);
> if (dump_dp_payload_table(mgr, buf))
> - seq_printf(m, "payload table: %*ph\n", 63,
> buf);
> -
> + seq_printf(m, "payload table: %*ph\n",
> DP_PAYLOAD_TABLE_SIZE, buf);
> }
>
> mutex_unlock(&mgr->lock);
--
Andy Shevchenko
Intel Finland Oy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 2/3] drm: bridge: Add thc63lvd1024 LVDS decoder driver
Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
output converter.
Signed-off-by: Jacopo Mondi
Reviewed-by: Andrzej Hajda
Reviewed-by: Niklas Söderlund
---
drivers/gpu/drm/bridge/Kconfig| 6 +
drivers/gpu/drm/bridge/Makefile | 1 +
drivers/gpu/drm/bridge/thc63lvd1024.c | 255 ++
3 files changed, 262 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/thc63lvd1024.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3b99d5a..5815a20 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -92,6 +92,12 @@ config DRM_SII9234
It is an I2C driver, that detects connection of MHL bridge
and starts encapsulation of HDMI signal.
+config DRM_THINE_THC63LVD1024
+ tristate "Thine THC63LVD1024 LVDS decoder bridge"
+ depends on OF
+ ---help---
+ Thine THC63LVD1024 LVDS/parallel converter driver.
+
config DRM_TOSHIBA_TC358767
tristate "Toshiba TC358767 eDP bridge"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 373eb28..fd90b16 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
obj-$(CONFIG_DRM_SIL_SII8620) += sil-sii8620.o
obj-$(CONFIG_DRM_SII902X) += sii902x.o
obj-$(CONFIG_DRM_SII9234) += sii9234.o
+obj-$(CONFIG_DRM_THINE_THC63LVD1024) += thc63lvd1024.o
obj-$(CONFIG_DRM_TOSHIBA_TC358767) += tc358767.o
obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511/
diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c
b/drivers/gpu/drm/bridge/thc63lvd1024.c
new file mode 100644
index 000..02a54c2
--- /dev/null
+++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
@@ -0,0 +1,255 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * THC63LVD1024 LVDS to parallel data DRM bridge driver.
+ *
+ * Copyright (C) 2018 Jacopo Mondi
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+enum {
+ THC63_LVDS_IN0,
+ THC63_LVDS_IN1,
+ THC63_DIGITAL_OUT0,
+ THC63_DIGITAL_OUT1,
+};
+
+static const char * const thc63_reg_names[] = {
+ "vcc", "lvcc", "pvcc", "cvcc",
+};
+
+struct thc63_dev {
+ struct device *dev;
+
+ struct regulator *vccs[ARRAY_SIZE(thc63_reg_names)];
+
+ struct gpio_desc *pdwn;
+ struct gpio_desc *oe;
+
+ struct drm_bridge bridge;
+ struct drm_bridge *next;
+};
+
+static inline struct thc63_dev *to_thc63(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct thc63_dev, bridge);
+}
+
+static int thc63_attach(struct drm_bridge *bridge)
+{
+ struct thc63_dev *thc63 = to_thc63(bridge);
+
+ return drm_bridge_attach(bridge->encoder, thc63->next, bridge);
+}
+
+static void thc63_enable(struct drm_bridge *bridge)
+{
+ struct thc63_dev *thc63 = to_thc63(bridge);
+ struct regulator *vcc;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(thc63->vccs); i++) {
+ vcc = thc63->vccs[i];
+ if (!vcc)
+ continue;
+
+ if (regulator_enable(vcc))
+ goto error_vcc_enable;
+ }
+
+ if (thc63->pdwn)
+ gpiod_set_value(thc63->pdwn, 0);
+
+ if (thc63->oe)
+ gpiod_set_value(thc63->oe, 1);
+
+ return;
+
+error_vcc_enable:
+ dev_err(thc63->dev, "Failed to enable regulator %s\n",
+ thc63_reg_names[i]);
+
+ for (i = i - 1; i >= 0; i--) {
+ vcc = thc63->vccs[i];
+ if (!vcc)
+ continue;
+
+ regulator_disable(vcc);
+ }
+}
+
+static void thc63_disable(struct drm_bridge *bridge)
+{
+ struct thc63_dev *thc63 = to_thc63(bridge);
+ struct regulator *vcc;
+ int i;
+
+ if (thc63->oe)
+ gpiod_set_value(thc63->oe, 0);
+
+ if (thc63->pdwn)
+ gpiod_set_value(thc63->pdwn, 1);
+
+ for (i = ARRAY_SIZE(thc63->vccs) - 1; i >= 0; i--) {
+ vcc = thc63->vccs[i];
+ if (!vcc)
+ continue;
+
+ if (regulator_disable(vcc))
+ dev_dbg(thc63->dev,
+ "Failed to disable regulator %s\n",
+ thc63_reg_names[i]);
+ }
+}
+
+struct drm_bridge_funcs thc63_bridge_func = {
+ .attach = thc63_attach,
+ .enable = thc63_enable,
+ .disable = thc63_disable,
+};
+
+static int thc63_parse_dt(struct thc63_dev *thc63)
+{
+ struct device_node *thc63_out;
+ struct device_node *remote;
+ int ret = 0;
+
+ thc63_out = of_graph_get_endpoint_by_regs(thc63->dev->of_node,
+ THC63_DIGITAL_OUT0, -1);
+ if (!thc63_out) {
+ dev_err(thc63->dev, "Missing endpoint in Port@%u\n
[PATCH v6 3/3] arm64: dts: renesas: Add LVDS decoder to R-Car V3M Eagle
The R-Car V3M Eagle board includes a transparent THC63LVD1024 LVDS
decoder, connected to the on-chip LVDS encoder output on one side
and to HDMI encoder ADV7511w on the other one.
As the decoder does not need any configuration it has been so-far
omitted from DTS. Now that a driver is available, describe it in DT
as well.
Signed-off-by: Jacopo Mondi
Reviewed-by: Andrzej Hajda
---
List of patch dependencies, as of renesas-drivers-2018-03-13-v4.16-rc5:
- [PATCH v2 0/5] arm64: dts: renesas: r8a77970: enable HDMI output
which includes DU, LVDS and FCPD enablement from:
[PATCH v2 0/5] Add R8A77970/V3MSK LVDS/HDMI support
- [PATCH v4] v4l: vsp1: Fix video output on R8A77970
Patches to be applied on top of
"arm64: dts: renesas: eagle: add HDMI output using the ADV7511W"
Thanks
j
---
arch/arm64/boot/dts/renesas/r8a77970-eagle.dts | 33 +++---
1 file changed, 30 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
index c0fd144..69f43b8 100644
--- a/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77970-eagle.dts
@@ -42,6 +42,33 @@
};
};
};
+
+ thc63lvd1024: lvds-decoder {
+ compatible = "thine,thc63lvd1024";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ thc63lvd1024_in_0: endpoint {
+ remote-endpoint = <&lvds0_out>;
+ };
+ };
+
+ port@2{
+ reg = <2>;
+
+ thc63lvd1024_out_2: endpoint {
+ remote-endpoint = <&adv7511_in>;
+ };
+
+ };
+
+ };
+ };
};
&avb {
@@ -98,7 +125,7 @@
port@0 {
reg = <0>;
adv7511_in: endpoint {
- remote-endpoint = <&lvds0_out>;
+ remote-endpoint = <&thc63lvd1024_out_2>;
};
};
@@ -152,8 +179,8 @@
ports {
port@1 {
- endpoint {
- remote-endpoint = <&adv7511_in>;
+ lvds0_out: endpoint {
+ remote-endpoint = <&thc63lvd1024_in_0>;
};
};
};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103277] [bisected] Systems hangs on resume from S3 sleep due to "Match actual state during S3 resume" commit
https://bugs.freedesktop.org/show_bug.cgi?id=103277 --- Comment #21 from dwagner --- Created attachment 138169 --> https://bugs.freedesktop.org/attachment.cgi?id=138169&action=edit kernel .config as used with git at commit 61deb7d0941d1e3ffee0d799396ac93b0e90 (HEAD, origin/drm-next-4.17-wip) -- 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 103277] [bisected] Systems hangs on resume from S3 sleep due to "Match actual state during S3 resume" commit
https://bugs.freedesktop.org/show_bug.cgi?id=103277 --- Comment #20 from dwagner --- (In reply to mikita.lip...@amd.com from comment #19) > I have attempted to reproduce an issue, but didn't succeed. > We have used an identical hardware setup with a reference rx460 card and > couldn't reproduce a hang on various kernel versions. Strange. If I didn't keep an older amd-staging-drm-next kernel from October 2017 in use where S3 resumes work every time, I would doubt my hardware - but the way it is the only possible cause is a kernel change sine then. > There is still a possibility that some kernel config options might be > causing an issue. > If its possible, could you please provide kernel configuration so the > testing environment is identical. Sure, will attach my .config (as used with the current drm-next-4.17-wip) after this comment. > Also does the issue reproduce reproduce if you disable DC? (amdgpu.dc=0 in > GRUB menu) Tested with today's drm-next-4.17-wip git: With "amdgpu.dc=0" on the kernel command line, resume from S3 works fine for me, both from the console (before starting X11) and when running X11. (But of course, no 4k/60Hz video and no HDMI audio with amdgpu.dc=0, so that is not really an option for actual use.) So the resume-from-S3 failures are definitely caused by something in the DC code that changed since early October 2017. -- 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
https://bugzilla.kernel.org/show_bug.cgi?id=199133 --- Comment #1 from Hector Cavalcanti Saavedra (hectorcavalcantisaave...@gmail.com) --- *** Bug 198853 has been marked as a duplicate of 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
[Bug 199133] New: nouveau_mem_host+0x47/0x1b0 [nouveau]: NULL pointer dereference at 0000000000000040
https://bugzilla.kernel.org/show_bug.cgi?id=199133 Bug ID: 199133 Summary: nouveau_mem_host+0x47/0x1b0 [nouveau]: NULL pointer dereference at 0040 Product: Drivers Version: 2.5 Kernel Version: 4.15.8-300.fc27.x86_64 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: blocking Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: hectorcavalcantisaave...@gmail.com Regression: No Created attachment 274787 --> https://bugzilla.kernel.org/attachment.cgi?id=274787&action=edit Details on the kernel oops. The nouveau driver causes kernel oops after the new DRM changes. I can reproduce by using my system for a few minutes, mainly when using Chromium or opening a PDF file (on Evince or on Chromium). -- 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
[Bug 199133] nouveau_mem_host+0x47/0x1b0 [nouveau]: NULL pointer dereference at 0000000000000040
https://bugzilla.kernel.org/show_bug.cgi?id=199133 Hector Cavalcanti Saavedra (hectorcavalcantisaave...@gmail.com) changed: What|Removed |Added Tree|Mainline|Fedora Regression|No |Yes -- 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
