From mboxrd@z Thu Jan 1 00:00:00 1970 From: Soeren Moch Date: Sun, 20 Dec 2020 20:28:35 +0100 Subject: FW: [PATCH 0/6] video: remove VIDCONSOLE_AS_LCD and VIDCONSOLE_AS_NAME In-Reply-To: <20201208161630.GP32272@bill-the-cat> References: <20201203091549.7031-1-patrick.delaunay@st.com> <9d8e34fa-cd69-f2ac-7d63-0b2da2e382f5@web.de> <27f75682-4527-ffeb-24d3-420e7ff3bd35@foss.st.com> <20201208161630.GP32272@bill-the-cat> Message-ID: <2cb8cd7b-4380-b1dd-4236-c85f0586d77a@web.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 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