Re: [Intel-gfx] [PATCH] fbcon: Remove fbcon_has_exited
Hi Daniel, On 5/21/19 4:23 PM, Daniel Vetter wrote: > This is unused code since > > commit 6104c37094e729f3d4ce65797002112735d49cd1 > Author: Daniel Vetter > Date: Tue Aug 1 17:32:07 2017 +0200 > > fbcon: Make fbcon a built-time depency for fbdev > > when fbcon was made a compile-time static dependency of fbdev. We > can't exit fbcon anymore without exiting fbdev first, which only works > if all fbdev drivers have unloaded already. Hence this is all dead > code. > > v2: I missed that fbcon_exit is also called from con_deinit stuff, and > there fbcon_has_exited prevents double-cleanup. But we can fix that > by properly resetting con2fb_map[] to all -1, which is used everywhere > else to indicate "no fb_info allocate to this console". With that > change the double-cleanup (which resulted in a module refcount underflow, > among other things) is prevented. > > Aside: con2fb_map is a signed char, so don't register more than 128 fb_info > or hilarity will ensue. > > v3: CI showed me that I still didn't fully understand what's going on > here. The leaked references in con2fb_map have been used upon > rebinding the fb console in fbcon_init. It worked because fbdev > unregistering still cleaned out con2fb_map, and reset it to info_idx. > If the last fbdev driver unregistered, then it also reset info_idx, > and unregistered the fbcon driver. > > Imo that's all a bit fragile, so let's keep the con2fb_map reset to > -1, and in fbcon_init pick info_idx if we're starting fresh. That > means unbinding and rebinding will cleanse the mapping, but why are > you doing that if you want to retain the mapping, so should be fine. > > Also, I think info_idx == -1 is impossible in fbcon_init - we > unregister the fbcon in that case. So catch&warn about that. > > Signed-off-by: Daniel Vetter > Cc: Maarten Lankhorst > Cc: Bartlomiej Zolnierkiewicz > Cc: Daniel Vetter > Cc: Hans de Goede > Cc: "Noralf Trønnes" > Cc: Yisheng Xie > Cc: Konstantin Khorenko > Cc: Prarit Bhargava > Cc: Kees Cook > --- > drivers/video/fbdev/core/fbcon.c | 39 +--- > 1 file changed, 6 insertions(+), 33 deletions(-) This patch was #09/33 in your patch series, now it is independent change. Do you want me to apply it now or should I wait for the new version of the whole series? [ I looked at all patches in the series and they look fine to me. After outstanding issues are fixed I'll be happy to apply them all to fbdev-for-next (I can create immutable branch if needed). ] Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 24/33] Revert "backlight/fbcon: Add FB_EVENT_CONBLANK"
On 5/24/19 5:28 PM, Daniel Vetter wrote: > Hi Daniel, > > On Fri, May 24, 2019 at 3:14 PM Daniel Thompson > wrote: >> >> On Fri, May 24, 2019 at 10:53:45AM +0200, Daniel Vetter wrote: >>> This reverts commit 994efacdf9a087b52f71e620b58dfa526b0cf928. >>> >>> The justification is that if hw blanking fails (i.e. fbops->fb_blank) >>> fails, then we still want to shut down the backlight. Which is exactly >>> _not_ what fb_blank() does and so rather inconsistent if we end up >>> with different behaviour between fbcon and direct fbdev usage. Given >>> that the entire notifier maze is getting in the way anyway I figured >>> it's simplest to revert this not well justified commit. >>> >>> v2: Add static inline to the dummy version. >>> >>> Cc: Richard Purdie >>> Signed-off-by: Daniel Vetter >>> Cc: Lee Jones >>> Cc: Daniel Thompson >>> Cc: Jingoo Han >>> Cc: Bartlomiej Zolnierkiewicz >>> Cc: Daniel Vetter >>> Cc: Hans de Goede >>> Cc: Yisheng Xie >>> Cc: linux-fb...@vger.kernel.org >> >> Hi Daniel >> >> When this goes round again could you add me to the covering letter? >> >> I looked at all three of the patches and no objections on my side but >> I'm reluctant to send out acks because I'm not sure I understood the >> wider picture well enough. > > It's one of these patch series with some many different subsystems and > people you can't cc the cover to all of them or mailing lists start > rejecting you because too many recipients. I tried to spam sufficient > mailng lists, but I guess not enough. BTW Not all relevant patches were posted to linux-fbdev and me (i.e. "[PATCH 05/33] fbdev/sa1100fb: Remove dead code") - I found them on other mailing lists but it requires some additional work from me to find / process them. If possible please Cc: linux-fbdev & me on all patches in the patchset. Thanks! Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm: remove redundant 'default n' from Kconfig
'default n' is the default value for any bool or tristate Kconfig
setting so there is no need to write it explicitly.
Also since commit f467c5640c29 ("kconfig: only write '# CONFIG_FOO
is not set' for visible symbols") the Kconfig behavior is the same
regardless of 'default n' being present or not:
...
One side effect of (and the main motivation for) this change is making
the following two definitions behave exactly the same:
config FOO
bool
config FOO
bool
default n
With this change, neither of these will generate a
'# CONFIG_FOO is not set' line (assuming FOO isn't selected/implied).
That might make it clearer to people that a bare 'default n' is
redundant.
...
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/gpu/drm/Kconfig |5 -
drivers/gpu/drm/amd/amdgpu/Kconfig |1 -
drivers/gpu/drm/arm/Kconfig |1 -
drivers/gpu/drm/exynos/Kconfig |2 --
drivers/gpu/drm/i915/Kconfig|3 ---
drivers/gpu/drm/i915/Kconfig.debug | 13 -
drivers/gpu/drm/msm/Kconfig |2 --
drivers/gpu/drm/nouveau/Kconfig |2 --
drivers/gpu/drm/omapdrm/Kconfig |1 -
drivers/gpu/drm/omapdrm/dss/Kconfig |6 --
10 files changed, 36 deletions(-)
Index: b/drivers/gpu/drm/Kconfig
===
--- a/drivers/gpu/drm/Kconfig 2019-04-12 11:42:30.070095359 +0200
+++ b/drivers/gpu/drm/Kconfig 2019-04-12 11:42:30.066095359 +0200
@@ -37,7 +37,6 @@ config DRM_DP_AUX_CHARDEV
config DRM_DEBUG_MM
bool "Insert extra checks and debug info into the DRM range managers"
- default n
depends on DRM=y
depends on STACKTRACE_SUPPORT
select STACKDEPOT
@@ -56,7 +55,6 @@ config DRM_DEBUG_SELFTEST
select PRIME_NUMBERS
select DRM_LIB_RANDOM
select DRM_KMS_HELPER
- default n
help
This option provides kernel modules that can be used to run
various selftests on parts of the DRM api. This option is not
@@ -113,7 +111,6 @@ config DRM_FBDEV_OVERALLOC
config DRM_FBDEV_LEAK_PHYS_SMEM
bool "Shamelessly allow leaking of fbdev physical address (DANGEROUS)"
depends on DRM_FBDEV_EMULATION && EXPERT
- default n
help
In order to keep user-space compatibility, we want in certain
use-cases to keep leaking the fbdev physical address to the
@@ -247,7 +244,6 @@ config DRM_VKMS
tristate "Virtual KMS (EXPERIMENTAL)"
depends on DRM
select DRM_KMS_HELPER
- default n
help
Virtual Kernel Mode-Setting (VKMS) is used for testing or for
running GPU in a headless machines. Choose this option to get
@@ -424,4 +420,3 @@ config DRM_PANEL_ORIENTATION_QUIRKS
config DRM_LIB_RANDOM
bool
- default n
Index: b/drivers/gpu/drm/amd/amdgpu/Kconfig
===
--- a/drivers/gpu/drm/amd/amdgpu/Kconfig2019-04-12 11:42:30.070095359
+0200
+++ b/drivers/gpu/drm/amd/amdgpu/Kconfig2019-04-12 11:42:30.066095359
+0200
@@ -35,7 +35,6 @@ config DRM_AMDGPU_GART_DEBUGFS
bool "Allow GART access through debugfs"
depends on DRM_AMDGPU
depends on DEBUG_FS
- default n
help
Selecting this option creates a debugfs file to inspect the mapped
pages. Uses more memory for housekeeping, enable only for debugging.
Index: b/drivers/gpu/drm/arm/Kconfig
===
--- a/drivers/gpu/drm/arm/Kconfig 2019-04-12 11:42:30.070095359 +0200
+++ b/drivers/gpu/drm/arm/Kconfig 2019-04-12 11:42:30.066095359 +0200
@@ -16,7 +16,6 @@ config DRM_HDLCD
config DRM_HDLCD_SHOW_UNDERRUN
bool "Show underrun conditions"
depends on DRM_HDLCD
- default n
help
Enable this option to show in red colour the pixels that the
HDLCD device did not fetch from framebuffer due to underrun
Index: b/drivers/gpu/drm/exynos/Kconfig
===
--- a/drivers/gpu/drm/exynos/Kconfig2019-04-12 11:42:30.070095359 +0200
+++ b/drivers/gpu/drm/exynos/Kconfig2019-04-12 11:42:30.066095359 +0200
@@ -46,7 +46,6 @@ config DRM_EXYNOS_DPI
bool "Parallel output"
depends on DRM_EXYNOS_FIMD
select DRM_PANEL
- default n
help
This enables support for Exynos parallel output.
@@ -55,7 +54,6 @@ config DRM_EXYNOS_DSI
depends on DRM_EXYNOS_FIMD || DRM_EXYNOS5433_DECON || DRM_EXYNOS7_DECON
select DRM_MIPI_DSI
select DRM_PA
Re: [Intel-gfx] [PATCH 00/33] fbcon notifier begone v3!
On 6/6/19 9:38 AM, Daniel Vetter wrote: > Hi Bart, Hi Daniel, > On Tue, May 28, 2019 at 11:02:31AM +0200, Daniel Vetter wrote: >> Hi all, >> >> I think we're slowly getting there. Previous cover letters with more >> context: >> >> https://lists.freedesktop.org/archives/dri-devel/2019-May/218362.html >> >> tldr; I have a multi-year plan to improve fbcon locking, because the >> current thing is a bit a mess. >> >> Cover letter of this version, where I detail a bit more the details >> fixed in this one here: >> >> https://lists.freedesktop.org/archives/dri-devel/2019-May/218984.html >> >> Note that the locking plan in this one is already outdated, I overlooked a >> few fun issues around any printk() going back to console_lock. >> >> I think remaining bits: >> >> - Ack from Daniel Thompson for the backlight bits, he wanted to check the >> big picture. > > I think Daniel is still on vacation until next week or so. > >> - Hash out actual merge plan. > > I'd like to stuff this into drm.git somehow, I guess topic branch works > too. I would like to have topic branch for this patchset. > Long term I think we need to reconsider how we handle fbdev, at least the > core/fbcon pieces. Since a few years all the work in that area has been > motivated by drm, and pushed by drm contributors. Having that maintained > in a separate tree that doesn't regularly integrate imo doesn't make much > sense, and we ended up merging almost everything through some drm tree. > That one time we didn't (for some panel rotation stuff) it resulted in > some good suprises. > > I think best solution is if we put the core and fbcon bits into drm-misc, > as group maintained infrastructure piece. All the other gfx infra pieces > are maintained in there already too. You'd obviously get commit rights. > I think that would include > - drivers/video/fbdev > - drivers/video/*c > - drivers/video/console Sounds fine to me. > I don't really care about what happens with the actual fbdev drivers > (aside from the drm one in drm_fb_helper.c, but that's already maintained > as part of drm). I guess we could also put those into drm-misc, or as a > separate tree, depending what you want. > > Thoughts? I would like to handle fbdev changes for v5.3 merge window using fbdev tree but after that everything (including changes to fbdev drivers) can go through drm-misc tree. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics > Cheers, Daniel > > >> >> I'm also cc'ing the entire pile to a lot more people on request. >> >> Thanks, Daniel >> >> Daniel Vetter (33): >> dummycon: Sprinkle locking checks >> fbdev: locking check for fb_set_suspend >> vt: might_sleep() annotation for do_blank_screen >> vt: More locking checks >> fbdev/sa1100fb: Remove dead code >> fbdev/cyber2000: Remove struct display >> fbdev/aty128fb: Remove dead code >> fbcon: s/struct display/struct fbcon_display/ >> fbcon: Remove fbcon_has_exited >> fbcon: call fbcon_fb_(un)registered directly >> fbdev/sh_mobile: remove sh_mobile_lcdc_display_notify >> fbdev/omap: sysfs files can't disappear before the device is gone >> fbdev: sysfs files can't disappear before the device is gone >> staging/olpc: lock_fb_info can't fail >> fbdev/atyfb: lock_fb_info can't fail >> fbdev: lock_fb_info cannot fail >> fbcon: call fbcon_fb_bind directly >> fbdev: make unregister/unlink functions not fail >> fbdev: unify unlink_framebuffer paths >> fbdev/sh_mob: Remove fb notifier callback >> fbdev: directly call fbcon_suspended/resumed >> fbcon: Call fbcon_mode_deleted/new_modelist directly >> fbdev: Call fbcon_get_requirement directly >> Revert "backlight/fbcon: Add FB_EVENT_CONBLANK" >> fbmem: pull fbcon_fb_blanked out of fb_blank >> fbdev: remove FBINFO_MISC_USEREVENT around fb_blank >> fb: Flatten control flow in fb_set_var >> fbcon: replace FB_EVENT_MODE_CHANGE/_ALL with direct calls >> vgaswitcheroo: call fbcon_remap_all directly >> fbcon: Call con2fb_map functions directly >> fbcon: Document what I learned about fbcon locking >> staging/olpc_dcon: Add drm conversion to TODO >> backlight: simplify lcd notifier >> >> arch/arm/mach-pxa/am200epd.c | 13 +- >> drivers/gpu/vga/vga_switcheroo.c | 11 +- >> drivers/media/pci/ivtv/ivtvfb.c | 6 +- >> drivers/staging/fbtft/fbtft-c
Re: [Intel-gfx] [PULL] topic/remove-fbcon-notifiers for v5.3
Hi, On 6/18/19 11:20 AM, Maarten Lankhorst wrote: > Op 14-06-2019 om 11:25 schreef Maarten Lankhorst: >> Hi all, >> >> As discussed with Daniel V, I'm just doing the paperwork here as drm-misc >> maintainer. >> >> This is the topic pull request for the fbdev notifier removal. >> >> Bar, please make a final check and pull into your fbdev tree. >> >> Lee, please make a final check and pull into your backlight tree. >> >> Greg, this is just fyi, you already acked all the vt and staging patches in >> here >> to land through other trees. >> >> I'll pull this into drm-misc-next once Bart & Lee acked it. >> >> Cheers, Maarten. > > Bart, Lee, ping? Looks OK to me (I have test pulled it locally and there is only trivial merge conflict on removed mxsfb fbdev driver) but it seems that all patches miss your "S-o-B:" line (there is only "Reviewed-by:" tag which is OK but has a different meaning)? Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics > >> topic/remove-fbcon-notifiers-2019-06-14-1: >> >> topic/remove-fbcon-notifiers: >> - remove fbdev notifier usage for fbcon, as prep work to clean up the fbcon >> locking >> - assorted locking checks in vt/console code >> - assorted notifier and cleanups in fbdev and backlight code >> >> The following changes since commit d1fdb6d8f6a4109a4263176c84b899076a5f8008: >> >> Linux 5.2-rc4 (2019-06-08 20:24:46 -0700) >> >> are available in the Git repository at: >> >> git://anongit.freedesktop.org/drm/drm-misc >> tags/topic/remove-fbcon-notifiers-2019-06-14-1 >> >> for you to fetch changes up to 1dcff4ae65185e8c0300972f6d8d39d9a9db2bda: >> >> backlight: simplify lcd notifier (2019-06-13 10:07:20 +0200) >> >> >> Daniel Vetter (33): >> dummycon: Sprinkle locking checks >> fbdev: locking check for fb_set_suspend >> vt: might_sleep() annotation for do_blank_screen >> vt: More locking checks >> fbdev/sa1100fb: Remove dead code >> fbdev/cyber2000: Remove struct display >> fbdev/aty128fb: Remove dead code >> fbcon: s/struct display/struct fbcon_display/ >> fbcon: Remove fbcon_has_exited >> fbcon: call fbcon_fb_(un)registered directly >> fbdev/sh_mobile: remove sh_mobile_lcdc_display_notify >> fbdev/omap: sysfs files can't disappear before the device is gone >> fbdev: sysfs files can't disappear before the device is gone >> staging/olpc: lock_fb_info can't fail >> fbdev/atyfb: lock_fb_info can't fail >> fbdev: lock_fb_info cannot fail >> fbcon: call fbcon_fb_bind directly >> fbdev: make unregister/unlink functions not fail >> fbdev: unify unlink_framebuffer paths >> fbdev/sh_mob: Remove fb notifier callback >> fbdev: directly call fbcon_suspended/resumed >> fbcon: Call fbcon_mode_deleted/new_modelist directly >> fbdev: Call fbcon_get_requirement directly >> Revert "backlight/fbcon: Add FB_EVENT_CONBLANK" >> fbmem: pull fbcon_fb_blanked out of fb_blank >> fbdev: remove FBINFO_MISC_USEREVENT around fb_blank >> fb: Flatten control flow in fb_set_var >> fbcon: replace FB_EVENT_MODE_CHANGE/_ALL with direct calls >> vgaswitcheroo: call fbcon_remap_all directly >> fbcon: Call con2fb_map functions directly >> fbcon: Document what I learned about fbcon locking >> staging/olpc_dcon: Add drm conversion to TODO >> backlight: simplify lcd notifier >> >> arch/arm/mach-pxa/am200epd.c| 13 +- >> drivers/gpu/vga/vga_switcheroo.c| 11 +- >> drivers/media/pci/ivtv/ivtvfb.c | 6 +- >> drivers/staging/fbtft/fbtft-core.c | 4 +- >> drivers/staging/olpc_dcon/TODO | 7 + >> drivers/staging/olpc_dcon/olpc_dcon.c | 6 +- >> drivers/tty/vt/vt.c | 18 ++ >> drivers/video/backlight/backlight.c | 2 +- >> drivers/video/backlight/lcd.c | 12 - >> drivers/video/console/dummycon.c| 6 + >> drivers/video/fbdev/aty/aty128fb.c | 64 >> drivers/video/fbdev/aty/atyfb_base.c| 3 +- >> drivers/video/fbdev/core/fbcmap.c |
Re: [Intel-gfx] [PULL] topic/remove-fbcon-notifiers for v5.3
On 6/18/19 1:46 PM, Maarten Lankhorst wrote: > Op 18-06-2019 om 13:17 schreef Bartlomiej Zolnierkiewicz: >> Hi, >> >> On 6/18/19 11:20 AM, Maarten Lankhorst wrote: >>> Op 14-06-2019 om 11:25 schreef Maarten Lankhorst: >>>> Hi all, >>>> >>>> As discussed with Daniel V, I'm just doing the paperwork here as drm-misc >>>> maintainer. >>>> >>>> This is the topic pull request for the fbdev notifier removal. >>>> >>>> Bar, please make a final check and pull into your fbdev tree. >>>> >>>> Lee, please make a final check and pull into your backlight tree. >>>> >>>> Greg, this is just fyi, you already acked all the vt and staging patches >>>> in here >>>> to land through other trees. >>>> >>>> I'll pull this into drm-misc-next once Bart & Lee acked it. >>>> >>>> Cheers, Maarten. >>> Bart, Lee, ping? >> Looks OK to me (I have test pulled it locally and there is only trivial >> merge conflict on removed mxsfb fbdev driver) but it seems that all >> patches miss your "S-o-B:" line (there is only "Reviewed-by:" tag which >> is OK but has a different meaning)? > > Hey, > > I created the topic branch, but daniel pushed the patches to it. :) > > That explains why there's a R-B but no S-o-B. I see, that's kind of interesting work-flow.. :) Anyway, I've pulled topic/remove-fbcon-notifiers-2019-06-14-1 tag (and also topic/remove-fbcon-notifiers branch to get a buildfix) into fbdev-for-next, thanks! Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics > Cheers, > > Maarten > >> Best regards, >> -- >> Bartlomiej Zolnierkiewicz >> Samsung R&D Institute Poland >> Samsung Electronics >> >>>> topic/remove-fbcon-notifiers-2019-06-14-1: >>>> >>>> topic/remove-fbcon-notifiers: >>>> - remove fbdev notifier usage for fbcon, as prep work to clean up the >>>> fbcon locking >>>> - assorted locking checks in vt/console code >>>> - assorted notifier and cleanups in fbdev and backlight code >>>> >>>> The following changes since commit >>>> d1fdb6d8f6a4109a4263176c84b899076a5f8008: >>>> >>>> Linux 5.2-rc4 (2019-06-08 20:24:46 -0700) >>>> >>>> are available in the Git repository at: >>>> >>>> git://anongit.freedesktop.org/drm/drm-misc >>>> tags/topic/remove-fbcon-notifiers-2019-06-14-1 >>>> >>>> for you to fetch changes up to 1dcff4ae65185e8c0300972f6d8d39d9a9db2bda: >>>> >>>> backlight: simplify lcd notifier (2019-06-13 10:07:20 +0200) >>>> >>>> >>>> Daniel Vetter (33): >>>> dummycon: Sprinkle locking checks >>>> fbdev: locking check for fb_set_suspend >>>> vt: might_sleep() annotation for do_blank_screen >>>> vt: More locking checks >>>> fbdev/sa1100fb: Remove dead code >>>> fbdev/cyber2000: Remove struct display >>>> fbdev/aty128fb: Remove dead code >>>> fbcon: s/struct display/struct fbcon_display/ >>>> fbcon: Remove fbcon_has_exited >>>> fbcon: call fbcon_fb_(un)registered directly >>>> fbdev/sh_mobile: remove sh_mobile_lcdc_display_notify >>>> fbdev/omap: sysfs files can't disappear before the device is gone >>>> fbdev: sysfs files can't disappear before the device is gone >>>> staging/olpc: lock_fb_info can't fail >>>> fbdev/atyfb: lock_fb_info can't fail >>>> fbdev: lock_fb_info cannot fail >>>> fbcon: call fbcon_fb_bind directly >>>> fbdev: make unregister/unlink functions not fail >>>> fbdev: unify unlink_framebuffer paths >>>> fbdev/sh_mob: Remove fb notifier callback >>>> fbdev: directly call fbcon_suspended/resumed >>>> fbcon: Call fbcon_mode_deleted/new_modelist directly >>>> fbdev: Call fbcon_get_requirement directly >>>> Revert "backlight/fbcon: Add FB_EVENT_CONBLANK" >>>> fbmem: pull fbcon_fb_blanked out of fb_blank >>>> fbdev: remove FBINFO_MISC_USEREVENT aroun
Re: [Intel-gfx] linux-next: build failure after merge of the drm-misc tree
Hi Stephen,
On 4/29/20 12:33 AM, Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 20 Apr 2020 13:01:18 +1000 Stephen Rothwell
> wrote:
>>
>> After merging the drm-misc tree, today's linux-next build (powerpc
>> allyesconfig) failed like this:
>>
>> drivers/video/fbdev/controlfb.c: In function 'controlfb_mmap':
>> drivers/video/fbdev/controlfb.c:756:23: error: implicit declaration of
>> function 'pgprot_cached_wthru'; did you mean 'pgprot_cached'?
>> [-Werror=implicit-function-declaration]
>> 756 | vma->vm_page_prot = pgprot_cached_wthru(vma->vm_page_prot);
>> | ^~~
>> | pgprot_cached
>> drivers/video/fbdev/controlfb.c:756:23: error: incompatible types when
>> assigning to type 'pgprot_t' {aka 'struct '} from type 'int'
>>
>> Presumably exposed by commit
>>
>> a07a63b0e24d ("video: fbdev: controlfb: add COMPILE_TEST support")
>>
>> I just turned off COMPILE_TEST again for today. Please let me know when
>> this is fixed.
>
> This still appears to have not been addressed.
Sorry for the delay, I've just posted a patch (also included below):
"[PATCH] video: fbdev: controlfb: fix build for COMPILE_TEST=y && PPC_PMAC=y &&
PPC32=n"
which should fix it.
Please verify it, thank you!
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
From: Bartlomiej Zolnierkiewicz
Subject: [PATCH] video: fbdev: controlfb: fix build for COMPILE_TEST=y &&
PPC_PMAC=y && PPC32=n
powerpc allyesconfig fails like this:
drivers/video/fbdev/controlfb.c: In function 'controlfb_mmap':
drivers/video/fbdev/controlfb.c:756:23: error: implicit declaration of function
'pgprot_cached_wthru'; did you mean 'pgprot_cached'?
[-Werror=implicit-function-declaration]
756 | vma->vm_page_prot = pgprot_cached_wthru(vma->vm_page_prot);
| ^~~
| pgprot_cached
drivers/video/fbdev/controlfb.c:756:23: error: incompatible types when
assigning to type 'pgprot_t' {aka 'struct '} from type 'int'
Fix it by adding missing PPC32 dependency.
Fixes: a07a63b0e24d ("video: fbdev: controlfb: add COMPILE_TEST support")
Reported-by: Stephen Rothwell
Reported-by: kbuild test robot
Cc: Sam Ravnborg
Cc: Daniel Vetter
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/video/fbdev/controlfb.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: b/drivers/video/fbdev/controlfb.c
===
--- a/drivers/video/fbdev/controlfb.c
+++ b/drivers/video/fbdev/controlfb.c
@@ -47,7 +47,7 @@
#include
#include
#include
-#ifdef CONFIG_PPC_PMAC
+#if defined(CONFIG_PPC_PMAC) && defined(CONFIG_PPC32)
#include
#include
#endif
@@ -55,7 +55,7 @@
#include "macmodes.h"
#include "controlfb.h"
-#ifndef CONFIG_PPC_PMAC
+#if !defined(CONFIG_PPC_PMAC) || !defined(CONFIG_PPC32)
#define invalid_vram_cache(addr)
#undef in_8
#undef out_8
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: build failure after merge of the drm-misc tree
On 4/29/20 10:09 AM, Bartlomiej Zolnierkiewicz wrote:
>
> Hi Stephen,
>
> On 4/29/20 12:33 AM, Stephen Rothwell wrote:
>> Hi all,
>>
>> On Mon, 20 Apr 2020 13:01:18 +1000 Stephen Rothwell
>> wrote:
>>>
>>> After merging the drm-misc tree, today's linux-next build (powerpc
>>> allyesconfig) failed like this:
>>>
>>> drivers/video/fbdev/controlfb.c: In function 'controlfb_mmap':
>>> drivers/video/fbdev/controlfb.c:756:23: error: implicit declaration of
>>> function 'pgprot_cached_wthru'; did you mean 'pgprot_cached'?
>>> [-Werror=implicit-function-declaration]
>>> 756 | vma->vm_page_prot = pgprot_cached_wthru(vma->vm_page_prot);
>>> | ^~~
>>> | pgprot_cached
>>> drivers/video/fbdev/controlfb.c:756:23: error: incompatible types when
>>> assigning to type 'pgprot_t' {aka 'struct '} from type 'int'
>>>
>>> Presumably exposed by commit
>>>
>>> a07a63b0e24d ("video: fbdev: controlfb: add COMPILE_TEST support")
>>>
>>> I just turned off COMPILE_TEST again for today. Please let me know when
>>> this is fixed.
>>
>> This still appears to have not been addressed.
>
> Sorry for the delay, I've just posted a patch (also included below):
>
> "[PATCH] video: fbdev: controlfb: fix build for COMPILE_TEST=y && PPC_PMAC=y
> && PPC32=n"
>
> which should fix it.
>
> Please verify it, thank you!
I have tested it with powerpc allyesconfig now and it adds one dependency too
much,
fixed in v2:
https://lore.kernel.org/lkml/fe520316-3863-e6c4-9581-5d709f49e...@samsung.com/
Sam, could you please review / merge it to drm-misc-next?
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PULL] topic/remove-fbcon-notifiers for v5.3, fixes
Hi, On 6/26/19 10:48 AM, Maarten Lankhorst wrote: > Hi all, > > This is the followup pull request for the remove-fbcon-notifiers topic branch. > No major changes, just a few compile fixes. > > This will be pulled into drm-misc-next, but it might be useful for the fbdev > and backlight trees too. Pulled into fbdev-for-next, thanks! > Cheers, > Maarten > > topic/remove-fbcon-notifiers-2019-06-26: > - Export fbcon_update_vcs to fix sh_mobile_lcdcfb.c compilation. > - Rely on fbcon being builtin when vgaswitcheroo is builtin. > The following changes since commit 1dcff4ae65185e8c0300972f6d8d39d9a9db2bda: > > backlight: simplify lcd notifier (2019-05-28 11:03:04 +0200) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-misc > tags/topic/remove-fbcon-notifiers-2019-06-26 > > for you to fetch changes up to 6116b892bd4fd0ddc5f30566a556218bb2e1a9b6: > > vga_switcheroo: Depend upon fbcon being built-in, if enabled (2019-06-26 > 10:36:49 +0200) > > > topic/remove-fbcon-notifiers: > - Export fbcon_update_vcs to fix sh_mobile_lcdcfb.c compilation. > - Rely on fbcon being builtin when vgaswitcheroo is builtin. > > > Daniel Vetter (2): > fbcon: Export fbcon_update_vcs > vga_switcheroo: Depend upon fbcon being built-in, if enabled > > drivers/gpu/vga/Kconfig | 1 + > drivers/video/fbdev/core/fbcon.c | 1 + > 2 files changed, 2 insertions(+) Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] fbdev: Drop FBINFO_CAN_FORCE_OUTPUT flag
On 08/22/2018 10:54 AM, Daniel Vetter wrote: > This was only added for the drm's fbdev emulation support, so that it > would try harder to show the Oops. > > Unfortunately this never really worked reliably, and in practice ended > up pushing the real Oops off the screen due to plentyfull locking, > sleep-while-atomic and other issues. So we removed all that support > from the fbdev emulation a while back. Aside: We've also removed the > kgdb support, for similar reasons. > > Since it's such a small patch I figured I don't split this up into the > usual 3-phase removal. > > Cc: Ben Skeggs > Cc: Bartlomiej Zolnierkiewicz > Cc: Greg Kroah-Hartman > Cc: Hans de Goede > Cc: Daniel Vetter > Cc: Alexander Kapshuk > Cc: Kees Cook > Cc: Thierry Reding > Cc: David Lechner > Cc: nouv...@lists.freedesktop.org > Cc: linux-fb...@vger.kernel.org > Signed-off-by: Daniel Vetter Acked-by: Bartlomiej Zolnierkiewicz Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] fbdev: Add FBINFO_HIDE_SMEM_START flag
On 08/22/2018 10:54 AM, Daniel Vetter wrote: > DRM drivers really, really, really don't want random userspace to > share buffer behind it's back, bypassing the dma-buf buffer sharing > machanism. For that reason we've ruthlessly rejected any IOCTL > exposing the physical address of any graphics buffer. > > Unfortunately fbdev comes with that built-in. We could just set > smem_start to 0, but that means we'd have to hand-roll our own fb_mmap > implementation. For good reasons many drivers do that, but > smem_start/length is still super convenient. > > Hence instead just stop the leak in the ioctl, to keep fb mmap working > as-is. A second patch will set this flag for all drm drivers. > > Cc: Bartlomiej Zolnierkiewicz > Cc: Kees Cook > Cc: Daniel Vetter > Cc: linux-fb...@vger.kernel.org > Signed-off-by: Daniel Vetter Acked-by: Bartlomiej Zolnierkiewicz Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] fbdev: Drop FBINFO_CAN_FORCE_OUTPUT flag
On 09/11/2018 09:42 AM, Daniel Vetter wrote: > On Mon, Sep 10, 2018 at 02:48:43PM +0200, Bartlomiej Zolnierkiewicz wrote: >> >> On 08/22/2018 10:54 AM, Daniel Vetter wrote: >>> This was only added for the drm's fbdev emulation support, so that it >>> would try harder to show the Oops. >>> >>> Unfortunately this never really worked reliably, and in practice ended >>> up pushing the real Oops off the screen due to plentyfull locking, >>> sleep-while-atomic and other issues. So we removed all that support >>> from the fbdev emulation a while back. Aside: We've also removed the >>> kgdb support, for similar reasons. >>> >>> Since it's such a small patch I figured I don't split this up into the >>> usual 3-phase removal. >>> >>> Cc: Ben Skeggs >>> Cc: Bartlomiej Zolnierkiewicz >>> Cc: Greg Kroah-Hartman >>> Cc: Hans de Goede >>> Cc: Daniel Vetter >>> Cc: Alexander Kapshuk >>> Cc: Kees Cook >>> Cc: Thierry Reding >>> Cc: David Lechner >>> Cc: nouv...@lists.freedesktop.org >>> Cc: linux-fb...@vger.kernel.org >>> Signed-off-by: Daniel Vetter >> >> Acked-by: Bartlomiej Zolnierkiewicz > > Ack for merging the entire series through drm-misc-next? Yes, thanks for taking care of this. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 20/41] fbdev/pvr2fb: convert put_page() to put_user_page*()
On 8/7/19 3:33 AM, john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> For pages that were retained via get_user_pages*(), release those pages
> via the new put_user_page*() routines, instead of via put_page() or
> release_pages().
>
> This is part a tree-wide conversion, as described in commit fc1d8e7cca2d
> ("mm: introduce put_user_page*(), placeholder versions").
>
> Cc: Bartlomiej Zolnierkiewicz
> Cc: Kees Cook
> Cc: Al Viro
> Cc: Bhumika Goyal
> Cc: Arvind Yadav
> Cc: dri-de...@lists.freedesktop.org
> Cc: linux-fb...@vger.kernel.org
> Signed-off-by: John Hubbard
Acked-by: Bartlomiej Zolnierkiewicz
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
> ---
> drivers/video/fbdev/pvr2fb.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/pvr2fb.c b/drivers/video/fbdev/pvr2fb.c
> index 7ff4b6b84282..0e4f9aa6444d 100644
> --- a/drivers/video/fbdev/pvr2fb.c
> +++ b/drivers/video/fbdev/pvr2fb.c
> @@ -700,8 +700,7 @@ static ssize_t pvr2fb_write(struct fb_info *info, const
> char *buf,
> ret = count;
>
> out_unmap:
> - for (i = 0; i < nr_pages; i++)
> - put_page(pages[i]);
> + put_user_pages(pages, nr_pages);
>
> kfree(pages);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [-next PATCH 2/4] treewide: Use DEVICE_ATTR_RW
On Tuesday, December 19, 2017 10:15:07 AM Joe Perches wrote:
> Convert DEVICE_ATTR uses to DEVICE_ATTR_RW where possible.
>
> Done with perl script:
>
> $ git grep -w --name-only DEVICE_ATTR | \
> xargs perl -i -e 'local $/; while (<>) {
> s/\bDEVICE_ATTR\s*\(\s*(\w+)\s*,\s*\(?(\s*S_IRUGO\s*\|\s*S_IWUSR|\s*S_IWUSR\s*\|\s*S_IRUGO\s*|\s*0644\s*)\)?\s*,\s*\1_show\s*,\s*\1_store\s*\)/DEVICE_ATTR_RW(\1)/g;
> print;}'
>
> Signed-off-by: Joe Perches
> ---
> arch/s390/kernel/topology.c | 3 +--
> arch/tile/kernel/sysfs.c | 2 +-
> drivers/gpu/drm/i915/i915_sysfs.c| 6 ++---
> drivers/platform/x86/compal-laptop.c | 18 +--
> drivers/s390/cio/device.c| 2 +-
> drivers/scsi/lpfc/lpfc_attr.c| 43
>
> drivers/thermal/thermal_sysfs.c | 9
> drivers/tty/serial/sh-sci.c | 2 +-
> drivers/usb/host/xhci-dbgcap.c | 2 +-
> drivers/usb/phy/phy-tahvo.c | 2 +-
> drivers/video/fbdev/auo_k190x.c | 4 ++--
> drivers/video/fbdev/w100fb.c | 4 ++--
> lib/test_firmware.c | 14 +---
> lib/test_kmod.c | 14 +---
> sound/soc/omap/mcbsp.c | 4 ++--
> 15 files changed, 49 insertions(+), 80 deletions(-)
For fbdev changes:
Acked-by: Bartlomiej Zolnierkiewicz
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7 0/7] drm/fbdev: Panel orientation connector property support
On Saturday, November 25, 2017 08:35:46 PM Hans de Goede wrote: > Here is v7 of my series to add a "panel orientation" property to > the drm-connector for the LCD panel to let userspace know about LCD > panels which are not mounted upright, as well as detecting upside-down > panels without needing quirks (like we do for 90 degree rotated screens). > > Bartlomiej, can we please have your Acked-by for merging patches 1, > 6 and 7 through the drm tree? Acked-by: Bartlomiej Zolnierkiewicz Given that you add (can be in a incremental patch) a comment to: drivers/gpu/drm/drm_panel_orientation_quirks.c [ at the top ] and drivers/gpu/drm/Kconfig [ to config DRM_PANEL_ORIENTATION_QUIRKS ] explaining that the code in question is shared with fbdev/efifb (so hopefully people will be careful and not try to make this code DRM specific at some point in a future). > New in v7: > -Fix embarrassing build error in efifb due to me only rebuilding modules > after cleanups from v6 > > New in v6: > -Fix / reference kernel-doc comments > -Don't export the DRM_MODE_PANEL_ORIENTATION_* defines in the UAPI > -Move i915 dsi hardware rotation state read-out to intel_dsi_init() > > New in v5: > -Add kernel-doc comment documenting drm_get_panel_orientation_quirk() > -drm_fb_helper: Only use hardware (crtc primary plane) rotation for > 180 degrees for now as 9-/270 degrees rotation requires special handling > > New in v4: > -Fix drm_fb_helper code setting an invalid rotation value on the primary > plane of disabled/unused crtcs (caught by Fi.CI) > > New in v3: > -As requested by Daniel v3 moves the quirks over from the fbdev > subsys to the drm subsys. I've done this by simpy starting with a copy of > the quirk table and eventually removing the fbdev version. > > The 1st patch in this series is a small fbdev/fbcon patch, patches 2-5 > are all drm patches and patches 6-7 are fbdev/fbcon patches again. As > discussed previously the plan is to merge all 7 patches through the > drm tree. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] fbcon: Make fbcon a built-time depency for fbdev
it works fine when built-in). > > Since this tight binding is the entire goal the simplest solution is > to move all the fbcon modules (and there's a bunch of optinal > source-files which are each modules of their own, for no good > reason) into the overall fb.ko core module. That's a bit more than > what I would have liked to do in this patch, but oh well. > > Cc: Alan Cox > Cc: Sergey Senozhatsky > Cc: Linux Fbdev development list > Cc: Steven Rostedt > Cc: Bartlomiej Zolnierkiewicz > Cc: dri-de...@lists.freedesktop.org > Signed-off-by: Daniel Vetter Acked-by: Bartlomiej Zolnierkiewicz > --- > v2: Switch to building fbcon code into fb.ko right away because the > cheap trick leads to a module depency loop. > --- Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] fbdev: Nuke FBINFO_MODULE
On Tuesday, July 11, 2017 04:52:19 PM Daniel Vetter wrote: > Instead check info->ops->owner, which amounts to the same. > > Spotted because I want to remove the pile of broken and cargo-culted > fb_info->flags assignments in drm drivers. > > v2: Fixup matrox (reported by kbuild). Also nuke FBINFO_FLAG_* defines > that I've failed to spot. > > v3: Don't nuke FBINFO_FLAG_DEFAULT, that's used all over the place. > > Cc: Bartlomiej Zolnierkiewicz > Cc: linux-fb...@vger.kernel.org > Signed-off-by: Daniel Vetter Acked-by: Bartlomiej Zolnierkiewicz Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] fbdev: Nuke FBINFO_MODULE
On Wednesday, July 12, 2017 02:42:14 PM Daniel Vetter wrote: > On Wed, Jul 12, 2017 at 12:41:34PM +0200, Bartlomiej Zolnierkiewicz wrote: > > On Tuesday, July 11, 2017 04:52:19 PM Daniel Vetter wrote: > > > Instead check info->ops->owner, which amounts to the same. > > > > > > Spotted because I want to remove the pile of broken and cargo-culted > > > fb_info->flags assignments in drm drivers. > > > > > > v2: Fixup matrox (reported by kbuild). Also nuke FBINFO_FLAG_* defines > > > that I've failed to spot. > > > > > > v3: Don't nuke FBINFO_FLAG_DEFAULT, that's used all over the place. > > > > > > Cc: Bartlomiej Zolnierkiewicz > > > Cc: linux-fb...@vger.kernel.org > > > Signed-off-by: Daniel Vetter > > > > Acked-by: Bartlomiej Zolnierkiewicz > > Do you plan to pick these two patches up yourself, or do you expect me to > merge them? Since the original patchset contained DRM changes (two last patches) depending on fbdev changes (two first patches, the patch being discussed was the second one) I assumed that you would like to take them all through DRM tree. If this is not what is preferred, please tell me. > I'm always confused when the official maintainer acks something without > saying anything else ... Point taken, I will try to be more verbose next time. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] fbdev: Nuke FBINFO_MODULE
On Wednesday, July 12, 2017 05:07:42 PM Daniel Vetter wrote: > On Wed, Jul 12, 2017 at 2:54 PM, Bartlomiej Zolnierkiewicz > wrote: > > On Wednesday, July 12, 2017 02:42:14 PM Daniel Vetter wrote: > >> On Wed, Jul 12, 2017 at 12:41:34PM +0200, Bartlomiej Zolnierkiewicz wrote: > >> > On Tuesday, July 11, 2017 04:52:19 PM Daniel Vetter wrote: > >> > > Instead check info->ops->owner, which amounts to the same. > >> > > > >> > > Spotted because I want to remove the pile of broken and cargo-culted > >> > > fb_info->flags assignments in drm drivers. > >> > > > >> > > v2: Fixup matrox (reported by kbuild). Also nuke FBINFO_FLAG_* defines > >> > > that I've failed to spot. > >> > > > >> > > v3: Don't nuke FBINFO_FLAG_DEFAULT, that's used all over the place. > >> > > > >> > > Cc: Bartlomiej Zolnierkiewicz > >> > > Cc: linux-fb...@vger.kernel.org > >> > > Signed-off-by: Daniel Vetter > >> > > >> > Acked-by: Bartlomiej Zolnierkiewicz > >> > >> Do you plan to pick these two patches up yourself, or do you expect me to > >> merge them? > > > > Since the original patchset contained DRM changes (two last patches) > > depending on fbdev changes (two first patches, the patch being discussed > > was the second one) I assumed that you would like to take them all > > through DRM tree. If this is not what is preferred, please tell me. > > There's no direct depency between 1&2 and 3&4, the only effect of > merging them through separate trees is that the bootup logo might not > show up when it's expected, until the trees are merged together. We > could merge them through separate trees if you prefer that (I forgot > to mention that in the cover letter), but I'm fine with putting them > all into drm-misc with your ack for 4.14. > > Whatever you prefer, I don't mind either way. Then I will merge patches 1&2 for v4.14 through fbdev tree (there are some other changes pending touching fbdev core and I would like to avoid conflicts between fbdev & drm-misc trees). Thanks! Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] fbdev: Nuke FBINFO_MODULE
On Thursday, July 13, 2017 04:01:50 PM Bartlomiej Zolnierkiewicz wrote: > On Wednesday, July 12, 2017 05:07:42 PM Daniel Vetter wrote: > > On Wed, Jul 12, 2017 at 2:54 PM, Bartlomiej Zolnierkiewicz > > wrote: > > > On Wednesday, July 12, 2017 02:42:14 PM Daniel Vetter wrote: > > >> On Wed, Jul 12, 2017 at 12:41:34PM +0200, Bartlomiej Zolnierkiewicz > > >> wrote: > > >> > On Tuesday, July 11, 2017 04:52:19 PM Daniel Vetter wrote: > > >> > > Instead check info->ops->owner, which amounts to the same. > > >> > > > > >> > > Spotted because I want to remove the pile of broken and cargo-culted > > >> > > fb_info->flags assignments in drm drivers. > > >> > > > > >> > > v2: Fixup matrox (reported by kbuild). Also nuke FBINFO_FLAG_* > > >> > > defines > > >> > > that I've failed to spot. > > >> > > > > >> > > v3: Don't nuke FBINFO_FLAG_DEFAULT, that's used all over the place. > > >> > > > > >> > > Cc: Bartlomiej Zolnierkiewicz > > >> > > Cc: linux-fb...@vger.kernel.org > > >> > > Signed-off-by: Daniel Vetter > > >> > > > >> > Acked-by: Bartlomiej Zolnierkiewicz > > >> > > >> Do you plan to pick these two patches up yourself, or do you expect me to > > >> merge them? > > > > > > Since the original patchset contained DRM changes (two last patches) > > > depending on fbdev changes (two first patches, the patch being discussed > > > was the second one) I assumed that you would like to take them all > > > through DRM tree. If this is not what is preferred, please tell me. > > > > There's no direct depency between 1&2 and 3&4, the only effect of > > merging them through separate trees is that the bootup logo might not > > show up when it's expected, until the trees are merged together. We > > could merge them through separate trees if you prefer that (I forgot > > to mention that in the cover letter), but I'm fine with putting them > > all into drm-misc with your ack for 4.14. > > > > Whatever you prefer, I don't mind either way. > > Then I will merge patches 1&2 for v4.14 through fbdev tree (there are > some other changes pending touching fbdev core and I would like to avoid > conflicts between fbdev & drm-misc trees). Thanks! Patch queued for 4.14, thanks. Best regards, -- Bartlomiej Zolnierkiewicz Samsung R&D Institute Poland Samsung Electronics ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] fbcon: Make fbcon a built-time depency for fbdev
On Wednesday, July 12, 2017 12:40:45 PM Bartlomiej Zolnierkiewicz wrote: > On Thursday, July 06, 2017 02:57:32 PM Daniel Vetter wrote: > > There's a bunch of folks who're trying to make printk less > > contended and faster, but there's a problem: printk uses the > > console_lock, and the console lock has become the BKL for all things > > fbdev/fbcon, which in turn pulled in half the drm subsystem under that > > lock. That's awkward. > > > > There reasons for that is probably just a historical accident: > > > > - fbcon is a runtime option of fbdev, i.e. at runtime you can pick > > whether your fbdev driver instances are used as kernel consoles. > > Unfortunately this wasn't implemented with some module option, but > > through some module loading magic: As long as you don't load > > fbcon.ko, there's no fbdev console support, but loading it (in any > > order wrt fbdev drivers) will create console instances for all fbdev > > drivers. > > > > - This was implemented through a notifier chain. fbcon.ko enumerates > > all fbdev instances at load time and also registers itself as > > listener in the fbdev notifier. The fbdev core tries to register new > > fbdev instances with fbcon using the notifier. > > > > - On top of that the modifier chain is also used at runtime by the > > fbdev subsystem to e.g. control backlights for panels. > > > > - The problem is that the notifier puts a mutex locking context > > between fbdev and fbcon, which mixes up the locking contexts for > > both the runtime usage and the register time usage to notify fbcon. > > And at runtime fbcon (through the fbdev core) might call into the > > notifier from a printk critical section while console_lock is held. > > > > - This means console_lock must be an outer lock for the entire fbdev > > subsystem, which also means it must be acquired when registering a > > new framebuffer driver as the outermost lock since we might call > > into fbcon (through the notifier) which would result in a locking > > inversion if fbcon would acquire the console_lock from its notifier > > callback (which it needs to register the console). > > > > - console_lock can be held anywhere, since printk can be called > > anywhere, and through the above story, plus drm/kms being an fbdev > > driver, we pull in a shocking amount of locking hiercharchy > > underneath the console_lock. Which makes cleaning up printk really > > hard (not even splitting console_lock into an rwsem is all that > > useful due to this). > > > > There's various ways to address this, but the cleanest would be to > > make fbcon a compile-time option, where fbdev directly calls the fbcon > > register functions from register_framebuffer, or dummy static inline > > versions if fbcon is disabled. Maybe augmented with a runtime knob to > > disable fbcon, if that's needed (for debugging perhaps). > > > > But this could break some users who rely on the magic "loading > > fbcon.ko enables/disables fbdev framebuffers at runtime" thing, even > > if that's unlikely. Hence we must be careful: > > > > 1. Create a compile-time dependency between fbcon and fbdev in the > > least minimal way. This is what this patch does. > > > > 2. Wait at least 1 year to give possible users time to scream about > > how we broke their setup. Unlikely, since all distros make fbcon > > compile-in, and embedded platforms only compile stuff they know they > > need anyway. But still. > > > > 3. Convert the notifier to direct functions calls, with dummy static > > inlines if fbcon is disabled. We'll still need the fb notifier for the > > other uses (like backlights), but we can probably move it into the fb > > core (atm it must be built-into vmlinux). > > > > 4. Push console_lock down the call-chain, until it is down in > > console_register again. > > > > 5. Finally start to clean up and rework the printk/console locking. > > > > For context of this saga see > > > > commit 50e244cc793d511b86adea24972f3a7264cae114 > > Author: Alan Cox > > Date: Fri Jan 25 10:28:15 2013 +1000 > > > > fb: rework locking to fix lock ordering on takeover > > > > plus the pile of commits on top that tried to make this all work > > without terminally upsetting lockdep. We've uncovered all this when > > console_lock lockdep annotations where added in > > > > commit daee779718a319ff9f83e1ba3339334ac650bb22 > >
