Re: [RESEND v7 00/37] Device Tree support for SH7751 based board
Hi Yoshinori, On Mon, 2024-05-20 at 22:06 +0900, Yoshinori Sato wrote: > On Sat, 18 May 2024 18:08:30 +0900, > John Paul Adrian Glaubitz wrote: > > > > Hi Yoshinori, > > > > On Thu, 2024-04-04 at 14:14 +0900, Yoshinori Sato wrote: > > > Sorry. previus mail is thread broken. > > > > > > This is an updated version of something I wrote about 7 years ago. > > > Minimum support for R2D-plus and LANDISK. > > > I think R2D-1 will work if you add AX88796 to dts. > > > And board-specific functions and SCI's SPI functions are not supported. > > > > > > You can get it working with qemu found here. > > > https://gitlab.com/yoshinori.sato/qemu/-/tree/landisk > > > > > > v7 changes. > > > - sh/kernel/setup.c: fix kernel parameter handling. > > > - clk-sh7750.c: cleanup. > > > - sh_tmu.c: cleanup. > > > - irq-renesas-sh7751.c: IPR definition move to code. > > > - irq-renesas-sh7751irl.c: update register definition. > > > - pci-sh7751.c: Register initialization fix. > > > - sm501 and sm501fb: Re-design Device Tree properties. > > > > Could you push your v7 version to your Gitlab [1] repository so I can fetch > > it from there? > > updated it. Thanks! > I'll be posting v8 soon. Sounds good! Maybe we can start merging the patches that contain fixes only and that have already been reviewed. This way, we can reduce the overall size of the series a bit. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [RESEND v7 00/37] Device Tree support for SH7751 based board
Hi Yoshinori, On Thu, 2024-04-04 at 14:14 +0900, Yoshinori Sato wrote: > Sorry. previus mail is thread broken. > > This is an updated version of something I wrote about 7 years ago. > Minimum support for R2D-plus and LANDISK. > I think R2D-1 will work if you add AX88796 to dts. > And board-specific functions and SCI's SPI functions are not supported. > > You can get it working with qemu found here. > https://gitlab.com/yoshinori.sato/qemu/-/tree/landisk > > v7 changes. > - sh/kernel/setup.c: fix kernel parameter handling. > - clk-sh7750.c: cleanup. > - sh_tmu.c: cleanup. > - irq-renesas-sh7751.c: IPR definition move to code. > - irq-renesas-sh7751irl.c: update register definition. > - pci-sh7751.c: Register initialization fix. > - sm501 and sm501fb: Re-design Device Tree properties. Could you push your v7 version to your Gitlab [1] repository so I can fetch it from there? Thanks, Adrian > [1] https://gitlab.com/yoshinori.sato/linux -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH] fbdev/sh7760fb: allow modular build
Hi Randy, On Tue, 2024-04-09 at 21:54 -0700, Randy Dunlap wrote: > Will someone be merging this patch? Shall I pick it up through my tree? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH] fbdev/sh7760fb: allow modular build
On Wed, 2024-04-10 at 15:17 +0200, Helge Deller wrote: > On 4/10/24 06:54, Randy Dunlap wrote: > > Hi, > > > > Will someone be merging this patch? > > I've just added it to the fbdev git tree. Ah, good. Then I can drop it from my queue again. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [linux-next:master] BUILD REGRESSION e31185ce00a96232308300008db193416ceb9769
On Fri, 2024-02-23 at 07:46 -0800, Kees Cook wrote: > > arch/sh/boot/compressed/../../../../lib/decompress_unxz.c:350:(.text+0x20b4): > > undefined reference to `__ubsan_handle_out_of_bounds' > > sh4-linux-ld: > > arch/sh/boot/compressed/../../../../lib/xz/xz_dec_lzma2.c:751:(.text+0x904): > > undefined reference to `__ubsan_handle_out_of_bounds' > > This is fixed here and is waiting to land: > https://lore.kernel.org/linux-hardening/20240130232717.work.088-k...@kernel.org/ I was unable to reproduce this issue. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH] fbdev/sh7760fb: allow modular build
On Fri, 2024-02-09 at 21:39 -0800, Randy Dunlap wrote:
> There is no reason to prohibit sh7760fb from being built as a
> loadable module as suggested by Geert, so change the config symbol
> from bool to tristate to allow that and change the FB dependency as
> needed.
>
> Fixes: f75f71b2c418 ("fbdev/sh7760fb: Depend on FB=y")
> Suggested-by: Geert Uytterhoeven
> Signed-off-by: Randy Dunlap
> Cc: Thomas Zimmermann
> Cc: Javier Martinez Canillas
> Cc: John Paul Adrian Glaubitz
> Cc: Sam Ravnborg
> Cc: Helge Deller
> Cc: linux-fb...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> ---
> drivers/video/fbdev/Kconfig |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff -- a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -1645,8 +1645,8 @@ config FB_COBALT
> select FB_IOMEM_HELPERS
>
> config FB_SH7760
> - bool "SH7760/SH7763/SH7720/SH7721 LCDC support"
> - depends on FB=y && (CPU_SUBTYPE_SH7760 || CPU_SUBTYPE_SH7763 \
> + tristate "SH7760/SH7763/SH7720/SH7721 LCDC support"
> + depends on FB && (CPU_SUBTYPE_SH7760 || CPU_SUBTYPE_SH7763 \
> || CPU_SUBTYPE_SH7720 || CPU_SUBTYPE_SH7721)
> select FB_IOMEM_HELPERS
> help
Acked-by: John Paul Adrian Glaubitz
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH 00/27] sparc32: sunset sun4m and sun4d
Hi Sam, On Sun, 2024-02-04 at 20:21 +0100, Sam Ravnborg wrote: > Assuming you agree with the patchset how do you want me to move forward? > I can rebase on top of the latest -rc and collect acks if that helps. > > Arnd promised to pick up the patches until you got a git tree up, > but I do not expect Arnd to pick up anything unless you have acked or > reviewed said patch(es). > > If I rebase the patch-set I will likely include a few bug-fix patches that > was prepared in the meantime. > I can also send them as a separate series, no worries. I met with Andreas this weekend and he got GPG signatures from at least me and Geert which he needs for his kernel.org account. Please give him a few more days, maybe be even 2-3 weeks to get everything up and comfortable with the whole process. The more patches Andreas can review and merge himself, the better. And since your patches have been laying around for some time already, I don't think that waiting a little longer will be a problem. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH] sh: ecovec24: Rename missed backlight field from fbdev to dev
On Mon, 2023-09-25 at 13:10 +0200, Geert Uytterhoeven wrote:
> One instance of gpio_backlight_platform_data.fbdev was renamed, but the
> second instance was forgotten, causing a build failure:
>
> arch/sh/boards/mach-ecovec24/setup.c: In function ‘arch_setup’:
> arch/sh/boards/mach-ecovec24/setup.c:1223:37: error: ‘struct
> gpio_backlight_platform_data’ has no member named ‘fbdev’; did you mean ‘dev’?
> 1223 | gpio_backlight_data.fbdev = NULL;
> | ^
> | dev
>
> Fix this by updating the second instance.
>
> Fixes: ed369def91c1579a ("backlight/gpio_backlight: Rename field 'fbdev' to
> 'dev'")
> Reported-by: kernel test robot
> Closes:
> https://lore.kernel.org/oe-kbuild-all/202309231601.uu6qcrnu-...@intel.com/
> Signed-off-by: Geert Uytterhoeven
> ---
> arch/sh/boards/mach-ecovec24/setup.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/sh/boards/mach-ecovec24/setup.c
> b/arch/sh/boards/mach-ecovec24/setup.c
> index 3be293335de54512..7a788d44cc73496c 100644
> --- a/arch/sh/boards/mach-ecovec24/setup.c
> +++ b/arch/sh/boards/mach-ecovec24/setup.c
> @@ -1220,7 +1220,7 @@ static int __init arch_setup(void)
> lcdc_info.ch[0].num_modes =
> ARRAY_SIZE(ecovec_dvi_modes);
>
> /* No backlight */
> - gpio_backlight_data.fbdev = NULL;
> + gpio_backlight_data.dev = NULL;
>
> gpio_set_value(GPIO_PTA2, 1);
> gpio_set_value(GPIO_PTU1, 1);
Applied to my sh-linux tree.
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH] sh: ecovec24: Rename missed backlight field from fbdev to dev
On Mon, 2023-09-25 at 13:10 +0200, Geert Uytterhoeven wrote:
> One instance of gpio_backlight_platform_data.fbdev was renamed, but the
> second instance was forgotten, causing a build failure:
>
> arch/sh/boards/mach-ecovec24/setup.c: In function ‘arch_setup’:
> arch/sh/boards/mach-ecovec24/setup.c:1223:37: error: ‘struct
> gpio_backlight_platform_data’ has no member named ‘fbdev’; did you mean ‘dev’?
> 1223 | gpio_backlight_data.fbdev = NULL;
> | ^
> | dev
>
> Fix this by updating the second instance.
>
> Fixes: ed369def91c1579a ("backlight/gpio_backlight: Rename field 'fbdev' to
> 'dev'")
> Reported-by: kernel test robot
> Closes:
> https://lore.kernel.org/oe-kbuild-all/202309231601.uu6qcrnu-...@intel.com/
> Signed-off-by: Geert Uytterhoeven
> ---
> arch/sh/boards/mach-ecovec24/setup.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/sh/boards/mach-ecovec24/setup.c
> b/arch/sh/boards/mach-ecovec24/setup.c
> index 3be293335de54512..7a788d44cc73496c 100644
> --- a/arch/sh/boards/mach-ecovec24/setup.c
> +++ b/arch/sh/boards/mach-ecovec24/setup.c
> @@ -1220,7 +1220,7 @@ static int __init arch_setup(void)
> lcdc_info.ch[0].num_modes =
> ARRAY_SIZE(ecovec_dvi_modes);
>
> /* No backlight */
> - gpio_backlight_data.fbdev = NULL;
> + gpio_backlight_data.dev = NULL;
>
> gpio_set_value(GPIO_PTA2, 1);
> gpio_set_value(GPIO_PTU1, 1);
Reviewed-by: John Paul Adrian Glaubitz
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH 00/27] sparc32: sunset sun4m and sun4d
Hi Sam, On Wed, 2023-12-20 at 16:22 +0100, Sam Ravnborg wrote: > > The leon3_generic machine is maintained by different people so I'd suggest > > contacting them: see [1] for their contact details. I see there is an > > avocado boot test for the leon3_generic machine included within the QEMU > > source tree, but it uses a downloadable image of HelenOS rather than Linux. > > Thanks for the pointer, I will try to reach out to them when I have > something a bit more solid than "it does not work". > > I tried to hack around a little in qemu and I have an idea where things > goes wrong. The leon_generic assumes another address layout than what is > used by the kernel, so the very first jump to a kernel address fails. I would argue that before we start introducing larger changes to arch/sparc, we should settle the maintainership question first. Once we have an active maintainer again, we can have a more extended discussion about what to keep and how to name things. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH 00/27] sparc32: sunset sun4m and sun4d
On Wed, 2023-12-20 at 08:36 +, Arnd Bergmann wrote: > All of these were found through inspection rather than testing, > so there is a good chance that other fatal kernel bugs prevent > testing in qemu, at least until the fixes from Andreas' tree > are included. Andreas has fixes for these issues? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH 00/27] sparc32: sunset sun4m and sun4d
Re: [PATCH v2] drm/virtio: Add suppport for non-native buffer formats
On Sat, 2023-11-25 at 11:06 +0100, Christian Zigotzky wrote: > Could you please revert the v2 patch because of the issue with the > virtio-mouse-pci cursor? I will try to use the v1 patch for the RC3 of > kernel 6.7. I don't understand why the v2 patch should yield any different results as the only change compared to v1 is the fixed patch subject. There are no functional differences, I just diffed the patches against each other: --- geert-patch-v1.patch2023-11-25 12:09:19.122936658 +0100 +++ geert-patch-v2.patch2023-11-25 12:09:36.313039085 +0100 @@ -34,6 +34,9 @@ Suggested-by: Gerd Hoffmann Signed-off-by: Geert Uytterhoeven --- +v2: + - Fix truncated one-line summary. +--- drivers/gpu/drm/virtio/virtgpu_display.c | 11 +-- drivers/gpu/drm/virtio/virtgpu_plane.c | 6 -- 2 files changed, 13 insertions(+), 4 deletions(-) Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH] fbdev/sh7760fb: Depend on FB=y
On Mon, 2023-09-18 at 11:03 +0200, Thomas Zimmermann wrote: > Fix linker error if FB=m about missing fb_io_read and fb_io_write. The > linker's error message suggests that this config setting has already > been broken for other symbols. > > All errors (new ones prefixed by >>): > > sh4-linux-ld: drivers/video/fbdev/sh7760fb.o: in function > `sh7760fb_probe': > sh7760fb.c:(.text+0x374): undefined reference to `framebuffer_alloc' > sh4-linux-ld: sh7760fb.c:(.text+0x394): undefined reference to > `fb_videomode_to_var' > sh4-linux-ld: sh7760fb.c:(.text+0x39c): undefined reference to > `fb_alloc_cmap' > sh4-linux-ld: sh7760fb.c:(.text+0x3a4): undefined reference to > `register_framebuffer' > sh4-linux-ld: sh7760fb.c:(.text+0x3ac): undefined reference to > `fb_dealloc_cmap' > sh4-linux-ld: sh7760fb.c:(.text+0x434): undefined reference to > `framebuffer_release' > sh4-linux-ld: drivers/video/fbdev/sh7760fb.o: in function > `sh7760fb_remove': > sh7760fb.c:(.text+0x800): undefined reference to `unregister_framebuffer' > sh4-linux-ld: sh7760fb.c:(.text+0x804): undefined reference to > `fb_dealloc_cmap' > sh4-linux-ld: sh7760fb.c:(.text+0x814): undefined reference to > `framebuffer_release' > >> sh4-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0xc): undefined > reference to `fb_io_read' > >> sh4-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0x10): undefined > reference to `fb_io_write' > sh4-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0x2c): undefined > reference to `cfb_fillrect' > sh4-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0x30): undefined > reference to `cfb_copyarea' > sh4-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0x34): undefined > reference to `cfb_imageblit' > > Suggested-by: Randy Dunlap > Reported-by: kernel test robot > Closes: > https://lore.kernel.org/oe-kbuild-all/202309130632.ls04cpwu-...@intel.com/ > Signed-off-by: Thomas Zimmermann > --- > drivers/video/fbdev/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig > index 4455bfd57f0ec..64ccb34d882dd 100644 > --- a/drivers/video/fbdev/Kconfig > +++ b/drivers/video/fbdev/Kconfig > @@ -1756,7 +1756,7 @@ config FB_COBALT > > config FB_SH7760 > bool "SH7760/SH7763/SH7720/SH7721 LCDC support" > - depends on FB && (CPU_SUBTYPE_SH7760 || CPU_SUBTYPE_SH7763 \ > + depends on FB=y && (CPU_SUBTYPE_SH7760 || CPU_SUBTYPE_SH7763 \ > || CPU_SUBTYPE_SH7720 || CPU_SUBTYPE_SH7721) > select FB_IOMEM_HELPERS > help Acked-by: John Paul Adrian Glaubitz -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH] fbdev: sh7760fb: require FB=y to build cleanly
Hi Randy!
On Wed, 2023-09-20 at 23:02 -0700, Randy Dunlap wrote:
> Fix build errors when CONFIG_FB=m and CONFIG_FB_SH7760=y:
>
> sh2-linux-ld: drivers/video/fbdev/sh7760fb.o: in function `sh7760fb_probe':
> sh7760fb.c:(.text+0x374): undefined reference to `framebuffer_alloc'
> sh2-linux-ld: sh7760fb.c:(.text+0x394): undefined reference to
> `fb_videomode_to_var'
> sh2-linux-ld: sh7760fb.c:(.text+0x3a0): undefined reference to `fb_alloc_cmap'
> sh2-linux-ld: sh7760fb.c:(.text+0x3a4): undefined reference to
> `register_framebuffer'
> sh2-linux-ld: sh7760fb.c:(.text+0x3ac): undefined reference to
> `fb_dealloc_cmap'
> sh2-linux-ld: sh7760fb.c:(.text+0x434): undefined reference to
> `framebuffer_release'
> sh2-linux-ld: drivers/video/fbdev/sh7760fb.o: in function `sh7760fb_remove':
> sh7760fb.c:(.text+0x800): undefined reference to `unregister_framebuffer'
> sh2-linux-ld: sh7760fb.c:(.text+0x804): undefined reference to
> `fb_dealloc_cmap'
> sh2-linux-ld: sh7760fb.c:(.text+0x814): undefined reference to
> `framebuffer_release'
> sh2-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0xc): undefined
> reference to `fb_io_read'
> sh2-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0x10): undefined
> reference to `fb_io_write'
> sh2-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0x2c): undefined
> reference to `cfb_fillrect'
> sh2-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0x30): undefined
> reference to `cfb_copyarea'
> sh2-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0x34): undefined
> reference to `cfb_imageblit'
>
> Fixes: 4a25e41831ee ("video: sh7760fb: SH7760/SH7763 LCDC framebuffer driver")
> Signed-off-by: Randy Dunlap
> Cc: Daniel Vetter
> Cc: Helge Deller
> Cc: linux-fb...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: John Paul Adrian Glaubitz
> Cc: linux...@vger.kernel.org
> ---
> drivers/video/fbdev/Kconfig |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff -- a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
> --- a/drivers/video/fbdev/Kconfig
> +++ b/drivers/video/fbdev/Kconfig
> @@ -1762,7 +1762,7 @@ config FB_COBALT
>
> config FB_SH7760
> bool "SH7760/SH7763/SH7720/SH7721 LCDC support"
> - depends on FB && (CPU_SUBTYPE_SH7760 || CPU_SUBTYPE_SH7763 \
> + depends on FB=y && (CPU_SUBTYPE_SH7760 || CPU_SUBTYPE_SH7763 \
> || CPU_SUBTYPE_SH7720 || CPU_SUBTYPE_SH7721)
> select FB_IOMEM_HELPERS
> help
Actually, Thomas Zimmermann already posted the same patch already on Monday ;-).
See [1].
Adrian
> [1] https://marc.info/?l=dri-devel=169502772500717=2
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH] fbdev/sh7760fb: Depend on FB=y
On Mon, 2023-09-18 at 11:03 +0200, Thomas Zimmermann wrote: > Fix linker error if FB=m about missing fb_io_read and fb_io_write. The > linker's error message suggests that this config setting has already > been broken for other symbols. > > All errors (new ones prefixed by >>): > > sh4-linux-ld: drivers/video/fbdev/sh7760fb.o: in function > `sh7760fb_probe': > sh7760fb.c:(.text+0x374): undefined reference to `framebuffer_alloc' > sh4-linux-ld: sh7760fb.c:(.text+0x394): undefined reference to > `fb_videomode_to_var' > sh4-linux-ld: sh7760fb.c:(.text+0x39c): undefined reference to > `fb_alloc_cmap' > sh4-linux-ld: sh7760fb.c:(.text+0x3a4): undefined reference to > `register_framebuffer' > sh4-linux-ld: sh7760fb.c:(.text+0x3ac): undefined reference to > `fb_dealloc_cmap' > sh4-linux-ld: sh7760fb.c:(.text+0x434): undefined reference to > `framebuffer_release' > sh4-linux-ld: drivers/video/fbdev/sh7760fb.o: in function > `sh7760fb_remove': > sh7760fb.c:(.text+0x800): undefined reference to `unregister_framebuffer' > sh4-linux-ld: sh7760fb.c:(.text+0x804): undefined reference to > `fb_dealloc_cmap' > sh4-linux-ld: sh7760fb.c:(.text+0x814): undefined reference to > `framebuffer_release' > >> sh4-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0xc): undefined > reference to `fb_io_read' > >> sh4-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0x10): undefined > reference to `fb_io_write' > sh4-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0x2c): undefined > reference to `cfb_fillrect' > sh4-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0x30): undefined > reference to `cfb_copyarea' > sh4-linux-ld: drivers/video/fbdev/sh7760fb.o:(.rodata+0x34): undefined > reference to `cfb_imageblit' > > Suggested-by: Randy Dunlap > Reported-by: kernel test robot > Closes: > https://lore.kernel.org/oe-kbuild-all/202309130632.ls04cpwu-...@intel.com/ > Signed-off-by: Thomas Zimmermann > --- > drivers/video/fbdev/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig > index 4455bfd57f0ec..64ccb34d882dd 100644 > --- a/drivers/video/fbdev/Kconfig > +++ b/drivers/video/fbdev/Kconfig > @@ -1756,7 +1756,7 @@ config FB_COBALT > > config FB_SH7760 > bool "SH7760/SH7763/SH7720/SH7721 LCDC support" > - depends on FB && (CPU_SUBTYPE_SH7760 || CPU_SUBTYPE_SH7763 \ > + depends on FB=y && (CPU_SUBTYPE_SH7760 || CPU_SUBTYPE_SH7763 \ > || CPU_SUBTYPE_SH7720 || CPU_SUBTYPE_SH7721) > select FB_IOMEM_HELPERS > help Acked-by: John Paul Adrian Glaubitz -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH v2 08/18] sh: Assign FB_MODE_IS_UNKNOWN to struct fb_videomode.flag
Hi Thomas!
On Thu, 2023-07-13 at 15:53 +0200, John Paul Adrian Glaubitz wrote:
> On Thu, 2023-07-13 at 14:58 +0200, Thomas Zimmermann wrote:
> > Assign FB_MODE_IS_UNKNOWN to sh7763fb_videomode.flag instead of
> > FBINFO_FLAG_DEFAULT. Both are 0, so the stored value does not change.
> >
> > FBINFO_FLAG_DEFAULT is a flag for a framebuffer in struct fb_info.
> > Flags for videomodes are prefixed with FB_MODE_.
> >
> > v2:
> > * assign FB_MODE_IS_UNKNOWN (Adrian)
> >
> > Signed-off-by: Thomas Zimmermann
> > Acked-by: Sam Ravnborg
> > Cc: Yoshinori Sato
> > Cc: Rich Felker
> > Cc: John Paul Adrian Glaubitz
> > ---
> > arch/sh/boards/mach-sh7763rdp/setup.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/sh/boards/mach-sh7763rdp/setup.c
> > b/arch/sh/boards/mach-sh7763rdp/setup.c
> > index 97e715e4e9b3..e25193001ea0 100644
> > --- a/arch/sh/boards/mach-sh7763rdp/setup.c
> > +++ b/arch/sh/boards/mach-sh7763rdp/setup.c
> > @@ -119,7 +119,7 @@ static struct fb_videomode sh7763fb_videomode = {
> > .vsync_len = 1,
> > .sync = 0,
> > .vmode = FB_VMODE_NONINTERLACED,
> > - .flag = FBINFO_FLAG_DEFAULT,
> > + .flag = FB_MODE_IS_UNKNOWN,
> > };
> >
> > static struct sh7760fb_platdata sh7763fb_def_pdata = {
>
> Acked-by: John Paul Adrian Glaubitz
Ah, just one tiny request: Could you change the subject to include the
board name, i.e.:
sh: mach-sh7763rdp: Assign FB_MODE_IS_UNKNOWN to struct
fb_videomode.flag
?
I wasn't paying close attention to the path of the file being changed when
I first looked at your patch. Sorry for that.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH v2 08/18] sh: Assign FB_MODE_IS_UNKNOWN to struct fb_videomode.flag
On Thu, 2023-07-13 at 14:58 +0200, Thomas Zimmermann wrote:
> Assign FB_MODE_IS_UNKNOWN to sh7763fb_videomode.flag instead of
> FBINFO_FLAG_DEFAULT. Both are 0, so the stored value does not change.
>
> FBINFO_FLAG_DEFAULT is a flag for a framebuffer in struct fb_info.
> Flags for videomodes are prefixed with FB_MODE_.
>
> v2:
> * assign FB_MODE_IS_UNKNOWN (Adrian)
>
> Signed-off-by: Thomas Zimmermann
> Acked-by: Sam Ravnborg
> Cc: Yoshinori Sato
> Cc: Rich Felker
> Cc: John Paul Adrian Glaubitz
> ---
> arch/sh/boards/mach-sh7763rdp/setup.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/sh/boards/mach-sh7763rdp/setup.c
> b/arch/sh/boards/mach-sh7763rdp/setup.c
> index 97e715e4e9b3..e25193001ea0 100644
> --- a/arch/sh/boards/mach-sh7763rdp/setup.c
> +++ b/arch/sh/boards/mach-sh7763rdp/setup.c
> @@ -119,7 +119,7 @@ static struct fb_videomode sh7763fb_videomode = {
> .vsync_len = 1,
> .sync = 0,
> .vmode = FB_VMODE_NONINTERLACED,
> - .flag = FBINFO_FLAG_DEFAULT,
> + .flag = FB_MODE_IS_UNKNOWN,
> };
>
> static struct sh7760fb_platdata sh7763fb_def_pdata = {
Acked-by: John Paul Adrian Glaubitz
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH 08/17] arch/sh: Do not assign FBINFO_FLAG_DEFAULT to fb_videomode.flag
Hi! On Mon, 2023-07-10 at 16:04 +0200, Thomas Zimmermann wrote: > > > I won't argue with that, but the flag itself is wrong. > > > FBINFO_FLAG_DEFAULT is/was for struct fb_info.flags. You have struct > > > fb_videomode.flag. The valid flags for this field are at [1]. If > > > anything, the field could be initialized to FB_MODE_IS_UNKNOWN, which > > > has the same value. > > > > > > [1] https://elixir.bootlin.com/linux/latest/source/include/linux/fb.h#L681 > > > > FB_MODE_IS_UNKNOWN sounds very reasonable to me. Would you agree using that > > instead? > > Sure, I'll update the patch accordingly. Thanks! I'll ack the updated patch. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH 08/17] arch/sh: Do not assign FBINFO_FLAG_DEFAULT to fb_videomode.flag
Hi Thomas! On Mon, 2023-07-10 at 15:52 +0200, Thomas Zimmermann wrote: > > I would argue that the current code is more readable that your proposed > > change. > > > > I agree that it's a no-op, but code is not just about functionality but also > > readability, isn't it? > > I won't argue with that, but the flag itself is wrong. > FBINFO_FLAG_DEFAULT is/was for struct fb_info.flags. You have struct > fb_videomode.flag. The valid flags for this field are at [1]. If > anything, the field could be initialized to FB_MODE_IS_UNKNOWN, which > has the same value. > > [1] https://elixir.bootlin.com/linux/latest/source/include/linux/fb.h#L681 FB_MODE_IS_UNKNOWN sounds very reasonable to me. Would you agree using that instead? > > > > Also, I prefer "sh:" as the architecture prefix, not "arch/sh:". > > Ok. Thanks. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH 08/17] arch/sh: Do not assign FBINFO_FLAG_DEFAULT to fb_videomode.flag
Hi Thomas!
On Mon, 2023-07-10 at 14:50 +0200, Thomas Zimmermann wrote:
> FBINFO_FLAG_DEFAULT is a flag for a framebuffer in struct fb_info.
> Flags for videomodes are prefixed with FB_MODE_. FBINFO_FLAG_DEFAULT
> is 0 and the static declaration already clears the memory area of
> sh7763fb_videomode. So remove the assignment.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Yoshinori Sato
> Cc: Rich Felker
> Cc: John Paul Adrian Glaubitz
> ---
> arch/sh/boards/mach-sh7763rdp/setup.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/sh/boards/mach-sh7763rdp/setup.c
> b/arch/sh/boards/mach-sh7763rdp/setup.c
> index 97e715e4e9b3..345f2b76c85a 100644
> --- a/arch/sh/boards/mach-sh7763rdp/setup.c
> +++ b/arch/sh/boards/mach-sh7763rdp/setup.c
> @@ -119,7 +119,6 @@ static struct fb_videomode sh7763fb_videomode = {
> .vsync_len = 1,
> .sync = 0,
> .vmode = FB_VMODE_NONINTERLACED,
> - .flag = FBINFO_FLAG_DEFAULT,
> };
>
> static struct sh7760fb_platdata sh7763fb_def_pdata = {
I would argue that the current code is more readable that your proposed change.
I agree that it's a no-op, but code is not just about functionality but also
readability, isn't it?
Also, I prefer "sh:" as the architecture prefix, not "arch/sh:".
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH v3 16/19] arch/sh: Implement with generic helpers
On Mon, 2023-04-17 at 14:56 +0200, Thomas Zimmermann wrote:
> Replace the architecture's fbdev helpers with the generic
> ones from . No functional changes.
>
> v2:
> * use default implementation for fb_pgprotect() (Arnd)
>
> Signed-off-by: Thomas Zimmermann
> Cc: Yoshinori Sato
> Cc: Rich Felker
> Cc: John Paul Adrian Glaubitz
> ---
> arch/sh/include/asm/fb.h | 15 +--
> 1 file changed, 1 insertion(+), 14 deletions(-)
>
> diff --git a/arch/sh/include/asm/fb.h b/arch/sh/include/asm/fb.h
> index 9a0bca2686fd..19df13ee9ca7 100644
> --- a/arch/sh/include/asm/fb.h
> +++ b/arch/sh/include/asm/fb.h
> @@ -2,19 +2,6 @@
> #ifndef _ASM_FB_H_
> #define _ASM_FB_H_
>
> -#include
> -#include
> -#include
> -
> -static inline void fb_pgprotect(struct file *file, struct vm_area_struct
> *vma,
> - unsigned long off)
> -{
> - vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
> -}
> -
> -static inline int fb_is_primary_device(struct fb_info *info)
> -{
> - return 0;
> -}
> +#include
>
> #endif /* _ASM_FB_H_ */
Acked-by: John Paul Adrian Glaubitz
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH v3 16/19] arch/sh: Implement with generic helpers
Hi Thomas!
On Mon, 2023-04-17 at 16:06 +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 17.04.23 um 15:02 schrieb John Paul Adrian Glaubitz:
> > Hi Thomas!
> >
> > On Mon, 2023-04-17 at 14:56 +0200, Thomas Zimmermann wrote:
> > > Replace the architecture's fbdev helpers with the generic
> > > ones from . No functional changes.
> > >
> > > v2:
> > > * use default implementation for fb_pgprotect() (Arnd)
> > >
> > > Signed-off-by: Thomas Zimmermann
> > > Cc: Yoshinori Sato
> > > Cc: Rich Felker
> > > Cc: John Paul Adrian Glaubitz
> > > ---
> > > arch/sh/include/asm/fb.h | 15 +--
> > > 1 file changed, 1 insertion(+), 14 deletions(-)
> > >
> > > diff --git a/arch/sh/include/asm/fb.h b/arch/sh/include/asm/fb.h
> > > index 9a0bca2686fd..19df13ee9ca7 100644
> > > --- a/arch/sh/include/asm/fb.h
> > > +++ b/arch/sh/include/asm/fb.h
> > > @@ -2,19 +2,6 @@
> > > #ifndef _ASM_FB_H_
> > > #define _ASM_FB_H_
> > >
> > > -#include
> > > -#include
> > > -#include
> > > -
> > > -static inline void fb_pgprotect(struct file *file, struct vm_area_struct
> > > *vma,
> > > - unsigned long off)
> > > -{
> > > - vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
> > > -}
> >
> > Looking at the macro in asm-generic/fb.h, fb_pgprotect() is being replaced
> > with
> > a no-op function. Is that intentional? Can you briefly explain the
> > background
> > for this change?
>
> Patch 01 of this patchset changes the generic fb_pgprotect() to set
> pgprot_writecombine(). So on SH, there should be no change at all.
>
Ah, I missed that, thanks for the explanation. Let me check and Ack your patch
then. I assume you will be taking this patch as part of the whole series through
your own tree?
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH v3 16/19] arch/sh: Implement with generic helpers
Hi Thomas!
On Mon, 2023-04-17 at 14:56 +0200, Thomas Zimmermann wrote:
> Replace the architecture's fbdev helpers with the generic
> ones from . No functional changes.
>
> v2:
> * use default implementation for fb_pgprotect() (Arnd)
>
> Signed-off-by: Thomas Zimmermann
> Cc: Yoshinori Sato
> Cc: Rich Felker
> Cc: John Paul Adrian Glaubitz
> ---
> arch/sh/include/asm/fb.h | 15 +--
> 1 file changed, 1 insertion(+), 14 deletions(-)
>
> diff --git a/arch/sh/include/asm/fb.h b/arch/sh/include/asm/fb.h
> index 9a0bca2686fd..19df13ee9ca7 100644
> --- a/arch/sh/include/asm/fb.h
> +++ b/arch/sh/include/asm/fb.h
> @@ -2,19 +2,6 @@
> #ifndef _ASM_FB_H_
> #define _ASM_FB_H_
>
> -#include
> -#include
> -#include
> -
> -static inline void fb_pgprotect(struct file *file, struct vm_area_struct
> *vma,
> - unsigned long off)
> -{
> - vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
> -}
Looking at the macro in asm-generic/fb.h, fb_pgprotect() is being replaced with
a no-op function. Is that intentional? Can you briefly explain the background
for this change?
> -static inline int fb_is_primary_device(struct fb_info *info)
> -{
> - return 0;
> -}
> +#include
>
> #endif /* _ASM_FB_H_ */
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: remove arch/sh
Hi Steve! On Mon, 2023-02-06 at 10:08 +1100, Stephen Rothwell wrote: > Hi, > > On Fri, 3 Feb 2023 09:30:37 +0100 Christoph Hellwig wrote: > > > > On Fri, Feb 03, 2023 at 09:24:46AM +0100, John Paul Adrian Glaubitz wrote: > > > Since this is my very first time stepping up as a kernel maintainer, I > > > was hoping > > > to get some pointers on what to do to make this happen. > > > > > > So far, we have set up a new kernel tree and I have set up a local > > > development and > > > test environment for SH kernels using my SH7785LCR board as the target > > > platform. > > > > > > Do I just need to send a patch asking to change the corresponding entry > > > in the > > > MAINTAINERS file? > > > > I'm not sure a there is a document, but: > > > > - add the MAINTAINERS change to your tree > > - ask Stephen to get your tree included in linux-next > > And by "Stephen", Christoph means me. When you are ready, please send > me a request to include your tree/branch in linux-next (usually the > branch is called something like "for-next" or just "next") telling me > the git URL, and the contacts I should send email to if there are > conflicts/build issues with the branch. I will then fetch the branch > every time I create a new linux-next release (most work days), so all > you need to do is update that branch each time you are ready to publish > more commits. I'm in the MAINTAINERS now in Linus' tree. I have requested a kernel.org account now and will hopefully have my trees set up later this week. I'll let you know about the URLs as soon as possible. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: remove arch/sh
On Wed, 2023-02-08 at 21:09 -0600, Rob Landley wrote: > > Geert has suggested to wait with adding a tree source to the entry until I > > get my > > own kernel.org account. I have enough GPG signatures from multiple kernel > > developers > > on my GPG key, so I think it shouldn't be too difficult to qualify for an > > account. > > So you're not planning to use https://lk.j-core.org/J-Core-Developers/sh-linux > but push to kernel.org and ask Linus to pull from there? Yes, that's what Geert recommended. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: remove arch/sh
Hi Huacei! On Wed, 2023-02-08 at 20:24 +0800, Huacai Chen wrote: > Emm, maybe this patch has its chance to be merged now. :) > > https://lore.kernel.org/linux-sh/caahv-h6siotvkzpks4aabejgzcqtwp3tiha0+0hgz1+mu3x...@mail.gmail.com/T/#u Yes, that's the plan. We're collecting the various patches people have sent in for arch/sh, review and test them and apply them. My test board is running the latest kernel now, so I can test new patches, too. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: remove arch/sh
Hi Randy! On Tue, 2023-02-07 at 17:31 -0800, Randy Dunlap wrote: > > On 2/7/23 01:06, John Paul Adrian Glaubitz wrote: > > Hello Christoph! > > > > On Fri, 2023-02-03 at 08:14 +0100, Christoph Hellwig wrote: > > > On Mon, Jan 16, 2023 at 09:52:10AM +0100, John Paul Adrian Glaubitz wrote: > > > > We have had a discussion between multiple people invested in the SuperH > > > > port and > > > > I have decided to volunteer as a co-maintainer of the port to support > > > > Rich Felker > > > > when he isn't available. > > > > > > So, this still isn't reflected in MAINTAINERS in linux-next. When > > > do you plan to take over? What platforms will remain supported and > > > what can we start dropping due to being unused and unmaintained? > > > > I'm getting everything ready now with Geert's help and I have a probably > > dumb > > question regarding the MAINTAINERS file change: Shall I just add myself as > > an > > additional maintainer first or shall I also drop Yoshinori Sato? > > > > Also, is it desirable to add a "T:" entry for the kernel tree? > > Yes, definitely. Geert has suggested to wait with adding a tree source to the entry until I get my own kernel.org account. I have enough GPG signatures from multiple kernel developers on my GPG key, so I think it shouldn't be too difficult to qualify for an account. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: remove arch/sh
Hello Christoph! On Fri, 2023-02-03 at 08:14 +0100, Christoph Hellwig wrote: > On Mon, Jan 16, 2023 at 09:52:10AM +0100, John Paul Adrian Glaubitz wrote: > > We have had a discussion between multiple people invested in the SuperH > > port and > > I have decided to volunteer as a co-maintainer of the port to support Rich > > Felker > > when he isn't available. > > So, this still isn't reflected in MAINTAINERS in linux-next. When > do you plan to take over? What platforms will remain supported and > what can we start dropping due to being unused and unmaintained? I'm getting everything ready now with Geert's help and I have a probably dumb question regarding the MAINTAINERS file change: Shall I just add myself as an additional maintainer first or shall I also drop Yoshinori Sato? Also, is it desirable to add a "T:" entry for the kernel tree? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: remove arch/sh
Hi Stephen! On Mon, 2023-02-06 at 10:08 +1100, Stephen Rothwell wrote: > Hi, > > On Fri, 3 Feb 2023 09:30:37 +0100 Christoph Hellwig wrote: > > > > On Fri, Feb 03, 2023 at 09:24:46AM +0100, John Paul Adrian Glaubitz wrote: > > > Since this is my very first time stepping up as a kernel maintainer, I > > > was hoping > > > to get some pointers on what to do to make this happen. > > > > > > So far, we have set up a new kernel tree and I have set up a local > > > development and > > > test environment for SH kernels using my SH7785LCR board as the target > > > platform. > > > > > > Do I just need to send a patch asking to change the corresponding entry > > > in the > > > MAINTAINERS file? > > > > I'm not sure a there is a document, but: > > > > - add the MAINTAINERS change to your tree > > - ask Stephen to get your tree included in linux-next > > And by "Stephen", Christoph means me. When you are ready, please send > me a request to include your tree/branch in linux-next (usually the > branch is called something like "for-next" or just "next") telling me > the git URL, and the contacts I should send email to if there are > conflicts/build issues with the branch. I will then fetch the branch > every time I create a new linux-next release (most work days), so all > you need to do is update that branch each time you are ready to publish > more commits. Thanks a lot! I will start with that tomorrow with Geert giving me some guidance. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: remove arch/sh
Hi Geert! On Fri, 2023-02-03 at 11:33 +0100, Geert Uytterhoeven wrote: > Hi Adrian, > > On Fri, Feb 3, 2023 at 11:29 AM John Paul Adrian Glaubitz > wrote: > > On Fri, 2023-02-03 at 09:30 +0100, Christoph Hellwig wrote: > > > On Fri, Feb 03, 2023 at 09:24:46AM +0100, John Paul Adrian Glaubitz wrote: > > > > Since this is my very first time stepping up as a kernel maintainer, I > > > > was hoping > > > > to get some pointers on what to do to make this happen. > > > > > > > > So far, we have set up a new kernel tree and I have set up a local > > > > development and > > > > test environment for SH kernels using my SH7785LCR board as the target > > > > platform. > > > > > > > > Do I just need to send a patch asking to change the corresponding entry > > > > in the > > > > MAINTAINERS file? > > > > > > I'm not sure a there is a document, but: > > > > > > - add the MAINTAINERS change to your tree > > > - ask Stephen to get your tree included in linux-next > > > > > > then eventually send a pull request to Linus with all of that. Make > > > sure it's been in linux-next for a while. > > > > OK, thanks for the pointers! Will try to get this done by next week. > > > > We're still discussing among SuperH developer community whether there will > > be a second > > maintainer, so please bear with us a few more days. I will collect patches > > in the > > meantime. > > Thanks a lot! > > If you need any help with process, setup, ... don't hesitate to ask > (on e.g. #renesas-soc on Libera). Thanks a lot! I've got some real-life tasks to do today, but I will join later today. And I will ask questions ;-). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: remove arch/sh
Hi Christoph! On Fri, 2023-02-03 at 09:30 +0100, Christoph Hellwig wrote: > On Fri, Feb 03, 2023 at 09:24:46AM +0100, John Paul Adrian Glaubitz wrote: > > Since this is my very first time stepping up as a kernel maintainer, I was > > hoping > > to get some pointers on what to do to make this happen. > > > > So far, we have set up a new kernel tree and I have set up a local > > development and > > test environment for SH kernels using my SH7785LCR board as the target > > platform. > > > > Do I just need to send a patch asking to change the corresponding entry in > > the > > MAINTAINERS file? > > I'm not sure a there is a document, but: > > - add the MAINTAINERS change to your tree > - ask Stephen to get your tree included in linux-next > > then eventually send a pull request to Linus with all of that. Make > sure it's been in linux-next for a while. OK, thanks for the pointers! Will try to get this done by next week. We're still discussing among SuperH developer community whether there will be a second maintainer, so please bear with us a few more days. I will collect patches in the meantime. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: remove arch/sh
Hello Christoph! On Fri, 2023-02-03 at 08:14 +0100, Christoph Hellwig wrote: > On Mon, Jan 16, 2023 at 09:52:10AM +0100, John Paul Adrian Glaubitz wrote: > > We have had a discussion between multiple people invested in the SuperH > > port and > > I have decided to volunteer as a co-maintainer of the port to support Rich > > Felker > > when he isn't available. > > So, this still isn't reflected in MAINTAINERS in linux-next. When > do you plan to take over? Since this is my very first time stepping up as a kernel maintainer, I was hoping to get some pointers on what to do to make this happen. So far, we have set up a new kernel tree and I have set up a local development and test environment for SH kernels using my SH7785LCR board as the target platform. Do I just need to send a patch asking to change the corresponding entry in the MAINTAINERS file? > What platforms will remain supported and what can we start dropping due to > being unused and unmaintained? This has not been sorted out yet. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PULL] drm-misc-next
Hi Thomas! On 1/23/23 16:35, Thomas Zimmermann wrote: The only thing that is not supported any longer is hardware-accelerated 3d rendering. However, this has not worked anyway, as Mesa has dropped support for those chips a long time ago. Correct me if I'm wrong, but I thought that's what Mesa Classic was forked off for? AFAIK Mesa classic is for old radeon, i915 and old nouveau code. The so-called amber branch: https://docs.mesa3d.org/amber.html But the removed code is for even older hardware. https://docs.mesa3d.org/systems.html#deprecated-systems-and-drivers OK, thanks a lot for the clarification! I'm glad the 2D drivers will still work and it seems that news article on Phoronix [1] is a little misleading as from reading the it, it seems that driver support for the afore- mentioned hardware is dropped completely which is it not the case. Thanks, Adrian [1] https://www.phoronix.com/news/Linux-6.3-Dropping-Old-DRM -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PULL] drm-misc-next
Hi Thomas! On 1/23/23 16:13, Thomas Zimmermann wrote: Driver Changes: * Remove obsolete drivers for userspace modesetting i810, mga, r128, savage, sis, tdfx, via Is the Rage 128 GPU still supported via the generic modesetting driver? I'm asking because, we're still supporting PowerMacs in Debian Ports of which some of those are sporting a Rage 128 GPU. Similar question applies to the i810 GPU used in some old ThinkPads, for example. Yes, all of those chips are still supported by the generic modesetting drivers and even the old userspace Xorg drivers. OK, good to know. The only thing that is not supported any longer is hardware-accelerated 3d rendering. However, this has not worked anyway, as Mesa has dropped support for those chips a long time ago. Correct me if I'm wrong, but I thought that's what Mesa Classic was forked off for? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH/RFC 0/3] Atari DRM driver
Hi Geert! On 11/25/22 21:31, Geert Uytterhoeven wrote: This RFC patch series adds a DRM driver for the good old Atari ST/TT/Falcon hardware. It was developed and tested (only) on the ARAnyM emulator. I just remembered this WIP driver. Has there been any progress? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PULL] drm-misc-next
Hi Thomas! Driver Changes: * Remove obsolete drivers for userspace modesetting i810, mga, r128, savage, sis, tdfx, via Is the Rage 128 GPU still supported via the generic modesetting driver? I'm asking because, we're still supporting PowerMacs in Debian Ports of which some of those are sporting a Rage 128 GPU. Similar question applies to the i810 GPU used in some old ThinkPads, for example. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: remove arch/sh
Hello Christoph! On 1/16/23 08:13, Christoph Hellwig wrote: On Fri, Jan 13, 2023 at 09:09:52AM +0100, John Paul Adrian Glaubitz wrote: I'm still maintaining and using this port in Debian. It's a bit disappointing that people keep hammering on it. It works fine for me. What platforms do you (or your users) use it on? We have had a discussion between multiple people invested in the SuperH port and I have decided to volunteer as a co-maintainer of the port to support Rich Felker when he isn't available. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: remove arch/sh
Hi Rob! On 1/13/23 20:11, Rob Landley wrote: I actually would be willing to do it but I'm a bit hesitant as I'm not 100% sure my skills are sufficient. Maybe if someone can assist me? My skills aren't sufficient and I dunno how much time I have, but I can certainly assist. I test sh4 regularlyish and it's in the list of architectures I ship binaries and tiny VM images for, just refreshed tuesday: https://landley.net/toybox/downloads/binaries/0.8.9/ https://landley.net/toybox/downloads/binaries/mkroot/0.8.9/ (The sh2eb isn't a VM, it's a physical board I have here...) There is definitely interest in this architecture. I'm aware Rich hasn't been the most responsive maintainer. (I'm told he's on vacation with his family at the moment, according to the text I got about this issue from the J-core hardware guys in Japan.) Well, maybe we can just give it a try together ... The main reason we haven't converted everything to device tree is we only have access to test hardware for a subset of the boards. Pruning the list of supported boards and converting the rest to device tree might make sense. We can always add/convert boards back later... There is a patch by Yoshinori Sato which adds device tree support to SH. Maybe we can revive it. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: remove arch/sh
Hi Geert! On 1/13/23 09:26, Geert Uytterhoeven wrote: Indeed. The main issue is not the lack of people sending patches and fixes, but those patches never being applied by the maintainers. Perhaps someone is willing to stand up to take over maintainership? I actually would be willing to do it but I'm a bit hesitant as I'm not 100% sure my skills are sufficient. Maybe if someone can assist me? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: remove arch/sh
Hello! On 1/13/23 07:23, Christoph Hellwig wrote: arch/sh has been a long drag because it supports a lot of SOCs, and most of them haven't even been converted to device tree infrastructure. These SOCs are generally obsolete as well, and all of the support has been barely maintained for almost 10 years, and not at all for more than 1 year. Drop arch/sh and everything that depends on it. I'm still maintaining and using this port in Debian. It's a bit disappointing that people keep hammering on it. It works fine for me. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH 1/2] video: fbdev: amifb: remove dead APUS support
Hi Geert! On 6/2/20 12:37 PM, Bartlomiej Zolnierkiewicz wrote: > > On 5/14/20 10:21 PM, Geert Uytterhoeven wrote: > >> These #ifdefs are relics from APUS (Amiga Power-Up System), which >> added a PPC board. APUS support was killed off a long time ago, >> when arch/ppc/ was still king, but these #ifdefs were missed, because >> they didn't test for CONFIG_APUS. > > Reported-by: Al Viro > Reported-by: Geert Uytterhoeven > Signed-off-by: Bartlomiej Zolnierkiewicz > --- > drivers/video/fbdev/amifb.c | 63 > > 1 file changed, 63 deletions(-) What do you mean with the sentence "when arch/ppc/ was still king"? Does that mean - in the case we would re-add APUS support in the future, that these particular changes would not be necessary? I assume there could be new affordable PowerPC upgrade cards for the Amiga in the future as the PowerPC cards are still sought after by the Amiga community, so there is still demand for those on the market. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] video: fbdev: amifb: remove dead APUS support
Hi! On 6/2/20 1:04 PM, Geert Uytterhoeven wrote: >> What do you mean with the sentence "when arch/ppc/ was still king"? > > Ah, Bartl copied that from my email ;-) > > There used to be APUS support under arch/ppc/. > Later, 32-bit arch/ppc/ and 64-bit arch/ppc64/ were merged in a new\ > architecture port under arch/powerpc/, and the old ones were dropped. > APUS was never converted, and thus dropped. Ah, yes. Similar to the merge with x86. >> Does that mean - in the case we would re-add APUS support in the future, that >> these particular changes would not be necessary? > > They would still be necessary, as PowerPC doesn't grok m68k instructions. > Alternatively, we could just drop the m68k inline asm, and retain the C > version instead? I have no idea how big of a difference that would make > on m68k, using a more modern compiler than when the code was written > originally. Hmm, no idea. I would keep the assembly for the time being. This was just a question out of curiosity. We could still consider such a change if someone should consider working on APUS support again. > Note that all of this is used only for cursor handling, which I doubt is > actually used by any user space application. The only exception is the > DIVUL() macro, which is used once during initialization, thus also not > performance critical. I see, thanks. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM
Hello Christian! On 5/13/20 3:44 PM, Christian Zigotzky wrote: > AGP mode/support is deactivated on PowerPC and it doesn't work reliable > > And what does these lines mean: AGP mode is actually disabled in the Radeon driver for PowerPC as Alex has pointed out earlier in this thread [1]. Your graphics cards are basically running in PCI mode. I don't know, however, what the performance impact is when AGP mode is turned off. But it was turned off because it made PowerPC systems unstable. It also seems that AGP mode poses an additional maintenance burden for the KMS/DRM maintainers of the kernel so I understand the reasoning behind such a change. I wonder though whether it would make sense to move the support for older GPUs in legacy drivers, similar to what nVidia does with their commercial drivers. Thanks, Adrian > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=037d1a66ae640ca2723f47c0115ffa9e603699b3 > [2] https://bugs.freedesktop.org/show_bug.cgi?id=95017 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM
Hi David! On 5/12/20 7:04 AM, David VANTYGHEM wrote: > Im happy now that after your work, Debian and GRUB install fine on my > iMac G3. But Xserver doesn't start, I've got an AMD Rage 128 Pro AGP 4x > (see joined screenshot). This is an unrelated problem as the reason why you don't have a working graphics driver at the moment is because Debian's X.org maintainers removed a couple of older drivers from the package archive - without knowing these drivers are still used by PowerPC users. I will take over package maintainership of these drivers soon and re-upload them to the Debian archive. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM
Hi Alex! On 5/11/20 10:46 PM, Alex Deucher wrote: >>> Note there is no loss of functionality here, at least on radeon >>> hardware. It just comes down to which MMU gets used for access to >>> system memory, the AGP MMU on the chipset or the MMU built into the >>> GPU. On powerpc hardware, AGP has been particularly unstable, and >>> IIRC, AGP has been disabled by default on radeon on powerpc for a >>> while. >> Do you have a code reference at hand for this bit of information (AGP >> being disabled on Macs)? > > It was disabled 2 years ago: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=037d1a66ae640ca2723f47c0115ffa9e603699b3 Ok, that makes less dramatic then than I initially thought. I would still like to collect some voices from the debian-powerpc list though and maybe some comments from other directions. In any case, I agree with Christian's stance that if the code is supposed to be removed, it should be deprecated first. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM
On 5/11/20 10:05 PM, Alex Deucher wrote: >>> For Nouveau I'm not 100% sure, but from the code it of hand looks like we >>> can do it similar to Radeon. >>> >>> Please comment what you think about this. >> >> I would be against such a move as AGP graphics is still used by people >> running the powerpc >> and ppc64 Debian ports on their vintage hardware [1]. >> >> I have also CC'ed the debian-powerpc mailing list so that other users can >> voice their >> opinion. > > Note there is no loss of functionality here, at least on radeon > hardware. It just comes down to which MMU gets used for access to > system memory, the AGP MMU on the chipset or the MMU built into the > GPU. On powerpc hardware, AGP has been particularly unstable, and > IIRC, AGP has been disabled by default on radeon on powerpc for a > while. Do you have a code reference at hand for this bit of information (AGP being disabled on Macs)? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM
On 5/11/20 10:12 PM, Christian König wrote: > I unfortunately only have an x86 Mac to test this on, but as far as I know > the Radeon > AGP support for PowerPC is disabled for years already because it didn't > worked reliable. I have a current Debian unstable running on an iBook G4 with Radeon graphics enabled on a current kernel and graphics stack and it runs fine. Not sure though whether it currently employs all AGP features, but I would like to be able to continue using it and so are the users on the debian-powerpc mailing list. >>> So the idea here is to just go ahead and remove the support from Radeon and >>> Nouveau and >>> then drop the necessary code from TTM. >>> For Radeon this means that we just switch over to the driver specific page >>> tables and >>> everything should more or less continue to work. >>> >>> For Nouveau I'm not 100% sure, but from the code it of hand looks like we >>> can do it similar to Radeon. >>> >>> Please comment what you think about this. >> I would be against such a move as AGP graphics is still used by people >> running the powerpc >> and ppc64 Debian ports on their vintage hardware [1]. > > Please note that at least the Mac I was able to test with Radeon hardware > just continuous > to work. But it is certainly possible that some pre r3xx generation hardware > will break with this. > > We just stop using this bogus idea of trying to use uncached system memory as > "extension" of the > on board video memory and instead switch to the reliable device internal GART. Well, the title "Remove AGP support" in the subject implied something else to me which is why I wrote this mail. If this just applies to the mechanism to allow system memory to be used as graphics memory, the results may be different. > Maybe we should just deprecate the configuration option first? Would this change imply the removal of CONFIG_AGP_*? If yes, I assume that would kill CONFIG_AGP_UNINORTH which we have enabled on our PowerPC kernels for powerpc and ppc64. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Remove AGP support from Radeon/Nouveau/TTM
Hi Christian! > Well let's face it AGP is a total headache to maintain and dead for at least > 10+ years. > > We have a lot of x86 specific stuff in the architecture independent graphics > memory management > to get the caching right, abusing the DMA API on multiple occasions, need to > distinct between > AGP and driver specific page tables etc etc... AGP isn't exclusively used on x86 but there are also a lot of PowerPC desktop machines (Apple PowerMac, Pegasos etc) that employ AGP graphics. > So the idea here is to just go ahead and remove the support from Radeon and > Nouveau and > then drop the necessary code from TTM. > For Radeon this means that we just switch over to the driver specific page > tables and > everything should more or less continue to work. > > For Nouveau I'm not 100% sure, but from the code it of hand looks like we can > do it similar to Radeon. > > Please comment what you think about this. I would be against such a move as AGP graphics is still used by people running the powerpc and ppc64 Debian ports on their vintage hardware [1]. I have also CC'ed the debian-powerpc mailing list so that other users can voice their opinion. Thanks, Adrian > [1] https://cdimage.debian.org/cdimage/ports/2020-04-19/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] video: fbdev: remove dead igafb driver
Hi Bartlomiej!
On 10/18/2017 02:56 PM, Bartlomiej Zolnierkiewicz wrote:
igafb driver hasn't compiled since at least kernel v2.6.34 as
commit 6016a363f6b5 ("of: unify phandle name in struct device_node")
missed updating igafb.c to use dp->phandle instead of dp->node.
Would it take a lot of work to port the driver to the new interface?
I'm not sure which SPARC machines use this particular framebuffer, but
my plans are to fix up all these old framebuffer drivers. I have already
received several Amiga (Zorro) graphics cards for testing the updated
drivers on Amiga.
It could be that I actually have this particular SPARC framebuffer in
my hardware collection.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
