| Message ID | 20201203091549.7031-1-patrick.delaunay@st.com |
|---|---|
| Headers | show |
| Series | video: remove VIDCONSOLE_AS_LCD and VIDCONSOLE_AS_NAME | expand |
On 03.12.20 10:15, Patrick Delaunay wrote: > I propose this serie to remove the vidconsole work-around, activated with > the 2 options VIDCONSOLE_AS_LCD and VIDCONSOLE_AS_NAME and cleanup > the associated code in console.c (under #ifdef CONFIG_VIDCONSOLE_AS_LCD) > > This options are now obsolete and they was planned to be > removed around the end of 2020. > > I propose this patchset for v2021.04 even if I don't > test this serie on real boards. I really would like to keep this code for now. On the tbs2910 board this workaround was introduced in the last u-boot release (v2020.10), so there was almost no time for end users to notice the warning and to update there environment. Not every end user installs every new u-boot release, so we really should give more time for this change. This workaround is self-contained, small, easy to maintain, and strictly opt-in. So this workaround hurts nobody, but removing this will let users alone without any HDMI output. So on this board (without included serial console port), this will result in unhappy users, especially since without any console output there is no chance to get any idea what is going wrong. Thanks, Soeren > > Patrick. > > > > Patrick Delaunay (6): > tbs2910: configs: remove VIDCONSOLE_AS_LCD > peach-pit: configs: remove VIDCONSOLE_AS_LCD > snow: configs: remove VIDCONSOLE_AS_LCD > peach-pi: configs: remove VIDCONSOLE_AS_LCD > spring: configs: remove VIDCONSOLE_AS_LCD > video: remove VIDCONSOLE_AS_LCD and VIDCONSOLE_AS_NAME > > common/console.c | 10 ---------- > configs/peach-pi_defconfig | 1 - > configs/peach-pit_defconfig | 1 - > configs/snow_defconfig | 1 - > configs/spring_defconfig | 1 - > configs/tbs2910_defconfig | 1 - > drivers/video/Kconfig | 22 ---------------------- > 7 files changed, 37 deletions(-) >
Hi Soeren, > From: Soeren Moch <smoch@web.de> Sent: dimanche 6 décembre 2020 20:59 > On 03.12.20 10:15, Patrick Delaunay wrote: > >> I propose this serie to remove the vidconsole work-around, activated >> with the 2 options VIDCONSOLE_AS_LCD and VIDCONSOLE_AS_NAME and >> cleanup the associated code in console.c (under #ifdef >> CONFIG_VIDCONSOLE_AS_LCD) This options are now obsolete and they was >> planned to be removed around the end of 2020. I propose this patchset >> for v2021.04 even if I don't test this serie on real boards. >> > I really would like to keep this code for now. > I propose to remove these options because they are indicated obsolete in the config description in drivers/video/Kconfig (I see it during code review): "This option will be removed around the end of 2020" But I have no issue to kept it. > On the tbs2910 board this workaround was introduced in the last u-boot > release (v2020.10), so there was almost no time for end users to > notice the warning and to update there environment. Not every end user > installs every new u-boot release, so we really should give more time > for this change. > I agree that for your project, with migration to DM_VIDEO it is a really short notice. commit 645d39aea367064868dcdd30c411806f4403b67b board: tbs2910: Fix video output with existing environments => only integrated in v2020.10-rc2, sorry to miss it > This workaround is self-contained, small, easy to maintain, and > strictly opt-in. So this workaround hurts nobody, but removing this > will let users alone without any HDMI output. So on this board > (without included serial console port), this will result in unhappy > users, especially since without any console output there is no chance > to get any idea what is going wrong. > Initially, I proposed this patch to cleanup the console.c code with 2 other series: 1) http://patchwork.ozlabs.org/project/uboot/list/?series=218309 "console: remove #ifdef CONFIG when it is possible" 2) http://patchwork.ozlabs.org/project/uboot/list/?series=218089 "console: cosmetics: remove #if 0" And I just want just to remove the remaining "#ifdef CONFIG_...." in console.c But I agree that I need to change my proposal to remove this workaround code (it is only use to help the DM VIDEO migration for existing board) and change the release target. I propose to : - remove patch 1/6 of the serie for your board - no more remove the options in 6/6 but add warning in Makefile when the option is activated and change target in config desciption ifeq ($(CONFIG_VIDCONSOLE_AS_LCD),y) @echo >&2 "===================== WARNING ======================" @echo >&2 "This board does use CONFIG_VIDCONSOLE_AS_LCD workaround." @echo >&2 "Please update the existing user defined environments before " @echo >&2 "v2022.01 release." @echo >&2 "Failure to update by the deadline may result in video console" @echo >&2 "issue when this woarkaround will be removed." @echo >&2 "====================================================" endif => open point: which acceptable target to remove this feature ? v2022.01 ? Anyway, if the the maintainers (video or console) think this code should be kept, I can also drop this serie. Thanks. Patrick
On Tue, Dec 08, 2020 at 03:30:43PM +0100, Patrick DELAUNAY wrote: > Hi Soeren, > > > From: Soeren Moch <smoch@web.de> Sent: dimanche 6 décembre 2020 20:59 On > > 03.12.20 10:15, Patrick Delaunay wrote: > > > > > I propose this serie to remove the vidconsole work-around, activated > > > with the 2 options VIDCONSOLE_AS_LCD and VIDCONSOLE_AS_NAME and > > > cleanup the associated code in console.c (under #ifdef > > > CONFIG_VIDCONSOLE_AS_LCD) This options are now obsolete and they was > > > planned to be removed around the end of 2020. I propose this > > > patchset for v2021.04 even if I don't test this serie on real > > > boards. > > > > > I really would like to keep this code for now. > > > I propose to remove these options because they are indicated obsolete in the > config description > > in drivers/video/Kconfig (I see it during code review): > > "This option will be removed around the end of 2020" > > But I have no issue to kept it. > > > On the tbs2910 board this workaround was introduced in the last u-boot > > release (v2020.10), so there was almost no time for end users to notice > > the warning and to update there environment. Not every end user installs > > every new u-boot release, so we really should give more time for this > > change. > > > I agree that for your project, with migration to DM_VIDEO it is a really > short notice. > > commit 645d39aea367064868dcdd30c411806f4403b67b > > board: tbs2910: Fix video output with existing environments > > => only integrated in v2020.10-rc2, sorry to miss it > > > This workaround is self-contained, small, easy to maintain, and strictly > > opt-in. So this workaround hurts nobody, but removing this will let > > users alone without any HDMI output. So on this board (without included > > serial console port), this will result in unhappy users, especially > > since without any console output there is no chance to get any idea what > > is going wrong. > > > Initially, I proposed this patch to cleanup the console.c code with 2 other > series: > > 1) http://patchwork.ozlabs.org/project/uboot/list/?series=218309 > > "console: remove #ifdef CONFIG when it is possible" > > 2) http://patchwork.ozlabs.org/project/uboot/list/?series=218089 > > "console: cosmetics: remove #if 0" > > > And I just want just to remove the remaining "#ifdef CONFIG_...." in > console.c > > > But I agree that I need to change my proposal to remove this workaround code > > (it is only use to help the DM VIDEO migration for existing board) > > and change the release target. > > > I propose to : > > - remove patch 1/6 of the serie for your board > > - no more remove the options in 6/6 but add warning in Makefile when the > option is activated > > and change target in config desciption > > > ifeq ($(CONFIG_VIDCONSOLE_AS_LCD),y) > @echo >&2 "===================== WARNING ======================" > @echo >&2 "This board does use CONFIG_VIDCONSOLE_AS_LCD workaround." > @echo >&2 "Please update the existing user defined environments before " > @echo >&2 "v2022.01 release." > @echo >&2 "Failure to update by the deadline may result in video > console" > > @echo >&2 "issue when this woarkaround will be removed." > @echo >&2 "====================================================" > endif > > => open point: which acceptable target to remove this feature ? v2022.01 ? This sounds like a good plan and reasonable date to me. Anatolij? Thanks!
On 08.12.20 17:16, Tom Rini wrote: > On Tue, Dec 08, 2020 at 03:30:43PM +0100, Patrick DELAUNAY wrote: >> Hi Soeren, >> >>> From: Soeren Moch <smoch@web.de> Sent: dimanche 6 décembre 2020 20:59 On >>> 03.12.20 10:15, Patrick Delaunay wrote: >>> >>>> I propose this serie to remove the vidconsole work-around, activated >>>> with the 2 options VIDCONSOLE_AS_LCD and VIDCONSOLE_AS_NAME and >>>> cleanup the associated code in console.c (under #ifdef >>>> CONFIG_VIDCONSOLE_AS_LCD) This options are now obsolete and they was >>>> planned to be removed around the end of 2020. I propose this >>>> patchset for v2021.04 even if I don't test this serie on real >>>> boards. >>>> >>> I really would like to keep this code for now. >>> >> I propose to remove these options because they are indicated obsolete in the >> config description >> >> in drivers/video/Kconfig (I see it during code review): >> >> "This option will be removed around the end of 2020" >> >> But I have no issue to kept it. >> >>> On the tbs2910 board this workaround was introduced in the last u-boot >>> release (v2020.10), so there was almost no time for end users to notice >>> the warning and to update there environment. Not every end user installs >>> every new u-boot release, so we really should give more time for this >>> change. >>> >> I agree that for your project, with migration to DM_VIDEO it is a really >> short notice. >> >> commit 645d39aea367064868dcdd30c411806f4403b67b >> >> board: tbs2910: Fix video output with existing environments >> >> => only integrated in v2020.10-rc2, sorry to miss it >> >>> This workaround is self-contained, small, easy to maintain, and strictly >>> opt-in. So this workaround hurts nobody, but removing this will let >>> users alone without any HDMI output. So on this board (without included >>> serial console port), this will result in unhappy users, especially >>> since without any console output there is no chance to get any idea what >>> is going wrong. >>> >> Initially, I proposed this patch to cleanup the console.c code with 2 other >> series: >> >> 1) http://patchwork.ozlabs.org/project/uboot/list/?series=218309 >> >> "console: remove #ifdef CONFIG when it is possible" >> >> 2) http://patchwork.ozlabs.org/project/uboot/list/?series=218089 >> >> "console: cosmetics: remove #if 0" >> >> >> And I just want just to remove the remaining "#ifdef CONFIG_...." in >> console.c >> >> >> But I agree that I need to change my proposal to remove this workaround code >> >> (it is only use to help the DM VIDEO migration for existing board) >> >> and change the release target. >> >> >> I propose to : >> >> - remove patch 1/6 of the serie for your board >> >> - no more remove the options in 6/6 but add warning in Makefile when the >> option is activated >> >> and change target in config desciption >> >> >> ifeq ($(CONFIG_VIDCONSOLE_AS_LCD),y) >> @echo >&2 "===================== WARNING ======================" >> @echo >&2 "This board does use CONFIG_VIDCONSOLE_AS_LCD workaround." >> @echo >&2 "Please update the existing user defined environments before " >> @echo >&2 "v2022.01 release." >> @echo >&2 "Failure to update by the deadline may result in video >> console" >> >> @echo >&2 "issue when this woarkaround will be removed." >> @echo >&2 "====================================================" >> endif >> >> => open point: which acceptable target to remove this feature ? v2022.01 ? > This sounds like a good plan and reasonable date to me. Anatolij? > Thanks! > Probably board users will not pay much attention to the build warning, hopefully more to the console output warning. Nevertheless, the proposed plan sounds like a good idea to me. Thanks, Soeren
On Tue, 8 Dec 2020 11:16:30 -0500 Tom Rini trini@konsulko.com wrote: ... > > => open point: which acceptable target to remove this feature ? v2022.01 ? > > This sounds like a good plan and reasonable date to me. Anatolij? I have no objection, this target date is okay for me. -- Anatolij
On Sun, Dec 20, 2020 at 10:14:06PM +0100, Anatolij Gustschin wrote: > On Tue, 8 Dec 2020 11:16:30 -0500 > Tom Rini trini@konsulko.com wrote: > ... > > > => open point: which acceptable target to remove this feature ? v2022.01 ? > > > > This sounds like a good plan and reasonable date to me. Anatolij? > > I have no objection, this target date is okay for me. Can you please make up the patch for noting this, etc? Thanks!