[PATCH] Nokia RX-51: Convert to CONFIG_DM_KEYBOARD
Signed-off-by: Pali Rohár pali@kernel.org ---
I would really appreciate if U-Boot test framework starts printing deprecation warnings, instead of sending patches which directly drop support for some boards.
There is absolutely no warning during building U-Boot for RX-51 board that this board has not been converted to DM_KEYBOARD yet.
--- board/nokia/rx51/rx51.c | 37 +++++++++++++++++++++++++++++++----- configs/nokia_rx51_defconfig | 2 +- include/configs/nokia_rx51.h | 13 +------------ 3 files changed, 34 insertions(+), 18 deletions(-)
diff --git a/board/nokia/rx51/rx51.c b/board/nokia/rx51/rx51.c index 99ca36fbbea1..a52691509da4 100644 --- a/board/nokia/rx51/rx51.c +++ b/board/nokia/rx51/rx51.c @@ -31,6 +31,7 @@ #include <twl4030.h> #include <i2c.h> #include <video_fb.h> +#include <keyboard.h> #include <asm/global_data.h> #include <asm/io.h> #include <asm/setup.h> @@ -579,10 +580,10 @@ static u8 keybuf_head; static u8 keybuf_tail;
/* - * Routine: rx51_kp_init + * Routine: rx51_kp_start * Description: Initialize HW keyboard. */ -int rx51_kp_init(void) +static int rx51_kp_start(struct udevice *dev) { int ret = 0; u8 ctrl; @@ -656,7 +657,7 @@ static void rx51_kp_fill(u8 k, u8 mods) * Routine: rx51_kp_tstc * Description: Test if key was pressed (from buffer). */ -int rx51_kp_tstc(struct stdio_dev *sdev) +static int rx51_kp_tstc(struct udevice *dev) { u8 c, r, dk, i; u8 intr; @@ -712,14 +713,36 @@ int rx51_kp_tstc(struct stdio_dev *sdev) * Routine: rx51_kp_getc * Description: Get last pressed key (from buffer). */ -int rx51_kp_getc(struct stdio_dev *sdev) +static int rx51_kp_getc(struct udevice *dev) { keybuf_head %= KEYBUF_SIZE; - while (!rx51_kp_tstc(sdev)) + while (!rx51_kp_tstc(dev)) WATCHDOG_RESET(); return keybuf[keybuf_head++]; }
+static int rx51_kp_probe(struct udevice *dev) +{ + struct keyboard_priv *uc_priv = dev_get_uclass_priv(dev); + struct stdio_dev *sdev = &uc_priv->sdev; + + strcpy(sdev->name, "keyboard"); + return input_stdio_register(sdev); +} + +static const struct keyboard_ops rx51_kp_ops = { + .start = rx51_kp_start, + .tstc = rx51_kp_tstc, + .getc = rx51_kp_getc, +}; + +U_BOOT_DRIVER(rx51_kp) = { + .name = "rx51_kp", + .id = UCLASS_KEYBOARD, + .probe = rx51_kp_probe, + .ops = &rx51_kp_ops, +}; + static const struct mmc_config rx51_mmc_cfg = { .host_caps = MMC_MODE_4BIT | MMC_MODE_HS_52MHz | MMC_MODE_HS, .f_min = 400000, @@ -753,3 +776,7 @@ U_BOOT_DRVINFOS(rx51_i2c) = { U_BOOT_DRVINFOS(rx51_watchdog) = { { "rx51_watchdog" }, }; + +U_BOOT_DRVINFOS(rx51_kp) = { + { "rx51_kp" }, +}; diff --git a/configs/nokia_rx51_defconfig b/configs/nokia_rx51_defconfig index 4a95f42e4eb4..47b7bc3b4f03 100644 --- a/configs/nokia_rx51_defconfig +++ b/configs/nokia_rx51_defconfig @@ -66,6 +66,7 @@ CONFIG_DM=y # CONFIG_DM_SEQ_ALIAS is not set # CONFIG_BLOCK_CACHE is not set CONFIG_DM_I2C=y +CONFIG_DM_KEYBOARD=y # CONFIG_MMC_HW_PARTITIONING is not set # CONFIG_MMC_VERBOSE is not set CONFIG_MMC_OMAP_HS=y @@ -78,7 +79,6 @@ CONFIG_USB_MUSB_UDC=y CONFIG_USB_OMAP3=y CONFIG_CFB_CONSOLE=y CONFIG_CFB_CONSOLE_ANSI=y -# CONFIG_VGA_AS_SINGLE_DEVICE is not set CONFIG_SPLASH_SCREEN=y CONFIG_WATCHDOG_TIMEOUT_MSECS=31000 CONFIG_WDT=y diff --git a/include/configs/nokia_rx51.h b/include/configs/nokia_rx51.h index adfc055a2c9e..9be64c3d3f87 100644 --- a/include/configs/nokia_rx51.h +++ b/include/configs/nokia_rx51.h @@ -77,21 +77,10 @@ #define VIDEO_FB_16BPP_PIXEL_SWAP #define VIDEO_FB_16BPP_WORD_SWAP
-/* functions for cfb_console */ -#define VIDEO_KBD_INIT_FCT rx51_kp_init() -#define VIDEO_TSTC_FCT rx51_kp_tstc -#define VIDEO_GETC_FCT rx51_kp_getc -#ifndef __ASSEMBLY__ -struct stdio_dev; -int rx51_kp_init(void); -int rx51_kp_tstc(struct stdio_dev *sdev); -int rx51_kp_getc(struct stdio_dev *sdev); -#endif - /* Environment information */ #define CONFIG_EXTRA_ENV_SETTINGS \ "usbtty=cdc_acm\0" \ - "stdin=usbtty,serial,vga\0" \ + "stdin=usbtty,serial,keyboard\0" \ "stdout=usbtty,serial,vga\0" \ "stderr=usbtty,serial,vga\0" \ "slide=gpio input " __stringify(GPIO_SLIDE) "\0" \
On Thu, Feb 03, 2022 at 07:38:50PM +0100, Pali Rohár wrote:
Signed-off-by: Pali Rohár pali@kernel.org
I would really appreciate if U-Boot test framework starts printing deprecation warnings, instead of sending patches which directly drop support for some boards.
There is absolutely no warning during building U-Boot for RX-51 board that this board has not been converted to DM_KEYBOARD yet.
Please send some patch that implements what you're wanting to see for how to make the warnings more visible. I do agree the warning for v2022.10 only showed up after the merge to -next once v2022.01 came out, but it's still a fairly long time to clean up the few unconverted boards.
On Thu, Feb 03, 2022 at 04:16:23PM -0500, Tom Rini wrote:
On Thu, Feb 03, 2022 at 07:38:50PM +0100, Pali Rohár wrote:
Signed-off-by: Pali Rohár pali@kernel.org
I would really appreciate if U-Boot test framework starts printing deprecation warnings, instead of sending patches which directly drop support for some boards.
There is absolutely no warning during building U-Boot for RX-51 board that this board has not been converted to DM_KEYBOARD yet.
Please send some patch that implements what you're wanting to see for how to make the warnings more visible. I do agree the warning for v2022.10 only showed up after the merge to -next once v2022.01 came out, but it's still a fairly long time to clean up the few unconverted boards.
Oh, I see what's going on. Simon, the DM_KEYBOARD check isn't triggering for any boards. I'll look more.
On Thu, Feb 03, 2022 at 04:45:44PM -0500, Tom Rini wrote:
On Thu, Feb 03, 2022 at 04:16:23PM -0500, Tom Rini wrote:
On Thu, Feb 03, 2022 at 07:38:50PM +0100, Pali Rohár wrote:
Signed-off-by: Pali Rohár pali@kernel.org
I would really appreciate if U-Boot test framework starts printing deprecation warnings, instead of sending patches which directly drop support for some boards.
There is absolutely no warning during building U-Boot for RX-51 board that this board has not been converted to DM_KEYBOARD yet.
Please send some patch that implements what you're wanting to see for how to make the warnings more visible. I do agree the warning for v2022.10 only showed up after the merge to -next once v2022.01 came out, but it's still a fairly long time to clean up the few unconverted boards.
Oh, I see what's going on. Simon, the DM_KEYBOARD check isn't triggering for any boards. I'll look more.
And here's where we're at. nokia_rx51 doesn't set CONFIG_KEYBOARD, so didn't trigger the warning about migration. Every platform that sets CONFIG_KEYBOARD is migrated. I don't know how many other platforms are in the situation nokia_rx51 is in. Yanking out the legacy code and seeing what fails to build, and going from there is probably the next option.
Hi,
On Thu, 3 Feb 2022 at 14:53, Tom Rini trini@konsulko.com wrote:
On Thu, Feb 03, 2022 at 04:45:44PM -0500, Tom Rini wrote:
On Thu, Feb 03, 2022 at 04:16:23PM -0500, Tom Rini wrote:
On Thu, Feb 03, 2022 at 07:38:50PM +0100, Pali Rohár wrote:
Signed-off-by: Pali Rohár pali@kernel.org
I would really appreciate if U-Boot test framework starts printing deprecation warnings, instead of sending patches which directly drop support for some boards.
There is absolutely no warning during building U-Boot for RX-51 board that this board has not been converted to DM_KEYBOARD yet.
Please send some patch that implements what you're wanting to see for how to make the warnings more visible. I do agree the warning for v2022.10 only showed up after the merge to -next once v2022.01 came out, but it's still a fairly long time to clean up the few unconverted boards.
Oh, I see what's going on. Simon, the DM_KEYBOARD check isn't triggering for any boards. I'll look more.
And here's where we're at. nokia_rx51 doesn't set CONFIG_KEYBOARD, so didn't trigger the warning about migration. Every platform that sets CONFIG_KEYBOARD is migrated. I don't know how many other platforms are in the situation nokia_rx51 is in. Yanking out the legacy code and seeing what fails to build, and going from there is probably the next option.
Yes.
As to your questoin, none that I know of. I sent a series to drop cfb_console which was how this used to work, although in fact it hasn't worked for a while. The problem here seems to be that this board was multiple migrations behind and so was not caught.
We should be able to remove the migration check.
Pali, just to explain from the other POV, I am finding it increasingly frustrating dealing with ad-hoc CONFIG options, old drivers, etc. We really need to complete some of the migrations we started 6 years ago.
Regards, Simon
Hi,
On Thu, 3 Feb 2022 at 15:02, Simon Glass sjg@chromium.org wrote:
Hi,
On Thu, 3 Feb 2022 at 14:53, Tom Rini trini@konsulko.com wrote:
On Thu, Feb 03, 2022 at 04:45:44PM -0500, Tom Rini wrote:
On Thu, Feb 03, 2022 at 04:16:23PM -0500, Tom Rini wrote:
On Thu, Feb 03, 2022 at 07:38:50PM +0100, Pali Rohár wrote:
Signed-off-by: Pali Rohár pali@kernel.org
I would really appreciate if U-Boot test framework starts printing deprecation warnings, instead of sending patches which directly drop support for some boards.
There is absolutely no warning during building U-Boot for RX-51 board that this board has not been converted to DM_KEYBOARD yet.
Please send some patch that implements what you're wanting to see for how to make the warnings more visible. I do agree the warning for v2022.10 only showed up after the merge to -next once v2022.01 came out, but it's still a fairly long time to clean up the few unconverted boards.
Oh, I see what's going on. Simon, the DM_KEYBOARD check isn't triggering for any boards. I'll look more.
And here's where we're at. nokia_rx51 doesn't set CONFIG_KEYBOARD, so didn't trigger the warning about migration. Every platform that sets CONFIG_KEYBOARD is migrated. I don't know how many other platforms are in the situation nokia_rx51 is in. Yanking out the legacy code and seeing what fails to build, and going from there is probably the next option.
Yes.
As to your questoin, none that I know of. I sent a series to drop cfb_console which was how this used to work, although in fact it hasn't worked for a while. The problem here seems to be that this board was multiple migrations behind and so was not caught.
We should be able to remove the migration check.
Pali, just to explain from the other POV, I am finding it increasingly frustrating dealing with ad-hoc CONFIG options, old drivers, etc. We really need to complete some of the migrations we started 6 years ago.
BTW the keyboard driver should go in drivers/input and should use device tree, not platdata.
Regards, Simon
On Thu, Feb 03, 2022 at 03:03:21PM -0700, Simon Glass wrote:
Hi,
On Thu, 3 Feb 2022 at 15:02, Simon Glass sjg@chromium.org wrote:
Hi,
On Thu, 3 Feb 2022 at 14:53, Tom Rini trini@konsulko.com wrote:
On Thu, Feb 03, 2022 at 04:45:44PM -0500, Tom Rini wrote:
On Thu, Feb 03, 2022 at 04:16:23PM -0500, Tom Rini wrote:
On Thu, Feb 03, 2022 at 07:38:50PM +0100, Pali Rohár wrote:
Signed-off-by: Pali Rohár pali@kernel.org
I would really appreciate if U-Boot test framework starts printing deprecation warnings, instead of sending patches which directly drop support for some boards.
There is absolutely no warning during building U-Boot for RX-51 board that this board has not been converted to DM_KEYBOARD yet.
Please send some patch that implements what you're wanting to see for how to make the warnings more visible. I do agree the warning for v2022.10 only showed up after the merge to -next once v2022.01 came out, but it's still a fairly long time to clean up the few unconverted boards.
Oh, I see what's going on. Simon, the DM_KEYBOARD check isn't triggering for any boards. I'll look more.
And here's where we're at. nokia_rx51 doesn't set CONFIG_KEYBOARD, so didn't trigger the warning about migration. Every platform that sets CONFIG_KEYBOARD is migrated. I don't know how many other platforms are in the situation nokia_rx51 is in. Yanking out the legacy code and seeing what fails to build, and going from there is probably the next option.
Yes.
As to your questoin, none that I know of. I sent a series to drop cfb_console which was how this used to work, although in fact it hasn't worked for a while. The problem here seems to be that this board was multiple migrations behind and so was not caught.
We should be able to remove the migration check.
Pali, just to explain from the other POV, I am finding it increasingly frustrating dealing with ad-hoc CONFIG options, old drivers, etc. We really need to complete some of the migrations we started 6 years ago.
BTW the keyboard driver should go in drivers/input and should use device tree, not platdata.
This is likely one of the cases where we end up saying a platform is only platdata, given size concerns? That's my quick recollection from talking about the USB stuff a few months back, and some other related size questions.
Hi Tom,
On Thu, 3 Feb 2022 at 15:09, Tom Rini trini@konsulko.com wrote:
On Thu, Feb 03, 2022 at 03:03:21PM -0700, Simon Glass wrote:
Hi,
On Thu, 3 Feb 2022 at 15:02, Simon Glass sjg@chromium.org wrote:
Hi,
On Thu, 3 Feb 2022 at 14:53, Tom Rini trini@konsulko.com wrote:
On Thu, Feb 03, 2022 at 04:45:44PM -0500, Tom Rini wrote:
On Thu, Feb 03, 2022 at 04:16:23PM -0500, Tom Rini wrote:
On Thu, Feb 03, 2022 at 07:38:50PM +0100, Pali Rohár wrote:
> Signed-off-by: Pali Rohár pali@kernel.org > --- > > I would really appreciate if U-Boot test framework starts printing > deprecation warnings, instead of sending patches which directly drop > support for some boards. > > There is absolutely no warning during building U-Boot for RX-51 board > that this board has not been converted to DM_KEYBOARD yet.
Please send some patch that implements what you're wanting to see for how to make the warnings more visible. I do agree the warning for v2022.10 only showed up after the merge to -next once v2022.01 came out, but it's still a fairly long time to clean up the few unconverted boards.
Oh, I see what's going on. Simon, the DM_KEYBOARD check isn't triggering for any boards. I'll look more.
And here's where we're at. nokia_rx51 doesn't set CONFIG_KEYBOARD, so didn't trigger the warning about migration. Every platform that sets CONFIG_KEYBOARD is migrated. I don't know how many other platforms are in the situation nokia_rx51 is in. Yanking out the legacy code and seeing what fails to build, and going from there is probably the next option.
Yes.
As to your questoin, none that I know of. I sent a series to drop cfb_console which was how this used to work, although in fact it hasn't worked for a while. The problem here seems to be that this board was multiple migrations behind and so was not caught.
We should be able to remove the migration check.
Pali, just to explain from the other POV, I am finding it increasingly frustrating dealing with ad-hoc CONFIG options, old drivers, etc. We really need to complete some of the migrations we started 6 years ago.
BTW the keyboard driver should go in drivers/input and should use device tree, not platdata.
This is likely one of the cases where we end up saying a platform is only platdata, given size concerns? That's my quick recollection from talking about the USB stuff a few months back, and some other related size questions.
OK, I see. Yes, device tree would add a lot (in fact it doesn't even use OF_CONTROL).
Regards, Simon
On Thursday 03 February 2022 15:10:58 Simon Glass wrote:
Hi Tom,
On Thu, 3 Feb 2022 at 15:09, Tom Rini trini@konsulko.com wrote:
On Thu, Feb 03, 2022 at 03:03:21PM -0700, Simon Glass wrote:
Hi,
On Thu, 3 Feb 2022 at 15:02, Simon Glass sjg@chromium.org wrote:
Hi,
On Thu, 3 Feb 2022 at 14:53, Tom Rini trini@konsulko.com wrote:
On Thu, Feb 03, 2022 at 04:45:44PM -0500, Tom Rini wrote:
On Thu, Feb 03, 2022 at 04:16:23PM -0500, Tom Rini wrote: > On Thu, Feb 03, 2022 at 07:38:50PM +0100, Pali Rohár wrote: > > > Signed-off-by: Pali Rohár pali@kernel.org > > --- > > > > I would really appreciate if U-Boot test framework starts printing > > deprecation warnings, instead of sending patches which directly drop > > support for some boards. > > > > There is absolutely no warning during building U-Boot for RX-51 board > > that this board has not been converted to DM_KEYBOARD yet. > > Please send some patch that implements what you're wanting to see for > how to make the warnings more visible. I do agree the warning for > v2022.10 only showed up after the merge to -next once v2022.01 came out, > but it's still a fairly long time to clean up the few unconverted > boards.
Oh, I see what's going on. Simon, the DM_KEYBOARD check isn't triggering for any boards. I'll look more.
And here's where we're at. nokia_rx51 doesn't set CONFIG_KEYBOARD, so didn't trigger the warning about migration. Every platform that sets CONFIG_KEYBOARD is migrated. I don't know how many other platforms are in the situation nokia_rx51 is in. Yanking out the legacy code and seeing what fails to build, and going from there is probably the next option.
Yes.
As to your questoin, none that I know of. I sent a series to drop cfb_console which was how this used to work, although in fact it hasn't worked for a while. The problem here seems to be that this board was multiple migrations behind and so was not caught.
We should be able to remove the migration check.
Pali, just to explain from the other POV, I am finding it increasingly frustrating dealing with ad-hoc CONFIG options, old drivers, etc. We really need to complete some of the migrations we started 6 years ago.
BTW the keyboard driver should go in drivers/input and should use device tree, not platdata.
This is likely one of the cases where we end up saying a platform is only platdata, given size concerns? That's my quick recollection from talking about the USB stuff a few months back, and some other related size questions.
OK, I see. Yes, device tree would add a lot (in fact it doesn't even use OF_CONTROL).
Regards, Simon
Yes, there is no OF_CONTROL, no device tree, just plat data, because all those options eats too many space... There was already discussion about it in past and it is not possible to do anything with it.
As keyboard support was in board code before, I let it in board code as I do not see any value to move this code into drivers/input as it is board specific.
On Thursday 03 February 2022 15:02:02 Simon Glass wrote:
Hi,
On Thu, 3 Feb 2022 at 14:53, Tom Rini trini@konsulko.com wrote:
On Thu, Feb 03, 2022 at 04:45:44PM -0500, Tom Rini wrote:
On Thu, Feb 03, 2022 at 04:16:23PM -0500, Tom Rini wrote:
On Thu, Feb 03, 2022 at 07:38:50PM +0100, Pali Rohár wrote:
Signed-off-by: Pali Rohár pali@kernel.org
I would really appreciate if U-Boot test framework starts printing deprecation warnings, instead of sending patches which directly drop support for some boards.
There is absolutely no warning during building U-Boot for RX-51 board that this board has not been converted to DM_KEYBOARD yet.
Please send some patch that implements what you're wanting to see for how to make the warnings more visible. I do agree the warning for v2022.10 only showed up after the merge to -next once v2022.01 came out, but it's still a fairly long time to clean up the few unconverted boards.
Oh, I see what's going on. Simon, the DM_KEYBOARD check isn't triggering for any boards. I'll look more.
And here's where we're at. nokia_rx51 doesn't set CONFIG_KEYBOARD, so didn't trigger the warning about migration. Every platform that sets CONFIG_KEYBOARD is migrated. I don't know how many other platforms are in the situation nokia_rx51 is in. Yanking out the legacy code and seeing what fails to build, and going from there is probably the next option.
Yes.
As to your questoin, none that I know of. I sent a series to drop cfb_console which was how this used to work, although in fact it hasn't worked for a while. The problem here seems to be that this board was multiple migrations behind and so was not caught.
It is not truth that cfb_console has not worked. This driver is / was working fine on n900 without any issues.
We should be able to remove the migration check.
Pali, just to explain from the other POV, I am finding it increasingly frustrating dealing with ad-hoc CONFIG options, old drivers, etc. We really need to complete some of the migrations we started 6 years ago.
Regards, Simon
Well, I see and understand you. But as I explained it more times, it was me who is/was waiting for review of n900 patches and I was not able to speed up review process. There was always some n900 patch in waiting state.
Now when pending n900 patches were reviewed and merged, I prepared and sent another one -- this DM_KEYBOARD which removes one part of cfb_console code from n900 board code.
On Fri, Feb 04, 2022 at 11:56:52AM +0100, Pali Rohár wrote:
On Thursday 03 February 2022 15:02:02 Simon Glass wrote:
Hi,
On Thu, 3 Feb 2022 at 14:53, Tom Rini trini@konsulko.com wrote:
On Thu, Feb 03, 2022 at 04:45:44PM -0500, Tom Rini wrote:
On Thu, Feb 03, 2022 at 04:16:23PM -0500, Tom Rini wrote:
On Thu, Feb 03, 2022 at 07:38:50PM +0100, Pali Rohár wrote:
Signed-off-by: Pali Rohár pali@kernel.org
I would really appreciate if U-Boot test framework starts printing deprecation warnings, instead of sending patches which directly drop support for some boards.
There is absolutely no warning during building U-Boot for RX-51 board that this board has not been converted to DM_KEYBOARD yet.
Please send some patch that implements what you're wanting to see for how to make the warnings more visible. I do agree the warning for v2022.10 only showed up after the merge to -next once v2022.01 came out, but it's still a fairly long time to clean up the few unconverted boards.
Oh, I see what's going on. Simon, the DM_KEYBOARD check isn't triggering for any boards. I'll look more.
And here's where we're at. nokia_rx51 doesn't set CONFIG_KEYBOARD, so didn't trigger the warning about migration. Every platform that sets CONFIG_KEYBOARD is migrated. I don't know how many other platforms are in the situation nokia_rx51 is in. Yanking out the legacy code and seeing what fails to build, and going from there is probably the next option.
Yes.
As to your questoin, none that I know of. I sent a series to drop cfb_console which was how this used to work, although in fact it hasn't worked for a while. The problem here seems to be that this board was multiple migrations behind and so was not caught.
It is not truth that cfb_console has not worked. This driver is / was working fine on n900 without any issues.
Yes, it's such an old missed migration that there's no check for it.
We should be able to remove the migration check.
Pali, just to explain from the other POV, I am finding it increasingly frustrating dealing with ad-hoc CONFIG options, old drivers, etc. We really need to complete some of the migrations we started 6 years ago.
Regards, Simon
Well, I see and understand you. But as I explained it more times, it was me who is/was waiting for review of n900 patches and I was not able to speed up review process. There was always some n900 patch in waiting state.
Now when pending n900 patches were reviewed and merged, I prepared and sent another one -- this DM_KEYBOARD which removes one part of cfb_console code from n900 board code.
Alright. So, do you see the warning about DM_SERIAL? Are you going to start work on that migration now, or in about a week or two when I pick this up, assuming no changes are requested?
On Friday 04 February 2022 08:41:55 Tom Rini wrote:
On Fri, Feb 04, 2022 at 11:56:52AM +0100, Pali Rohár wrote:
On Thursday 03 February 2022 15:02:02 Simon Glass wrote:
Hi,
On Thu, 3 Feb 2022 at 14:53, Tom Rini trini@konsulko.com wrote:
On Thu, Feb 03, 2022 at 04:45:44PM -0500, Tom Rini wrote:
On Thu, Feb 03, 2022 at 04:16:23PM -0500, Tom Rini wrote:
On Thu, Feb 03, 2022 at 07:38:50PM +0100, Pali Rohár wrote:
> Signed-off-by: Pali Rohár pali@kernel.org > --- > > I would really appreciate if U-Boot test framework starts printing > deprecation warnings, instead of sending patches which directly drop > support for some boards. > > There is absolutely no warning during building U-Boot for RX-51 board > that this board has not been converted to DM_KEYBOARD yet.
Please send some patch that implements what you're wanting to see for how to make the warnings more visible. I do agree the warning for v2022.10 only showed up after the merge to -next once v2022.01 came out, but it's still a fairly long time to clean up the few unconverted boards.
Oh, I see what's going on. Simon, the DM_KEYBOARD check isn't triggering for any boards. I'll look more.
And here's where we're at. nokia_rx51 doesn't set CONFIG_KEYBOARD, so didn't trigger the warning about migration. Every platform that sets CONFIG_KEYBOARD is migrated. I don't know how many other platforms are in the situation nokia_rx51 is in. Yanking out the legacy code and seeing what fails to build, and going from there is probably the next option.
Yes.
As to your questoin, none that I know of. I sent a series to drop cfb_console which was how this used to work, although in fact it hasn't worked for a while. The problem here seems to be that this board was multiple migrations behind and so was not caught.
It is not truth that cfb_console has not worked. This driver is / was working fine on n900 without any issues.
Yes, it's such an old missed migration that there's no check for it.
We should be able to remove the migration check.
Pali, just to explain from the other POV, I am finding it increasingly frustrating dealing with ad-hoc CONFIG options, old drivers, etc. We really need to complete some of the migrations we started 6 years ago.
Regards, Simon
Well, I see and understand you. But as I explained it more times, it was me who is/was waiting for review of n900 patches and I was not able to speed up review process. There was always some n900 patch in waiting state.
Now when pending n900 patches were reviewed and merged, I prepared and sent another one -- this DM_KEYBOARD which removes one part of cfb_console code from n900 board code.
Alright. So, do you see the warning about DM_SERIAL? Are you going to start work on that migration now, or in about a week or two when I pick this up, assuming no changes are requested?
I do not see any warning, neither about DM_SERIAL nor any other in RX-51 test job which builds bootable image for RX-51. See CI link: https://dev.azure.com/u-boot/u-boot/_build/results?buildId=3580&view=log...
But there is CONFIG_DM_SERIAL warning for nokia_rx51 board in the Build the World omap job, see CI link: https://dev.azure.com/u-boot/u-boot/_build/results?buildId=3580&view=log...
After this DM_KEYBOARD patch, I'm planning to look at DM_VIDEO as Simon really wants it and then I can look at DM_SERIAL.
On Fri, Feb 04, 2022 at 02:55:39PM +0100, Pali Rohár wrote:
On Friday 04 February 2022 08:41:55 Tom Rini wrote:
On Fri, Feb 04, 2022 at 11:56:52AM +0100, Pali Rohár wrote:
On Thursday 03 February 2022 15:02:02 Simon Glass wrote:
Hi,
On Thu, 3 Feb 2022 at 14:53, Tom Rini trini@konsulko.com wrote:
On Thu, Feb 03, 2022 at 04:45:44PM -0500, Tom Rini wrote:
On Thu, Feb 03, 2022 at 04:16:23PM -0500, Tom Rini wrote: > On Thu, Feb 03, 2022 at 07:38:50PM +0100, Pali Rohár wrote: > > > Signed-off-by: Pali Rohár pali@kernel.org > > --- > > > > I would really appreciate if U-Boot test framework starts printing > > deprecation warnings, instead of sending patches which directly drop > > support for some boards. > > > > There is absolutely no warning during building U-Boot for RX-51 board > > that this board has not been converted to DM_KEYBOARD yet. > > Please send some patch that implements what you're wanting to see for > how to make the warnings more visible. I do agree the warning for > v2022.10 only showed up after the merge to -next once v2022.01 came out, > but it's still a fairly long time to clean up the few unconverted > boards.
Oh, I see what's going on. Simon, the DM_KEYBOARD check isn't triggering for any boards. I'll look more.
And here's where we're at. nokia_rx51 doesn't set CONFIG_KEYBOARD, so didn't trigger the warning about migration. Every platform that sets CONFIG_KEYBOARD is migrated. I don't know how many other platforms are in the situation nokia_rx51 is in. Yanking out the legacy code and seeing what fails to build, and going from there is probably the next option.
Yes.
As to your questoin, none that I know of. I sent a series to drop cfb_console which was how this used to work, although in fact it hasn't worked for a while. The problem here seems to be that this board was multiple migrations behind and so was not caught.
It is not truth that cfb_console has not worked. This driver is / was working fine on n900 without any issues.
Yes, it's such an old missed migration that there's no check for it.
We should be able to remove the migration check.
Pali, just to explain from the other POV, I am finding it increasingly frustrating dealing with ad-hoc CONFIG options, old drivers, etc. We really need to complete some of the migrations we started 6 years ago.
Regards, Simon
Well, I see and understand you. But as I explained it more times, it was me who is/was waiting for review of n900 patches and I was not able to speed up review process. There was always some n900 patch in waiting state.
Now when pending n900 patches were reviewed and merged, I prepared and sent another one -- this DM_KEYBOARD which removes one part of cfb_console code from n900 board code.
Alright. So, do you see the warning about DM_SERIAL? Are you going to start work on that migration now, or in about a week or two when I pick this up, assuming no changes are requested?
I do not see any warning, neither about DM_SERIAL nor any other in RX-51 test job which builds bootable image for RX-51. See CI link: https://dev.azure.com/u-boot/u-boot/_build/results?buildId=3580&view=log...
But there is CONFIG_DM_SERIAL warning for nokia_rx51 board in the Build the World omap job, see CI link: https://dev.azure.com/u-boot/u-boot/_build/results?buildId=3580&view=log...
It's also visible when just doing "make CROSS_COMPILE=... nokia_rx51_config all" so I guess you need to debug your script and see why it's not showing that?
After this DM_KEYBOARD patch, I'm planning to look at DM_VIDEO as Simon really wants it and then I can look at DM_SERIAL.
OK. But, are you going to start before or after this gets merged?
On Friday 04 February 2022 09:00:55 Tom Rini wrote:
On Fri, Feb 04, 2022 at 02:55:39PM +0100, Pali Rohár wrote:
On Friday 04 February 2022 08:41:55 Tom Rini wrote:
On Fri, Feb 04, 2022 at 11:56:52AM +0100, Pali Rohár wrote:
On Thursday 03 February 2022 15:02:02 Simon Glass wrote:
Hi,
On Thu, 3 Feb 2022 at 14:53, Tom Rini trini@konsulko.com wrote:
On Thu, Feb 03, 2022 at 04:45:44PM -0500, Tom Rini wrote: > On Thu, Feb 03, 2022 at 04:16:23PM -0500, Tom Rini wrote: > > On Thu, Feb 03, 2022 at 07:38:50PM +0100, Pali Rohár wrote: > > > > > Signed-off-by: Pali Rohár pali@kernel.org > > > --- > > > > > > I would really appreciate if U-Boot test framework starts printing > > > deprecation warnings, instead of sending patches which directly drop > > > support for some boards. > > > > > > There is absolutely no warning during building U-Boot for RX-51 board > > > that this board has not been converted to DM_KEYBOARD yet. > > > > Please send some patch that implements what you're wanting to see for > > how to make the warnings more visible. I do agree the warning for > > v2022.10 only showed up after the merge to -next once v2022.01 came out, > > but it's still a fairly long time to clean up the few unconverted > > boards. > > Oh, I see what's going on. Simon, the DM_KEYBOARD check isn't > triggering for any boards. I'll look more.
And here's where we're at. nokia_rx51 doesn't set CONFIG_KEYBOARD, so didn't trigger the warning about migration. Every platform that sets CONFIG_KEYBOARD is migrated. I don't know how many other platforms are in the situation nokia_rx51 is in. Yanking out the legacy code and seeing what fails to build, and going from there is probably the next option.
Yes.
As to your questoin, none that I know of. I sent a series to drop cfb_console which was how this used to work, although in fact it hasn't worked for a while. The problem here seems to be that this board was multiple migrations behind and so was not caught.
It is not truth that cfb_console has not worked. This driver is / was working fine on n900 without any issues.
Yes, it's such an old missed migration that there's no check for it.
We should be able to remove the migration check.
Pali, just to explain from the other POV, I am finding it increasingly frustrating dealing with ad-hoc CONFIG options, old drivers, etc. We really need to complete some of the migrations we started 6 years ago.
Regards, Simon
Well, I see and understand you. But as I explained it more times, it was me who is/was waiting for review of n900 patches and I was not able to speed up review process. There was always some n900 patch in waiting state.
Now when pending n900 patches were reviewed and merged, I prepared and sent another one -- this DM_KEYBOARD which removes one part of cfb_console code from n900 board code.
Alright. So, do you see the warning about DM_SERIAL? Are you going to start work on that migration now, or in about a week or two when I pick this up, assuming no changes are requested?
I do not see any warning, neither about DM_SERIAL nor any other in RX-51 test job which builds bootable image for RX-51. See CI link: https://dev.azure.com/u-boot/u-boot/_build/results?buildId=3580&view=log...
But there is CONFIG_DM_SERIAL warning for nokia_rx51 board in the Build the World omap job, see CI link: https://dev.azure.com/u-boot/u-boot/_build/results?buildId=3580&view=log...
It's also visible when just doing "make CROSS_COMPILE=... nokia_rx51_config all" so I guess you need to debug your script and see why it's not showing that?
After this DM_KEYBOARD patch, I'm planning to look at DM_VIDEO as Simon really wants it and then I can look at DM_SERIAL.
OK. But, are you going to start before or after this gets merged?
-- Tom
As that cfb code shares both video and keyboard functionality, switching to DM_VIDEO depends on working DM_KEYBOARD migration. So I can start working on DM_VIDEO changes after I would see how support for DM_KEYBOARD for n900 would look like. I do not want before because I would enter into rebase, conflicts, rework and reimplementation from zero circle (with which I have experience from past n900 u-boot patches).
Hi Pali,
On Fri, 4 Feb 2022 at 07:13, Pali Rohár pali@kernel.org wrote:
On Friday 04 February 2022 09:00:55 Tom Rini wrote:
On Fri, Feb 04, 2022 at 02:55:39PM +0100, Pali Rohár wrote:
On Friday 04 February 2022 08:41:55 Tom Rini wrote:
On Fri, Feb 04, 2022 at 11:56:52AM +0100, Pali Rohár wrote:
On Thursday 03 February 2022 15:02:02 Simon Glass wrote:
Hi,
On Thu, 3 Feb 2022 at 14:53, Tom Rini trini@konsulko.com wrote: > > On Thu, Feb 03, 2022 at 04:45:44PM -0500, Tom Rini wrote: > > On Thu, Feb 03, 2022 at 04:16:23PM -0500, Tom Rini wrote: > > > On Thu, Feb 03, 2022 at 07:38:50PM +0100, Pali Rohár wrote: > > > > > > > Signed-off-by: Pali Rohár pali@kernel.org > > > > --- > > > > > > > > I would really appreciate if U-Boot test framework starts printing > > > > deprecation warnings, instead of sending patches which directly drop > > > > support for some boards. > > > > > > > > There is absolutely no warning during building U-Boot for RX-51 board > > > > that this board has not been converted to DM_KEYBOARD yet. > > > > > > Please send some patch that implements what you're wanting to see for > > > how to make the warnings more visible. I do agree the warning for > > > v2022.10 only showed up after the merge to -next once v2022.01 came out, > > > but it's still a fairly long time to clean up the few unconverted > > > boards. > > > > Oh, I see what's going on. Simon, the DM_KEYBOARD check isn't > > triggering for any boards. I'll look more. > > And here's where we're at. nokia_rx51 doesn't set CONFIG_KEYBOARD, so > didn't trigger the warning about migration. Every platform that sets > CONFIG_KEYBOARD is migrated. I don't know how many other platforms are > in the situation nokia_rx51 is in. Yanking out the legacy code and > seeing what fails to build, and going from there is probably the next > option.
Yes.
As to your questoin, none that I know of. I sent a series to drop cfb_console which was how this used to work, although in fact it hasn't worked for a while. The problem here seems to be that this board was multiple migrations behind and so was not caught.
It is not truth that cfb_console has not worked. This driver is / was working fine on n900 without any issues.
Yes, it's such an old missed migration that there's no check for it.
We should be able to remove the migration check.
Pali, just to explain from the other POV, I am finding it increasingly frustrating dealing with ad-hoc CONFIG options, old drivers, etc. We really need to complete some of the migrations we started 6 years ago.
Regards, Simon
Well, I see and understand you. But as I explained it more times, it was me who is/was waiting for review of n900 patches and I was not able to speed up review process. There was always some n900 patch in waiting state.
Now when pending n900 patches were reviewed and merged, I prepared and sent another one -- this DM_KEYBOARD which removes one part of cfb_console code from n900 board code.
Alright. So, do you see the warning about DM_SERIAL? Are you going to start work on that migration now, or in about a week or two when I pick this up, assuming no changes are requested?
I do not see any warning, neither about DM_SERIAL nor any other in RX-51 test job which builds bootable image for RX-51. See CI link: https://dev.azure.com/u-boot/u-boot/_build/results?buildId=3580&view=log...
But there is CONFIG_DM_SERIAL warning for nokia_rx51 board in the Build the World omap job, see CI link: https://dev.azure.com/u-boot/u-boot/_build/results?buildId=3580&view=log...
It's also visible when just doing "make CROSS_COMPILE=... nokia_rx51_config all" so I guess you need to debug your script and see why it's not showing that?
After this DM_KEYBOARD patch, I'm planning to look at DM_VIDEO as Simon really wants it and then I can look at DM_SERIAL.
OK. But, are you going to start before or after this gets merged?
-- Tom
As that cfb code shares both video and keyboard functionality, switching to DM_VIDEO depends on working DM_KEYBOARD migration. So I can start working on DM_VIDEO changes after I would see how support for DM_KEYBOARD for n900 would look like. I do not want before because I would enter into rebase, conflicts, rework and reimplementation from zero circle (with which I have experience from past n900 u-boot patches).
If the problem is reviews I can help with that. If it is lost patches then we should be able to get them all in now-ish. Can you resend everything that is outstanding.
Yes you do need to put drivers in drivers/ so please create a Kconfig for your keyboard driver and put it in drivers/input
Regards, Simon
On Friday 04 February 2022 08:24:03 Simon Glass wrote:
Hi Pali,
On Fri, 4 Feb 2022 at 07:13, Pali Rohár pali@kernel.org wrote:
On Friday 04 February 2022 09:00:55 Tom Rini wrote:
On Fri, Feb 04, 2022 at 02:55:39PM +0100, Pali Rohár wrote:
On Friday 04 February 2022 08:41:55 Tom Rini wrote:
On Fri, Feb 04, 2022 at 11:56:52AM +0100, Pali Rohár wrote:
On Thursday 03 February 2022 15:02:02 Simon Glass wrote: > Hi, > > On Thu, 3 Feb 2022 at 14:53, Tom Rini trini@konsulko.com wrote: > > > > On Thu, Feb 03, 2022 at 04:45:44PM -0500, Tom Rini wrote: > > > On Thu, Feb 03, 2022 at 04:16:23PM -0500, Tom Rini wrote: > > > > On Thu, Feb 03, 2022 at 07:38:50PM +0100, Pali Rohár wrote: > > > > > > > > > Signed-off-by: Pali Rohár pali@kernel.org > > > > > --- > > > > > > > > > > I would really appreciate if U-Boot test framework starts printing > > > > > deprecation warnings, instead of sending patches which directly drop > > > > > support for some boards. > > > > > > > > > > There is absolutely no warning during building U-Boot for RX-51 board > > > > > that this board has not been converted to DM_KEYBOARD yet. > > > > > > > > Please send some patch that implements what you're wanting to see for > > > > how to make the warnings more visible. I do agree the warning for > > > > v2022.10 only showed up after the merge to -next once v2022.01 came out, > > > > but it's still a fairly long time to clean up the few unconverted > > > > boards. > > > > > > Oh, I see what's going on. Simon, the DM_KEYBOARD check isn't > > > triggering for any boards. I'll look more. > > > > And here's where we're at. nokia_rx51 doesn't set CONFIG_KEYBOARD, so > > didn't trigger the warning about migration. Every platform that sets > > CONFIG_KEYBOARD is migrated. I don't know how many other platforms are > > in the situation nokia_rx51 is in. Yanking out the legacy code and > > seeing what fails to build, and going from there is probably the next > > option. > > Yes. > > As to your questoin, none that I know of. I sent a series to drop > cfb_console which was how this used to work, although in fact it > hasn't worked for a while. The problem here seems to be that this > board was multiple migrations behind and so was not caught.
It is not truth that cfb_console has not worked. This driver is / was working fine on n900 without any issues.
Yes, it's such an old missed migration that there's no check for it.
> We should be able to remove the migration check. > > Pali, just to explain from the other POV, I am finding it increasingly > frustrating dealing with ad-hoc CONFIG options, old drivers, etc. We > really need to complete some of the migrations we started 6 years ago. > > Regards, > Simon
Well, I see and understand you. But as I explained it more times, it was me who is/was waiting for review of n900 patches and I was not able to speed up review process. There was always some n900 patch in waiting state.
Now when pending n900 patches were reviewed and merged, I prepared and sent another one -- this DM_KEYBOARD which removes one part of cfb_console code from n900 board code.
Alright. So, do you see the warning about DM_SERIAL? Are you going to start work on that migration now, or in about a week or two when I pick this up, assuming no changes are requested?
I do not see any warning, neither about DM_SERIAL nor any other in RX-51 test job which builds bootable image for RX-51. See CI link: https://dev.azure.com/u-boot/u-boot/_build/results?buildId=3580&view=log...
But there is CONFIG_DM_SERIAL warning for nokia_rx51 board in the Build the World omap job, see CI link: https://dev.azure.com/u-boot/u-boot/_build/results?buildId=3580&view=log...
It's also visible when just doing "make CROSS_COMPILE=... nokia_rx51_config all" so I guess you need to debug your script and see why it's not showing that?
After this DM_KEYBOARD patch, I'm planning to look at DM_VIDEO as Simon really wants it and then I can look at DM_SERIAL.
OK. But, are you going to start before or after this gets merged?
-- Tom
As that cfb code shares both video and keyboard functionality, switching to DM_VIDEO depends on working DM_KEYBOARD migration. So I can start working on DM_VIDEO changes after I would see how support for DM_KEYBOARD for n900 would look like. I do not want before because I would enter into rebase, conflicts, rework and reimplementation from zero circle (with which I have experience from past n900 u-boot patches).
If the problem is reviews I can help with that. If it is lost patches then we should be able to get them all in now-ish. Can you resend everything that is outstanding.
This is the only outstanding patch right now. All others were finally reviewed and merged.
Yes you do need to put drivers in drivers/ so please create a Kconfig for your keyboard driver and put it in drivers/input
But this is not easy and make it harder to develop and debug. All these functionality shares lot of functions, variables and locks; so it cannot be moved into drivers/input unless you want also watchdog or other code in drivers/input. Not mentioning that this is specific board code which is not on any other board, so I do not see any value of trying to invest lot of time in this.
On Fri, Feb 04, 2022 at 04:30:23PM +0100, Pali Rohár wrote:
On Friday 04 February 2022 08:24:03 Simon Glass wrote:
Hi Pali,
On Fri, 4 Feb 2022 at 07:13, Pali Rohár pali@kernel.org wrote:
On Friday 04 February 2022 09:00:55 Tom Rini wrote:
On Fri, Feb 04, 2022 at 02:55:39PM +0100, Pali Rohár wrote:
On Friday 04 February 2022 08:41:55 Tom Rini wrote:
On Fri, Feb 04, 2022 at 11:56:52AM +0100, Pali Rohár wrote: > On Thursday 03 February 2022 15:02:02 Simon Glass wrote: > > Hi, > > > > On Thu, 3 Feb 2022 at 14:53, Tom Rini trini@konsulko.com wrote: > > > > > > On Thu, Feb 03, 2022 at 04:45:44PM -0500, Tom Rini wrote: > > > > On Thu, Feb 03, 2022 at 04:16:23PM -0500, Tom Rini wrote: > > > > > On Thu, Feb 03, 2022 at 07:38:50PM +0100, Pali Rohár wrote: > > > > > > > > > > > Signed-off-by: Pali Rohár pali@kernel.org > > > > > > --- > > > > > > > > > > > > I would really appreciate if U-Boot test framework starts printing > > > > > > deprecation warnings, instead of sending patches which directly drop > > > > > > support for some boards. > > > > > > > > > > > > There is absolutely no warning during building U-Boot for RX-51 board > > > > > > that this board has not been converted to DM_KEYBOARD yet. > > > > > > > > > > Please send some patch that implements what you're wanting to see for > > > > > how to make the warnings more visible. I do agree the warning for > > > > > v2022.10 only showed up after the merge to -next once v2022.01 came out, > > > > > but it's still a fairly long time to clean up the few unconverted > > > > > boards. > > > > > > > > Oh, I see what's going on. Simon, the DM_KEYBOARD check isn't > > > > triggering for any boards. I'll look more. > > > > > > And here's where we're at. nokia_rx51 doesn't set CONFIG_KEYBOARD, so > > > didn't trigger the warning about migration. Every platform that sets > > > CONFIG_KEYBOARD is migrated. I don't know how many other platforms are > > > in the situation nokia_rx51 is in. Yanking out the legacy code and > > > seeing what fails to build, and going from there is probably the next > > > option. > > > > Yes. > > > > As to your questoin, none that I know of. I sent a series to drop > > cfb_console which was how this used to work, although in fact it > > hasn't worked for a while. The problem here seems to be that this > > board was multiple migrations behind and so was not caught. > > It is not truth that cfb_console has not worked. This driver is / was > working fine on n900 without any issues.
Yes, it's such an old missed migration that there's no check for it.
> > We should be able to remove the migration check. > > > > Pali, just to explain from the other POV, I am finding it increasingly > > frustrating dealing with ad-hoc CONFIG options, old drivers, etc. We > > really need to complete some of the migrations we started 6 years ago. > > > > Regards, > > Simon > > Well, I see and understand you. But as I explained it more times, it was > me who is/was waiting for review of n900 patches and I was not able to > speed up review process. There was always some n900 patch in waiting > state. > > Now when pending n900 patches were reviewed and merged, I prepared and > sent another one -- this DM_KEYBOARD which removes one part of > cfb_console code from n900 board code.
Alright. So, do you see the warning about DM_SERIAL? Are you going to start work on that migration now, or in about a week or two when I pick this up, assuming no changes are requested?
I do not see any warning, neither about DM_SERIAL nor any other in RX-51 test job which builds bootable image for RX-51. See CI link: https://dev.azure.com/u-boot/u-boot/_build/results?buildId=3580&view=log...
But there is CONFIG_DM_SERIAL warning for nokia_rx51 board in the Build the World omap job, see CI link: https://dev.azure.com/u-boot/u-boot/_build/results?buildId=3580&view=log...
It's also visible when just doing "make CROSS_COMPILE=... nokia_rx51_config all" so I guess you need to debug your script and see why it's not showing that?
After this DM_KEYBOARD patch, I'm planning to look at DM_VIDEO as Simon really wants it and then I can look at DM_SERIAL.
OK. But, are you going to start before or after this gets merged?
-- Tom
As that cfb code shares both video and keyboard functionality, switching to DM_VIDEO depends on working DM_KEYBOARD migration. So I can start working on DM_VIDEO changes after I would see how support for DM_KEYBOARD for n900 would look like. I do not want before because I would enter into rebase, conflicts, rework and reimplementation from zero circle (with which I have experience from past n900 u-boot patches).
If the problem is reviews I can help with that. If it is lost patches then we should be able to get them all in now-ish. Can you resend everything that is outstanding.
This is the only outstanding patch right now. All others were finally reviewed and merged.
Yes you do need to put drivers in drivers/ so please create a Kconfig for your keyboard driver and put it in drivers/input
But this is not easy and make it harder to develop and debug. All these functionality shares lot of functions, variables and locks; so it cannot be moved into drivers/input unless you want also watchdog or other code in drivers/input. Not mentioning that this is specific board code which is not on any other board, so I do not see any value of trying to invest lot of time in this.
So yes, board/nokia/rx51/rx51.c is 751 lines and should get split in to having watchdog under drivers/watchdog/ and video stuff under drivers/video/ and keyboard under drivers/input/ as that's how a modern board would be done. I probably should have pushed back on such a large board file when things first came in as that's really always been the case, but there used to be more bad examples than there are now. But at the end of the day, I really want to see this board brought up to modern APIs and it's not going to be used as the basis for a new board port, so there's a smaller risk of something new using this as an example.
Hi Tom,
On Fri, 4 Feb 2022 at 08:37, Tom Rini trini@konsulko.com wrote:
On Fri, Feb 04, 2022 at 04:30:23PM +0100, Pali Rohár wrote:
On Friday 04 February 2022 08:24:03 Simon Glass wrote:
Hi Pali,
On Fri, 4 Feb 2022 at 07:13, Pali Rohár pali@kernel.org wrote:
On Friday 04 February 2022 09:00:55 Tom Rini wrote:
On Fri, Feb 04, 2022 at 02:55:39PM +0100, Pali Rohár wrote:
On Friday 04 February 2022 08:41:55 Tom Rini wrote: > On Fri, Feb 04, 2022 at 11:56:52AM +0100, Pali Rohár wrote: > > On Thursday 03 February 2022 15:02:02 Simon Glass wrote: > > > Hi, > > > > > > On Thu, 3 Feb 2022 at 14:53, Tom Rini trini@konsulko.com wrote: > > > > > > > > On Thu, Feb 03, 2022 at 04:45:44PM -0500, Tom Rini wrote: > > > > > On Thu, Feb 03, 2022 at 04:16:23PM -0500, Tom Rini wrote: > > > > > > On Thu, Feb 03, 2022 at 07:38:50PM +0100, Pali Rohár wrote: > > > > > > > > > > > > > Signed-off-by: Pali Rohár pali@kernel.org > > > > > > > --- > > > > > > > > > > > > > > I would really appreciate if U-Boot test framework starts printing > > > > > > > deprecation warnings, instead of sending patches which directly drop > > > > > > > support for some boards. > > > > > > > > > > > > > > There is absolutely no warning during building U-Boot for RX-51 board > > > > > > > that this board has not been converted to DM_KEYBOARD yet. > > > > > > > > > > > > Please send some patch that implements what you're wanting to see for > > > > > > how to make the warnings more visible. I do agree the warning for > > > > > > v2022.10 only showed up after the merge to -next once v2022.01 came out, > > > > > > but it's still a fairly long time to clean up the few unconverted > > > > > > boards. > > > > > > > > > > Oh, I see what's going on. Simon, the DM_KEYBOARD check isn't > > > > > triggering for any boards. I'll look more. > > > > > > > > And here's where we're at. nokia_rx51 doesn't set CONFIG_KEYBOARD, so > > > > didn't trigger the warning about migration. Every platform that sets > > > > CONFIG_KEYBOARD is migrated. I don't know how many other platforms are > > > > in the situation nokia_rx51 is in. Yanking out the legacy code and > > > > seeing what fails to build, and going from there is probably the next > > > > option. > > > > > > Yes. > > > > > > As to your questoin, none that I know of. I sent a series to drop > > > cfb_console which was how this used to work, although in fact it > > > hasn't worked for a while. The problem here seems to be that this > > > board was multiple migrations behind and so was not caught. > > > > It is not truth that cfb_console has not worked. This driver is / was > > working fine on n900 without any issues. > > Yes, it's such an old missed migration that there's no check for it. > > > > We should be able to remove the migration check. > > > > > > Pali, just to explain from the other POV, I am finding it increasingly > > > frustrating dealing with ad-hoc CONFIG options, old drivers, etc. We > > > really need to complete some of the migrations we started 6 years ago. > > > > > > Regards, > > > Simon > > > > Well, I see and understand you. But as I explained it more times, it was > > me who is/was waiting for review of n900 patches and I was not able to > > speed up review process. There was always some n900 patch in waiting > > state. > > > > Now when pending n900 patches were reviewed and merged, I prepared and > > sent another one -- this DM_KEYBOARD which removes one part of > > cfb_console code from n900 board code. > > Alright. So, do you see the warning about DM_SERIAL? Are you going to > start work on that migration now, or in about a week or two when I pick > this up, assuming no changes are requested?
I do not see any warning, neither about DM_SERIAL nor any other in RX-51 test job which builds bootable image for RX-51. See CI link: https://dev.azure.com/u-boot/u-boot/_build/results?buildId=3580&view=log...
But there is CONFIG_DM_SERIAL warning for nokia_rx51 board in the Build the World omap job, see CI link: https://dev.azure.com/u-boot/u-boot/_build/results?buildId=3580&view=log...
It's also visible when just doing "make CROSS_COMPILE=... nokia_rx51_config all" so I guess you need to debug your script and see why it's not showing that?
After this DM_KEYBOARD patch, I'm planning to look at DM_VIDEO as Simon really wants it and then I can look at DM_SERIAL.
OK. But, are you going to start before or after this gets merged?
-- Tom
As that cfb code shares both video and keyboard functionality, switching to DM_VIDEO depends on working DM_KEYBOARD migration. So I can start working on DM_VIDEO changes after I would see how support for DM_KEYBOARD for n900 would look like. I do not want before because I would enter into rebase, conflicts, rework and reimplementation from zero circle (with which I have experience from past n900 u-boot patches).
If the problem is reviews I can help with that. If it is lost patches then we should be able to get them all in now-ish. Can you resend everything that is outstanding.
This is the only outstanding patch right now. All others were finally reviewed and merged.
Yes you do need to put drivers in drivers/ so please create a Kconfig for your keyboard driver and put it in drivers/input
But this is not easy and make it harder to develop and debug. All these functionality shares lot of functions, variables and locks; so it cannot be moved into drivers/input unless you want also watchdog or other code in drivers/input. Not mentioning that this is specific board code which is not on any other board, so I do not see any value of trying to invest lot of time in this.
So yes, board/nokia/rx51/rx51.c is 751 lines and should get split in to having watchdog under drivers/watchdog/ and video stuff under drivers/video/ and keyboard under drivers/input/ as that's how a modern board would be done. I probably should have pushed back on such a large board file when things first came in as that's really always been the case, but there used to be more bad examples than there are now. But at the end of the day, I really want to see this board brought up to modern APIs and it's not going to be used as the basis for a new board port, so there's a smaller risk of something new using this as an example.
Well if you are OK with it, it is fine with me.
I do wonder how this board got so out of date. E.g. even the DM_I2C support is actually just veneered onto the old API.
Regards, Simon
On Friday 04 February 2022 08:41:01 Simon Glass wrote:
I do wonder how this board got so out of date.
I think I have explained it... Because every time I sent some patch for this board it took months or half of year until patch was reviewed. So I lost interest in sending new patches or do development, and did only small necessary changes to do required migration.
Hi Pali,
On Fri, 4 Feb 2022 at 08:46, Pali Rohár pali@kernel.org wrote:
On Friday 04 February 2022 08:41:01 Simon Glass wrote:
I do wonder how this board got so out of date.
I think I have explained it... Because every time I sent some patch for this board it took months or half of year until patch was reviewed. So I lost interest in sending new patches or do development, and did only small necessary changes to do required migration.
Who is actually the maintainer for your stuff? Given that it is so special, perhaps it should have its own maintainer?
Also if you push back on reviews a lot, people stop reviewing things. I'm not sure if that happened in this case, but I've seen it.
Regards, Simon
On Friday 04 February 2022 08:54:45 Simon Glass wrote:
Hi Pali,
On Fri, 4 Feb 2022 at 08:46, Pali Rohár pali@kernel.org wrote:
On Friday 04 February 2022 08:41:01 Simon Glass wrote:
I do wonder how this board got so out of date.
I think I have explained it... Because every time I sent some patch for this board it took months or half of year until patch was reviewed. So I lost interest in sending new patches or do development, and did only small necessary changes to do required migration.
Who is actually the maintainer for your stuff? Given that it is so special, perhaps it should have its own maintainer?
I do not know. I would be happy if somebody tell me this information. get_maintainer.pl prints me but such information does not help me.
Also if you push back on reviews a lot, people stop reviewing things. I'm not sure if that happened in this case, but I've seen it.
Regards, Simon
On Thursday 03 February 2022 16:45:44 Tom Rini wrote:
On Thu, Feb 03, 2022 at 04:16:23PM -0500, Tom Rini wrote:
On Thu, Feb 03, 2022 at 07:38:50PM +0100, Pali Rohár wrote:
Signed-off-by: Pali Rohár pali@kernel.org
I would really appreciate if U-Boot test framework starts printing deprecation warnings, instead of sending patches which directly drop support for some boards.
There is absolutely no warning during building U-Boot for RX-51 board that this board has not been converted to DM_KEYBOARD yet.
Please send some patch that implements what you're wanting to see for how to make the warnings more visible. I do agree the warning for v2022.10 only showed up after the merge to -next once v2022.01 came out, but it's still a fairly long time to clean up the few unconverted boards.
Oh, I see what's going on. Simon, the DM_KEYBOARD check isn't triggering for any boards. I'll look more.
-- Tom
The point is that this board does not show any deprecation warning on the Azure CI nor during local building and I really cannot easily determinate _what_ is old code and what needs to be migrated to new new code (and what it is).
On Thu, Feb 03, 2022 at 07:38:50PM +0100, Pali Rohár wrote:
Signed-off-by: Pali Rohár pali@kernel.org
Applied to u-boot/master, thanks!
On Tuesday 08 February 2022 12:36:24 Tom Rini wrote:
On Thu, Feb 03, 2022 at 07:38:50PM +0100, Pali Rohár wrote:
Signed-off-by: Pali Rohár pali@kernel.org
Applied to u-boot/master, thanks!
-- Tom
Thank you Tom!
participants (3)
-
Pali Rohár -
Simon Glass -
Tom Rini