This repository was archived by the owner on Oct 5, 2018. It is now read-only.
Working hdmi test updates v3 #101
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Member
docularxu
commented
Jul 23, 2015
docularxu
commented
- Integrate Andy's patchset: tag 'hikey-hdmi-test-2015-07-05-1'
- Check and set syspll by reading from registors
- Workaround to set medpll and ddrsrc to the same value as syspll. To make both ATF/UEFI and fastboot happy.
We only need to fill the logs with this if something is dying. Signed-off-by: Andy Green <[email protected]>
Otherwise we can't even make a 1080p framebuffer Signed-off-by: Andy Green <[email protected]>
Signed-off-by: Andy Green <[email protected]>
Signed-off-by: Andy Green <[email protected]>
Signed-off-by: Andy Green <[email protected]>
Signed-off-by: Andy Green <[email protected]>
The existing code seems to expect there is only one setting for the number of lanes in use. On a pluggable HDMI device, the number of lanes needed changes dynamically depending on the mode that is chosen. This patch makes the number of lanes optional in the dts, if left out then it's decided dynamically, on the heuristic that pixel clock > 80MHz == 4 lanes, otherwise 3 Signed-off-by: Andy Green <[email protected]>
This patch iteratively selects the ADE pixel clock, optionally in order to always choose the next highest clock, but always to avoid 72MHz base clock, which later selects 576MHz DSI clock which is unreliable, it only locks correctly about 50% of boots. Storing the actual chosen clock in adj_mode is used elsewhere to provide correct computations in later patches. Signed-off-by: Andy Green <[email protected]>
The helpers bloat the code and hide what's actually going in the registers. I'm a bit dubious about these bitfields always mapping correctly as well, also get rid of those (-94 LOC) Signed-off-by: Andy Green <[email protected]>
Framebuffer console no longer needs this to work, EDID fetch and 3-lane restriction automatically selects 720p or best mode available on monitor. Signed-off-by: Andy Green <[email protected]>
1) Enhance all the computations to use ps period resolution and kHz frequency resolution, improving accuracy.
2) Automatically use 4 lanes when clock rate > 80MHz, for compatibility with
1080p
3) I found enable and disable of the DSI LP mode when other transmissions can
occur was necessary to make each mode work. By trial and error I found what
is needed for each mode and implemented heuristics.
4) Some modes require one more byte lane clock compared to the calculated
amount, I added a heuristic to do it
With these changes 1080p50 and 60 modes work on all 3 of my monitors, and
720p60 can also work. 720p50 worked on one monitor but on another he was
flicking between showing it correctly and feeling the mode was invalid,
so I disabled it.
There is a colour swap problem on 1080p60 I noticed sometimes. On some
boots what should be R, G, B are misordered as B, R, G, I think it means we
slipped a colour byte
sent by DSI: RGBRGBRGBRGB
received by ADV7533: RGBRGBRGBRGB
This happens between DSI and ADV7533 because
- it's the first place the pixels are serialized
- swapping monitors after this happens it never changes afterwards (ie,
problem is not happening in the monitor receiver)
I only just noticed it so not sure what to do about it yet.
Signed-off-by: Andy Green <[email protected]>
This creates a canned DRM mode for 720p60, and in the event there is no usable mode left after DRM checks validity, the canned mode will be used. This is helpful in two cases 1) No EDID appeared, but the device supports the fallback mode 2) An EDID appeared, but it does not list any acceptable mode. However, the device does actually support the fallback mode. It's implemented by adding a new optional connector func callback which is called in the event we are left with no valid modes. Connectors may handle the "fallback_mode" callback and add a fallback mode to use rather than the DRM default of 1024 x 768. In the case no EDID came but you forced your mode with video= on the kernel commandline, normally DRM will attempt to synthesize appropriate mode timings. But these very seldom work with HDMI monitors. In the case a mode was forced that does not exist in the EDID already but a fallback mode exists, this patch makes it choose the fallback mode and ignore the mode forcing. You can test "no EDID" by shorting HDMI connector p16 (SDA) to p17 (0V) Signed-off-by: Andy Green <[email protected]>
Signed-off-by: Xinliang Liu <[email protected]>
When the pixel clock differs from the DSI byte lane clock, the timing for h blanking related items becomes fractional. So we can understand the relationship, log the affected timings to three decimal places. Signed-off-by: Andy Green <[email protected]>
The existing code here assumes that the framebuffer size is always the scanout size. There is no requirement that is true, and eg, if you start on a 1080p mode and change mode in the framebuffer console to 720p later, the framebuffer console remains at 1080p and the new mode is a subwindow on the 1080p sized original framebuffer console. This patch corrects the computations to use the right mix of information about the memory layout (framebuffer stride) and the current scanout (crtc active mode dimensions) so it works for all cases. Signed-off-by: Andy Green <[email protected]>
This patch let you force cycling between the remaining DRM modes from the kernel alone. It can only deal with one CRTC. It's useful if a working display is needed for using or setting up a device, but the HDMI compatibility is not 100%. At least the user can check every valid mode to see if it can work on his display. Force the mode change by typing Alt-Gr SysRq g that is - hold down the right-hand ALT key - hold down the SysRq key - tap g key - let go of everything Each time he will move to the "next" mode, when at the last mode he will go back to the first. Signed-off-by: Andy Green <[email protected]>
For now having the sysrq-g mode hack is useful with hikey Signed-off-by: Andy Green <[email protected]>
Signed-off-by: Andy Green <[email protected]>
If the HDMI connector is out during boot, this forces the HDMI up anyway and causes it to select the fallback (720p) mode since no EDID is coming. It means the HDMI is configured and working for 720p all the time. This provides a neat way to force the fallback 720p mode by unplugging until boot is complete, then plugging the monitor to find whatever booted (Xorg, framebuffer console) configured fully for the fallback mode. Signed-off-by: Andy Green <[email protected]>
Signed-off-by: Andy Green <[email protected]>
Bootloader should rewrite these to actual setting. When it does, remove this patch. Signed-off-by: Andy Green <[email protected]>
…t-0723 hikey-hdmi-test-2015-07-05-1 * tag 'hikey-hdmi-test-2015-07-05-1': (22 commits) clk hi6220 HACK force fixed clocks to 1.1904GHz in dtsi clk hi6220 allow dt to override fixed clk rates adv7511 force hpd and fallback mode if no hpd at boot drm hisi dsi move init after clock calc drm hisi use sysrq g modehack drm sysrq g mode hack drm hisi ade use correct stride to allow scanout and fb size to differ drm hisi ade avoid setting powered-down DPI drm hisi dsi compute and log true timings 720p dsi clock 640MHz V3 drm hisi provide canned 720p if no other mode drm hisi use kHz for clock computations drm hisi remove forced modes drm hikey ade remove unhelpful helpers drm hikey ade fixup real adjusted clock and disallow 72MHz drm adv7511 make num lanes decideable dynamically adv7511 hikey integrate align mainline basis adv7511 drm import v4.1 rc7 adv7511.c drm adv7533 remove driver from tree ...
This reverts commit 99ac3ef.
This reverts commit 0b3a0a3.
Signed-off-by: Andy Green <[email protected]> Signed-off-by: Guodong Xu <[email protected]>
Signed-off-by: Guodong Xu <[email protected]>
…driver init. SYSPLL is set by bootloader. Hikey has two different bootloader rate settings due to historical reasons. So, in order to compatible to both bootloader settings, in kernel space, when clk init, we read the actual setting from registers. Previously, this is assumed static and hardcoded in a static data structure. Signed-off-by: Guodong Xu <[email protected]>
According to Hi6220 SoC designer, when you change syspll to 1.19GHz, medpll and ddrsrc should remain as 1.2GHz. When I test with fastboot bootloader that doesn't make any problem. However, when test with ATF/UEFI, I found HDMI cannot work properly if I set syspll, medpll and ddrsrc to different values. This is a workaround patch which keeps all three clks at the same value, either 1.2GHz or 1.19GHz according to bootloader's setting. With this patch, no regression issues are found so far on both fastboot and ATF/UEFI. Signed-off-by: Guodong Xu <[email protected]>
docularxu
added a commit
that referenced
this pull request
Jul 23, 2015
Working hdmi test updates v3
idlethread
pushed a commit
that referenced
this pull request
May 19, 2016
In certain probe conditions the interrupt came right after registering the handler causing a NULL pointer exception because of uninitialized waitqueue: $ udevadm trigger i2c-gpio i2c-gpio-1: using pins 143 (SDA) and 144 (SCL) i2c-gpio i2c-gpio-3: using pins 53 (SDA) and 52 (SCL) Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = e8b3800 [00000000] *pgd=00000000 Internal error: Oops: 5 [#1] SMP ARM Modules linked in: snd_soc_i2s(+) i2c_gpio(+) snd_soc_idma snd_soc_s3c_dma snd_soc_core snd_pcm_dmaengine snd_pcm snd_timer snd soundcore ac97_bus spi_s3c64xx pwm_samsung dwc2 exynos_adc phy_exynos_usb2 exynosdrm exynos_rng rng_core rtc_s3c CPU: 0 PID: 717 Comm: data-provider-m Not tainted 4.6.0-rc1-next-20160401-00011-g1b8d87473b9e-dirty #101 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) (...) (__wake_up_common) from [<c0379624>] (__wake_up+0x38/0x4c) (__wake_up) from [<c0a41d30>] (ak8975_irq_handler+0x28/0x30) (ak8975_irq_handler) from [<c0386720>] (handle_irq_event_percpu+0x88/0x140) (handle_irq_event_percpu) from [<c038681c>] (handle_irq_event+0x44/0x68) (handle_irq_event) from [<c0389c40>] (handle_edge_irq+0xf0/0x19c) (handle_edge_irq) from [<c0385e04>] (generic_handle_irq+0x24/0x34) (generic_handle_irq) from [<c05ee360>] (exynos_eint_gpio_irq+0x50/0x68) (exynos_eint_gpio_irq) from [<c0386720>] (handle_irq_event_percpu+0x88/0x140) (handle_irq_event_percpu) from [<c038681c>] (handle_irq_event+0x44/0x68) (handle_irq_event) from [<c0389a70>] (handle_fasteoi_irq+0xb4/0x194) (handle_fasteoi_irq) from [<c0385e04>] (generic_handle_irq+0x24/0x34) (generic_handle_irq) from [<c03860b4>] (__handle_domain_irq+0x5c/0xb4) (__handle_domain_irq) from [<c0301774>] (gic_handle_irq+0x54/0x94) (gic_handle_irq) from [<c030c910>] (__irq_usr+0x50/0x80) The bug was reproduced on exynos4412-trats2 (with a max77693 device also using i2c-gpio) after building max77693 as a module. Cc: <[email protected]> Fixes: 94a6d5c ("iio:ak8975 Implement data ready interrupt handling") Signed-off-by: Krzysztof Kozlowski <[email protected]> Tested-by: Gregor Boirie <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
idlethread
pushed a commit
that referenced
this pull request
May 26, 2016
commit 07d2390 upstream. In certain probe conditions the interrupt came right after registering the handler causing a NULL pointer exception because of uninitialized waitqueue: $ udevadm trigger i2c-gpio i2c-gpio-1: using pins 143 (SDA) and 144 (SCL) i2c-gpio i2c-gpio-3: using pins 53 (SDA) and 52 (SCL) Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = e8b3800 [00000000] *pgd=00000000 Internal error: Oops: 5 [#1] SMP ARM Modules linked in: snd_soc_i2s(+) i2c_gpio(+) snd_soc_idma snd_soc_s3c_dma snd_soc_core snd_pcm_dmaengine snd_pcm snd_timer snd soundcore ac97_bus spi_s3c64xx pwm_samsung dwc2 exynos_adc phy_exynos_usb2 exynosdrm exynos_rng rng_core rtc_s3c CPU: 0 PID: 717 Comm: data-provider-m Not tainted 4.6.0-rc1-next-20160401-00011-g1b8d87473b9e-dirty #101 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) (...) (__wake_up_common) from [<c0379624>] (__wake_up+0x38/0x4c) (__wake_up) from [<c0a41d30>] (ak8975_irq_handler+0x28/0x30) (ak8975_irq_handler) from [<c0386720>] (handle_irq_event_percpu+0x88/0x140) (handle_irq_event_percpu) from [<c038681c>] (handle_irq_event+0x44/0x68) (handle_irq_event) from [<c0389c40>] (handle_edge_irq+0xf0/0x19c) (handle_edge_irq) from [<c0385e04>] (generic_handle_irq+0x24/0x34) (generic_handle_irq) from [<c05ee360>] (exynos_eint_gpio_irq+0x50/0x68) (exynos_eint_gpio_irq) from [<c0386720>] (handle_irq_event_percpu+0x88/0x140) (handle_irq_event_percpu) from [<c038681c>] (handle_irq_event+0x44/0x68) (handle_irq_event) from [<c0389a70>] (handle_fasteoi_irq+0xb4/0x194) (handle_fasteoi_irq) from [<c0385e04>] (generic_handle_irq+0x24/0x34) (generic_handle_irq) from [<c03860b4>] (__handle_domain_irq+0x5c/0xb4) (__handle_domain_irq) from [<c0301774>] (gic_handle_irq+0x54/0x94) (gic_handle_irq) from [<c030c910>] (__irq_usr+0x50/0x80) The bug was reproduced on exynos4412-trats2 (with a max77693 device also using i2c-gpio) after building max77693 as a module. Fixes: 94a6d5c ("iio:ak8975 Implement data ready interrupt handling") Signed-off-by: Krzysztof Kozlowski <[email protected]> Tested-by: Gregor Boirie <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
docularxu
pushed a commit
to 96boards-hikey/linux
that referenced
this pull request
Mar 15, 2017
We cannot do printk() from tk_debug_account_sleep_time(), because tk_debug_account_sleep_time() is called under tk_core seq lock. The reason why printk() is unsafe there is that console_sem may invoke scheduler (up()->wake_up_process()->activate_task()), which, in turn, can return back to timekeeping code, for instance, via get_time()->ktime_get(), deadlocking the system on tk_core seq lock. [ 48.950592] ====================================================== [ 48.950622] [ INFO: possible circular locking dependency detected ] [ 48.950622] 4.10.0-rc7-next-20170213+ 96boards#101 Not tainted [ 48.950622] ------------------------------------------------------- [ 48.950622] kworker/0:0/3 is trying to acquire lock: [ 48.950653] (tk_core){----..}, at: [<c01cc624>] retrigger_next_event+0x4c/0x90 [ 48.950683] but task is already holding lock: [ 48.950683] (hrtimer_bases.lock){-.-...}, at: [<c01cc610>] retrigger_next_event+0x38/0x90 [ 48.950714] which lock already depends on the new lock. [ 48.950714] the existing dependency chain (in reverse order) is: [ 48.950714] -> #5 (hrtimer_bases.lock){-.-...}: [ 48.950744] _raw_spin_lock_irqsave+0x50/0x64 [ 48.950775] lock_hrtimer_base+0x28/0x58 [ 48.950775] hrtimer_start_range_ns+0x20/0x5c8 [ 48.950775] __enqueue_rt_entity+0x320/0x360 [ 48.950805] enqueue_rt_entity+0x2c/0x44 [ 48.950805] enqueue_task_rt+0x24/0x94 [ 48.950836] ttwu_do_activate+0x54/0xc0 [ 48.950836] try_to_wake_up+0x248/0x5c8 [ 48.950836] __setup_irq+0x420/0x5f0 [ 48.950836] request_threaded_irq+0xdc/0x184 [ 48.950866] devm_request_threaded_irq+0x58/0xa4 [ 48.950866] omap_i2c_probe+0x530/0x6a0 [ 48.950897] platform_drv_probe+0x50/0xb0 [ 48.950897] driver_probe_device+0x1f8/0x2cc [ 48.950897] __driver_attach+0xc0/0xc4 [ 48.950927] bus_for_each_dev+0x6c/0xa0 [ 48.950927] bus_add_driver+0x100/0x210 [ 48.950927] driver_register+0x78/0xf4 [ 48.950958] do_one_initcall+0x3c/0x16c [ 48.950958] kernel_init_freeable+0x20c/0x2d8 [ 48.950958] kernel_init+0x8/0x110 [ 48.950988] ret_from_fork+0x14/0x24 [ 48.950988] -> #4 (&rt_b->rt_runtime_lock){-.-...}: [ 48.951019] _raw_spin_lock+0x40/0x50 [ 48.951019] rq_offline_rt+0x9c/0x2bc [ 48.951019] set_rq_offline.part.2+0x2c/0x58 [ 48.951049] rq_attach_root+0x134/0x144 [ 48.951049] cpu_attach_domain+0x18c/0x6f4 [ 48.951049] build_sched_domains+0xba4/0xd80 [ 48.951080] sched_init_smp+0x68/0x10c [ 48.951080] kernel_init_freeable+0x160/0x2d8 [ 48.951080] kernel_init+0x8/0x110 [ 48.951080] ret_from_fork+0x14/0x24 [ 48.951110] -> #3 (&rq->lock){-.-.-.}: [ 48.951110] _raw_spin_lock+0x40/0x50 [ 48.951141] task_fork_fair+0x30/0x124 [ 48.951141] sched_fork+0x194/0x2e0 [ 48.951141] copy_process.part.5+0x448/0x1a20 [ 48.951171] _do_fork+0x98/0x7e8 [ 48.951171] kernel_thread+0x2c/0x34 [ 48.951171] rest_init+0x1c/0x18c [ 48.951202] start_kernel+0x35c/0x3d4 [ 48.951202] 0x8000807c [ 48.951202] -> #2 (&p->pi_lock){-.-.-.}: [ 48.951232] _raw_spin_lock_irqsave+0x50/0x64 [ 48.951232] try_to_wake_up+0x30/0x5c8 [ 48.951232] up+0x4c/0x60 [ 48.951263] __up_console_sem+0x2c/0x58 [ 48.951263] console_unlock+0x3b4/0x650 [ 48.951263] vprintk_emit+0x270/0x474 [ 48.951293] vprintk_default+0x20/0x28 [ 48.951293] printk+0x20/0x30 [ 48.951324] kauditd_hold_skb+0x94/0xb8 [ 48.951324] kauditd_thread+0x1a4/0x56c [ 48.951324] kthread+0x104/0x148 [ 48.951354] ret_from_fork+0x14/0x24 [ 48.951354] -> #1 ((console_sem).lock){-.....}: [ 48.951385] _raw_spin_lock_irqsave+0x50/0x64 [ 48.951385] down_trylock+0xc/0x2c [ 48.951385] __down_trylock_console_sem+0x24/0x80 [ 48.951385] console_trylock+0x10/0x8c [ 48.951416] vprintk_emit+0x264/0x474 [ 48.951416] vprintk_default+0x20/0x28 [ 48.951416] printk+0x20/0x30 [ 48.951446] tk_debug_account_sleep_time+0x5c/0x70 [ 48.951446] __timekeeping_inject_sleeptime.constprop.3+0x170/0x1a0 [ 48.951446] timekeeping_resume+0x218/0x23c [ 48.951477] syscore_resume+0x94/0x42c [ 48.951477] suspend_enter+0x554/0x9b4 [ 48.951477] suspend_devices_and_enter+0xd8/0x4b4 [ 48.951507] enter_state+0x934/0xbd4 [ 48.951507] pm_suspend+0x14/0x70 [ 48.951507] state_store+0x68/0xc8 [ 48.951538] kernfs_fop_write+0xf4/0x1f8 [ 48.951538] __vfs_write+0x1c/0x114 [ 48.951538] vfs_write+0xa0/0x168 [ 48.951568] SyS_write+0x3c/0x90 [ 48.951568] __sys_trace_return+0x0/0x10 [ 48.951568] -> #0 (tk_core){----..}: [ 48.951599] lock_acquire+0xe0/0x294 [ 48.951599] ktime_get_update_offsets_now+0x5c/0x1d4 [ 48.951629] retrigger_next_event+0x4c/0x90 [ 48.951629] on_each_cpu+0x40/0x7c [ 48.951629] clock_was_set_work+0x14/0x20 [ 48.951660] process_one_work+0x2b4/0x808 [ 48.951660] worker_thread+0x3c/0x550 [ 48.951660] kthread+0x104/0x148 [ 48.951690] ret_from_fork+0x14/0x24 [ 48.951690] other info that might help us debug this: [ 48.951690] Chain exists of: tk_core --> &rt_b->rt_runtime_lock --> hrtimer_bases.lock [ 48.951721] Possible unsafe locking scenario: [ 48.951721] CPU0 CPU1 [ 48.951721] ---- ---- [ 48.951721] lock(hrtimer_bases.lock); [ 48.951751] lock(&rt_b->rt_runtime_lock); [ 48.951751] lock(hrtimer_bases.lock); [ 48.951751] lock(tk_core); [ 48.951782] *** DEADLOCK *** [ 48.951782] 3 locks held by kworker/0:0/3: [ 48.951782] #0: ("events"){.+.+.+}, at: [<c0156590>] process_one_work+0x1f8/0x808 [ 48.951812] #1: (hrtimer_work){+.+...}, at: [<c0156590>] process_one_work+0x1f8/0x808 [ 48.951843] #2: (hrtimer_bases.lock){-.-...}, at: [<c01cc610>] retrigger_next_event+0x38/0x90 [ 48.951843] stack backtrace: [ 48.951873] CPU: 0 PID: 3 Comm: kworker/0:0 Not tainted 4.10.0-rc7-next-20170213+ [ 48.951904] Workqueue: events clock_was_set_work [ 48.951904] [<c0110208>] (unwind_backtrace) from [<c010c224>] (show_stack+0x10/0x14) [ 48.951934] [<c010c224>] (show_stack) from [<c04ca6c0>] (dump_stack+0xac/0xe0) [ 48.951934] [<c04ca6c0>] (dump_stack) from [<c019b5cc>] (print_circular_bug+0x1d0/0x308) [ 48.951965] [<c019b5cc>] (print_circular_bug) from [<c019d2a8>] (validate_chain+0xf50/0x1324) [ 48.951965] [<c019d2a8>] (validate_chain) from [<c019ec18>] (__lock_acquire+0x468/0x7e8) [ 48.951995] [<c019ec18>] (__lock_acquire) from [<c019f634>] (lock_acquire+0xe0/0x294) [ 48.951995] [<c019f634>] (lock_acquire) from [<c01d0ea0>] (ktime_get_update_offsets_now+0x5c/0x1d4) [ 48.952026] [<c01d0ea0>] (ktime_get_update_offsets_now) from [<c01cc624>] (retrigger_next_event+0x4c/0x90) [ 48.952026] [<c01cc624>] (retrigger_next_event) from [<c01e4e24>] (on_each_cpu+0x40/0x7c) [ 48.952056] [<c01e4e24>] (on_each_cpu) from [<c01cafc4>] (clock_was_set_work+0x14/0x20) [ 48.952056] [<c01cafc4>] (clock_was_set_work) from [<c015664c>] (process_one_work+0x2b4/0x808) [ 48.952087] [<c015664c>] (process_one_work) from [<c0157774>] (worker_thread+0x3c/0x550) [ 48.952087] [<c0157774>] (worker_thread) from [<c015d644>] (kthread+0x104/0x148) [ 48.952087] [<c015d644>] (kthread) from [<c0107830>] (ret_from_fork+0x14/0x24) Replace printk() with printk_deferred(), which does not call into the scheduler. Fixes: 0bf43f1 ("timekeeping: Prints the amounts of time spent during suspend") Reported-and-tested-by: Tony Lindgren <[email protected]> Signed-off-by: Sergey Senozhatsky <[email protected]> Cc: Petr Mladek <[email protected]> Cc: Sergey Senozhatsky <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: "Rafael J . Wysocki" <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: John Stultz <[email protected]> Cc: "[4.9+]" <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.