On Mon, Mar 04, 2024 at 11:07:22AM +0100, Geert Uytterhoeven wrote: > Hi Maxime, > > On Mon, Mar 4, 2024 at 10:15 AM Maxime Ripard <mrip...@kernel.org> wrote: > > On Mon, Mar 04, 2024 at 09:12:38AM +0100, Geert Uytterhoeven wrote: > > > On Sun, Mar 3, 2024 at 10:30 AM Geert Uytterhoeven <ge...@linux-m68k.org> > > > wrote: > > > > On Sun, Mar 3, 2024 at 3:30 AM Randy Dunlap <rdun...@infradead.org> > > > > wrote: > > > > > On 3/2/24 14:10, Guenter Roeck wrote: > > > > > > While checkpatch is indeed of arguable value, I think it would help > > > > > > a > > > > > > lot not having to bother about the persistent _build_ failures on > > > > > > 32-bit systems. You mentioned the fancy drm CI system above, but > > > > > > they > > > > > > don't run tests and not even test builds on 32-bit targets, which > > > > > > has > > > > > > repeatedly caused (and currently does cause) build failures in drm > > > > > > code when trying to build, say, arm:allmodconfig in linux-next. Most > > > > > > trivial build failures in linux-next (and, yes, sometimes mainline) > > > > > > could be prevented with a simple generic CI. > > > > > > > > > > Yes, definitely. Thanks for bringing that up. > > > > > > > > +1 > > > > > > > Kisskb can send out email when builds get broken, and when they get > > > > fixed again. I receive such emails for the m68k builds. > > > > > > Like this (yes, one more in DRM; sometimes I wonder if DRM is meant only > > > for 64-bit little-endian platforms with +200 GiB/s memory bandwidth): > > > > > > ---8<------------------------------------------------------------------- > > > Subject: kisskb: FAILED linux-next/m68k-allmodconfig/m68k-gcc8 Mon Mar > > > 04, 06:35 > > > To: ge...@linux-m68k.org > > > Date: Mon, 04 Mar 2024 08:05:14 -0000 > > > > > > FAILED linux-next/m68k-allmodconfig/m68k-gcc8 Mon Mar 04, 06:35 > > > > > > http://kisskb.ellerman.id.au/kisskb/buildresult/15135537/ > > > > > > Commit: Add linux-next specific files for 20240304 > > > 67908bf6954b7635d33760ff6dfc189fc26ccc89 > > > Compiler: m68k-linux-gcc (GCC) 8.5.0 / GNU ld (GNU Binutils) 2.36.1 > > > > > > Possible errors > > > --------------- > > > > > > ERROR: modpost: "__udivdi3" [drivers/gpu/drm/sun4i/sun4i-drm-hdmi.ko] > > > undefined! > > > make[3]: *** [scripts/Makefile.modpost:145: Module.symvers] Error 1 > > > make[2]: *** [Makefile:1871: modpost] Error 2 > > > make[1]: *** [Makefile:240: __sub-make] Error 2 > > > make: *** [Makefile:240: __sub-make] Error 2 > > > > > > No warnings found in log. > > > ------------------------------------------------------------------->8--- > > > > The driver is meant for a controller featured in an SoC with a Cortex-A8 > > ARM CPU and less than a GiB/s memory bandwidth. > > Good, so the hardware cannot possibly need 64-bit pixel clock values ;-)
This is an early patch to convert that function into a framework hook implementation. HDMI 2.1 has a max TMDS character rate of slightly less than 6GHz, so larger than 2^32 - 1. So yes, this driver doesn't need to. The framework does however. > BTW, doesn't the build fail on arm32, too? It seems like gcc vs clang plays a role too. I had the same defconfig building for arm with gcc and reporting the error above with clang. I didn't look further because there was something to fix indeed. Maxime
signature.asc
Description: PGP signature
