[RESEND PATCH v4 3/3] ARM: dts: exynos: Remove the display-timing and delay from rinato dts
The display-timing and delay are included in the panel driver. So it
should be removed in dts.
Signed-off-by: Hoegeun Kwon
---
Hi Krzysztof,
This patch was rebased to the mainline (v4.14-rc1).
Best regards,
Hoegeun
arch/arm/boot/dts/exynos3250-rinato.dts | 22 --
1 file changed, 22 deletions(-)
diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts
b/arch/arm/boot/dts/exynos3250-rinato.dts
index 0b45467..ff792ff 100644
--- a/arch/arm/boot/dts/exynos3250-rinato.dts
+++ b/arch/arm/boot/dts/exynos3250-rinato.dts
@@ -227,28 +227,6 @@
vci-supply = <&ldo20_reg>;
reset-gpios = <&gpe0 1 GPIO_ACTIVE_LOW>;
te-gpios = <&gpx0 6 GPIO_ACTIVE_HIGH>;
- power-on-delay= <30>;
- power-off-delay= <120>;
- reset-delay = <5>;
- init-delay = <100>;
- flip-horizontal;
- flip-vertical;
- panel-width-mm = <29>;
- panel-height-mm = <29>;
-
- display-timings {
- timing-0 {
- clock-frequency = <460>;
- hactive = <320>;
- vactive = <320>;
- hfront-porch = <1>;
- hback-porch = <1>;
- hsync-len = <1>;
- vfront-porch = <150>;
- vback-porch = <1>;
- vsync-len = <2>;
- };
- };
};
};
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/rockchip: Replace dev_* with DRM_DEV_*
On 2017年09月15日 16:36, Haneen Mohammed wrote:
This patch replace instances of dev_info/err/debug with
DRM_DEV_INFO/ERROR/WARN respectively inorder to use a drm-formatted
specific log messages. Issue corrected with the help of the following
Coccinelle script:
@r@
@@
(
-dev_info
+DRM_DEV_INFO
|
-dev_err
+DRM_DEV_ERROR
|
-dev_dbg
+DRM_DEV_DEBUG
)
Signed-off-by: Haneen Mohammed
Hi Haneen
Pushed to drm-misc-next, Thanks for the patch.
Mark
---
Changes in v2:
- Change patch title
- Remove redundant print messages from DRM_DEV_*
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 26
drivers/gpu/drm/rockchip/cdn-dp-reg.c | 2 +-
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 86 ++---
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 19 +++---
drivers/gpu/drm/rockchip/inno_hdmi.c| 14 ++--
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 12 ++--
drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 8 ++-
drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 18 --
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 32 -
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 +-
10 files changed, 121 insertions(+), 98 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 9606121..4d3f6ad 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -88,7 +88,7 @@ static void analogix_dp_psr_set(struct drm_encoder *encoder,
bool enabled)
if (!analogix_dp_psr_supported(dp->dev))
return;
- dev_dbg(dp->dev, "%s PSR...\n", enabled ? "Entry" : "Exit");
+ DRM_DEV_DEBUG(dp->dev, "%s PSR...\n", enabled ? "Entry" : "Exit");
spin_lock_irqsave(&dp->psr_lock, flags);
if (enabled)
@@ -110,7 +110,7 @@ static void analogix_dp_psr_work(struct work_struct *work)
ret = rockchip_drm_wait_vact_end(dp->encoder.crtc,
PSR_WAIT_LINE_FLAG_TIMEOUT_MS);
if (ret) {
- dev_err(dp->dev, "line flag interrupt did not arrive\n");
+ DRM_DEV_ERROR(dp->dev, "line flag interrupt did not arrive\n");
return;
}
@@ -140,13 +140,13 @@ static int rockchip_dp_poweron(struct analogix_dp_plat_data *plat_data)
ret = clk_prepare_enable(dp->pclk);
if (ret < 0) {
- dev_err(dp->dev, "failed to enable pclk %d\n", ret);
+ DRM_DEV_ERROR(dp->dev, "failed to enable pclk %d\n", ret);
return ret;
}
ret = rockchip_dp_pre_init(dp);
if (ret < 0) {
- dev_err(dp->dev, "failed to dp pre init %d\n", ret);
+ DRM_DEV_ERROR(dp->dev, "failed to dp pre init %d\n", ret);
clk_disable_unprepare(dp->pclk);
return ret;
}
@@ -211,17 +211,17 @@ static void rockchip_dp_drm_encoder_enable(struct
drm_encoder *encoder)
else
val = dp->data->lcdsel_big;
- dev_dbg(dp->dev, "vop %s output to dp\n", (ret) ? "LIT" : "BIG");
+ DRM_DEV_DEBUG(dp->dev, "vop %s output to dp\n", (ret) ? "LIT" : "BIG");
ret = clk_prepare_enable(dp->grfclk);
if (ret < 0) {
- dev_err(dp->dev, "failed to enable grfclk %d\n", ret);
+ DRM_DEV_ERROR(dp->dev, "failed to enable grfclk %d\n", ret);
return;
}
ret = regmap_write(dp->grf, dp->data->lcdsel_grf_reg, val);
if (ret != 0)
- dev_err(dp->dev, "Could not write to GRF: %d\n", ret);
+ DRM_DEV_ERROR(dp->dev, "Could not write to GRF: %d\n", ret);
clk_disable_unprepare(dp->grfclk);
}
@@ -277,7 +277,7 @@ static int rockchip_dp_init(struct rockchip_dp_device *dp)
dp->grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf");
if (IS_ERR(dp->grf)) {
- dev_err(dev, "failed to get rockchip,grf property\n");
+ DRM_DEV_ERROR(dev, "failed to get rockchip,grf property\n");
return PTR_ERR(dp->grf);
}
@@ -287,31 +287,31 @@ static int rockchip_dp_init(struct rockchip_dp_device *dp)
} else if (PTR_ERR(dp->grfclk) == -EPROBE_DEFER) {
return -EPROBE_DEFER;
} else if (IS_ERR(dp->grfclk)) {
- dev_err(dev, "failed to get grf clock\n");
+ DRM_DEV_ERROR(dev, "failed to get grf clock\n");
return PTR_ERR(dp->grfclk);
}
dp->pclk = devm_clk_get(dev, "pclk");
if (IS_ERR(dp->pclk)) {
- dev_err(dev, "failed to get pclk property\n");
+ DRM_DEV_ERROR(dev, "failed to get pclk property\n");
return PTR_ERR(dp->pclk);
}
dp->rst = devm_reset_control_get(dev, "dp");
if (IS_ERR(dp->rst)) {
- dev_err(dev, "failed to get dp reset control\n");
+ DRM_DEV_ERROR(dev, "failed to get dp reset co
[Bug 102683] mpv confuses the frequency scaling, leading to freqyency flapping and missed vsyncs
https://bugs.freedesktop.org/show_bug.cgi?id=102683 Niklas Haas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Niklas Haas --- Re-testing this I noticed that it's possible */amdgpu_pm_info just delivers more unrealiable data or something; with GALLIUM_HUD_PERIOD=0 GALLIUM_HUD=shader-clock,gpu-load I noticed it working much better. As for the “performance issues”, I think it may be because of timers getting confused due to the change in frequency? Re-testing I can't notice more dropped frames than usual except at the very beginning, probably due to the very fact that it does frequency scaling. I'll close this issue unless I have something more concrete to report. -- 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 102820] [bisected] commit ebbf7337e2daacacef3e01114e6be68a2a4f11b4 prevents X11 from starting
https://bugs.freedesktop.org/show_bug.cgi?id=102820 --- Comment #5 from dwagner --- Two additional remarks: - I meanwhile verified that X runs fine when I compile the current amd-staging-drm-next with only commit ebbf7337e2daacacef3e01114e6be68a2a4f11b4 reverted. - The kernel Call Trace starting with "amdgpu_dm_connector_atomic_set_property+0x10a/0x180 [amdgpu]" is probably an unrelated issue, as it also occurs without commit ebbf7337e2daacacef3e01114e6be68a2a4f11b4. -- 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 102820] [bisected] commit ebbf7337e2daacacef3e01114e6be68a2a4f11b4 prevents X11 from starting
https://bugs.freedesktop.org/show_bug.cgi?id=102820 --- Comment #4 from dwagner --- I attached the Xorg.0.log as requested, the "dmesg" output as a whole would be somewhat hard to edit for potentially sensitive content, thus I filtered it through "grep -i -w -e drm -e amdgpu" and hope that is good enough. I do not use an xorg.conf file, but I do have some minor customization in /etc/X11/xorg.conf.d/* files that were supplied by the Linux Arch distribution: Section "Monitor" Identifier "Monitor0" DisplaySize 508 285 HorizSync 20.0 - 150.0 VertRefresh 23.96 - 90.0 Option "DPMS" # 3840x2160p at 24Hz 16:9 ModeLine "3840x2160@24" 297.000 3840 5116 5204 5500 2160 2168 2178 2250 +hsync +vsync # 3840x2160p at 25Hz 16:9 ModeLine "3840x2160@25" 297.000 3840 4896 4984 5280 2160 2168 2178 2250 +hsync +vsync # 3840x2160p at 30Hz 16:9 ModeLine "3840x2160@30" 297.000 3840 4016 4104 4400 2160 2168 2178 2250 +hsync +vsync # 3840x2160p at 50Hz 16:9 ModeLine "3840x2160@50" 594.000 3840 4896 4984 5280 2160 2168 2178 2250 +hsync +vsync # 3840x2160p at 60Hz 16:9 ModeLine "3840x2160@60" 594.000 3840 4016 4104 4400 2160 2168 2178 2250 +hsync +vsync EndSection Section "Device" Identifier "Card0" Option "Monitor-HDMI-A-0" "Monitor0" Driver "amdgpu" BusID "PCI:40:0:0" Option "TearFree" "On" # [] EndSection Section "Screen" Identifier "Screen0" Device "Card0" Monitor"Monitor0" DefaultDepth24 SubSection "Display" Viewport0 0 Depth 24 EndSubSection EndSection (The once manually added ModeLines are not currently in use.) -- 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 102820] [bisected] commit ebbf7337e2daacacef3e01114e6be68a2a4f11b4 prevents X11 from starting
https://bugs.freedesktop.org/show_bug.cgi?id=102820 --- Comment #3 from dwagner --- Created attachment 134300 --> https://bugs.freedesktop.org/attachment.cgi?id=134300&action=edit dmesg (filtered by "grep -i -w -e drm -e amdgpu") -- 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 102820] [bisected] commit ebbf7337e2daacacef3e01114e6be68a2a4f11b4 prevents X11 from starting
https://bugs.freedesktop.org/show_bug.cgi?id=102820 --- Comment #2 from dwagner --- Created attachment 134299 --> https://bugs.freedesktop.org/attachment.cgi?id=134299&action=edit Xorg.0.log written while symptoms of Bug 102820 occur -- 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 102820] [bisected] commit ebbf7337e2daacacef3e01114e6be68a2a4f11b4 prevents X11 from starting
https://bugs.freedesktop.org/show_bug.cgi?id=102820 --- Comment #1 from Alex Deucher --- Please attach your xorg log, dmesg output, and xorg conf if you are using one. -- 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: [git pull] amdkfd next 4.14
On Sat, Sep 16, 2017 at 11:58 AM, Oded Gabbay wrote: > On Mon, Sep 4, 2017 at 10:50 AM, Daniel Vetter wrote: >> Hi Alex, >> >> Since Dave is out, can you just pull that into the amd pile? >> -Daniel >> > > Hi Alex, > Did you take the patches to your pile ? > If not, I'll ping Dave again as it seems he is back to work (at least > partially). I didn't pick up these patches. Dave was around last week so he took my pull. Not sure if he is around this week or not. I'll be travelling for XDC so I'm not sure if I'll get around to a pull this week or not. Alex > > Oded > >> On Sat, Sep 02, 2017 at 04:29:38PM +0300, Oded Gabbay wrote: >>> Hi Dave, >>> >>> Three more amdkfd commits for the 4.14 merge window, nothing too major: >>> >>> - Removing redundant memset before memcpy >>> - Passing valid mqd pointer to destroy_mqd function (fix apply to VI cards) >>> - Replace uint32_t and uint64_t with __u32 and __u64 respectively in >>> kfd_ioctl.h >>> >>> Thanks, >>> Oded >>> >>> The following changes since commit 7846b12fe0b5feab5446d892f41b5140c1419109: >>> >>> Merge branch 'drm-vmwgfx-next' of >>> git://people.freedesktop.org/~syeh/repos_linux into drm-next (2017-08-29 >>> 10:38:14 +1000) >>> >>> are available in the git repository at: >>> >>> git://people.freedesktop.org/~gabbayo/linux >>> tags/drm-amdkfd-next-2017-09-02 >>> >>> for you to fetch changes up to 1fabbf781167052f4480bdcc627378a27e78a559: >>> >>> drm/amdkfd: pass queue's mqd when destroying mqd (2017-09-02 15:00:25 >>> +0300) >>> >>> >>> Himanshu Jha (1): >>> drm/amdkfd: remove memset before memcpy >>> >>> Mikko Rapeli (1): >>> uapi linux/kfd_ioctl.h: only use __u32 and __u64 >>> >>> Oded Gabbay (1): >>> drm/amdkfd: pass queue's mqd when destroying mqd >>> >>> drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c | 2 +- >>> .../gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 1 - >>> include/uapi/linux/kfd_ioctl.h | 172 >>> ++--- >>> 3 files changed, 87 insertions(+), 88 deletions(-) >>> ___ >>> dri-devel mailing list >>> dri-devel@lists.freedesktop.org >>> https://lists.freedesktop.org/mailman/listinfo/dri-devel >> >> -- >> Daniel Vetter >> Software Engineer, Intel Corporation >> http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102358] WarThunder freezes at start, with activated vsync (vblank_mode=2)
https://bugs.freedesktop.org/show_bug.cgi?id=102358
--- Comment #22 from har...@gmx.de ---
Created attachment 134297
--> https://bugs.freedesktop.org/attachment.cgi?id=134297&action=edit
debug log: concurrent waiting in xcb_wait_for_special_event()
This command's are used for logging (all in 'src/loader/loader_dri3_helper.c'):
printf("%4x =>dri3_handle_present_event: XCB_PRESENT_COMPLETE_NOTIFY: serial:%u
\n", (uint16_t)pthread_self(), ce->serial);
printf("%4x =>dri3_handle_present_event: XCB_PRESENT_EVENT_IDLE_NOTIFY:
pixmap:%u \n", (uint16_t)pthread_self(), ie->pixmap);
printf("%4x =>xcb_wait_for_special_event in dri3_wait_for_event: send_sbc:%lu
recv_sbc:%lu\n", (uint16_t)pthread_self(), draw->send_sbc, draw->recv_sbc);
printf("%4x =>xcb_wait_for_special_event in dri3_find_back: send_sbc:%lu
recv_sbc:%lu\n", (uint16_t)pthread_self(), draw->send_sbc, draw->recv_sbc);
printf("%4x =>loader_dri3_swapbuffer_barrier:send_sbc:%lu
recv_sbc:%lu\n", (uint16_t)pthread_self(), draw->send_sbc, draw->recv_sbc);
'9240' is obviously the main thread.
--
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 102358] WarThunder freezes at start, with activated vsync (vblank_mode=2)
https://bugs.freedesktop.org/show_bug.cgi?id=102358 --- Comment #21 from har...@gmx.de --- ... looks like the reason for freezing, is a concurrent waiting in xcb_wait_for_special_event(..). While the main thread is waiting for present related events, another thread is consuming this events (because he was the first one entering the wait) and the main thread is waiting for ever (freeze). I will attach the debug log for some frames before the freeze. @Thomas, if my frame rate is lower (FPS < Monitor Sync, because of to much debug output), i don't get any freezes. Could this be the reason why you can't reproduce the freezes with svga-stack? -- 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 101483] A10-8780P (Carrizo) + R7 M260/M265 does not boot without any "workaround" parameter.
https://bugs.freedesktop.org/show_bug.cgi?id=101483 --- Comment #13 from FFAB --- Upstream kernel test - kernel 4.14-rc1 Installation, on which upstream kernel was installed: ubuntu 16.04.3, kernel4.10.0-33, updated 2017-09-17 1. booting without any workaround parameters 2. booting with kernel parameter iommu=soft boot-time 45sec (message sound), black screen remote-login (ssh) o.k. -- 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 101483] A10-8780P (Carrizo) + R7 M260/M265 does not boot without any "workaround" parameter.
https://bugs.freedesktop.org/show_bug.cgi?id=101483 FFAB changed: What|Removed |Added Attachment #133777|0 |1 is obsolete|| --- Comment #12 from FFAB --- Created attachment 134296 --> https://bugs.freedesktop.org/attachment.cgi?id=134296&action=edit dmesg kernel 4.14-rc1 boot, no workaround parameter -- 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 101483] A10-8780P (Carrizo) + R7 M260/M265 does not boot without any "workaround" parameter.
https://bugs.freedesktop.org/show_bug.cgi?id=101483 FFAB changed: What|Removed |Added Attachment #133857|0 |1 is obsolete|| Attachment #133964|0 |1 is obsolete|| Attachment #133965|0 |1 is obsolete|| --- Comment #11 from FFAB --- Created attachment 134295 --> https://bugs.freedesktop.org/attachment.cgi?id=134295&action=edit dmesg kernel 4.14-rc1 -- 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 100387] War Thunder game has visual errors, missing textures
https://bugs.freedesktop.org/show_bug.cgi?id=100387 --- Comment #17 from Maksim --- (In reply to aceman from comment #6) > Are those problems solved in radeonsi? (In reply to aceman from comment #10) > I asked about the radeonSI drive in comment 6 but didn't get a reply. If you > could find out if you are running with it and rendering is fine, I would > like to know. On my other machine amdgpu+radeonsi it is working OK. -- 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 100387] War Thunder game has visual errors, missing textures
https://bugs.freedesktop.org/show_bug.cgi?id=100387 Maksim Bobylev changed: What|Removed |Added Version|git |17.1 --- Comment #16 from Maksim Bobylev --- Same problem on Radeon HD 6470M mesa-17.0.6/17.1.9 llvm-3.9.1-r1/4.0.1 xf86-video-ati-7.9.0 xorg-server-1.19.3 kernel-4.12.12-gentoo -- 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 101900] No HDMI HBR audio on Polaris (no TrueHD, no Atmos, no Neo:X, no HD Master audio)
https://bugs.freedesktop.org/show_bug.cgi?id=101900 Frederik changed: What|Removed |Added CC||frederik.vogels...@gmail.co ||m --- Comment #9 from Frederik --- I have the same issue on my Sapphire RX470. I am on the "amd-staging-drm-next" tree and HD audio does not work at all. When playing back a Dolby TrueHD or DTS-HD Master audio file I have also noise coming from my internal speakers instead of the passthrough device. After the noise comes up, HDMI audio dies completely on me. This means that HDMI audio only works until a HD audio file is being sent to the passthrough device. I would like to help getting this fixed, as this is a blocker for Kodi users. What logs are needed to get to the root of this issue? From Takashi Iwai's comment on the Alsa bug it looks like this is not an Alsa issue. -- 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 102814] Blender 2.79 flickering
https://bugs.freedesktop.org/show_bug.cgi?id=102814 --- Comment #4 from Luke A. Guest --- Turn on triple buffering, this is an old issue that's been reported before. -- 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] drm/amdkfd: check for null dev to avoid a null pointer dereference
On Fri, Sep 8, 2017 at 5:13 PM, Colin King wrote:
> From: Colin Ian King
>
> The call to kfd_device_by_id can potentially return null, so check that
> dev is null and return with -EINVAL to avoid a null pointer dereference.
>
> Detected by CoverityScan CID#1454629 ("Dereference null return value")
>
> Fixes: 5d71dbc3a588 ("drm/amdkfd: Implement image tiling mode support v2")
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
> b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
> index e4a8c2e52cb2..660b3fbade41 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_chardev.c
> @@ -892,6 +892,8 @@ static int kfd_ioctl_get_tile_config(struct file *filep,
> int err = 0;
>
> dev = kfd_device_by_id(args->gpu_id);
> + if (!dev)
> + return -EINVAL;
>
> dev->kfd2kgd->get_tile_config(dev->kgd, &config);
>
> --
> 2.14.1
>
Thanks!
Applied to my -fixes tree
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102389] Random black screen on RX 470, HDMI 4k-60Hz
https://bugs.freedesktop.org/show_bug.cgi?id=102389 --- Comment #8 from jeremi.jasin...@gmail.com --- Thank you for your response. I've tried two different cables, and none of them fixed the problem. I will buy dedicated 4k 60hz cable and see if theres any difference. -- 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 102820] [bisected] commit ebbf7337e2daacacef3e01114e6be68a2a4f11b4 prevents X11 from starting
https://bugs.freedesktop.org/show_bug.cgi?id=102820 Bug ID: 102820 Summary: [bisected] commit ebbf7337e2daacacef3e01114e6be68a2a4f11b4 prevents X11 from starting Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: blocker Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: jb5sgc1n@20mm.eu After returning from a 2-weeks-vacation, I saw that some new and interesting features made it into https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next which I had used before (at commit 94097b0f7f1bfa54b3b1f8b0d74bbd271a0564e4), so I updated my kernel to the current-as-of-today version (at commit 43dd6fde5df450938568885249b836eb376e2ad6) - but found that X11 would not start anymore with the new version. The symptom more specifically is: Booting to the console is fine. When I invoke "X" (manually), the console remains visible, and the Xorg.0.log output indefinitely pauses after the messages [36.622] (EE) AMDGPU(0): Failed to allocate scanout buffer memory [36.623] (EE) AMDGPU(0): Failed to allocate scanout buffer memory [36.623] (EE) AMDGPU(0): failed to set mode: Invalid argument have been emitted. (These messages are not present with the older, working kernel version.) At about the same time, the following dmesg output is emitted: [ 36.405078] [ cut here ] [ 36.405090] WARNING: CPU: 5 PID: 758 at drivers/gpu/drm/drm_mode_object.c:294 drm_object_property_get_value+0x22/0x30 [drm] [ 36.405090] Modules linked in: ipt_REJECT nf_reject_ipv4 nf_log_ipv4 nf_log_common xt_LOG xt_tcpudp xt_owner xt_mark iptable_nat cmac nf_conntrack_ipv4 c pufreq_ondemand nf_defrag_ipv4 nf_nat_ipv4 nf_nat msr bnep nf_conntrack iptable_mangle iptable_filter nls_iso8859_1 nls_cp437 vfat fat snd_hda_codec_realtek snd_hda_codec_generic btusb btrtl btbcm btintel snd_hda_codec_hdmi bluetooth igb snd_hda_intel snd_hda_codec ptp ecdh_generic pps_core rfkill snd_hda_core dca crc16 snd_hwdep snd_pcm edac_mce_amd snd_timer kvm_amd snd soundcore sp5100_tco kvm tpm_tis tpm_tis_core input_leds evdev i2c_piix4 shpchp irqbypass pcs pkr led_class tpm button 8250_dw acpi_cpufreq sch_fq_codel usbip_host usbip_core sg exfat(O) it87(O) hwmon_vid ip_tables x_tables algif_skcipher af_alg sd_m od uas usb_storage serio_raw atkbd [ 36.405113] libps2 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd glue_helper cryptd ccp rng_core ahci libahc i xhci_pci xhci_hcd libata usbcore scsi_mod usb_common i8042 serio amdgpu i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm xfs libcrc32c crc32c_generic crc32c_intel dm_crypt dm_mod dax nvme nvme_core i2c_dev [ 36.405125] CPU: 5 PID: 758 Comm: Xorg Tainted: GW O 4.13.0-rc5-amd+ #6 [ 36.405125] Hardware name: System manufacturer System Product Name/PRIME X370-PRO, BIOS 0810 08/01/2017 [ 36.405126] task: 8807fa35a940 task.stack: c90008be [ 36.405134] RIP: 0010:drm_object_property_get_value+0x22/0x30 [drm] [ 36.405135] RSP: 0018:c90008be3bc8 EFLAGS: 00010282 [ 36.405136] RAX: a04b9340 RBX: 8807f5ac RCX: [ 36.405136] RDX: c90008be3be8 RSI: 8807fa3f4880 RDI: 8807f6b84028 [ 36.405137] RBP: c90008be3bc8 R08: 8807fa3f6520 R09: 8807ed303c00 [ 36.405137] R10: 0040 R11: R12: 8807f6b84000 [ 36.405138] R13: ffea R14: 8807faf17980 R15: 8807f6b84028 [ 36.405138] FS: 7f42ac7fc940() GS:88081ed4() knlGS: [ 36.405139] CS: 0010 DS: ES: CR0: 80050033 [ 36.405140] CR2: 00706e122018 CR3: 0007f790f000 CR4: 003406e0 [ 36.405140] Call Trace: [ 36.405175] amdgpu_dm_connector_atomic_set_property+0x10a/0x180 [amdgpu] [ 36.405184] drm_atomic_set_property+0x186/0x4a0 [drm] [ 36.405191] drm_mode_obj_set_property_ioctl+0x12d/0x280 [drm] [ 36.405199] ? drm_mode_connector_set_obj_prop+0x80/0x80 [drm] [ 36.405206] drm_mode_connector_property_set_ioctl+0x3f/0x60 [drm] [ 36.405212] drm_ioctl_kernel+0x5d/0xb0 [drm] [ 36.405219] drm_ioctl+0x32a/0x400 [drm] [ 36.405226] ? drm_mode_connector_set_obj_prop+0x80/0x80 [drm] [ 36.405229] ? lru_cache_add_active_or_unevictable+0x36/0xb0 [ 36.405249] amdgpu_drm_ioctl+0x4f/0x90 [amdgpu] [ 36.405251] do_vfs_ioctl+0xa5/0x600 [ 36.405253] ? handle_mm_fault+0xd8/0x230 [ 36.405254] SyS_ioctl+0x79/0x90 [ 36.405256] entry_SYSCALL_64_fastpath+0x13/0x94 [ 36.405257] RIP: 0033:0x7f42aa0c30c7 [ 36.405258] RSP: 002b:7ffe62874da8 EFLAGS: 0246 ORIG_RAX: 0010 [ 36.405259] RAX: ffda RBX: 7f42aa387aa0 RCX: 7f42aa0c30c7 [ 36.405259] RDX:
[Bug 102814] Blender 2.79 flickering
https://bugs.freedesktop.org/show_bug.cgi?id=102814 --- Comment #3 from freedesk...@ca.sh13.net --- Indeed, that solves the issue. I guess this needs to be filed with Blender then? -- 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 102389] Random black screen on RX 470, HDMI 4k-60Hz
https://bugs.freedesktop.org/show_bug.cgi?id=102389
--- Comment #7 from dwagner ---
Just a thought: The symptom you describe ("random black screen, lasting for 1-2
seconds") can be caused by bad HDMI cables - especially when using 4k / 60Hz
modes - I had experienced that in the past on two occasions.
Have you tried using a different (preferably short, high-quality) cable?
BTW: Only very few HDMI cable vendors guarantee their products to work up to
600MHz clock frequency, which you require for 4k 60Hz.
--
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
[PATCHv6 5/5] MAINTAINERS: add cec-gpio entry
From: Hans Verkuil Add an entry for the CEC GPIO driver. Signed-off-by: Hans Verkuil --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index eb930ebecfcb..5ef0d34ef502 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3205,6 +3205,15 @@ F: include/uapi/linux/cec.h F: include/uapi/linux/cec-funcs.h F: Documentation/devicetree/bindings/media/cec.txt +CEC GPIO DRIVER +M: Hans Verkuil +L: linux-me...@vger.kernel.org +T: git git://linuxtv.org/media_tree.git +W: http://linuxtv.org +S: Supported +F: drivers/media/platform/cec-gpio/ +F: Documentation/devicetree/bindings/media/cec-gpio.txt + CELL BROADBAND ENGINE ARCHITECTURE M: Arnd Bergmann L: linuxppc-...@lists.ozlabs.org -- 2.14.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv6 3/5] dt-bindings: document the CEC GPIO bindings
From: Hans Verkuil
Document the bindings for the cec-gpio module for hardware where the
CEC line and optionally the HPD line are connected to GPIO lines.
Signed-off-by: Hans Verkuil
Reviewed-by: Linus Walleij
---
.../devicetree/bindings/media/cec-gpio.txt | 32 ++
1 file changed, 32 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/cec-gpio.txt
diff --git a/Documentation/devicetree/bindings/media/cec-gpio.txt
b/Documentation/devicetree/bindings/media/cec-gpio.txt
new file mode 100644
index ..46a0bac8b3b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/cec-gpio.txt
@@ -0,0 +1,32 @@
+* HDMI CEC GPIO driver
+
+The HDMI CEC GPIO module supports CEC implementations where the CEC line
+is hooked up to a pull-up GPIO line and - optionally - the HPD line is
+hooked up to another GPIO line.
+
+Required properties:
+ - compatible: value must be "cec-gpio".
+ - cec-gpios: gpio that the CEC line is connected to. The line should be
+tagged as open drain.
+
+If the CEC line is associated with an HDMI receiver/transmitter, then the
+following property is also required:
+
+ - hdmi-phandle - phandle to the HDMI controller, see also cec.txt.
+
+If the CEC line is not associated with an HDMI receiver/transmitter, then
+the following property is optional:
+
+ - hpd-gpios: gpio that the HPD line is connected to.
+
+Example for the Raspberry Pi 3 where the CEC line is connected to
+pin 26 aka BCM7 aka CE1 on the GPIO pin header and the HPD line is
+connected to pin 11 aka BCM17:
+
+#include
+
+cec-gpio {
+ compatible = "cec-gpio";
+ cec-gpios = <&gpio 7 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
+ hpd-gpios = <&gpio 17 GPIO_ACTIVE_HIGH>;
+};
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv6 2/5] cec-ioc-dqevent.rst: document new CEC_EVENT_PIN_HPD_LOW/HIGH events
From: Hans Verkuil
Document these new CEC events.
Signed-off-by: Hans Verkuil
---
Documentation/media/uapi/cec/cec-ioc-dqevent.rst | 18 ++
1 file changed, 18 insertions(+)
diff --git a/Documentation/media/uapi/cec/cec-ioc-dqevent.rst
b/Documentation/media/uapi/cec/cec-ioc-dqevent.rst
index db615e3405c0..32b47763f5a6 100644
--- a/Documentation/media/uapi/cec/cec-ioc-dqevent.rst
+++ b/Documentation/media/uapi/cec/cec-ioc-dqevent.rst
@@ -160,6 +160,24 @@ it is guaranteed that the state did change in between the
two events.
- Generated if the CEC pin goes from a low voltage to a high voltage.
Only applies to adapters that have the ``CEC_CAP_MONITOR_PIN``
capability set.
+* .. _`CEC-EVENT-PIN-HPD-LOW`:
+
+ - ``CEC_EVENT_PIN_HPD_LOW``
+ - 5
+ - Generated if the HPD pin goes from a high voltage to a low voltage.
+Only applies to adapters that have the ``CEC_CAP_MONITOR_PIN``
+ capability set. When open() is called, the HPD pin can be read and
+ the HPD is low, then an initial event will be generated for that
+ filehandle.
+* .. _`CEC-EVENT-PIN-HPD-HIGH`:
+
+ - ``CEC_EVENT_PIN_HPD_HIGH``
+ - 6
+ - Generated if the HPD pin goes from a low voltage to a high voltage.
+Only applies to adapters that have the ``CEC_CAP_MONITOR_PIN``
+ capability set. When open() is called, the HPD pin can be read and
+ the HPD is high, then an initial event will be generated for that
+ filehandle.
.. tabularcolumns:: |p{6.0cm}|p{0.6cm}|p{10.9cm}|
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv6 4/5] cec-gpio: add HDMI CEC GPIO driver
From: Hans Verkuil
Add a simple HDMI CEC GPIO driver that sits on top of the cec-pin framework.
While I have heard of SoCs that use the GPIO pin for CEC (apparently an
early RockChip SoC used that), the main use-case of this driver is to
function as a debugging tool.
By connecting the CEC line to a GPIO pin on a Raspberry Pi 3 for example
it turns it into a CEC debugger and protocol analyzer.
With 'cec-ctl --monitor-pin' the CEC traffic can be analyzed.
But of course it can also be used with any hardware project where the
HDMI CEC line is hooked up to a pull-up gpio line.
In addition this has (optional) support for tracing HPD changes if the
HPD is connected to a GPIO.
Signed-off-by: Hans Verkuil
Reviewed-by: Linus Walleij
---
drivers/media/platform/Kconfig | 10 ++
drivers/media/platform/Makefile| 2 +
drivers/media/platform/cec-gpio/Makefile | 1 +
drivers/media/platform/cec-gpio/cec-gpio.c | 236 +
4 files changed, 249 insertions(+)
create mode 100644 drivers/media/platform/cec-gpio/Makefile
create mode 100644 drivers/media/platform/cec-gpio/cec-gpio.c
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 7e7cc49b8674..e4c89a16a3e7 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -553,6 +553,16 @@ config VIDEO_MESON_AO_CEC
This is a driver for Amlogic Meson SoCs AO CEC interface. It uses the
generic CEC framework interface.
CEC bus is present in the HDMI connector and enables communication
+
+config CEC_GPIO
+ tristate "Generic GPIO-based CEC driver"
+ depends on PREEMPT
+ select CEC_CORE
+ select CEC_PIN
+ select GPIOLIB
+ ---help---
+ This is a generic GPIO-based CEC driver.
+ The CEC bus is present in the HDMI connector and enables communication
between compatible devices.
config VIDEO_SAMSUNG_S5P_CEC
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index c1ef946bf032..9bf48f118537 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -26,6 +26,8 @@ obj-$(CONFIG_VIDEO_CODA) += coda/
obj-$(CONFIG_VIDEO_SH_VEU) += sh_veu.o
+obj-$(CONFIG_CEC_GPIO) += cec-gpio/
+
obj-$(CONFIG_VIDEO_MEM2MEM_DEINTERLACE)+= m2m-deinterlace.o
obj-$(CONFIG_VIDEO_MUX)+= video-mux.o
diff --git a/drivers/media/platform/cec-gpio/Makefile
b/drivers/media/platform/cec-gpio/Makefile
new file mode 100644
index ..e82b258afa55
--- /dev/null
+++ b/drivers/media/platform/cec-gpio/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_CEC_GPIO) += cec-gpio.o
diff --git a/drivers/media/platform/cec-gpio/cec-gpio.c
b/drivers/media/platform/cec-gpio/cec-gpio.c
new file mode 100644
index ..eb982bce99fc
--- /dev/null
+++ b/drivers/media/platform/cec-gpio/cec-gpio.c
@@ -0,0 +1,236 @@
+/*
+ * Copyright 2017 Cisco Systems, Inc. and/or its affiliates. All rights
reserved.
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct cec_gpio {
+ struct cec_adapter *adap;
+ struct device *dev;
+
+ struct gpio_desc*cec_gpio;
+ int cec_irq;
+ boolcec_is_low;
+ boolcec_have_irq;
+
+ struct gpio_desc*hpd_gpio;
+ int hpd_irq;
+ boolhpd_is_high;
+ ktime_t hpd_ts;
+};
+
+static bool cec_gpio_read(struct cec_adapter *adap)
+{
+ struct cec_gpio *cec = cec_get_drvdata(adap);
+
+ if (cec->cec_is_low)
+ return false;
+ return gpiod_get_value(cec->cec_gpio);
+}
+
+static void cec_gpio_high(struct cec_adapter *adap)
+{
+ struct cec_gpio *cec = cec_get_drvdata(adap);
+
+ if (!cec->cec_is_low)
+ return;
+ cec->cec_is_low = false;
+ gpiod_set_value(cec->cec_gpio, 1);
+}
+
+static void cec_gpio_low(struct cec_adapter *adap)
+{
+ struct cec_gpio *cec = cec_get_drvdata(adap);
+
+ if (cec->cec_is_low)
+ return;
+ if (WARN_ON_ONCE(cec->cec_have_irq))
+ free_irq(
[PATCHv6 1/5] cec: add CEC_EVENT_PIN_HPD_LOW/HIGH events
From: Hans Verkuil
Add support for two new low-level events: PIN_HPD_LOW and PIN_HPD_HIGH.
This is specifically meant for use with the upcoming cec-gpio driver
and makes it possible to trace when the HPD pin changes. Some HDMI
sinks do strange things with the HPD and this makes it easy to debug
this.
Note that this also moves the initialization of a devnode mutex and
list to the allocate_adapter function: if the HPD is high, then as
soon as the HPD interrupt is created an interrupt occurs and
cec_queue_pin_hpd_event() is called which requires that the devnode
mutex and list are initialized.
Signed-off-by: Hans Verkuil
---
drivers/media/cec/cec-adap.c | 18 +-
drivers/media/cec/cec-api.c | 18 ++
drivers/media/cec/cec-core.c | 8
include/media/cec-pin.h | 4
include/media/cec.h | 12 +++-
include/uapi/linux/cec.h | 2 ++
6 files changed, 52 insertions(+), 10 deletions(-)
diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c
index dd769e40416f..eb904a71609a 100644
--- a/drivers/media/cec/cec-adap.c
+++ b/drivers/media/cec/cec-adap.c
@@ -86,7 +86,7 @@ void cec_queue_event_fh(struct cec_fh *fh,
const struct cec_event *new_ev, u64 ts)
{
static const u8 max_events[CEC_NUM_EVENTS] = {
- 1, 1, 64, 64,
+ 1, 1, 64, 64, 8, 8,
};
struct cec_event_entry *entry;
unsigned int ev_idx = new_ev->event - 1;
@@ -170,6 +170,22 @@ void cec_queue_pin_cec_event(struct cec_adapter *adap,
bool is_high, ktime_t ts)
}
EXPORT_SYMBOL_GPL(cec_queue_pin_cec_event);
+/* Notify userspace that the HPD pin changed state at the given time. */
+void cec_queue_pin_hpd_event(struct cec_adapter *adap, bool is_high, ktime_t
ts)
+{
+ struct cec_event ev = {
+ .event = is_high ? CEC_EVENT_PIN_HPD_HIGH :
+ CEC_EVENT_PIN_HPD_LOW,
+ };
+ struct cec_fh *fh;
+
+ mutex_lock(&adap->devnode.lock);
+ list_for_each_entry(fh, &adap->devnode.fhs, list)
+ cec_queue_event_fh(fh, &ev, ktime_to_ns(ts));
+ mutex_unlock(&adap->devnode.lock);
+}
+EXPORT_SYMBOL_GPL(cec_queue_pin_hpd_event);
+
/*
* Queue a new message for this filehandle.
*
diff --git a/drivers/media/cec/cec-api.c b/drivers/media/cec/cec-api.c
index a079f7fe018c..465bb3ec21f6 100644
--- a/drivers/media/cec/cec-api.c
+++ b/drivers/media/cec/cec-api.c
@@ -529,7 +529,7 @@ static int cec_open(struct inode *inode, struct file *filp)
* Initial events that are automatically sent when the cec device is
* opened.
*/
- struct cec_event ev_state = {
+ struct cec_event ev = {
.event = CEC_EVENT_STATE_CHANGE,
.flags = CEC_EVENT_FL_INITIAL_STATE,
};
@@ -569,9 +569,19 @@ static int cec_open(struct inode *inode, struct file *filp)
filp->private_data = fh;
/* Queue up initial state events */
- ev_state.state_change.phys_addr = adap->phys_addr;
- ev_state.state_change.log_addr_mask = adap->log_addrs.log_addr_mask;
- cec_queue_event_fh(fh, &ev_state, 0);
+ ev.state_change.phys_addr = adap->phys_addr;
+ ev.state_change.log_addr_mask = adap->log_addrs.log_addr_mask;
+ cec_queue_event_fh(fh, &ev, 0);
+#ifdef CONFIG_CEC_PIN
+ if (adap->pin && adap->pin->ops->read_hpd) {
+ err = adap->pin->ops->read_hpd(adap);
+ if (err >= 0) {
+ ev.event = err ? CEC_EVENT_PIN_HPD_HIGH :
+CEC_EVENT_PIN_HPD_LOW;
+ cec_queue_event_fh(fh, &ev, 0);
+ }
+ }
+#endif
list_add(&fh->list, &devnode->fhs);
mutex_unlock(&devnode->lock);
diff --git a/drivers/media/cec/cec-core.c b/drivers/media/cec/cec-core.c
index 648136e552d5..e3a1fb6d6690 100644
--- a/drivers/media/cec/cec-core.c
+++ b/drivers/media/cec/cec-core.c
@@ -112,10 +112,6 @@ static int __must_check cec_devnode_register(struct
cec_devnode *devnode,
int minor;
int ret;
- /* Initialization */
- INIT_LIST_HEAD(&devnode->fhs);
- mutex_init(&devnode->lock);
-
/* Part 1: Find a free minor number */
mutex_lock(&cec_devnode_lock);
minor = find_next_zero_bit(cec_devnode_nums, CEC_NUM_DEVICES, 0);
@@ -242,6 +238,10 @@ struct cec_adapter *cec_allocate_adapter(const struct
cec_adap_ops *ops,
INIT_LIST_HEAD(&adap->wait_queue);
init_waitqueue_head(&adap->kthread_waitq);
+ /* adap->devnode initialization */
+ INIT_LIST_HEAD(&adap->devnode.fhs);
+ mutex_init(&adap->devnode.lock);
+
adap->kthread = kthread_run(cec_thread_func, adap, "cec-%s", name);
if (IS_ERR(adap->kthread)) {
pr_err("cec-%s: kernel_thread() failed\n", name);
diff --git a/include/media/cec-pin.h b/include/media/cec-pin.h
index f09cc9579d53..e
[PATCHv6 0/5] cec-gpio: add HDMI CEC GPIO-based driver
From: Hans Verkuil This driver adds support for CEC implementations that use a pull-up GPIO line. While SoCs exist that do this, the primary use-case is to turn a single-board computer into a cheap CEC debugger. Together with 'cec-ctl --monitor-pin' you can do low-level CEC bus monitoring and do protocol analysis. And error injection is also planned for the future. Here is an example using the Raspberry Pi 3: https://hverkuil.home.xs4all.nl/rpi3-cec.jpg While this example is for the Rpi, this driver will work for any SoC with a pull-up GPIO line. In addition the cec-gpio driver can optionally monitor the HPD line. The state of the HPD line influences the CEC behavior so it is very useful to be able to monitor both. And some HDMI sinks are known to quickly toggle the HPD when e.g. switching between inputs. So it is useful to be able to see an event when the HPD changes value. The first two patches add support for the new HPD events. The last three patches are for the cec-gpio driver itself. Regards, Hans Changes since v5: - incorporated Linus Walleij's comments into the bindings document. Changes since v4: - cec-gpio.txt: *-gpio -> *-gpios - cec-gpio.txt: document hdmi-phandle. To be used when cec-gpio is associated with an HDMI receiver/transmitter. - cec-gpio.txt: remove incorrect @7 from dts example. Changes since v3: - cec-gpio.txt: refer to lines instead of pins and use OPEN_DRAIN in the example. - Kconfig: add select GPIOLIB - cec-gpio.c: switch to gpiod. - cec-core.c: initialize the devnode mutex/list in allocate_adapter. Doing this in register_adapter is too late if the HPD is high. Changes since v2: - Add support for HPD events. - Switch from pin BCM4 to pin BCM7 in the bindings example Changes since v1: - Updated the bindings doc to not refer to the driver, instead refer to the hardware. Hans Verkuil (5): cec: add CEC_EVENT_PIN_HPD_LOW/HIGH events cec-ioc-dqevent.rst: document new CEC_EVENT_PIN_HPD_LOW/HIGH events dt-bindings: document the CEC GPIO bindings cec-gpio: add HDMI CEC GPIO driver MAINTAINERS: add cec-gpio entry .../devicetree/bindings/media/cec-gpio.txt | 32 +++ Documentation/media/uapi/cec/cec-ioc-dqevent.rst | 18 ++ MAINTAINERS| 9 + drivers/media/cec/cec-adap.c | 18 +- drivers/media/cec/cec-api.c| 18 +- drivers/media/cec/cec-core.c | 8 +- drivers/media/platform/Kconfig | 10 + drivers/media/platform/Makefile| 2 + drivers/media/platform/cec-gpio/Makefile | 1 + drivers/media/platform/cec-gpio/cec-gpio.c | 236 + include/media/cec-pin.h| 4 + include/media/cec.h| 12 +- include/uapi/linux/cec.h | 2 + 13 files changed, 360 insertions(+), 10 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/cec-gpio.txt create mode 100644 drivers/media/platform/cec-gpio/Makefile create mode 100644 drivers/media/platform/cec-gpio/cec-gpio.c -- 2.14.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv5 4/5] cec-gpio: add HDMI CEC GPIO driver
On Sat, Sep 16, 2017 at 4:28 PM, Hans Verkuil wrote: > From: Hans Verkuil > > Add a simple HDMI CEC GPIO driver that sits on top of the cec-pin framework. > > While I have heard of SoCs that use the GPIO pin for CEC (apparently an > early RockChip SoC used that), the main use-case of this driver is to > function as a debugging tool. > > By connecting the CEC line to a GPIO pin on a Raspberry Pi 3 for example > it turns it into a CEC debugger and protocol analyzer. > > With 'cec-ctl --monitor-pin' the CEC traffic can be analyzed. > > But of course it can also be used with any hardware project where the > HDMI CEC line is hooked up to a pull-up gpio line. > > In addition this has (optional) support for tracing HPD changes if the > HPD is connected to a GPIO. > > Signed-off-by: Hans Verkuil Reviewed-by: Linus Walleij Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv5 3/5] dt-bindings: document the CEC GPIO bindings
On Sat, Sep 16, 2017 at 4:28 PM, Hans Verkuil wrote:
> From: Hans Verkuil
>
> Document the bindings for the cec-gpio module for hardware where the
> CEC line and optionally the HPD line are connected to GPIO lines.
>
> Signed-off-by: Hans Verkuil
Just to make things explicit:
> +Required properties:
> + - compatible: value must be "cec-gpio".
> + - cec-gpios: gpio that the CEC line is connected to.
Add "The line should be tagged as open drain."
> +Example for the Raspberry Pi 3 where the CEC line is connected to
> +pin 26 aka BCM7 aka CE1 on the GPIO pin header and the HPD line is
> +connected to pin 11 aka BCM17:
> +
#include
> +cec-gpio {
> + compatible = "cec-gpio";
> + cec-gpio = <&gpio 7 GPIO_OPEN_DRAIN>;
cec-gpios = <&gpio 7 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
> + hpd-gpio = <&gpio 17 GPIO_ACTIVE_HIGH>;
hpd-gpios = ..
With these fixups:
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: GC2000 series support GLES3
Hi Am 16.09.2017 23:41 schrieb "Torsten Sievers" : Hi guys, when i reading through the (somewhen) upcoming iMX8 and its GC7000 series i stumbled over this one: http://www.vivantecorp.com/index.php/en/technology/3d.html at the very end it is stating the the GC2000 series support GLES3. Correct. However when i am looking at my device on the hummingboard it appears to support only GLES2... Am I doing something wrong or Is this a etnaviv restriction? If so is there anything that we can help to support it? The gallium driver needs some love. Patches are always welcome so feel free to start hacking ;) If you need some starting points for RE work etc join #etnaviv on freenode. BTW: does anybody know if etnaviv is / will support the GC7000 already? It should/will support it (with some work). As far as I know boards with an imx8 are not publicly available and none of the developers have access to such hw. Greets -- Christian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 196777] Virtual guest using video device QXL does not reach GDM
https://bugzilla.kernel.org/show_bug.cgi?id=196777 --- Comment #9 from Krzysztof Nowicki (kri...@op.pl) --- (In reply to Gerd Hoffmann from comment #8) > https://www.kraxel.org/cgit/linux/log/?h=qxl-4.13 > please test Applied over vanilla 4.12 on top of the patch from comment #2. SDDM started fine, I was able to login to the Plasma session and use it for some time. Test repeated twice with the same results. No errors found in dmesg and system is stable. As for me - TEST PASSED Thanks :) -- 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 102814] Blender 2.79 flickering
https://bugs.freedesktop.org/show_bug.cgi?id=102814 --- Comment #2 from network...@rkmail.ru --- I think it's related to bug #98784, try starting blender with LIBGL_DRI3_DISABLE=1 -- 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 102814] Blender 2.79 flickering
https://bugs.freedesktop.org/show_bug.cgi?id=102814 --- Comment #1 from freedesk...@ca.sh13.net --- Should be of course "... the recently released Blender 2.79 doesn't work with Mesa 17.2 at all ...", a kingdom for an edit button :) -- 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 102814] Blender 2.79 flickering
https://bugs.freedesktop.org/show_bug.cgi?id=102814 Bug ID: 102814 Summary: Blender 2.79 flickering Product: Mesa Version: 17.2 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: freedesk...@ca.sh13.net QA Contact: dri-devel@lists.freedesktop.org The recently released Blender 2.79 doesn't work with Blender 2.79 at all, I'm getting super heavy flickering inside the viewport, where it looks like it's swapping between old contents previously rendered, and the "current" content (i.e. for instance the rendering view sometimes jumps between now and 1 second ago.) This makes Blender 2.79 unusable, 2.78 is working fine. I'm using Kubuntu 17.04, RX 480, with the Padoka Stable Mesa, so Mesa 17.2. -- 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
