[Bug 199749] amdgpu on Ryzen 2400G freeze randomly
https://bugzilla.kernel.org/show_bug.cgi?id=199749 --- Comment #31 from James Le Cuirot (ch...@gentoo.org) --- (In reply to notsyncing from comment #30) > Finally got logs from serial port when freezed. Seems my problem has nothing > to do with amdgpu. Maybe I should file a new bug. I may be off the mark but that looks more like bug #196683. Have you tried adjusting "Power Supply Idle Control" in the BIOS (if you have it) or using zenstates.py to disable the C6 package state? -- 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 199749] amdgpu on Ryzen 2400G freeze randomly
https://bugzilla.kernel.org/show_bug.cgi?id=199749 --- Comment #32 from notsyncing (song...@gmail.com) --- I've set that option to "Typical Current Idle" and still freezes. The logs in 196683 points to RCU, which seems not my case. I suspect it's due to the zram. Now I'm trying to reproduce it with zram disabled. -- 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 200383] New: amdgpu: some stacktrace from kernel log, dc110_stream_encoder_update_hdmi_info_packets
https://bugzilla.kernel.org/show_bug.cgi?id=200383 Bug ID: 200383 Summary: amdgpu: some stacktrace from kernel log, dc110_stream_encoder_update_hdmi_info_packets Product: Drivers Version: 2.5 Kernel Version: 4.17.2 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: farmb...@googlemail.com Regression: No Happened after system locked up hard on next boot. Not sure anything is not working atm though. Jul 1 12:33:35 kernel: [ 25.976326] WARNING: CPU: 5 PID: 2342 at drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:132 generic_reg_update_ex+0x101/0x150 Jul 1 12:33:35 kernel: [ 25.976327] Modules linked in: Jul 1 12:33:35 kernel: [ 25.976330] CPU: 5 PID: 2342 Comm: kwin_wayland Tainted: GW 4.17.2 #1 Jul 1 12:33:35 kernel: [ 25.976331] Hardware name: Micro-Star International Co., Ltd. MS-7A31/X370 XPOWER GAMING TITANIUM (MS-7A31), BIOS 1.90 09/19/2017 Jul 1 12:33:35 kernel: [ 25.976333] RIP: 0010:generic_reg_update_ex+0x101/0x150 Jul 1 12:33:35 kernel: [ 25.976333] RSP: 0018:b7aec3f77840 EFLAGS: 00010246 Jul 1 12:33:35 kernel: [ 25.976335] RAX: b7aec3f77860 RBX: 9d5bbd2bbb00 RCX: Jul 1 12:33:35 kernel: [ 25.976335] RDX: RSI: RDI: 9d5bbd2c0480 Jul 1 12:33:35 kernel: [ 25.976336] RBP: b7aec3f778a8 R08: R09: Jul 1 12:33:35 kernel: [ 25.976336] R10: 0001 R11: 0001 R12: Jul 1 12:33:35 kernel: [ 25.976337] R13: R14: R15: 9d5b7ac64000 Jul 1 12:33:35 kernel: [ 25.976338] FS: 7f727ad961c0() GS:9d5bbe74() knlGS: Jul 1 12:33:35 kernel: [ 25.976338] CS: 0010 DS: ES: CR0: 80050033 Jul 1 12:33:35 kernel: [ 25.976339] CR2: 7f72698ae218 CR3: 0007e5e0a000 CR4: 003406e0 Jul 1 12:33:35 kernel: [ 25.976340] Call Trace: Jul 1 12:33:35 kernel: [ 25.976345] dce110_stream_encoder_update_hdmi_info_packets+0x3e4/0x5f0 Jul 1 12:33:35 kernel: [ 25.976348] dce110_apply_ctx_to_hw+0x647/0x8d0 Jul 1 12:33:35 kernel: [ 25.976350] dc_commit_state+0x2c0/0x5b0 Jul 1 12:33:35 kernel: [ 25.976352] ? set_freesync_on_streams.part.7+0xcb/0x2e0 Jul 1 12:33:35 kernel: [ 25.976353] ? mod_freesync_set_user_enable+0x165/0x1b0 Jul 1 12:33:35 kernel: [ 25.976355] amdgpu_dm_atomic_commit_tail+0x327/0xde0 Jul 1 12:33:35 kernel: [ 25.976358] ? wait_for_common+0x14b/0x190 Jul 1 12:33:35 kernel: [ 25.976359] ? wait_for_common+0x14b/0x190 Jul 1 12:33:35 kernel: [ 25.976361] commit_tail+0x3a/0x70 Jul 1 12:33:35 kernel: [ 25.976363] drm_atomic_helper_commit+0x121/0x130 Jul 1 12:33:35 kernel: [ 25.976365] drm_mode_atomic_ioctl+0x86a/0xa40 Jul 1 12:33:35 kernel: [ 25.976367] ? __drm_mode_object_add+0x8e/0xc0 Jul 1 12:33:35 kernel: [ 25.976368] ? mutex_lock+0xe/0x30 Jul 1 12:33:35 kernel: [ 25.976369] ? drm_atomic_set_property+0x520/0x520 Jul 1 12:33:35 kernel: [ 25.976370] drm_ioctl_kernel+0x76/0xd0 Jul 1 12:33:35 kernel: [ 25.976372] drm_ioctl+0x31e/0x3b0 Jul 1 12:33:35 kernel: [ 25.976373] ? drm_atomic_set_property+0x520/0x520 Jul 1 12:33:35 kernel: [ 25.976375] amdgpu_drm_ioctl+0x5d/0xa0 Jul 1 12:33:35 kernel: [ 25.976378] do_vfs_ioctl+0xb0/0x620 Jul 1 12:33:35 kernel: [ 25.976379] ksys_ioctl+0x92/0xa0 Jul 1 12:33:35 kernel: [ 25.976381] __x64_sys_ioctl+0x16/0x20 Jul 1 12:33:35 kernel: [ 25.976383] do_syscall_64+0x4a/0x100 Jul 1 12:33:35 kernel: [ 25.976385] entry_SYSCALL_64_after_hwframe+0x49/0xbe Jul 1 12:33:35 kernel: [ 25.976387] RIP: 0033:0x7f7277bff317 Jul 1 12:33:35 kernel: [ 25.976387] RSP: 002b:7fff610317d8 EFLAGS: 0246 ORIG_RAX: 0010 Jul 1 12:33:35 kernel: [ 25.976388] RAX: ffda RBX: 55b6db2b07c0 RCX: 7f7277bff317 Jul 1 12:33:35 kernel: [ 25.976389] RDX: 7fff61031830 RSI: c03864bc RDI: 0033 Jul 1 12:33:35 kernel: [ 25.976389] RBP: 7fff61031830 R08: 55b6daa2a230 R09: Jul 1 12:33:35 kernel: [ 25.976390] R10: 0002 R11: 0246 R12: c03864bc Jul 1 12:33:35 kernel: [ 25.976390] R13: 0033 R14: 55b6db2416b0 R15: 55b6db2a1ed0 Jul 1 12:33:35 kernel: [ 25.976391] Code: 7f 18 89 da 48 8b 07 ff 50 08 48 8b 74 24 18 65 48 33 34 25 28 00 00 00 89 d8 75 35 48 83 c4 50 5b 41 5c 41 5d 5d c3 0f 0b eb bb <0f> 0b e9 44 ff ff ff 41 8b 0c 24 41 89 c0 49 83 c4 08 45 8b 2c Jul 1 12:33:35 kernel: [ 25.976411] ---[ end trace 38f1d57c974dc64d ]--- Jul 1 12:33:35 kernel: [ 25.979253] WARNING: CPU: 5 PID: 2342 at dr
[Bug 104300] Kernel 4.15-rc2 on Polaris RX 480 with amdgpu.dc=1 has trouble waking up displays after suspend
https://bugs.freedesktop.org/show_bug.cgi?id=104300 --- Comment #3 from Toni Spets --- Created attachment 140414 --> https://bugs.freedesktop.org/attachment.cgi?id=140414&action=edit dmesg of a boot with one suspend cycle This dmesg contains a suspend immediately after the system was booted up. After resuming both displays lit up and showed the last image before the system was suspended. The system was completely unresponsible for a while. Once it was working I had the Xfce hotplug window open and I clicked the extend button which again got the system stuck for the same amount of time. The displays were already correctly arranged so it was unneeded but it also triggered the issue. As a bonus xrandr shows three outputs connected when I have only two. I'll attach output of both (DC and non-DC). -- 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 104300] Kernel 4.15-rc2 on Polaris RX 480 with amdgpu.dc=1 has trouble waking up displays after suspend
https://bugs.freedesktop.org/show_bug.cgi?id=104300 --- Comment #5 from Toni Spets --- Created attachment 140416 --> https://bugs.freedesktop.org/attachment.cgi?id=140416&action=edit xrandr output with DC on -- 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 104300] Kernel 4.15-rc2 on Polaris RX 480 with amdgpu.dc=1 has trouble waking up displays after suspend
https://bugs.freedesktop.org/show_bug.cgi?id=104300 --- Comment #4 from Toni Spets --- Created attachment 140415 --> https://bugs.freedesktop.org/attachment.cgi?id=140415&action=edit xrandr output with DC off -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/arc: Replace drm_dev_unref with drm_dev_put
This patch unifies the naming of DRM functions for reference counting of struct drm_device. The resulting code is more aligned with the rest of the Linux kernel interfaces. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/arc/arcpgu_drv.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c index f067de4e1e82..27d426bf7d01 100644 --- a/drivers/gpu/drm/arc/arcpgu_drv.c +++ b/drivers/gpu/drm/arc/arcpgu_drv.c @@ -204,7 +204,7 @@ static int arcpgu_probe(struct platform_device *pdev) ret = arcpgu_load(drm); if (ret) - goto err_unref; + goto err_put; ret = drm_dev_register(drm, 0); if (ret) @@ -215,8 +215,8 @@ static int arcpgu_probe(struct platform_device *pdev) err_unload: arcpgu_unload(drm); -err_unref: - drm_dev_unref(drm); +err_put: + drm_dev_put(drm); return ret; } @@ -227,7 +227,7 @@ static int arcpgu_remove(struct platform_device *pdev) drm_dev_unregister(drm); arcpgu_unload(drm); - drm_dev_unref(drm); + drm_dev_put(drm); return 0; } -- 2.14.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[amdgpu][tahiti xt] cursor motion smoothness
Hi, I noticed that when my monitor runs at 60Hz, the cursor motion is really not smooth, even at low speed (it starts to be smooth at low speed when my monitor runs at 120/144Hz). Is there a way to improve this at the hardware level or is this a xserver issue? (I run everything git no older than 1/2 week/s). regards, -- Sylvain ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107082] With 4.18 rc kernel stop working video output on AMD GPU Vega 56
https://bugs.freedesktop.org/show_bug.cgi?id=107082 Bug ID: 107082 Summary: With 4.18 rc kernel stop working video output on AMD GPU Vega 56 Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: mikhail.v.gavri...@gmail.com - when monitor plugged via display port after boot I see blank screen, but system react on Ctrl-Alt-Delete and I could connect via ssh and reboot system by init 6 command. - when monitor plugged via HDMI was system hang during boot. More detail provided in downstream report: https://bugzilla.redhat.com/show_bug.cgi?id=1592110 Also I bisecting kernel for investigating problem: $ git bisect log # bad: [4c5e8fc62d6a63065eeae80808c498d1dcfea4f4] Merge tag 'linux-kselftest-4.18-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest # good: [2837461dbe6f4a9acc0d86f88825888109211c99] Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi git bisect start '4c5e8fc62d6a63065eeae80808c498d1dcfea4f4' '2837461dbe6f4a9acc0d86f88825888109211c99' # good: [b5d903c2d656e9bc54bc76554a477d796a63120d] Merge branch 'akpm' (patches from Andrew) git bisect good b5d903c2d656e9bc54bc76554a477d796a63120d # bad: [a0b2ac29415bb44d1c212184c1385a1abe68db5c] drm/amdgpu: fix the missed vcn fw version report git bisect bad a0b2ac29415bb44d1c212184c1385a1abe68db5c # bad: [0b19fdc45feffd7569c081fe32a258df3c8ebb9b] drm/amd/display: fix dscl_manual_ratio_init git bisect bad 0b19fdc45feffd7569c081fe32a258df3c8ebb9b # bad: [4c6530fd66399182d0332c5ed821ea473bdcd7c3] drm/amdgpu: remove unnecessary scheduler entity for VCN git bisect bad 4c6530fd66399182d0332c5ed821ea473bdcd7c3 # bad: [10dd2b865393bb45526ca342fe69207341f89fd5] drm/amd/display: Fix wrong latency assignment for VEGA clock levels git bisect bad 10dd2b865393bb45526ca342fe69207341f89fd5 # bad: [adea72c5046f7fa969ece04c3f31e669edf4] drm/amdgpu: vcn_v1_0_is_idle() can be static git bisect bad adea72c5046f7fa969ece04c3f31e669edf4 # bad: [bfdec234047889f4f6af1ec45c7c502a4405b3fb] drm/amd/display: Implement dm_pp_get_clock_levels_by_type_with_latency git bisect bad bfdec234047889f4f6af1ec45c7c502a4405b3fb # first bad commit: [bfdec234047889f4f6af1ec45c7c502a4405b3fb] drm/amd/display: Implement dm_pp_get_clock_levels_by_type_with_latency -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/atmel-hlcdc: Replace drm_dev_unref with drm_dev_put
This patch unifies the naming of DRM functions for reference counting of struct drm_device. The resulting code is more aligned with the rest of the Linux kernel interfaces. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c index 843cac222e60..fedbfa333bb0 100644 --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c @@ -763,7 +763,7 @@ static int atmel_hlcdc_dc_drm_probe(struct platform_device *pdev) ret = atmel_hlcdc_dc_load(ddev); if (ret) - goto err_unref; + goto err_put; ret = drm_dev_register(ddev, 0); if (ret) @@ -774,8 +774,8 @@ static int atmel_hlcdc_dc_drm_probe(struct platform_device *pdev) err_unload: atmel_hlcdc_dc_unload(ddev); -err_unref: - drm_dev_unref(ddev); +err_put: + drm_dev_put(ddev); return ret; } @@ -786,7 +786,7 @@ static int atmel_hlcdc_dc_drm_remove(struct platform_device *pdev) drm_dev_unregister(ddev); atmel_hlcdc_dc_unload(ddev); - drm_dev_unref(ddev); + drm_dev_put(ddev); return 0; } -- 2.14.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] Re: [PATCH v3 23/24] ARM: dts: sun8i: r40: Add HDMI pipeline
On Sun, Jul 1, 2018 at 6:41 PM, Jernej Škrabec wrote:
> Dne četrtek, 28. junij 2018 ob 08:51:07 CEST je Chen-Yu Tsai napisal(a):
>> On Thu, Jun 28, 2018 at 1:15 PM, Jernej Škrabec
> wrote:
>> > Dne četrtek, 28. junij 2018 ob 04:50:09 CEST je Chen-Yu Tsai napisal(a):
>> >> On Mon, Jun 25, 2018 at 8:03 PM, Jernej Skrabec
>> >
>> > wrote:
>> >> > Add all entries needed for HDMI to function properly.
>> >> >
>> >> > Since R40 has highly configurable pipeline, both mixers and both TCON
>> >> > TVs are added. Board specific DT should then connect them together
>> >> > trough TCON TOP muxers to best fit the purpose of the board.
>> >> >
>> >> > Signed-off-by: Jernej Skrabec
>> >> > ---
>> >> >
>> >> > arch/arm/boot/dts/sun8i-r40.dtsi | 269 +++
>> >> > 1 file changed, 269 insertions(+)
>> >> >
>> >> > diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi
>> >> > b/arch/arm/boot/dts/sun8i-r40.dtsi index 173dcc1652d2..a2a75fb04caf
>> >> > 100644
>> >> > --- a/arch/arm/boot/dts/sun8i-r40.dtsi
>> >> > +++ b/arch/arm/boot/dts/sun8i-r40.dtsi
>> >> > @@ -42,8 +42,11 @@
>> >> >
>> >> > */
>> >> >
>> >> > #include
>> >> >
>> >> > +#include
>> >> >
>> >> > #include
>> >> >
>> >> > +#include
>> >
>> > Maxime, above line breaks compilation for build robot, sorry.
>> >
>> >> > #include
>> >> >
>> >> > +#include
>> >> >
>> >> > / {
>> >> >
>> >> > #address-cells = <1>;
>> >> >
>> >> > @@ -99,12 +102,76 @@
>> >> >
>> >> > };
>> >> >
>> >> > };
>> >> >
>> >> > + de: display-engine {
>> >> > + compatible = "allwinner,sun8i-r40-display-engine",
>> >> > +"allwinner,sun8i-h3-display-engine";
>> >>
>> >> Given that the display pipeline looks different, they should not be
>> >> compatible.
>> >
>> > Ok.
>> >
>> >> > + allwinner,pipelines = <&mixer0>, <&mixer1>;
>> >> > + status = "disabled";
>> >> > + };
>> >> > +
>> >> >
>> >> > soc {
>> >> >
>> >> > compatible = "simple-bus";
>> >> > #address-cells = <1>;
>> >> > #size-cells = <1>;
>> >> > ranges;
>> >> >
>> >> > + display_clocks: clock@100 {
>> >> > + compatible = "allwinner,sun8i-r40-de2-clk",
>> >> > +"allwinner,sun8i-h3-de2-clk";
>> >> > + reg = <0x0100 0x10>;
>> >> > + clocks = <&ccu CLK_DE>,
>> >> > +<&ccu CLK_BUS_DE>;
>> >> > + clock-names = "mod",
>> >> > + "bus";
>> >> > + resets = <&ccu RST_BUS_DE>;
>> >> > + #clock-cells = <1>;
>> >> > + #reset-cells = <1>;
>> >> > + };
>> >> > +
>> >> > + mixer0: mixer@110 {
>> >> > + compatible = "allwinner,sun8i-r40-de2-mixer-0";
>> >> > + reg = <0x0110 0x10>;
>> >> > + clocks = <&display_clocks CLK_BUS_MIXER0>,
>> >> > +<&display_clocks CLK_MIXER0>;
>> >> > + clock-names = "bus",
>> >> > + "mod";
>> >> > + resets = <&display_clocks RST_MIXER0>;
>> >> > +
>> >> > + ports {
>> >> > + #address-cells = <1>;
>> >> > + #size-cells = <0>;
>> >> > +
>> >> > + mixer0_out: port@1 {
>> >> > + reg = <1>;
>> >> > + mixer0_out_tcon_top: endpoint {
>> >> > + remote-endpoint =
>> >> > <&tcon_top_mixer0_in_mixer0>; +
>> >> > };
>> >> > + };
>> >> > + };
>> >> > + };
>> >> > +
>> >> > + mixer1: mixer@120 {
>> >> > + compatible = "allwinner,sun8i-r40-de2-mixer-1";
>> >> > + reg = <0x0120 0x10>;
>> >> > + clocks = <&display_clocks CLK_BUS_MIXER1>,
>> >> > +<&display_clocks CLK_MIXER1>;
>> >> > + clock-names = "bus",
>> >> > + "mod";
>> >> > + resets = <&display_clocks RST_WB>;
>> >> > +
>> >> > + ports {
>> >> > + #address-cells = <1>;
>> >> > + #size-cells = <0>;
>> >> > +
>> >> > + mixer1_out: port@1 {
>> >> > + reg = <1>;
>> >> > + mixer1_out_tcon_top: endpoint {
>> >> > + remote-endpoint =
>> >> > <&tcon_top_mixer1_
[PATCH] drm/sun4i: Remove VLA usage
In the quest to remove all stack VLA usage from the kernel[1], this
switches to using a kmalloc allocation and moves all the size calculations
to the start to do an allocation. If an upper bounds on the mode timing
calculations could be determined, a fixed stack size could be used instead.
[1]
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Signed-off-by: Kees Cook
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 107 +++--
1 file changed, 64 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
index d4e7d16a2514..da9814f94d00 100644
--- a/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
+++ b/drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
@@ -13,6 +13,7 @@
#include
#include
#include
+#include
#include
@@ -247,10 +248,8 @@ static u16 sun6i_dsi_crc_compute(u8 const *buffer, size_t
len)
return crc_ccitt(0x, buffer, len);
}
-static u16 sun6i_dsi_crc_repeat_compute(u8 pd, size_t len)
+static u16 sun6i_dsi_crc_repeat(u8 pd, u8 *buffer, size_t len)
{
- u8 buffer[len];
-
memset(buffer, pd, len);
return sun6i_dsi_crc_compute(buffer, len);
@@ -274,11 +273,11 @@ static u32 sun6i_dsi_build_blk0_pkt(u8 vc, u16 wc)
wc & 0xff, wc >> 8);
}
-static u32 sun6i_dsi_build_blk1_pkt(u16 pd, size_t len)
+static u32 sun6i_dsi_build_blk1_pkt(u16 pd, u8 *buffer, size_t len)
{
u32 val = SUN6I_DSI_BLK_PD(pd);
- return val | SUN6I_DSI_BLK_PF(sun6i_dsi_crc_repeat_compute(pd, len));
+ return val | SUN6I_DSI_BLK_PF(sun6i_dsi_crc_repeat(pd, buffer, len));
}
static void sun6i_dsi_inst_abort(struct sun6i_dsi *dsi)
@@ -452,6 +451,54 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi,
struct mipi_dsi_device *device = dsi->device;
unsigned int Bpp = mipi_dsi_pixel_format_to_bpp(device->format) / 8;
u16 hbp, hfp, hsa, hblk, vblk;
+ size_t bytes;
+ u8 *buffer;
+
+ /* Do all timing calculations up front to allocate buffer space */
+
+ /*
+* A sync period is composed of a blanking packet (4 bytes +
+* payload + 2 bytes) and a sync event packet (4 bytes). Its
+* minimal size is therefore 10 bytes
+*/
+#define HSA_PACKET_OVERHEAD10
+ hsa = max((unsigned int)HSA_PACKET_OVERHEAD,
+ (mode->hsync_end - mode->hsync_start) * Bpp -
HSA_PACKET_OVERHEAD);
+
+ /*
+* The backporch is set using a blanking packet (4 bytes +
+* payload + 2 bytes). Its minimal size is therefore 6 bytes
+*/
+#define HBP_PACKET_OVERHEAD6
+ hbp = max((unsigned int)HBP_PACKET_OVERHEAD,
+ (mode->hsync_start - mode->hdisplay) * Bpp -
HBP_PACKET_OVERHEAD);
+
+ /*
+* The frontporch is set using a blanking packet (4 bytes +
+* payload + 2 bytes). Its minimal size is therefore 6 bytes
+*/
+#define HFP_PACKET_OVERHEAD6
+ hfp = max((unsigned int)HFP_PACKET_OVERHEAD,
+ (mode->htotal - mode->hsync_end) * Bpp - HFP_PACKET_OVERHEAD);
+
+ /*
+* hblk seems to be the line + porches length.
+*/
+ hblk = mode->htotal * Bpp - hsa;
+
+ /*
+* And I'm not entirely sure what vblk is about. The driver in
+* Allwinner BSP is using a rather convoluted calculation
+* there only for 4 lanes. However, using 0 (the !4 lanes
+* case) even with a 4 lanes screen seems to work...
+*/
+ vblk = 0;
+
+ /* How many bytes do we need to send all payloads? */
+ bytes = max_t(size_t, max(max(hfp, hblk), max(hsa, hbp)), vblk);
+ buffer = kmalloc(bytes, GFP_KERNEL);
+ if (WARN_ON(!buffer))
+ return;
regmap_write(dsi->regs, SUN6I_DSI_BASIC_CTL_REG, 0);
@@ -485,63 +532,37 @@ static void sun6i_dsi_setup_timings(struct sun6i_dsi *dsi,
SUN6I_DSI_BASIC_SIZE1_VACT(mode->vdisplay) |
SUN6I_DSI_BASIC_SIZE1_VT(mode->vtotal));
- /*
-* A sync period is composed of a blanking packet (4 bytes +
-* payload + 2 bytes) and a sync event packet (4 bytes). Its
-* minimal size is therefore 10 bytes
-*/
-#define HSA_PACKET_OVERHEAD10
- hsa = max((unsigned int)HSA_PACKET_OVERHEAD,
- (mode->hsync_end - mode->hsync_start) * Bpp -
HSA_PACKET_OVERHEAD);
+ /* sync */
regmap_write(dsi->regs, SUN6I_DSI_BLK_HSA0_REG,
sun6i_dsi_build_blk0_pkt(device->channel, hsa));
regmap_write(dsi->regs, SUN6I_DSI_BLK_HSA1_REG,
-sun6i_dsi_build_blk1_pkt(0, hsa));
+sun6i_dsi_build_blk1_pkt(0, buffer, hsa));
- /*
-* The backporch is set using a blanking packet (4 bytes +
-* payload + 2 bytes). Its minimal size is therefore 6 bytes
-*/
-#define HBP_PACKET_OVERHEAD
Re: drm SPDX updates
On Fri, Jun 29, 2018 at 03:32:23PM -0400, Alex Deucher wrote: > On Tue, May 15, 2018 at 3:53 PM, Alex Deucher wrote: > > On Mon, May 14, 2018 at 12:31 PM, Daniel Vetter wrote: > >> On Mon, May 14, 2018 at 08:10:29AM -0700, Dirk Hohndel wrote: > >>> On Mon, May 14, 2018 at 05:01:43PM +0200, Thomas Hellstrom wrote: > >>> > > I haven't seen any comments in the week since I wrote this. I'm not > >>> > > familiar with the process for the drm changes - so what are the usual > >>> > > next > >>> > > steps? Do I need to submit all or part of this somewhere else? Or does > >>> > > Dave simply take the series (since it has no executable code changes > >>> > > at > >>> > > all)? > >>> > > >>> > There are a number of teams sending pull requests to Dave. One option > >>> > would > >>> > be to have it all go through the drm-misc tree. (CC'ing Daniel Vetter > >>> > about > >>> > that). Another option would perhaps be to send a pull request directly > >>> > to > >>> > Dave (Dave?) And finally, one option would be to rely on the > >>> > maintainers of > >>> > each submodule to take the patches that touch that module. If you go for > >>> > this last option, I can surely take the patches that touch vmwgfx, and > >>> > Christian the TTM patches. > >>> > >>> Again, since this involves no code changes, I think I'd prefer the path > >>> directly via Dave, simply as it makes it more likely that none of them get > >>> lost... assuming you are willing to do that, Dave, where would you like > >>> that PR? > >> > >> Cc: dri-devel and send it to Dave and you should be good. But I thought > >> Alex pulled this all in now? In the end probably doesn't matter really if > >> it gets merged twice :-) > > > > Looks like Christian merged the ttm change and that is in my PR today. > > For the others I think we were running into some issues with merging > > them in our internal git tree (internal export control stuff) so feel > > free to send a separate PR for them if you don't want to wait for us > > to sort out the internal merge first. > > > > Did these ever get merged? Do you still need someone to commit them? A single one of them got merged :-) commit 1297bf2e916d2012995b642dd6851332a73126c2 Author: Dirk Hohndel Date: Wed May 2 15:46:21 2018 +0200 Add SPDX idenitifier and clarify license The rest didn't make it. I'm always happy to get comments. And of course I'd love to see them all routed up to Linus. As it happens Thomas Hellstrom and I talked today about taking some of them into his tree - the vmwgfx changes. But that still leaves quite a few. /D ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 10/24] drm/sun4i: tcon: Generalize engine search algorithm
Dne četrtek, 28. junij 2018 ob 20:25:43 CEST je Maxime Ripard napisal(a):
> On Thu, Jun 28, 2018 at 06:48:50AM +0200, Jernej Škrabec wrote:
> > Dne četrtek, 28. junij 2018 ob 04:06:52 CEST je Chen-Yu Tsai napisal(a):
> > > On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec
> > >
> >
> > wrote:
> > > > Current "old" method to find engine worked pretty well for DE2.
> > > > However,
> > > > it doesn't work when TCON TOP is between mixer (engine) and TCON.
> > > > TCON
> > > > TOP has multiple input ports, but current engine search algorithm
> > > > expects only one.
> > > >
> > > > This can be fixed by first looking for output port id and selecting
> > > > matching input by subtracting 1 for the next round. This work even if
> > > > there is only one input and output.
> > > >
> > > > Signed-off-by: Jernej Skrabec
> > > > ---
> > > >
> > > > drivers/gpu/drm/sun4i/sun4i_tcon.c | 22 ++
> > > > 1 file changed, 18 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > b/drivers/gpu/drm/sun4i/sun4i_tcon.c index 08747fc3ee71..264bcc43da11
> > > > 100644
> > > > --- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
> > > > @@ -791,12 +791,14 @@ static int sun4i_tcon_init_regmap(struct device
> > > > *dev,
> > > >
> > > > */
> > > >
> > > > static struct sunxi_engine *
> > > > sun4i_tcon_find_engine_traverse(struct sun4i_drv *drv,
> > > >
> > > > - struct device_node *node)
> > > > + struct device_node *node,
> > > > + u32 port_id)
> > > >
> > > > {
> > > >
> > > > struct device_node *port, *ep, *remote;
> > > > struct sunxi_engine *engine = ERR_PTR(-EINVAL);
> > > >
> > > > + u32 reg = 0;
> > > >
> > > > - port = of_graph_get_port_by_id(node, 0);
> > > > + port = of_graph_get_port_by_id(node, port_id);
> > > >
> > > > if (!port)
> > > >
> > > > return ERR_PTR(-EINVAL);
> > > >
> > > > @@ -826,8 +828,20 @@ sun4i_tcon_find_engine_traverse(struct sun4i_drv
> > > > *drv,
> > > >
> > > > if (remote == engine->node)
> > > >
> > > > goto out_put_remote;
> > > >
> > > > + /*
> > > > +* According to device tree binding input ports have even id
> > > > +* number and output ports have odd id. Since component with
> > > > +* more than one input and one output (TCON TOP) exits,
> > > > correct
> > > > +* remote input id has to be calculated by subtracting 1 from
> > > > +* remote output id. If this for some reason can't be done, 0
> > > > +* is used as input port id.
> > > > +*/
> > >
> > > You need to call
> > >
> > > of_node_put(port);
> > >
> > > to drop the reference to the original port.
> >
> > Thanks for noticing it. I guess I should send fix patch, since patches
> > from
> > drm-misc-next can't be dropped.
>
> Yeah, please send additional patches for all the issues pointed out by
> Chen-Yu.
Of course. I hope this can be resolved till the end of the next week. After
that, I will be away from PC for 2 weeks. Feel free to drop DT patches if you
think that it will come too close to merge window.
Best regards,
Jernej
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbcon: introduce for_each_registered_fb() helper
Hi Hans,
On 06/29/2018 02:50 AM, Hans de Goede wrote:
> Hi,
>
> Looks good, but you should probably do a new version based on:
>
> https://github.com/bzolnier/linux/tree/fbdev-for-next
>
> This has one more loop to replace, in the fbcon_output_notifier()
> function which was introduced by:
> https://github.com/bzolnier/linux/commit/83d83bebf40132e2d55ec58af666713cc76f9764
OK, I will rebase it to fbdev-for-next in coming version.
Thanks
Yisheng
>
> Regards,
>
> Hans
>
>
>
> On 28-06-18 18:20, Yisheng Xie wrote:
>> Following pattern is often used:
>>
>> for (i = 0; i < FB_MAX; i++) {
>> if (registered_fb[i]) {
>> ...
>> }
>> }
>>
>> Therefore, as Andy's suggestion, for_each_registered_fb() helper can
>> be introduced to make the code easier to read and write by reducing
>> indentation level. It also saves few lines of code in each occurrence.
>>
>> This patch convert all part here at the same time.
>>
>> Signed-off-by: Yisheng Xie
>> ---
>> drivers/video/fbdev/core/fbcon.c | 25 +
>> drivers/video/fbdev/core/fbmem.c | 4 +---
>> include/linux/fb.h | 4
>> 3 files changed, 14 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/video/fbdev/core/fbcon.c
>> b/drivers/video/fbdev/core/fbcon.c
>> index c910e74..610853d 100644
>> --- a/drivers/video/fbdev/core/fbcon.c
>> +++ b/drivers/video/fbdev/core/fbcon.c
>> @@ -2220,8 +2220,8 @@ static int fbcon_switch(struct vc_data *vc)
>>*
>>* info->currcon = vc->vc_num;
>>*/
>> -for (i = 0; i < FB_MAX; i++) {
>> -if (registered_fb[i] != NULL && registered_fb[i]->fbcon_par) {
>> +for_each_registered_fb(i) {
>> +if (registered_fb[i]->fbcon_par) {
>> struct fbcon_ops *o = registered_fb[i]->fbcon_par;
>> o->currcon = vc->vc_num;
>> @@ -3103,11 +3103,9 @@ static int fbcon_fb_unregistered(struct fb_info *info)
>> if (idx == info_idx) {
>> info_idx = -1;
>> -for (i = 0; i < FB_MAX; i++) {
>> -if (registered_fb[i] != NULL) {
>> -info_idx = i;
>> -break;
>> -}
>> +for_each_registered_fb(i) {
>> +info_idx = i;
>> +break;
>> }
>> }
>> @@ -3562,11 +3560,9 @@ static void fbcon_start(void)
>> console_lock();
>> -for (i = 0; i < FB_MAX; i++) {
>> -if (registered_fb[i] != NULL) {
>> -info_idx = i;
>> -break;
>> -}
>> +for_each_registered_fb(i) {
>> +info_idx = i;
>> +break;
>> }
>> do_fbcon_takeover(0);
>> @@ -3586,15 +3582,12 @@ static void fbcon_exit(void)
>> kfree((void *)softback_buf);
>> softback_buf = 0UL;
>> -for (i = 0; i < FB_MAX; i++) {
>> +for_each_registered_fb(i) {
>> int pending = 0;
>> mapped = 0;
>> info = registered_fb[i];
>> -if (info == NULL)
>> -continue;
>> -
>> if (info->queue.func)
>> pending = cancel_work_sync(&info->queue);
>> DPRINTK("fbcon: %s pending work\n", (pending ? "canceled" :
>> diff --git a/drivers/video/fbdev/core/fbmem.c
>> b/drivers/video/fbdev/core/fbmem.c
>> index 609438d..645c6ac 100644
>> --- a/drivers/video/fbdev/core/fbmem.c
>> +++ b/drivers/video/fbdev/core/fbmem.c
>> @@ -1593,10 +1593,8 @@ static int do_remove_conflicting_framebuffers(struct
>> apertures_struct *a,
>> int i, ret;
>> /* check all firmware fbs and kick off if the base addr overlaps */
>> -for (i = 0 ; i < FB_MAX; i++) {
>> +for_each_registered_fb(i) {
>> struct apertures_struct *gen_aper;
>> -if (!registered_fb[i])
>> -continue;
>> if (!(registered_fb[i]->flags & FBINFO_MISC_FIRMWARE))
>> continue;
>> diff --git a/include/linux/fb.h b/include/linux/fb.h
>> index aa74a22..3e13b95 100644
>> --- a/include/linux/fb.h
>> +++ b/include/linux/fb.h
>> @@ -650,6 +650,10 @@ extern int fb_get_color_depth(struct fb_var_screeninfo
>> *var,
>> extern int num_registered_fb;
>> extern struct class *fb_class;
>> +#define for_each_registered_fb(i)\
>> +for (i = 0; i < FB_MAX; i++)\
>> +if (registered_fb[i])
>> +
>> extern int lock_fb_info(struct fb_info *info);
>> static inline void unlock_fb_info(struct fb_info *info)
>>
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 16/24] drm/sun4i: Enable DW HDMI PHY clock
Dne četrtek, 28. junij 2018 ob 04:22:36 CEST je Chen-Yu Tsai napisal(a):
> On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec
wrote:
> > Current DW HDMI PHY code never prepares and enables PHY clock after it is
> > created. It's just used as it is. This may work in some cases, but it's
> > clearly wrong. Fix it by adding proper calls to enable/disable PHY
> > clock.
> >
> > Fixes: 4f86e81748fe ("drm/sun4i: Add support for H3 HDMI PHY variant")
> >
> > Signed-off-by: Jernej Skrabec
>
> So why does it work on the H3? Because there's only one PLL that the whole
> display pipeline uses?
>
> We should probably tag this for stable. So,
>
> Cc:
> Reviewed-by: Chen-Yu Tsai
Same question as before, how this should be handled? Can I send separate patch
with same content to stable ML only?
Best regards,
Jernej
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm/adreno: Remove VLA usage
In the quest to remove all stack VLA usage from the kernel[1], this
switches to using a kasprintf()ed buffer. Return paths are updated
to free the allocation.
[1]
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Signed-off-by: Kees Cook
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 7 +--
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 28 +
2 files changed, 24 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index d39400e5bc42..f5f76f8151f9 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -11,6 +11,7 @@
*
*/
+#include
#include
#include
#include
@@ -19,6 +20,7 @@
#include
#include
#include
+#include
#include "msm_gem.h"
#include "msm_mmu.h"
#include "a5xx_gpu.h"
@@ -91,12 +93,13 @@ static int zap_shader_load_mdt(struct msm_gpu *gpu, const
char *fwname)
ret = qcom_mdt_load(dev, fw, fwname, GPU_PAS_ID,
mem_region, mem_phys, mem_size, NULL);
} else {
- char newname[strlen("qcom/") + strlen(fwname) + 1];
+ char *newname;
- sprintf(newname, "qcom/%s", fwname);
+ newname = kasprintf(GFP_KERNEL, "qcom/%s", fwname);
ret = qcom_mdt_load(dev, fw, newname, GPU_PAS_ID,
mem_region, mem_phys, mem_size, NULL);
+ kfree(newname);
}
if (ret)
goto out;
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index bcbf9f2a29f9..bfaafdfc7eb2 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -17,7 +17,9 @@
* this program. If not, see
Re: [PATCH] drm/sun4i: Implement zpos for DE2
Dne petek, 29. junij 2018 ob 09:17:46 CEST je Maxime Ripard napisal(a): > On Wed, Jun 27, 2018 at 10:58:28PM +0200, Jernej Škrabec wrote: > > Dne sreda, 27. junij 2018 ob 20:25:00 CEST je Maxime Ripard napisal(a): > > > Hi! > > > > > > On Wed, Jun 27, 2018 at 06:45:14PM +0200, Jernej Skrabec wrote: > > > > Initial implementation of DE2 planes only supported fixed zpos. > > > > > > > > Expand implementation with configurable zpos property. > > > > > > > > Signed-off-by: Jernej Skrabec > > > > > > Thanks for that work. I guess you should expand a bit on the exact > > > setup you're doing here. > > > > OK. > > > > > Are the pipes working the same way on the DE2 than on DE1, ie does the > > > pipe blending applies before the alpha blending, and therefore you > > > need to make sure that there's not two planes with alpha going to the > > > same pipe? > > > > I'm not familiar with DE1 and I'm not sure what the problem is. > > The alpha blending is happening after the pipe blending. So you > basically have a two-stage blending, the first one between the planes > assigned to a pipe, only taking the plane priority into account, and > using the highest priority plane's pixel in overlapping area. And > then, you have alpha blending between the two pipes. > > But that means that if you have two planes with alpha assigned to the > same pipe, it's not going to work since the value and alpha of the > lowest priority plane is going to be dropped in favor of the highest > priority, instead of having transparency. This sounds familiar. Each channel contains 4 overlays. Those overlays have fixed order, cannot be scaled and only blending supported is premultiply. This is the first step HW does. I guess this is the thing similar to DE1 plane blending. After that, HW scaling is done on channel level (if it is enabled). Then channels are mapped (reordered) to pipes according to route register and at the end, alpha blending is done between pipes. As you can see, overlays don't fit in DRM concept. They have relative position to channel zpos setting and scalling can't be done on them, with only premultipy supported. Because of those limitations, only one overlay is used in one channel. With this restriction, everything else falls pretty nicely into DRM concept. > > > However, there is an issue in DE2 when alpha blending multiple planes if > > bottom-most plane doesn't cover all screen. In this case alpha blending > > produce weird result on screen. Fortunately, there is elegant solution. > > Black opaque fill color is enabled for pipe 0 (always at the bottom), > > which covers any "undefined region" and that makes alpha blending happy > > again. > > > > Alternatively, blending modes between planes could be tweaked or > > disabled, but I found aforementioned solution is much simpler and > > you set it only once. > > Yeah, we had a similar behaviour as well, if the lowest plane has a > some alpha (!= 0xff), the pixel value is completely dropped. We worked > around this by preventing any plane with alpha at the lowest position, > but it might be a good idea to check if the background color set to > black fixes it. I remember that we were indeed seeing the background > color, but I don't think I tried setting it to black and seeing what > happens. > I tested both corner cases I could think of and all seems to be fine. These are: 1. Having bottom-most plane only partialy covered. This caused issues with alpha blending. Solution is to set opaque black fill color to bottom-most pipe. In this case, previously undefined region doesn't have undefined pixel data and blending is correct. 2. Bottom-most plane has alpha values <0xff. This doesn't cause any issue at all. I suspect that the reason for that is background color set to black. > > > Also, you seem to use the pipe and channels indifferently now, why is > > > that? > > > > Why do you think so? > > Your driver used to use the channel id, and is now replaced by the > zpos assigned (for example in SUN8I_MIXER_BLEND_PIPE_CTL_EN) zpos represents pipe number, so that is correct thing to do. I think I know what bothers you. Patch shows only part of the changed functions. Please take a look at final functions. sun8i_vi_layer_enable() and sun8i_vi_layer_update_coord() still work (mostly) based on channel id. For example, sun8i_vi_layer_update_coord() function sets almost all of the registers based on channel id. Only output size after scaling is set based on pipe (zpos) id. More precisely, zpos has to be used for reading/writing pipe settings in global mixer registers (prefixed with SUN8I_MIXER_BLEND_). Channel id has to be used when reading/writing channel registers (prefixed with SUN8I_MIXER_CHAN_UI_ or SUN8I_MIXER_CHAN_VI_). Before the patch, channel id was actually the same as zpos id and because of that channel id was used for pipes too. > > > Channel always represents HW unit, for example, on H3, mixer0, channel 0 > > always represents VI
[PATCH v2 fbdev-for-next 1/2] fbcon: introduce for_each_registered_fb() helper
Following pattern is often used:
for (i = 0; i < FB_MAX; i++) {
if (registered_fb[i]) {
...
}
}
Therefore, as Andy's suggestion, for_each_registered_fb() helper can
be introduced to make the code easier to read and write by reducing
indentation level. It also saves few lines of code in each occurrence.
This patch convert all part here at the same time.
Suggested-by: Andy Shevchenko
Signed-off-by: Yisheng Xie
---
v2:
- rebase it to fbdev-for-next branch and add one more loop to replace - per
Hans
- Macro should be protected against nested conditionals. - per Andy
drivers/video/fbdev/core/fbcon.c | 31 +++
drivers/video/fbdev/core/fbmem.c | 4 +---
include/linux/fb.h | 4
3 files changed, 16 insertions(+), 23 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 5fb156b..e30d3a1 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -2234,8 +2234,8 @@ static int fbcon_switch(struct vc_data *vc)
*
* info->currcon = vc->vc_num;
*/
- for (i = 0; i < FB_MAX; i++) {
- if (registered_fb[i] != NULL && registered_fb[i]->fbcon_par) {
+ for_each_registered_fb(i) {
+ if (registered_fb[i]->fbcon_par) {
struct fbcon_ops *o = registered_fb[i]->fbcon_par;
o->currcon = vc->vc_num;
@@ -3124,11 +3124,9 @@ static int fbcon_fb_unregistered(struct fb_info *info)
if (idx == info_idx) {
info_idx = -1;
- for (i = 0; i < FB_MAX; i++) {
- if (registered_fb[i] != NULL) {
- info_idx = i;
- break;
- }
+ for_each_registered_fb(i) {
+ info_idx = i;
+ break;
}
}
@@ -3609,10 +3607,8 @@ static int fbcon_output_notifier(struct notifier_block
*nb,
deferred_takeover = false;
logo_shown = FBCON_LOGO_DONTSHOW;
- for (i = 0; i < FB_MAX; i++) {
- if (registered_fb[i])
- fbcon_fb_registered(registered_fb[i]);
- }
+ for_each_registered_fb(i)
+ fbcon_fb_registered(registered_fb[i]);
return NOTIFY_OK;
}
@@ -3638,11 +3634,9 @@ static void fbcon_start(void)
console_lock();
- for (i = 0; i < FB_MAX; i++) {
- if (registered_fb[i] != NULL) {
- info_idx = i;
- break;
- }
+ for_each_registered_fb(i) {
+ info_idx = i;
+ break;
}
do_fbcon_takeover(0);
@@ -3669,15 +3663,12 @@ static void fbcon_exit(void)
kfree((void *)softback_buf);
softback_buf = 0UL;
- for (i = 0; i < FB_MAX; i++) {
+ for_each_registered_fb(i) {
int pending = 0;
mapped = 0;
info = registered_fb[i];
- if (info == NULL)
- continue;
-
if (info->queue.func)
pending = cancel_work_sync(&info->queue);
DPRINTK("fbcon: %s pending work\n", (pending ? "canceled" :
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 609438d..645c6ac 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1593,10 +1593,8 @@ static int do_remove_conflicting_framebuffers(struct
apertures_struct *a,
int i, ret;
/* check all firmware fbs and kick off if the base addr overlaps */
- for (i = 0 ; i < FB_MAX; i++) {
+ for_each_registered_fb(i) {
struct apertures_struct *gen_aper;
- if (!registered_fb[i])
- continue;
if (!(registered_fb[i]->flags & FBINFO_MISC_FIRMWARE))
continue;
diff --git a/include/linux/fb.h b/include/linux/fb.h
index aa74a22..fd31e6f 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -650,6 +650,10 @@ extern int fb_get_color_depth(struct fb_var_screeninfo
*var,
extern int num_registered_fb;
extern struct class *fb_class;
+#define for_each_registered_fb(i) \
+ for (i = 0; i < FB_MAX; i++)\
+ if (!registered_fb[i]) {} else
+
extern int lock_fb_info(struct fb_info *info);
static inline void unlock_fb_info(struct fb_info *info)
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 fbdev-for-next 1/2] fbcon: introduce for_each_registered_fb() helper
On Sat, 2018-06-30 at 15:29 +0800, Yisheng Xie wrote:
> Following pattern is often used:
>
> for (i = 0; i < FB_MAX; i++) {
> if (registered_fb[i]) {
> ...
> }
> }
>
> Therefore, as Andy's suggestion, for_each_registered_fb() helper can
> be introduced to make the code easier to read and write by reducing
> indentation level. It also saves few lines of code in each occurrence.
>
> This patch convert all part here at the same time.
>
Reviewed-by: Andy Shevchenko
> Suggested-by: Andy Shevchenko
> Signed-off-by: Yisheng Xie
> ---
> v2:
> - rebase it to fbdev-for-next branch and add one more loop to replace
> - per Hans
> - Macro should be protected against nested conditionals. - per Andy
> drivers/video/fbdev/core/fbcon.c | 31 +++
> drivers/video/fbdev/core/fbmem.c | 4 +---
> include/linux/fb.h | 4
> 3 files changed, 16 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c
> b/drivers/video/fbdev/core/fbcon.c
> index 5fb156b..e30d3a1 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -2234,8 +2234,8 @@ static int fbcon_switch(struct vc_data *vc)
>*
>* info->currcon = vc->vc_num;
>*/
> - for (i = 0; i < FB_MAX; i++) {
> - if (registered_fb[i] != NULL && registered_fb[i]-
> >fbcon_par) {
> + for_each_registered_fb(i) {
> + if (registered_fb[i]->fbcon_par) {
> struct fbcon_ops *o = registered_fb[i]-
> >fbcon_par;
>
> o->currcon = vc->vc_num;
> @@ -3124,11 +3124,9 @@ static int fbcon_fb_unregistered(struct fb_info
> *info)
> if (idx == info_idx) {
> info_idx = -1;
>
> - for (i = 0; i < FB_MAX; i++) {
> - if (registered_fb[i] != NULL) {
> - info_idx = i;
> - break;
> - }
> + for_each_registered_fb(i) {
> + info_idx = i;
> + break;
> }
> }
>
> @@ -3609,10 +3607,8 @@ static int fbcon_output_notifier(struct
> notifier_block *nb,
> deferred_takeover = false;
> logo_shown = FBCON_LOGO_DONTSHOW;
>
> - for (i = 0; i < FB_MAX; i++) {
> - if (registered_fb[i])
> - fbcon_fb_registered(registered_fb[i]);
> - }
> + for_each_registered_fb(i)
> + fbcon_fb_registered(registered_fb[i]);
>
> return NOTIFY_OK;
> }
> @@ -3638,11 +3634,9 @@ static void fbcon_start(void)
>
> console_lock();
>
> - for (i = 0; i < FB_MAX; i++) {
> - if (registered_fb[i] != NULL) {
> - info_idx = i;
> - break;
> - }
> + for_each_registered_fb(i) {
> + info_idx = i;
> + break;
> }
>
> do_fbcon_takeover(0);
> @@ -3669,15 +3663,12 @@ static void fbcon_exit(void)
> kfree((void *)softback_buf);
> softback_buf = 0UL;
>
> - for (i = 0; i < FB_MAX; i++) {
> + for_each_registered_fb(i) {
> int pending = 0;
>
> mapped = 0;
> info = registered_fb[i];
>
> - if (info == NULL)
> - continue;
> -
> if (info->queue.func)
> pending = cancel_work_sync(&info->queue);
> DPRINTK("fbcon: %s pending work\n", (pending ?
> "canceled" :
> diff --git a/drivers/video/fbdev/core/fbmem.c
> b/drivers/video/fbdev/core/fbmem.c
> index 609438d..645c6ac 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -1593,10 +1593,8 @@ static int
> do_remove_conflicting_framebuffers(struct apertures_struct *a,
> int i, ret;
>
> /* check all firmware fbs and kick off if the base addr
> overlaps */
> - for (i = 0 ; i < FB_MAX; i++) {
> + for_each_registered_fb(i) {
> struct apertures_struct *gen_aper;
> - if (!registered_fb[i])
> - continue;
>
> if (!(registered_fb[i]->flags &
> FBINFO_MISC_FIRMWARE))
> continue;
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index aa74a22..fd31e6f 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -650,6 +650,10 @@ extern int fb_get_color_depth(struct
> fb_var_screeninfo *var,
> extern int num_registered_fb;
> extern struct class *fb_class;
>
> +#define for_each_registered_fb(i)\
> + for (i = 0; i < FB_MAX; i++)\
> + if (!registered_fb[i]) {} else
> +
> extern int lock_fb_info(struct fb_info *info);
>
> static inline void unlock_fb_info(struct fb_info *info)
--
Andy Shevchenko
Intel Finland Oy
___
dri-devel mail
Re: [PATCH v3 17/24] drm/sun4i: Don't change clock bits in DW HDMI PHY driver
Dne četrtek, 28. junij 2018 ob 04:24:02 CEST je Chen-Yu Tsai napisal(a): > On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec wrote: > > DW HDMI PHY driver and PHY clock driver share same registers. Make sure > > that DW HDMI PHY setup code doesn't change any clock related bits. > > During initialization, set PHY PLL parent bit to 0. > > > > Signed-off-by: Jernej Skrabec > > Reviewed-by: Chen-Yu Tsai > > and maybe a fixes tag? No need for fixes tag here. H3 and H5 HDMI PHYs have only one possible parent clock. Without this patch, 0 is always written in parent clock bit, which correctly selects first parent. This is preparation patch for 2 clock parents support. Best regards, Jernej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm v1 2/2] drm/fourcc: add msm compressed format modifiers
Qualcomm Snapdragon chipsets uses compressed format
to optimize BW across multiple IP's. This change adds
needed modifier support in drm for a simple 4x4 tile
based compressed variants of base formats.
derived from kernel patch: https://patchwork.kernel.org/patch/10449533/
Signed-off-by: Tanmay Shah
---
include/drm/drm_fourcc.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index e04613d..85c6fe1 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -298,6 +298,19 @@ extern "C" {
*/
#define DRM_FORMAT_MOD_SAMSUNG_64_32_TILE fourcc_mod_code(SAMSUNG, 1)
+/*
+ * MSM compressed format
+ *
+ * Refers to the compressed variant of a base format.
+ * Implementation may be platform and base-format specific.
+ *
+ * Each macrotile consists of m x n (mostly 4 x 4) tiles.
+ * Pixel data pitch/stride is aligned with macrotile width.
+ * Pixel data height is aligned with macrotile height.
+ * Entire pixel data buffer is aligned with 4k(bytes).
+ */
+#define DRM_FORMAT_MOD_QCOM_COMPRESSED fourcc_mod_code(QCOM, 1)
+
/* Vivante framebuffer modifiers */
/*
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] Re: [PATCH v3 09/24] drm/sun4i: Don't skip TCONs if they don't have channel 0
Dne četrtek, 28. junij 2018 ob 08:24:34 CEST je Chen-Yu Tsai napisal(a): > On Thu, Jun 28, 2018 at 12:45 PM, Jernej Škrabec > > wrote: > > Dne četrtek, 28. junij 2018 ob 03:51:31 CEST je Chen-Yu Tsai napisal(a): > >> On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec > > > > wrote: > >> > TV TCONs (channel 1 only) are always connected to TV or HDMI encoder. > >> > Because of that, all output endpoints on such TCON node will point to a > >> > encoder which is part of component framework. > >> > > >> > Correct current graph traversing algorithm in such way that it doesn't > >> > skip output enpoints with id 0 on TV TCONs. > >> > >> No. Our bindings say that endpoint 0 _is_ channel 0. For TCONs that don't > >> have channel 0, it must be skipped. > > > > I'm not sure where this is stated. I read TCON binding again. Can you > > please point me to it? > > https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bind > ings/display/sunxi/sun4i-drm.txt#L169 > > Our TCON driver still expects RGB or LVDS panel / bridges on endpoint 0. Yes, but that can only happen on TCON which has channel 0. TV TCONs (those with channel 1 only) can't have panels or bridges connected to them, because they are internally always connected to either HDMI or TV encoder or both. Actually, R40 is the only SoC, where same TV TCON can be connected to TV encoder or HDMI. Others have specialized TV TCONs, which are connect to only one encoder. IMO TV TCONs are really just stripped down LCD TCONs to support one (or max two) specific encoder. > So I guess this was sort of implied historically. It's no longer true. > This is something we should probably fix. Fixed in what way? You mean update bindings to mention that TCON output endpoint 0 is reserved for panels or bridges? > > In practice our drivers don't look at it (yet), but rely on the downstream > encoder type to determine which channel to use. > > But please add the "allwinner,tcon-channel" property as specified in > the binding. It's my understanding of TCON binding documentation that property "allwinner,tcon-channel" is needed only if TCON supports both channels. TV TCON clearly supports only channel 1. In that case, there is no doubt to which channel output endpoint belongs. If that's not true, dt bindings documentation should be reworded to contain word "needed" or something similar. Currently, no DT for newer SoC contains that property (for example, A83T, H3, H5 or even A33). On A33 this is even more interesting, since tcon0 has only channel 0 and has DSI output endpoint with number 1. According to TCON binding docs, if "allwinner,tcon-channel" is not preset, endpoint number represent channel. So, that would mean DSI needs channel 1 on tcon which supports clearly only channel 0. So either there TCON bindings documentation needs updates or DT for A33 has to be updated. BTW, "allwinner,tcon-channel" property is not used at all in the code. > > > So on TV TCONs on R40 (without channel 0) TVE would be endpoint 1 and HDMI > > endpoint 2 (or the other way around)? > > Which one goes first doesn't quite matter. IIRC there's also a mux for TVE? AFAIK, TV TCON is by default connected to TV encoder unless HDMI mux in TCON TOP points to it. I think it's best put TVE with lower number since it's default and HDMI with higher number. Best regards, Jernej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm v1 1/2] libdrm: add msm drm uapi header
file derived from msm-next kernel uapi header.
Signed-off-by: Tanmay Shah
---
Makefile.sources | 1 +
include/drm/msm_drm.h | 308 ++
2 files changed, 309 insertions(+)
create mode 100644 include/drm/msm_drm.h
diff --git a/Makefile.sources b/Makefile.sources
index 1f8372b..55290fe 100644
--- a/Makefile.sources
+++ b/Makefile.sources
@@ -25,6 +25,7 @@ LIBDRM_INCLUDE_H_FILES := \
include/drm/i915_drm.h \
include/drm/mach64_drm.h \
include/drm/mga_drm.h \
+ include/drm/msm_drm.h \
include/drm/nouveau_drm.h \
include/drm/qxl_drm.h \
include/drm/r128_drm.h \
diff --git a/include/drm/msm_drm.h b/include/drm/msm_drm.h
new file mode 100644
index 000..c06d0a5
--- /dev/null
+++ b/include/drm/msm_drm.h
@@ -0,0 +1,308 @@
+/*
+ * Copyright (C) 2013 Red Hat
+ * Author: Rob Clark
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE
+ * SOFTWARE.
+ */
+
+#ifndef __MSM_DRM_H__
+#define __MSM_DRM_H__
+
+#include "drm.h"
+
+#if defined(__cplusplus)
+extern "C" {
+#endif
+
+/* Please note that modifications to all structs defined here are
+ * subject to backwards-compatibility constraints:
+ * 1) Do not use pointers, use __u64 instead for 32 bit / 64 bit
+ * user/kernel compatibility
+ * 2) Keep fields aligned to their size
+ * 3) Because of how drm_ioctl() works, we can add new fields at
+ * the end of an ioctl if some care is taken: drm_ioctl() will
+ * zero out the new fields at the tail of the ioctl, so a zero
+ * value should have a backwards compatible meaning. And for
+ * output params, userspace won't see the newly added output
+ * fields.. so that has to be somehow ok.
+ */
+
+#define MSM_PIPE_NONE0x00
+#define MSM_PIPE_2D0 0x01
+#define MSM_PIPE_2D1 0x02
+#define MSM_PIPE_3D0 0x10
+
+/* The pipe-id just uses the lower bits, so can be OR'd with flags in
+ * the upper 16 bits (which could be extended further, if needed, maybe
+ * we extend/overload the pipe-id some day to deal with multiple rings,
+ * but even then I don't think we need the full lower 16 bits).
+ */
+#define MSM_PIPE_ID_MASK 0x
+#define MSM_PIPE_ID(x) ((x) & MSM_PIPE_ID_MASK)
+#define MSM_PIPE_FLAGS(x)((x) & ~MSM_PIPE_ID_MASK)
+
+/* timeouts are specified in clock-monotonic absolute times (to simplify
+ * restarting interrupted ioctls). The following struct is logically the
+ * same as 'struct timespec' but 32/64b ABI safe.
+ */
+struct drm_msm_timespec {
+ __s64 tv_sec; /* seconds */
+ __s64 tv_nsec; /* nanoseconds */
+};
+
+#define MSM_PARAM_GPU_ID 0x01
+#define MSM_PARAM_GMEM_SIZE 0x02
+#define MSM_PARAM_CHIP_ID0x03
+#define MSM_PARAM_MAX_FREQ 0x04
+#define MSM_PARAM_TIMESTAMP 0x05
+#define MSM_PARAM_GMEM_BASE 0x06
+#define MSM_PARAM_NR_RINGS 0x07
+
+struct drm_msm_param {
+ __u32 pipe; /* in, MSM_PIPE_x */
+ __u32 param; /* in, MSM_PARAM_x */
+ __u64 value; /* out (get_param) or in (set_param) */
+};
+
+/*
+ * GEM buffers:
+ */
+
+#define MSM_BO_SCANOUT 0x0001 /* scanout capable */
+#define MSM_BO_GPU_READONLY 0x0002
+#define MSM_BO_CACHE_MASK0x000f
+/* cache modes */
+#define MSM_BO_CACHED0x0001
+#define MSM_BO_WC0x0002
+#define MSM_BO_UNCACHED 0x0004
+
+#define MSM_BO_FLAGS (MSM_BO_SCANOUT | \
+ MSM_BO_GPU_READONLY | \
+ MSM_BO_CACHED | \
+ MSM_BO_WC | \
+ MSM_BO_UNCACHED)
+
+struct drm_msm_gem_new {
+ __u64 size; /* in */
+ __u32 flags; /* in, mask of MSM_BO_x */
+ __u32 handle; /* out */
+};
+
+#define MSM_INFO_IOVA 0x01
+
+#define MSM_INFO_FLAGS (MSM_INFO_IOVA)
+
+struct drm_msm_gem_info
Re: drm SPDX updates
On Fri, Jun 29, 2018 at 03:39:19PM -0400, Alex Deucher wrote: > >> > >> Did these ever get merged? Do you still need someone to commit them? > > > > A single one of them got merged :-) > > > > commit 1297bf2e916d2012995b642dd6851332a73126c2 > > Author: Dirk Hohndel > > Date: Wed May 2 15:46:21 2018 +0200 > > > > Add SPDX idenitifier and clarify license > > > > The rest didn't make it. I'm always happy to get comments. And of course > > I'd love to see them all routed up to Linus. > > > > As it happens Thomas Hellstrom and I talked today about taking some of > > them into his tree - the vmwgfx changes. But that still leaves quite a > > few. > > I just picked up the radeon and amd patches. I can push the others to > drm-misc if you'd like. Excellent and Yes Please! /D ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915/intel_dsi: Add acpi_gpio_mapping for the panel-enable GPIO
Add acpi_gpio_mapping for the panel-enable GPIO, this fixes the following
error: "Failed to own gpio for panel control" on BYT/CHT devices where
pwm_blc == PPS_BLC_PMIC.
Note this patch is untested as I don't have hardware to test this,
but it should fix things.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_dsi.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 3b7acb5a70b3..b2b75ed3cbf9 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
#include "i915_drv.h"
@@ -1713,6 +1714,13 @@ static void intel_dsi_add_properties(struct
intel_connector *connector)
}
}
+static const struct acpi_gpio_params panel_gpio = { 0, 0, false };
+
+static const struct acpi_gpio_mapping panel_gpios[] = {
+ { "panel", &panel_gpio, 1 },
+ { },
+};
+
void intel_dsi_init(struct drm_i915_private *dev_priv)
{
struct drm_device *dev = &dev_priv->drm;
@@ -1811,6 +1819,7 @@ void intel_dsi_init(struct drm_i915_private *dev_priv)
*/
if ((IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) &&
(dev_priv->vbt.dsi.config->pwm_blc == PPS_BLC_PMIC)) {
+ devm_acpi_dev_add_driver_gpios(dev->dev, panel_gpios);
intel_dsi->gpio_panel =
gpiod_get(dev->dev, "panel", GPIOD_OUT_HIGH);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 fbdev-for-next 2/2] fbdev: fix typo in comment
change beeng to being and occured to occurred.
Signed-off-by: Yisheng Xie
---
v2:
- new add one.
include/linux/fb.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index fd31e6f..3e7e753 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -126,7 +126,7 @@ struct fb_cursor_user {
/* The resolution of the passed in fb_info about to change */
#define FB_EVENT_MODE_CHANGE 0x01
-/* The display on this fb_info is beeing suspended, no access to the
+/* The display on this fb_info is being suspended, no access to the
* framebuffer is allowed any more after that call returns
*/
#define FB_EVENT_SUSPEND 0x02
@@ -159,9 +159,9 @@ struct fb_cursor_user {
#define FB_EVENT_FB_UNBIND 0x0E
/* CONSOLE-SPECIFIC: remap all consoles to new fb - for vga_switcheroo */
#define FB_EVENT_REMAP_ALL_CONSOLE 0x0F
-/* A hardware display blank early change occured */
+/* A hardware display blank early change occurred */
#define FB_EARLY_EVENT_BLANK 0x10
-/* A hardware display blank revert early change occured */
+/* A hardware display blank revert early change occurred */
#define FB_R_EARLY_EVENT_BLANK 0x11
struct fb_event {
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/intel_dsi: Add acpi_gpio_mapping for the panel-enable GPIO
On Fri, 2018-06-29 at 14:51 +0300, Ville Syrjälä wrote: > On Fri, Jun 29, 2018 at 01:32:58PM +0200, Hans de Goede wrote: I saw that the change was discarded but I would comment about the GPIO ACPI mapping tables. > > + devm_acpi_dev_add_driver_gpios(dev->dev, > > panel_gpios); > > Some explanation on what this actually does would be nice. There is no > documentation that I can see so it's totally unclear why this is > needed. Documentation is here Documentation/acpi/gpio-properties.txt. The key phrase is "...the driver is supposed to know what to use the GpioIo()/GpioInt() resources for once it has identified the device. Having done that, it can simply assign names to the GPIO lines it is going to use and provide the GPIO subsystem with a mapping between those names and the ACPI GPIO resources corresponding to them. To do that, the driver needs to define a mapping table..." -- Andy Shevchenko Intel Finland Oy ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] display: panel: Add KOE tx14d24vm1bpa display support (320x240)
Hi Thierry,
> Hi Thierry,
>
> > This commit adds support for KOE's 5.7" display.
> >
> > Signed-off-by: Lukasz Majewski
> > Reviewed-by: Rob Herring
> > ---
> > Changes for v2:
> > - Add Reviewed-by tag
>
> Could you apply this patch to your tree?
If I may gentle ping on this patch. It is quite mature now... :-)
Best regards,
Łukasz
>
> Thanks in advance,
> Łukasz
>
> >
> > ---
> > .../bindings/display/panel/koe,tx14d24vm1bpa.txt | 42
> > ++
> > drivers/gpu/drm/panel/panel-simple.c | 26
> > ++ 2 files changed, 68 insertions(+) create mode 100644
> > Documentation/devicetree/bindings/display/panel/koe,tx14d24vm1bpa.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/panel/koe,tx14d24vm1bpa.txt
> > b/Documentation/devicetree/bindings/display/panel/koe,tx14d24vm1bpa.txt
> > new file mode 100644 index ..be7ac666807b --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/display/panel/koe,tx14d24vm1bpa.txt
> > @@ -0,0 +1,42 @@ +Kaohsiung Opto-Electronics Inc. 5.7" QVGA (320 x
> > 240) TFT LCD panel +
> > +Required properties:
> > +- compatible: should be "koe,tx14d24vm1bpa"
> > +- backlight: phandle of the backlight device attached to the panel
> > +- power-supply: single regulator to provide the supply voltage
> > +
> > +Required nodes:
> > +- port: Parallel port mapping to connect this display
> > +
> > +This panel needs single power supply voltage. Its backlight is
> > conntrolled +via PWM signal.
> > +
> > +Example:
> > +
> > +
> > +Example device-tree definition when connected to iMX53 based board
> > +
> > + lcd_panel: lcd-panel {
> > + compatible = "koe,tx14d24vm1bpa";
> > + backlight = <&backlight_lcd>;
> > + power-supply = <®_3v3>;
> > +
> > + port {
> > + lcd_panel_in: endpoint {
> > + remote-endpoint =
> > <&lcd_display_out>;
> > + };
> > + };
> > + };
> > +
> > +Then one needs to extend the dispX node:
> > +
> > + lcd_display: disp1 {
> > +
> > + port@1 {
> > + reg = <1>;
> > +
> > + lcd_display_out: endpoint {
> > + remote-endpoint = <&lcd_panel_in>;
> > + };
> > + };
> > + };
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > b/drivers/gpu/drm/panel/panel-simple.c index
> > d9984bdb5bb5..103b43ce7dee 100644 ---
> > a/drivers/gpu/drm/panel/panel-simple.c +++
> > b/drivers/gpu/drm/panel/panel-simple.c @@ -1268,6 +1268,29 @@ static
> > const struct panel_desc innolux_zj070na_01p = { },
> > };
> >
> > +static const struct display_timing koe_tx14d24vm1bpa_timing = {
> > + .pixelclock = { 558, 585, 620 },
> > + .hactive = { 320, 320, 320 },
> > + .hfront_porch = { 30, 30, 30 },
> > + .hback_porch = { 30, 30, 30 },
> > + .hsync_len = { 1, 5, 17 },
> > + .vactive = { 240, 240, 240 },
> > + .vfront_porch = { 6, 6, 6 },
> > + .vback_porch = { 5, 5, 5 },
> > + .vsync_len = { 1, 2, 11 },
> > + .flags = DISPLAY_FLAGS_DE_HIGH,
> > +};
> > +
> > +static const struct panel_desc koe_tx14d24vm1bpa = {
> > + .timings = &koe_tx14d24vm1bpa_timing,
> > + .num_timings = 1,
> > + .bpc = 6,
> > + .size = {
> > + .width = 115,
> > + .height = 86,
> > + },
> > +};
> > +
> > static const struct display_timing koe_tx31d200vm0baa_timing = {
> > .pixelclock = { 3960, 4320, 4800 },
> > .hactive = { 1280, 1280, 1280 },
> > @@ -2204,6 +2227,9 @@ static const struct of_device_id
> > platform_of_match[] = { .compatible = "innolux,zj070na-01p",
> > .data = &innolux_zj070na_01p,
> > }, {
> > + .compatible = "koe,tx14d24vm1bpa",
> > + .data = &koe_tx14d24vm1bpa,
> > + }, {
> > .compatible = "koe,tx31d200vm0baa",
> > .data = &koe_tx31d200vm0baa,
> > }, {
>
>
>
>
> Best regards,
>
> Lukasz Majewski
>
> --
>
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
pgp9vrZP6K2O3.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 05/24] drm/sun4i: Add TCON TOP driver
Dne četrtek, 28. junij 2018 ob 03:47:20 CEST je Chen-Yu Tsai napisal(a):
> Hi,
>
> So I'm late to the party, but...
>
> On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec
wrote:
> > As already described in DT binding, TCON TOP is responsible for
> > configuring display pipeline. In this initial driver focus is on HDMI
> > pipeline, so TVE and LCD configuration is not implemented.
> >
> > Implemented features:
> > - HDMI source selection
> > - clock driver (TCON and DSI gating)
> > - connecting mixers and TCONS
> >
> > Something similar also existed in previous SoCs, except that it was part
> > of first TCON.
> >
> > Signed-off-by: Jernej Skrabec
> > ---
> >
> > drivers/gpu/drm/sun4i/Makefile | 3 +-
> > drivers/gpu/drm/sun4i/sun8i_tcon_top.c | 300 +
> > drivers/gpu/drm/sun4i/sun8i_tcon_top.h | 40
> > 3 files changed, 342 insertions(+), 1 deletion(-)
> > create mode 100644 drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > create mode 100644 drivers/gpu/drm/sun4i/sun8i_tcon_top.h
> >
> > diff --git a/drivers/gpu/drm/sun4i/Makefile
> > b/drivers/gpu/drm/sun4i/Makefile index 2589f4acd5ae..09fbfd6304ba 100644
> > --- a/drivers/gpu/drm/sun4i/Makefile
> > +++ b/drivers/gpu/drm/sun4i/Makefile
> > @@ -16,7 +16,8 @@ sun8i-drm-hdmi-y += sun8i_hdmi_phy_clk.o
> >
> > sun8i-mixer-y += sun8i_mixer.o sun8i_ui_layer.o \
> >
> >sun8i_vi_layer.o sun8i_ui_scaler.o \
> >
> > - sun8i_vi_scaler.o sun8i_csc.o
> > + sun8i_vi_scaler.o sun8i_csc.o \
> > + sun8i_tcon_top.o
> >
> > sun4i-tcon-y += sun4i_crtc.o
> > sun4i-tcon-y += sun4i_dotclock.o
> >
> > diff --git a/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c new file mode 100644
> > index ..8da0460e0028
> > --- /dev/null
> > +++ b/drivers/gpu/drm/sun4i/sun8i_tcon_top.c
> > @@ -0,0 +1,300 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/* Copyright (c) 2018 Jernej Skrabec */
> > +
> > +#include
> > +
> > +#include
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include "sun8i_tcon_top.h"
> > +
> > +static int sun8i_tcon_top_get_connected_ep_id(struct device_node *node,
> > + int port_id)
> > +{
> > + struct device_node *ep, *remote, *port;
> > + struct of_endpoint endpoint;
> > +
> > + port = of_graph_get_port_by_id(node, port_id);
> > + if (!port)
> > + return -ENOENT;
> > +
> > + for_each_available_child_of_node(port, ep) {
> > + remote = of_graph_get_remote_port_parent(ep);
> > + if (!remote)
> > + continue;
> > +
> > + if (of_device_is_available(remote)) {
> > + of_graph_parse_endpoint(ep, &endpoint);
> > +
> > + of_node_put(remote);
> > +
> > + return endpoint.id;
> > + }
> > +
> > + of_node_put(remote);
> > + }
> > +
> > + return -ENOENT;
> > +}
> > +
> > +static struct clk_hw *sun8i_tcon_top_register_gate(struct device *dev,
> > + struct clk *parent,
> > + void __iomem *regs,
> > + spinlock_t *lock,
> > + u8 bit, int name_index)
> > +{
> > + const char *clk_name, *parent_name;
> > + int ret;
> > +
> > + parent_name = __clk_get_name(parent);
>
> You can simply pass in the binding clock name, and have
>
> index = of_property_match_string(np, "clock-names", name);
> parent_name = of_clk_get_parent_name(dev->of_node, index);
That is elegant solution. Should I include that in follow up series?
Best regards,
Jernej
>
> > + ret = of_property_read_string_index(dev->of_node,
> > + "clock-output-names",
> > name_index, + &clk_name);
> > + if (ret)
> > + return ERR_PTR(ret);
> > +
> > + return clk_hw_register_gate(dev, clk_name, parent_name,
> > + CLK_SET_RATE_PARENT,
> > + regs + TCON_TOP_GATE_SRC_REG,
> > + bit, 0, lock);
> > +};
> > +
> > +static int sun8i_tcon_top_bind(struct device *dev, struct device *master,
> > + void *data)
> > +{
> > + struct platform_device *pdev = to_platform_device(dev);
> > + struct clk *dsi, *tcon_tv0, *tcon_tv1, *tve0, *tve1;
> > + struct clk_hw_onecell_data *clk_data;
> > + struct sun8i_tcon_top *tcon_top;
> > + bool mixer0_unused = false;
>
Re: [linux-sunxi] Re: [PATCH v3 15/24] dt-bindings: display: sun4i-drm: Add description of A64 HDMI PHY
Dne četrtek, 28. junij 2018 ob 09:00:32 CEST je Chen-Yu Tsai napisal(a): > On Thu, Jun 28, 2018 at 12:51 PM, Jernej Škrabec > > wrote: > > Dne četrtek, 28. junij 2018 ob 04:19:55 CEST je Chen-Yu Tsai napisal(a): > >> On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec > > > > wrote: > >> > A64 HDMI PHY is similar to H3 HDMI PHY except it has two possible PLL > >> > clock parents. It is compatible to other HDMI PHYs, like that found in > >> > R40. > >> > > >> > Acked-by: Rob Herring > >> > Signed-off-by: Jernej Skrabec > >> > --- > >> > > >> > Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 4 +++- > >> > 1 file changed, 3 insertions(+), 1 deletion(-) > >> > > >> > diff --git > >> > a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > >> > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index > >> > 84fe38dbb900..dc83f21ef188 100644 > >> > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > >> > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > >> > @@ -101,6 +101,7 @@ DWC HDMI PHY > >> > > >> > Required properties: > >> >- compatible: value must be one of: > >> > +* allwinner,sun50i-a64-hdmi-phy > >> > > >> > * allwinner,sun8i-a83t-hdmi-phy > >> > * allwinner,sun8i-h3-hdmi-phy > >> > >> Nit: the list is sorted by family first, then SoC name, so it should > >> be the last on the list. > > > > I went alphabetically, since "5" is before "8"... > > I see. I think version sort applies here, given that sun50i is newer > than sun8i. Should I make a patch for that? Best regards, Jernej > > ChenYu > > > Best regards, > > Jernej > > > >> Otherwise, > >> > >> Reviewed-by: Chen-Yu Tsai > >> > >> >- reg: base address and size of memory-mapped region > >> > > >> > @@ -111,8 +112,9 @@ Required properties: > >> >- resets: phandle to the reset controller driving the PHY > >> >- reset-names: must be "phy" > >> > > >> > -H3 HDMI PHY requires additional clock: > >> > > >> > +H3 and A64 HDMI PHY require additional clocks: > >> >- pll-0: parent of phy clock > >> > > >> > + - pll-1: second possible phy clock parent (A64 only) > >> > > >> > TV Encoder > >> > -- > >> > > >> > -- > >> > 2.18.0 > > > > -- > > You received this message because you are subscribed to the Google Groups > > "linux-sunxi" group. To unsubscribe from this group and stop receiving > > emails from it, send an email to > > linux-sunxi+unsubscr...@googlegroups.com. For more options, visit > > https://groups.google.com/d/optout. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbcon: introduce for_each_registered_fb() helper
On Fri, 2018-06-29 at 00:20 +0800, Yisheng Xie wrote:
> Following pattern is often used:
>
> for (i = 0; i < FB_MAX; i++) {
> if (registered_fb[i]) {
> ...
> }
> }
>
> Therefore, as Andy's suggestion, for_each_registered_fb() helper can
Suggested-by then ?
> be introduced to make the code easier to read and write by reducing
> indentation level. It also saves few lines of code in each occurrence.
>
> This patch convert all part here at the same time.
LGTM except macro implementation. That's why I have mentioned
for_each_pci_bridge() to look at.
> +#define for_each_registered_fb(i)\
> + for (i = 0; i < FB_MAX; i++)\
> + if (registered_fb[i])
> +
This needs to be protected against nested conditionals.
Otherwise compiler issues a warning and even may generate wrong code.
--
Andy Shevchenko
Intel Finland Oy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 fbdev-for-next 1/2] fbcon: introduce for_each_registered_fb() helper
Hi,
On 30-06-18 09:29, Yisheng Xie wrote:
Following pattern is often used:
for (i = 0; i < FB_MAX; i++) {
if (registered_fb[i]) {
...
}
}
Therefore, as Andy's suggestion, for_each_registered_fb() helper can
be introduced to make the code easier to read and write by reducing
indentation level. It also saves few lines of code in each occurrence.
This patch convert all part here at the same time.
Suggested-by: Andy Shevchenko
Signed-off-by: Yisheng Xie
Both patches look good to me, and both are:
Acked-by: Hans de Goede
Regards,
Hans
---
v2:
- rebase it to fbdev-for-next branch and add one more loop to replace - per
Hans
- Macro should be protected against nested conditionals. - per Andy
drivers/video/fbdev/core/fbcon.c | 31 +++
drivers/video/fbdev/core/fbmem.c | 4 +---
include/linux/fb.h | 4
3 files changed, 16 insertions(+), 23 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 5fb156b..e30d3a1 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -2234,8 +2234,8 @@ static int fbcon_switch(struct vc_data *vc)
*
* info->currcon = vc->vc_num;
*/
- for (i = 0; i < FB_MAX; i++) {
- if (registered_fb[i] != NULL && registered_fb[i]->fbcon_par) {
+ for_each_registered_fb(i) {
+ if (registered_fb[i]->fbcon_par) {
struct fbcon_ops *o = registered_fb[i]->fbcon_par;
o->currcon = vc->vc_num;
@@ -3124,11 +3124,9 @@ static int fbcon_fb_unregistered(struct fb_info *info)
if (idx == info_idx) {
info_idx = -1;
- for (i = 0; i < FB_MAX; i++) {
- if (registered_fb[i] != NULL) {
- info_idx = i;
- break;
- }
+ for_each_registered_fb(i) {
+ info_idx = i;
+ break;
}
}
@@ -3609,10 +3607,8 @@ static int fbcon_output_notifier(struct notifier_block *nb,
deferred_takeover = false;
logo_shown = FBCON_LOGO_DONTSHOW;
- for (i = 0; i < FB_MAX; i++) {
- if (registered_fb[i])
- fbcon_fb_registered(registered_fb[i]);
- }
+ for_each_registered_fb(i)
+ fbcon_fb_registered(registered_fb[i]);
return NOTIFY_OK;
}
@@ -3638,11 +3634,9 @@ static void fbcon_start(void)
console_lock();
- for (i = 0; i < FB_MAX; i++) {
- if (registered_fb[i] != NULL) {
- info_idx = i;
- break;
- }
+ for_each_registered_fb(i) {
+ info_idx = i;
+ break;
}
do_fbcon_takeover(0);
@@ -3669,15 +3663,12 @@ static void fbcon_exit(void)
kfree((void *)softback_buf);
softback_buf = 0UL;
- for (i = 0; i < FB_MAX; i++) {
+ for_each_registered_fb(i) {
int pending = 0;
mapped = 0;
info = registered_fb[i];
- if (info == NULL)
- continue;
-
if (info->queue.func)
pending = cancel_work_sync(&info->queue);
DPRINTK("fbcon: %s pending work\n", (pending ? "canceled" :
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 609438d..645c6ac 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1593,10 +1593,8 @@ static int do_remove_conflicting_framebuffers(struct
apertures_struct *a,
int i, ret;
/* check all firmware fbs and kick off if the base addr overlaps */
- for (i = 0 ; i < FB_MAX; i++) {
+ for_each_registered_fb(i) {
struct apertures_struct *gen_aper;
- if (!registered_fb[i])
- continue;
if (!(registered_fb[i]->flags & FBINFO_MISC_FIRMWARE))
continue;
diff --git a/include/linux/fb.h b/include/linux/fb.h
index aa74a22..fd31e6f 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -650,6 +650,10 @@ extern int fb_get_color_depth(struct fb_var_screeninfo
*var,
extern int num_registered_fb;
extern struct class *fb_class;
+#define for_each_registered_fb(i) \
+ for (i = 0; i < FB_MAX; i++) \
+ if (!registered_fb[i]) {} else
+
extern int lock_fb_info(struct fb_info *info);
static inline void unlock_fb_info(struct fb_info *info)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] video: fbdev: fsl-diu-fb: Remove VLA usage
In the quest to remove all stack VLA usage from the kernel[1], this moves
the buffer off the stack (since it could be as much as 1024 bytes), and
uses a new area in the cursor data structure. Additionally adds missed
documentation and removes redundant assignments.
[1]
https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com
Signed-off-by: Kees Cook
---
drivers/video/fbdev/fsl-diu-fb.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/video/fbdev/fsl-diu-fb.c b/drivers/video/fbdev/fsl-diu-fb.c
index 1bfd13cbd4e3..bc9eb8afc313 100644
--- a/drivers/video/fbdev/fsl-diu-fb.c
+++ b/drivers/video/fbdev/fsl-diu-fb.c
@@ -360,6 +360,10 @@ struct mfb_info {
* @ad[]: Area Descriptors for each real AOI
* @gamma: gamma color table
* @cursor: hardware cursor data
+ * @blank_cursor: blank cursor for hiding cursor
+ * @next_cursor: scratch space to build load cursor
+ * @edid_data: EDID information buffer
+ * @has_edid: whether or not the EDID buffer is valid
*
* This data structure must be allocated with 32-byte alignment, so that the
* internal fields can be aligned properly.
@@ -381,6 +385,8 @@ struct fsl_diu_data {
__le16 cursor[MAX_CURS * MAX_CURS] __aligned(32);
/* Blank cursor data -- used to hide the cursor */
__le16 blank_cursor[MAX_CURS * MAX_CURS] __aligned(32);
+ /* Scratch cursor data -- used to build new cursor */
+ __le16 next_cursor[MAX_CURS * MAX_CURS] __aligned(32);
uint8_t edid_data[EDID_LENGTH];
bool has_edid;
} __aligned(32);
@@ -1056,13 +1062,17 @@ static int fsl_diu_cursor(struct fb_info *info, struct
fb_cursor *cursor)
* FB_CUR_SETSHAPE - the cursor bitmask has changed
*/
if (cursor->set & (FB_CUR_SETSHAPE | FB_CUR_SETCMAP | FB_CUR_SETIMAGE))
{
+ /*
+* Determine the size of the cursor image data. Normally,
+* it's 8x16.
+*/
unsigned int image_size =
- DIV_ROUND_UP(cursor->image.width, 8) *
cursor->image.height;
+ DIV_ROUND_UP(cursor->image.width, 8) *
+ cursor->image.height;
unsigned int image_words =
DIV_ROUND_UP(image_size, sizeof(uint32_t));
unsigned int bg_idx = cursor->image.bg_color;
unsigned int fg_idx = cursor->image.fg_color;
- uint8_t buffer[image_size];
uint32_t *image, *source, *mask;
uint16_t fg, bg;
unsigned int i;
@@ -1070,13 +1080,6 @@ static int fsl_diu_cursor(struct fb_info *info, struct
fb_cursor *cursor)
if (info->state != FBINFO_STATE_RUNNING)
return 0;
- /*
-* Determine the size of the cursor image data. Normally,
-* it's 8x16.
-*/
- image_size = DIV_ROUND_UP(cursor->image.width, 8) *
- cursor->image.height;
-
bg = ((info->cmap.red[bg_idx] & 0xf8) << 7) |
((info->cmap.green[bg_idx] & 0xf8) << 2) |
((info->cmap.blue[bg_idx] & 0xf8) >> 3) |
@@ -1088,7 +1091,7 @@ static int fsl_diu_cursor(struct fb_info *info, struct
fb_cursor *cursor)
1 << 15;
/* Use 32-bit operations on the data to improve performance */
- image = (uint32_t *)buffer;
+ image = (uint32_t *)data->next_cursor;
source = (uint32_t *)cursor->image.data;
mask = (uint32_t *)cursor->mask;
--
2.17.1
--
Kees Cook
Pixel Security
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] [PATCH v3 06/24] drm/sun4i: Fix releasing node when enumerating enpoints
Dne četrtek, 28. junij 2018 ob 03:53:36 CEST je Chen-Yu Tsai napisal(a): > On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec wrote: > > sun4i_drv_add_endpoints() has a memory leak since it uses of_node_put() > > when remote is equal to NULL and does nothing when remote has a valid > > pointer. > > > > Invert the logic to fix memory leak. > > > > Signed-off-by: Jernej Skrabec > > Given this is a fix, it should have Fixes and stable tags. How should be this handled given that the patch is already merged and cannot be dropped? Best regards, Jernej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] Re: [PATCH v3 23/24] ARM: dts: sun8i: r40: Add HDMI pipeline
Dne četrtek, 28. junij 2018 ob 08:51:07 CEST je Chen-Yu Tsai napisal(a):
> On Thu, Jun 28, 2018 at 1:15 PM, Jernej Škrabec
wrote:
> > Dne četrtek, 28. junij 2018 ob 04:50:09 CEST je Chen-Yu Tsai napisal(a):
> >> On Mon, Jun 25, 2018 at 8:03 PM, Jernej Skrabec
> >
> > wrote:
> >> > Add all entries needed for HDMI to function properly.
> >> >
> >> > Since R40 has highly configurable pipeline, both mixers and both TCON
> >> > TVs are added. Board specific DT should then connect them together
> >> > trough TCON TOP muxers to best fit the purpose of the board.
> >> >
> >> > Signed-off-by: Jernej Skrabec
> >> > ---
> >> >
> >> > arch/arm/boot/dts/sun8i-r40.dtsi | 269 +++
> >> > 1 file changed, 269 insertions(+)
> >> >
> >> > diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi
> >> > b/arch/arm/boot/dts/sun8i-r40.dtsi index 173dcc1652d2..a2a75fb04caf
> >> > 100644
> >> > --- a/arch/arm/boot/dts/sun8i-r40.dtsi
> >> > +++ b/arch/arm/boot/dts/sun8i-r40.dtsi
> >> > @@ -42,8 +42,11 @@
> >> >
> >> > */
> >> >
> >> > #include
> >> >
> >> > +#include
> >> >
> >> > #include
> >> >
> >> > +#include
> >
> > Maxime, above line breaks compilation for build robot, sorry.
> >
> >> > #include
> >> >
> >> > +#include
> >> >
> >> > / {
> >> >
> >> > #address-cells = <1>;
> >> >
> >> > @@ -99,12 +102,76 @@
> >> >
> >> > };
> >> >
> >> > };
> >> >
> >> > + de: display-engine {
> >> > + compatible = "allwinner,sun8i-r40-display-engine",
> >> > +"allwinner,sun8i-h3-display-engine";
> >>
> >> Given that the display pipeline looks different, they should not be
> >> compatible.
> >
> > Ok.
> >
> >> > + allwinner,pipelines = <&mixer0>, <&mixer1>;
> >> > + status = "disabled";
> >> > + };
> >> > +
> >> >
> >> > soc {
> >> >
> >> > compatible = "simple-bus";
> >> > #address-cells = <1>;
> >> > #size-cells = <1>;
> >> > ranges;
> >> >
> >> > + display_clocks: clock@100 {
> >> > + compatible = "allwinner,sun8i-r40-de2-clk",
> >> > +"allwinner,sun8i-h3-de2-clk";
> >> > + reg = <0x0100 0x10>;
> >> > + clocks = <&ccu CLK_DE>,
> >> > +<&ccu CLK_BUS_DE>;
> >> > + clock-names = "mod",
> >> > + "bus";
> >> > + resets = <&ccu RST_BUS_DE>;
> >> > + #clock-cells = <1>;
> >> > + #reset-cells = <1>;
> >> > + };
> >> > +
> >> > + mixer0: mixer@110 {
> >> > + compatible = "allwinner,sun8i-r40-de2-mixer-0";
> >> > + reg = <0x0110 0x10>;
> >> > + clocks = <&display_clocks CLK_BUS_MIXER0>,
> >> > +<&display_clocks CLK_MIXER0>;
> >> > + clock-names = "bus",
> >> > + "mod";
> >> > + resets = <&display_clocks RST_MIXER0>;
> >> > +
> >> > + ports {
> >> > + #address-cells = <1>;
> >> > + #size-cells = <0>;
> >> > +
> >> > + mixer0_out: port@1 {
> >> > + reg = <1>;
> >> > + mixer0_out_tcon_top: endpoint {
> >> > + remote-endpoint =
> >> > <&tcon_top_mixer0_in_mixer0>; +
> >> > };
> >> > + };
> >> > + };
> >> > + };
> >> > +
> >> > + mixer1: mixer@120 {
> >> > + compatible = "allwinner,sun8i-r40-de2-mixer-1";
> >> > + reg = <0x0120 0x10>;
> >> > + clocks = <&display_clocks CLK_BUS_MIXER1>,
> >> > +<&display_clocks CLK_MIXER1>;
> >> > + clock-names = "bus",
> >> > + "mod";
> >> > + resets = <&display_clocks RST_WB>;
> >> > +
> >> > + ports {
> >> > + #address-cells = <1>;
> >> > + #size-cells = <0>;
> >> > +
> >> > + mixer1_out: port@1 {
> >> > + reg = <1>;
> >> > + mixer1_out_tcon_top: endpoint {
> >> > + remote-endpoint =
> >> > <&tcon_top_mixer1_in_mixer1>; +
> >> > };
> >> > + }
Re: [linux-sunxi] Re: [PATCH v3 09/24] drm/sun4i: Don't skip TCONs if they don't have channel 0
On Sun, Jul 1, 2018 at 4:27 PM, Jernej Škrabec wrote: > Dne četrtek, 28. junij 2018 ob 08:24:34 CEST je Chen-Yu Tsai napisal(a): >> On Thu, Jun 28, 2018 at 12:45 PM, Jernej Škrabec >> >> wrote: >> > Dne četrtek, 28. junij 2018 ob 03:51:31 CEST je Chen-Yu Tsai napisal(a): >> >> On Mon, Jun 25, 2018 at 8:02 PM, Jernej Skrabec >> > >> > wrote: >> >> > TV TCONs (channel 1 only) are always connected to TV or HDMI encoder. >> >> > Because of that, all output endpoints on such TCON node will point to a >> >> > encoder which is part of component framework. >> >> > >> >> > Correct current graph traversing algorithm in such way that it doesn't >> >> > skip output enpoints with id 0 on TV TCONs. >> >> >> >> No. Our bindings say that endpoint 0 _is_ channel 0. For TCONs that don't >> >> have channel 0, it must be skipped. >> > >> > I'm not sure where this is stated. I read TCON binding again. Can you >> > please point me to it? >> >> https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bind >> ings/display/sunxi/sun4i-drm.txt#L169 >> >> Our TCON driver still expects RGB or LVDS panel / bridges on endpoint 0. > > Yes, but that can only happen on TCON which has channel 0. TV TCONs (those > with channel 1 only) can't have panels or bridges connected to them, because > they are internally always connected to either HDMI or TV encoder or both. > Actually, R40 is the only SoC, where same TV TCON can be connected to TV > encoder or HDMI. Others have specialized TV TCONs, which are connect to only > one encoder. > > IMO TV TCONs are really just stripped down LCD TCONs to support one (or max > two) specific encoder. I agree. We've seen these first in the H3, and the reverse, TCONs only with LCD, on the A23/A33. >> So I guess this was sort of implied historically. It's no longer true. >> This is something we should probably fix. > > Fixed in what way? You mean update bindings to mention that TCON output > endpoint 0 is reserved for panels or bridges? Either that, or have the drm driver look at other endpoints. I guess we should ask Maxime if this is already done or not, since the DSI driver isn't endpoint 0 in the A33 dtsi. >> >> In practice our drivers don't look at it (yet), but rely on the downstream >> encoder type to determine which channel to use. >> >> But please add the "allwinner,tcon-channel" property as specified in >> the binding. > > It's my understanding of TCON binding documentation that property > "allwinner,tcon-channel" is needed only if TCON supports both channels. TV > TCON clearly supports only channel 1. In that case, there is no doubt to which > channel output endpoint belongs. > > If that's not true, dt bindings documentation should be reworded to contain > word "needed" or something similar. Currently, no DT for newer SoC contains > that property (for example, A83T, H3, H5 or even A33). On A33 this is even > more interesting, since tcon0 has only channel 0 and has DSI output endpoint > with number 1. According to TCON binding docs, if "allwinner,tcon-channel" is > not preset, endpoint number represent channel. So, that would mean DSI needs > channel 1 on tcon which supports clearly only channel 0. So either there TCON > bindings documentation needs updates or DT for A33 has to be updated. Maxime? You did the A33 DSI stuff. > BTW, "allwinner,tcon-channel" property is not used at all in the code. Yes I'm aware. We just base the channel selection on the encoder type instead. TV-like ones use channel 1, LCD ones use channel 0. >> >> > So on TV TCONs on R40 (without channel 0) TVE would be endpoint 1 and HDMI >> > endpoint 2 (or the other way around)? >> >> Which one goes first doesn't quite matter. IIRC there's also a mux for TVE? > > AFAIK, TV TCON is by default connected to TV encoder unless HDMI mux in TCON > TOP points to it. I think it's best put TVE with lower number since it's > default and HDMI with higher number. Ok. As long as its specified in the binding, as a contract between the dts and the graph parsing code. Regards ChenYu ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [linux-sunxi] Re: [PATCH v3 23/24] ARM: dts: sun8i: r40: Add HDMI pipeline
On Sun, Jul 1, 2018 at 11:13 PM, Jernej Škrabec wrote:
> Dne nedelja, 01. julij 2018 ob 15:52:55 CEST je Chen-Yu Tsai napisal(a):
>> On Sun, Jul 1, 2018 at 6:41 PM, Jernej Škrabec
> wrote:
>> > Dne četrtek, 28. junij 2018 ob 08:51:07 CEST je Chen-Yu Tsai napisal(a):
>> >> On Thu, Jun 28, 2018 at 1:15 PM, Jernej Škrabec
>> >
>> > wrote:
>> >> > Dne četrtek, 28. junij 2018 ob 04:50:09 CEST je Chen-Yu Tsai
> napisal(a):
>> >> >> On Mon, Jun 25, 2018 at 8:03 PM, Jernej Skrabec
>> >> >>
>> >> >
>> >> > wrote:
>> >> >> > Add all entries needed for HDMI to function properly.
>> >> >> >
>> >> >> > Since R40 has highly configurable pipeline, both mixers and both
>> >> >> > TCON
>> >> >> > TVs are added. Board specific DT should then connect them together
>> >> >> > trough TCON TOP muxers to best fit the purpose of the board.
>> >> >> >
>> >> >> > Signed-off-by: Jernej Skrabec
>> >> >> > ---
>> >> >> >
>> >> >> > arch/arm/boot/dts/sun8i-r40.dtsi | 269
>> >> >> > +++
>> >> >> > 1 file changed, 269 insertions(+)
>> >> >> >
>> >> >> > diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi
>> >> >> > b/arch/arm/boot/dts/sun8i-r40.dtsi index 173dcc1652d2..a2a75fb04caf
>> >> >> > 100644
>> >> >> > --- a/arch/arm/boot/dts/sun8i-r40.dtsi
>> >> >> > +++ b/arch/arm/boot/dts/sun8i-r40.dtsi
>> >> >> > @@ -42,8 +42,11 @@
>> >> >> >
>> >> >> > */
>> >> >> >
>> >> >> > #include
>> >> >> >
>> >> >> > +#include
>> >> >> >
>> >> >> > #include
>> >> >> >
>> >> >> > +#include
>> >> >
>> >> > Maxime, above line breaks compilation for build robot, sorry.
>> >> >
>> >> >> > #include
>> >> >> >
>> >> >> > +#include
>> >> >> >
>> >> >> > / {
>> >> >> >
>> >> >> > #address-cells = <1>;
>> >> >> >
>> >> >> > @@ -99,12 +102,76 @@
>> >> >> >
>> >> >> > };
>> >> >> >
>> >> >> > };
>> >> >> >
>> >> >> > + de: display-engine {
>> >> >> > + compatible = "allwinner,sun8i-r40-display-engine",
>> >> >> > +"allwinner,sun8i-h3-display-engine";
>> >> >>
>> >> >> Given that the display pipeline looks different, they should not be
>> >> >> compatible.
>> >> >
>> >> > Ok.
>> >> >
>> >> >> > + allwinner,pipelines = <&mixer0>, <&mixer1>;
>> >> >> > + status = "disabled";
>> >> >> > + };
>> >> >> > +
>> >> >> >
>> >> >> > soc {
>> >> >> >
>> >> >> > compatible = "simple-bus";
>> >> >> > #address-cells = <1>;
>> >> >> > #size-cells = <1>;
>> >> >> > ranges;
>> >> >> >
>> >> >> > + display_clocks: clock@100 {
>> >> >> > + compatible = "allwinner,sun8i-r40-de2-clk",
>> >> >> > +"allwinner,sun8i-h3-de2-clk";
>> >> >> > + reg = <0x0100 0x10>;
>> >> >> > + clocks = <&ccu CLK_DE>,
>> >> >> > +<&ccu CLK_BUS_DE>;
>> >> >> > + clock-names = "mod",
>> >> >> > + "bus";
>> >> >> > + resets = <&ccu RST_BUS_DE>;
>> >> >> > + #clock-cells = <1>;
>> >> >> > + #reset-cells = <1>;
>> >> >> > + };
>> >> >> > +
>> >> >> > + mixer0: mixer@110 {
>> >> >> > + compatible =
>> >> >> > "allwinner,sun8i-r40-de2-mixer-0";
>> >> >> > + reg = <0x0110 0x10>;
>> >> >> > + clocks = <&display_clocks CLK_BUS_MIXER0>,
>> >> >> > +<&display_clocks CLK_MIXER0>;
>> >> >> > + clock-names = "bus",
>> >> >> > + "mod";
>> >> >> > + resets = <&display_clocks RST_MIXER0>;
>> >> >> > +
>> >> >> > + ports {
>> >> >> > + #address-cells = <1>;
>> >> >> > + #size-cells = <0>;
>> >> >> > +
>> >> >> > + mixer0_out: port@1 {
>> >> >> > + reg = <1>;
>> >> >> > + mixer0_out_tcon_top:
>> >> >> > endpoint {
>> >> >> > + remote-endpoint =
>> >> >> > <&tcon_top_mixer0_in_mixer0>; +
>> >> >> > };
>> >> >> > + };
>> >> >> > + };
>> >> >> > + };
>> >> >> > +
>> >> >> > + mixer1: mixer@120 {
>> >> >> > + compatible =
>> >> >> > "allwinner,sun8i-r40-de2-mixer-1";
>> >> >> > + reg = <0x0120 0x10>;
>> >> >> > + clocks = <&display_clocks CLK_BUS_MIXER1>,
>> >> >> > +<&display_clocks CLK_MIXER1>;
>> >> >> > + clock-names = "bus",
>> >> >> > +
[Bug 200387] New: amdgpu uses unusually high memory
https://bugzilla.kernel.org/show_bug.cgi?id=200387 Bug ID: 200387 Summary: amdgpu uses unusually high memory Product: Drivers Version: 2.5 Kernel Version: 4.16.18, 4.17.3, 4.18.0-rc2 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: fe...@feldspaten.org Regression: No Created attachment 277107 --> https://bugzilla.kernel.org/attachment.cgi?id=277107&action=edit Config file for 4.17.3. Hi there, I'm experiencing some out-of-memory issues while running Cities:Skylines using the amdgpu driver. Trying to run a new game cases a complete system-freeze running any Kernel that runs the amdgpu driver instead of a rather old Kernel using the amdgpu-pro driver. The memory is the system related main memory, not the GPU memory. System details: I'm running Ubuntu Mate 16.04 with a custom build 4.17.3 Kernel (Find config attached) AMD FX-8350 32 GB RAM Radeon RX470 Sample Main Memory usage. Kernel 4.4 with amdgpu-pro driver- RAM Usage after 1 Minute: 2.4 GB Kernel 4.17.3 with amdgpu driver - RAM Usage after 1 Minute: 13 GB Kernel 4.16.18 with amdgpu driver- RAM Usage after 1 Minute: 13 GB Kernel 4.18.0-rc2 with amdgpu driver - RAM Usage after 1 Minute: 13 GB I get similar results with running Stardew Valley (Factor two difference, clearly measurable) Find attached the config file for the 4.17.3 Kernel. Other kernels have been build using this config file and the default suggestions for any unconfigured parameter. Greetings, Felix -- 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 105819] Window system hang due to GPU Fault
https://bugs.freedesktop.org/show_bug.cgi?id=105819 --- Comment #6 from Kertesz Laszlo --- My hardware is: Gigabyte GA-AB350M-HD3 mobo, 2200G CPU. -- 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 106940] Black screen on KMS with 4.18.0-rc1 with Kaveri+Topaz, amdgpu, dc=1
https://bugs.freedesktop.org/show_bug.cgi?id=106940 --- Comment #25 from Server Angels --- FYI this bug is still present in rc2. -- 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 1/2] drm/panel: Augment the TPO TPG110 bindings
On Wed, Jun 27, 2018 at 7:21 PM Rob Herring wrote: > On Thu, Jun 21, 2018 at 08:49:41PM +0200, Linus Walleij wrote: > > +This panel driver can driver a variety of panels. It requires > > s/can driver/can drive/ > > Though what a driver supports is irrelevant to the binding... It it not a software driver the text is referring to. It is a electrical interface to a panel. Like how a TTL circuit connected to a LED is referred to as a "LED driver", it's simply what the industry calls these things. So there are two things: the panel driver and the panel, the same panel driver is used with several panels. What the electronics engineer will do is put a panel driver like this into his design and then connect some panel s/he finds in the right quantity in the streets of Shenzhen. > If you remove timings, how does it drive a variety of panels? Just by > compatible? Yes. Like we did for Documentation/devicetree/bindings/display/panel/ilitek,ili9322.txt which is similar to this. In fact I think many panel drivers are just sloppily slipping in under the radar as "panels" in our bindings. >That would mean "tpo,tpg110" alone is not valid nor useful > as a fallback. Actually it is. The hardware is wired up to the desired resolution with hardware straps, which appear in the registers the (software) driver can read out so this is ideally self-describing hardware. But for the event that something needs tweaking in the future, like we overspecify say SoCs, I include the exact system on which it is deployd as a separate compatible string. > > +a few GPIO lines for control of its reset line and custom serial > > +protocol. > > > > Required properties: > > -- compatible : "tpo,tpg110" > > +- compatible : one of: > > + "ste,nomadik-nhk15-display", "tpo,tpg110" > > + "tpo,tpg110" > > - grestb-gpios : panel reset GPIO > > - scen-gpios : serial control enable GPIO > > - scl-gpios : serial control clock line GPIO > > - sda-gpios : serial control data line GPIO > > I2C? That should be done differently... It is not I2C, the lines are just named confusingly similar. None of the I2C (-like) protocols apply. I was similarly confused when I first implemented it. (Maybe I should add a comment to explain this.) Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 00/29] Add support for mediatek SOC MT2712
Hi, Stu: On Wed, 2018-06-20 at 16:19 +0800, Stu Hsieh wrote: > This patch add support for the Mediatek MT2712 DISP subsystem. > MT2712 is base on MT8173, there are some difference as following: > MT2712 support three disp output(two ovl and one rdma) > For the series, applied to mediatek-drm-next-4.19 [1], the patch 'drm/mediatek: Add support for mediatek SOC MT2712' has line over 80 character, so I've modified it. [1] https://github.com/ckhu-mediatek/linux.git-tags/commits/mediatek-drm-next-4.19 Regards, CK > Change in v6: > - Update commit message for the patch > "drm/mediatek: Update the definition of connection from RDMA1 to DPI0" > > Stu Hsieh (29): > drm/mediatek: update dt-bindings for mt2712 > drm/mediatek: support maximum 64 mutex mod > drm/mediatek: add ddp component AAL1 > drm/mediatek: add ddp component OD1 > drm/mediatek: add ddp component PWM1 > drm/mediatek: add ddp component PWM2 > drm/mediatek: add component DPI1 > drm/mediatek: add component DSI2 > drm/mediatek: add component DSI3 > drm/mediatek: add the DSI1 for component init condition > drm/mediatek: add connection from OD1 to RDMA1 > drm/mediatek: Update the definition of connection from RDMA1 to DPI0 > drm/mediatek: add connection from RDMA0 to DPI0 > drm/mediatek: add connection from RDMA0 to DSI2 > drm/mediatek: add connection from RDMA0 to DSI3 > drm/mediatek: add connection from RDMA1 to DPI1 > drm/mediatek: add connection from RDMA1 to DSI1 > drm/mediatek: add connection from RDMA1 to DSI2 > drm/mediatek: add connection from RDMA1 to DSI3 > drm/mediatek: add connection from RDMA2 to DPI0 > drm/mediatek: add connection from RDMA2 to DPI1 > drm/mediatek: add connection from RDMA2 to DSI1 > drm/mediatek: add connection from RDMA2 to DSI2 > drm/mediatek: add connection from RDMA2 to DSI3 > drm/mediatek: add DPI1 support for mutex > drm/mediatek: add DSI2 support for mutex > drm/mediatek: add DSI3 support for mutex > drm/mediatek: add third ddp path > drm/mediatek: Add support for mediatek SOC MT2712 > > .../bindings/display/mediatek/mediatek,disp.txt| 2 +- > drivers/gpu/drm/mediatek/mtk_drm_crtc.c| 3 + > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 235 > ++--- > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c| 15 +- > drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h| 10 +- > drivers/gpu/drm/mediatek/mtk_drm_drv.c | 47 - > drivers/gpu/drm/mediatek/mtk_drm_drv.h | 5 +- > 7 files changed, 274 insertions(+), 43 deletions(-) > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] drm/mtk: Remove impossible internal error
Hi, Daniel:
For the series, applied to mediatek-drm-next-4.19 [1].
[1]
https://github.com/ckhu-mediatek/linux.git-tags/commits/mediatek-drm-next-4.19
Regards,
CK
On Fri, 2018-05-18 at 14:47 +0100, Daniel Stone wrote:
> We cannot create a framebuffer with no objects, so there's no point
> testing for it.
>
> v2: Remove the error entirely. (Sean, CK, Thierry)
>
> Signed-off-by: Daniel Stone
> Cc: Sean Paul
> Cc: Thierry Reding
> Cc: CK Hu
> Cc: Philipp Zabel
> ---
> drivers/gpu/drm/mediatek/mtk_drm_plane.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> index 2f4b0ffee598..149fc4372917 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
> @@ -95,11 +95,6 @@ static int mtk_plane_atomic_check(struct drm_plane *plane,
> if (!fb)
> return 0;
>
> - if (!mtk_fb_get_gem_obj(fb)) {
> - DRM_DEBUG_KMS("buffer is null\n");
> - return -EFAULT;
> - }
> -
> if (!state->crtc)
> return 0;
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107065] "BUG: unable to handle kernel paging request at 0000000000002000" in amdgpu_vm_cpu_set_ptes at amdgpu_vm.c:921
https://bugs.freedesktop.org/show_bug.cgi?id=107065 --- Comment #10 from Andrey Grodzovsky --- Created attachment 140418 --> https://bugs.freedesktop.org/attachment.cgi?id=140418&action=edit drm/amdgpu: Verify root PD is mapped into kernel address space. dwagner, please try this patch. Fixes the issue for me and I observed no suspend/resume issues. Christian, please take a look at the patch, problem was that in amdgpu_vm_update_directories the parent BO didn't have a kernel mapping and so later inside amdgpu_vm_cpu_set_ptes pe += (unsigned long)amdgpu_bo_kptr(bo); would equal to 2000 since parent amdgpu_bo_kptr woudld return NULL. The parent was the root PD. This was still working in 67b8d5c Linus Torvalds 7 weeks agoLinux 4.17-rc5 (tag: v4.17-rc5) but I wasn't able to exactly pinpoint which change broke it. I am not sure my fix is the right one so please advise. -- 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 200387] amdgpu uses unusually high memory
https://bugzilla.kernel.org/show_bug.cgi?id=200387 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) --- Please attach your dmesg output and xorg log if using X. -- 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
[GIT PULL]: exynos-drm-fixes
Hi Dave,
Several fixups to Exynos DRM IPP v2 framework and relevant drivers
merged to mainline recently, and some clenaups.
Please kindely let me know if there is any problem.
Thanks,
Inki Dae
The following changes since commit 2d8aa4ef6aac566617052640e9bb07ecb9c45183:
Merge tag 'drm-misc-fixes-2018-06-28' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2018-06-29 06:25:08
+1000)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos
tags/exynos-drm-fixes-for-v4.18-rc4
for you to fetch changes up to aab109b340eaf3968337e1d19d71ff0551c57365:
drm/exynos: Replace drm_dev_unref with drm_dev_put (2018-07-02 11:40:49 +0900)
Fixups
- Fix several problems to IPPv2 merged to mainline recentely.
. An align problem of width size that IPP driver incorrectly
calculated the real buffer size.
. Horizontal and vertical flip problem.
. Per-plane global alpha for XRGB modes.
. Incorrect variant of the YUV modes.
- Fix plane overlapping problem.
. The stange order of overlapping planes on XRGB modes
by setting global alpha value to maximum value.
Cleanup
- Rename a enum type, drm_ipp_size_id, to one specific to Exynos,
drm_exynos_ipp_limit_type.
- Replace {un/reference} with {put,get} functions.
. it replaces several reference/unreference functions with Linux
kernel nameing standard.
Andrzej Pietrasiewicz (1):
drm/exynos: scaler: Reset hardware before starting the operation
Marek Szyprowski (10):
drm/exynos: ipp: Rework checking for the correct buffer formats
drm/exynos: rotator: Fix DRM_MODE_REFLECT_{X,Y} interpretation
drm/exynos: scaler: Fix support for YUV420, YUV422 and YUV444 modes
drm/exynos: gsc: Use real buffer width for configuring the hardware
drm/exynos: gsc: Increase Exynos5433 buffer width alignment to 16 pixels
drm/exynos: gsc: Fix DRM_MODE_REFLECT_{X,Y} interpretation
drm/exynos: gsc: Fix support for NV16/61, YUV420/YVU420 and YUV422 modes
drm/exynos: fimc: Use real buffer width for configuring the hardware
drm/exynos: decon5433: Fix per-plane global alpha for XRGB modes
drm/exynos: decon5433: Fix WINCONx reset value
Stefan Agner (1):
drm/exynos: ipp: use correct enum type
Thomas Zimmermann (3):
drm/exynos: Replace drm_framebuffer_{un/reference} with put,get functions
drm/exynos: Replace drm_gem_object_unreference_unlocked with put function
drm/exynos: Replace drm_dev_unref with drm_dev_put
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 6 +-
drivers/gpu/drm/exynos/exynos_drm_drv.c | 4 +-
drivers/gpu/drm/exynos/exynos_drm_fb.c| 2 +-
drivers/gpu/drm/exynos/exynos_drm_fimc.c | 17 ++--
drivers/gpu/drm/exynos/exynos_drm_gem.c | 10 +--
drivers/gpu/drm/exynos/exynos_drm_gsc.c | 51 +++-
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 110 ++
drivers/gpu/drm/exynos/exynos_drm_plane.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_rotator.c | 4 +-
drivers/gpu/drm/exynos/exynos_drm_scaler.c| 44 ---
drivers/gpu/drm/exynos/regs-gsc.h | 1 +
11 files changed, 149 insertions(+), 102 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
