All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Wahren <stefan.wahren@i2se.com>
To: Maxime Ripard <maxime@cerno.tech>, Peter Robinson <pbrobinson@gmail.com>
Cc: Peter Mattern <pmattern@arcor.de>, dri-devel@lists.freedesktop.org
Subject: Re: drm/vc4: module dysfunctional on Raspberry Pi 3B as of 5.18.0
Date: Thu, 9 Jun 2022 00:47:52 +0200	[thread overview]
Message-ID: <3648b281-c6b0-a91c-2a4f-ddbee6988b3f@i2se.com> (raw)
In-Reply-To: <20220608143605.x4arwudst3nqeg7b@houat>

Hi,

Am 08.06.22 um 16:36 schrieb Maxime Ripard:
> Hi Peter(s)
>
> On Wed, Jun 08, 2022 at 02:10:19PM +0100, Peter Robinson wrote:
>> Hi Peter,
>>
>> Adding Stefan and Maxime
>>
>>> As of Linux 5.18.0, module vc4 apparently isn't working on Raspberry Pi
>>> 3B any more.
>>>
>>> If a monitor is attached to the device, the boot messages show up as
>>> usual, but right when KMS starts, the screen turns black. Similarly, the
>>> screen also turns black when the module is blacklisted at boot time and
>>> loaded from the running system.
>>> The problem looks quite similar to the one posted some months ago in [1].
> If I understand you properly, it results in a blank screen if the
> monitor is connected, but the system is still responsive?
>
> If so, it's a very different problem than the link you provided, since
> it was occurring when no monitor was connected and resulted in a total
> system hang.
>
>>> Unfortunately, looking through systemd's journal didn't seem to yield
>>> any real hint. Nevertheless, the results from grepping vc4 are
>> I'm seeing the same issue with vc4 on a RPi3 on 5.18.1 on Fedora so
>> can confirm the regression. Maxime would know what might be up here?

i assume you are using the downstream DTB?


Please provide the version/date of the GPU firmware?

> I tested on 5.18 on my 3B and it works well. Could you paste your kernel
> configuration and config.txt somewhere?
>
>>> → 5.17.1
>>>   > kernel: vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
>>>   > kernel: rc rc0: vc4 as /devices/platform/soc/3f902000.hdmi/rc/rc0
>>>   > kernel: input: vc4 as /devices/platform/soc/3f902000.hdmi/rc/rc0/input0
>>>   > kernel: vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4])
>>>   > kernel: vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops [vc4])
>>>   > kernel: vc4-drm soc:gpu: bound 3f004000.txp (ops vc4_txp_ops [vc4])
>>>   > kernel: vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops
>>> [vc4])
>>>   > kernel: vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops
>>> [vc4])
>>>   > kernel: vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops
>>> [vc4])
>>>   > kernel: vc4-drm soc:gpu: bound 3fc00000.v3d (ops vc4_v3d_ops [vc4])
>>>   > kernel: fb0: switching to vc4 from simple
>>>   > kernel: [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0
>>>   > kernel: vc4-drm soc:gpu: [drm] fb0: vc4drmfb frame buffer device
>>>   > systemd-logind[338]: Watching system buttons on /dev/input/event0 (vc4)
>>> → 5.18.0
>>>   > kernel: fb0: switching to vc4 from simple
>>>   > kernel: vc4-drm soc:gpu: bound 3f400000.hvs (ops vc4_hvs_ops [vc4])
>>>   > kernel: rc rc0: vc4 as /devices/platform/soc/3f902000.hdmi/rc/rc0
>>>   > kernel: input: vc4 as /devices/platform/soc/3f902000.hdmi/rc/rc0/input0
>>>   > kernel: vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4])
>>>   > kernel: vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops [vc4])
>>>   > kernel: vc4-drm soc:gpu: bound 3f004000.txp (ops vc4_txp_ops [vc4])
>>>   > kernel: vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops vc4_crtc_ops
>>> [vc4])
>>>   > kernel: vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops vc4_crtc_ops
>>> [vc4])
>>>   > kernel: vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops vc4_crtc_ops
>>> [vc4])
>>>   > kernel: vc4-drm soc:gpu: bound 3fc00000.v3d (ops vc4_v3d_ops [vc4])
>>>   > kernel: [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on minor 0
>>>   > kernel: vc4-drm soc:gpu: [drm] fb0: vc4drmfb frame buffer device
>>>   > systemd-logind[337]: Watching system buttons on /dev/input/event0 (vc4)
> Yeah, it doesn't look that different.
>
> Maxime

  parent reply	other threads:[~2022-06-08 22:48 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-05 18:01 drm/vc4: module dysfunctional on Raspberry Pi 3B as of 5.18.0 Peter Mattern
2022-06-08 13:10 ` Peter Robinson
2022-06-08 14:36   ` Maxime Ripard
2022-06-08 15:14     ` Peter Robinson
2022-06-08 15:36       ` Maxime Ripard
2022-06-09  9:23         ` Maxime Ripard
2022-06-09 11:49           ` Peter Robinson
2022-06-09 13:37           ` Peter Mattern
2022-06-08 22:47     ` Stefan Wahren [this message]
2022-06-09 11:52       ` Peter Robinson
2022-06-09 21:33         ` Stefan Wahren
2022-06-10 20:06           ` Stefan Wahren
2022-06-10 22:02           ` Peter Robinson
2022-06-09 13:08     ` Peter Mattern
2022-06-05 23:57 Stefan Wahren
2022-06-09 12:49 Peter Mattern

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3648b281-c6b0-a91c-2a4f-ddbee6988b3f@i2se.com \
    --to=stefan.wahren@i2se.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=maxime@cerno.tech \
    --cc=pbrobinson@gmail.com \
    --cc=pmattern@arcor.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.