Hi, thank you for your information. On our website you can find email addresses of companies and people. https://www.skymem.info In short, it’s like Google for emails. Best regards, Robert, Skymem team On Tue, Sep 27, 2022 at 8:46 PM Stefan Wahren <stefan.wahren@xxxxxxxx> wrote: > > Hi Maxime, > > Am 27.09.22 um 15:15 schrieb Maxime Ripard: > > On Tue, Sep 27, 2022 at 02:25:12PM +0200, Maxime Ripard wrote: > >> On Tue, Sep 27, 2022 at 01:42:40PM +0200, Maxime Ripard wrote: > >>> On Tue, Sep 27, 2022 at 01:12:35PM +0200, Stefan Wahren wrote: > >>>> Am 27.09.22 um 11:42 schrieb Maxime Ripard: > >>>>> On Tue, Sep 27, 2022 at 09:25:54AM +0200, Maxime Ripard wrote: > >>>>>> Hi Stefan, > >>>>>> > >>>>>> On Mon, Sep 26, 2022 at 08:50:12PM +0200, Stefan Wahren wrote: > >>>>>>> Am 26.09.22 um 14:47 schrieb Maxime Ripard: > >>>>>>>> On Mon, Sep 26, 2022 at 02:40:48PM +0200, Marc Kleine-Budde wrote: > >>>>>>>>> On 26.09.2022 14:08:04, Stefan Wahren wrote: > >>>>>>>>>> Hi Marc, > >>>>>>>>>> > >>>>>>>>>> Am 26.09.22 um 12:21 schrieb Marc Kleine-Budde: > >>>>>>>>>>> On 22.09.2022 17:06:00, Maxime Ripard wrote: > >>>>>>>>>>>>> I'm on a Raspberry Pi 3 Model B+ running current Debian testing ARM64, > >>>>>>>>>>>>> using Debian's v5.19 kernel (Debian's v5.18 was working flawless). > >>>>>>>>>>>>> > >>>>>>>>>>>>> | [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] > >>>>>>>>>>>>> | [ 0.000000] Linux version 5.19.0-1-arm64 (debian-kernel@xxxxxxxxxxxxxxxx) (gcc-11 (Debian 11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.90.20220713) #1 SMP Debian 5.19.6-1 (2022-0 > >>>>>>>>>>>>> 9-01) > >>>>>>>>>>>>> | [ 0.000000] Machine model: Raspberry Pi 3 Model B+ > >>>>>>>>>>>>> | [ 3.747500] raspberrypi-firmware soc:firmware: Attached to firmware from 2022-03-24T13:21:11 > >>>>>>>>>>>>> > >>>>>>>>>>>>> As soon a the vc4 module is loaded the following warnings hits 4 > >>>>>>>>>>>>> times, then the machine stops. > >>>>>>>>>>> [...] > >>>>>>>>>>> > >>>>>>>>>>>> The warning itself is fixed, both upstream and in stable (5.19.7). > >>>>>>>>>>> Ok. Debian is using 5.19.6 > >>>>>>>>>>> > >>>>>>>>>>>> It shouldn't have any relation to the hang though. Can you share your > >>>>>>>>>>>> setup? > >>>>>>>>>>> - config.txt: > >>>>>>>>>>> > >>>>>>>>>>> -------->8-------->8-------->8-------->8-------- > >>>>>>>>>>> gpu_mem=16 > >>>>>>>>>>> disable_splash=1 > >>>>>>>>>>> > >>>>>>>>>>> arm_64bit=1 > >>>>>>>>>>> enable_uart=1 > >>>>>>>>>>> uart_2ndstage=1 > >>>>>>>>>>> > >>>>>>>>>>> os_prefix=/u-boot/ > >>>>>>>>>>> > >>>>>>>>>>> [pi3] > >>>>>>>>>>> force_turbo=1 > >>>>>>>>>>> -------->8-------->8-------->8-------->8-------- > >>>>>>>>>>> > >>>>>>>>>>> - Raspberry Pi 3 Model B+ > >>>>>>>>>>> - no HDMI connected > >>>>>>>>>> Does it mean, the issue only occurs without HDMI connected? > >>>>>>>>>> If you didn't test with HDMI yet, could you please do? > >>>>>>>>> The error occurs with HDMI not connected, as vc4 is the gfx driver I > >>>>>>>>> thought this might be of interest. :) > >>>>>>>>> > >>>>>>>>> I don't have a HDMI monitor here, but I'll come back to you as soon as I > >>>>>>>>> get access to one (might take some time). > >>>>>>>> It's not the first time an issue like this one would occur. I'm trying > >>>>>>>> to make my Pi3 boot again, and will try to bisect the issue. > >>>>>>> yes the issue is only triggered without HDMI connected. I was able to > >>>>>>> reproduce with an older vc4 firmware from 2020 (don't want to upgrade yet). > >>>>>>> Kernel was also an arm64 build with defconfig. > >>>>>>> > >>>>>>> Here some rough starting point for bisection: > >>>>>>> > >>>>>>> 5.18.0 good > >>>>>>> 5.19.0 bad > >>>>>>> 5.19.6 bad > >>>>>> Sorry it took a bit of time, it looks like I found another bug while > >>>>>> trying to test this yesterday. > >>>>>> > >>>>>> Your datapoints are interesting though. I have a custom configuration > >>>>>> and it does boot 5.19 without an HDMI connected. > >>>>>> > >>>>>> So I guess it leaves us with either the firmware version being different > >>>>>> (I'm using a newer version, from March 2022), or the configuration. I'll > >>>>>> test with defconfig. > >>>>> So it turns out compiling vc4 as a module is the culprit. > >>>> Do you mean regardless of the kernel version in your case? > >>> No, I mean that, with vc4 as a module, 5.18 works but 5.19 doesn't, like > >>> Marc said. But if vc4 is built in, both work. > >>> > >>>> In my test cases i build vc4 always as module. > >>>> > >>>>> It's not clear to me why at this point, but the first register write in > >>>>> vc4_hdmi_reset stalls. > >>>> Sounds like timing issue or a missing dependency (clock or power domain) > >>> It felt like a clock or power domain issue to me indeed, but adding > >>> clk_ignore_unused and pd_ignore_unused isn't enough, so it's probably > >>> something a bit more complicated than just the clock / PD being > >>> disabled. > >> I found the offending patch: > >> https://lore.kernel.org/dri-devel/20220225143534.405820-13-maxime@xxxxxxxxxx/ > >> > >> That code was removed because it was made irrelevant by that earlier patch: > >> https://lore.kernel.org/dri-devel/20220225143534.405820-10-maxime@xxxxxxxxxx/ > >> > >> But it turns out that while it works when the driver is built-in, it > >> doesn't when it's a module. If we add a clk_hw_get_rate() call right > >> after that call to raspberrypi_fw_set_rate(), the rate returned is 0. > >> > >> I'm not entirely sure why, but I wonder if it's related to: > >> https://github.com/raspberrypi/linux/issues/4962#issuecomment-1228593439 > > Turns out it's not, since the Pi3 is using the clk-bcm2835 driver. > > FWIW i can confirm, that i see the same behavior: > > fd5894fa2413cca3e6a3ea713b2bd57281af2e86 bad > > 5b6ef06ea6225570bc0b33325306c7b8c6bdf5eb good > > > > > However, even reverting that patch fails. clk_set_min_rate fails because > > the rate is protected, but it doesn't look like it is anywhere for that > > clock, so I'm a bit confused. > > > > Even if we do remove the clock protection check in > > clk_core_set_rate_nolock(), clk_calc_new_rates() will then fail because > > the bcm2835 driver will round the clock rate below the minimum, which is > > rejected. > > > > I'm not entirely sure what to do at this point. I guess the proper fix > > would be to: > > - Figure out why it's considered protected when it's not (or shouldn't be) > > - Make the driver compute an acceptable rate for that clock > > - Reintroduce the clk_set_min_rate call to HDMI's runtime_resume, or > > some other equivalent code > > > > Maxime > > _______________________________________________ > linux-rpi-kernel mailing list > linux-rpi-kernel@xxxxxxxxxxxxxxxxxxx > http://lists.infradead.org/mailman/listinfo/linux-rpi-kernel
