linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Dave Stevenson <dave.stevenson@raspberrypi.org>
To: Peter Robinson <pbrobinson@gmail.com>
Cc: Stefan Wahren <stefan.wahren@i2se.com>,
	devel@driverdev.osuosl.org, tiwai@suse.de,
	Greg KH <gregkh@linuxfoundation.org>,
	mikebrady@eircom.net, Eric Anholt <eric@anholt.net>,
	"moderated list:BROADCOM BCM2835 ARM ARCHITECTURE"
	<linux-rpi-kernel@lists.infradead.org>,
	nsaenzjulienne@suse.de, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH RFC 00/11] staging: vc04_services: Improve driver load/unload
Date: Fri, 11 Jan 2019 16:43:27 +0000	[thread overview]
Message-ID: <CAAoAYcNUp2fjdqHgae6wTaL6i7ztfn4zUxri1EjbBatgQb76NA@mail.gmail.com> (raw)
In-Reply-To: <CALeDE9OZpGVD4HGxCqjtWf1qCXxkH1YAAM28na7tBvFyRpHJow@mail.gmail.com>

Hi Peter

On Fri, 11 Jan 2019 at 06:10, Peter Robinson <pbrobinson@gmail.com> wrote:
>
> Hi Stefan,
>
> > > > > I get difference results with 5.0-rc1 but neither of the above apps
> > > > > work either, will follow up based on the rest of the thread there.
> > > > >
> > > >
> > > > My first step with Raspbian is to enable the Camera interface which results into an appending of the following lines to config.txt:
> > > >
> > > > start_x=1
> > > > gpu_mem=128
> > > >
> > > > AFAIK a smaller value for gpu_mem wont work. Please provide your settings which results in this crash.
> > >
> > > start_x=1
> > > gpu_mem=64
> >
> > even with those settings i'm getting a picture in qv4l2 (v1.12.3) and no crash.
> >
> > According to dmesg i also have 64M reserved for CMA. How many do you have?
>
> I have 192Mb of CMA with LXDE, the vc4 driver uses CMA rather than the
> gpu_mem via the firmware so that's what we set it to (and to 256Mb for
> GNOME)

As Stefan says, with Raspbian the default gpu_mem to use the camera is 128MB.
The memory required depends on your use case as it includes the
buffers for the output images.
Checking on a running system, a V2 camera streaming 1080P YU12 with 3
V4L2 buffers is using 58MB of gpu_mem for the camera stack. H264
encode isntead of YU12 and it's around 63MB.
With the vc4 driver loaded there's only a small number of other
allocations left from the gpu_mem heap, so it's around the 70MB mark
that will be the minimum to get the camera running.

> > Does your qc4l2 make use of OpenGL (not in my case)?
>
> Yes, mine does. The crash with qv4l2 was only when I tried Cheese
> first, if I reboot and just use qv4l2 it works fine when configured
> with 128Mb without any crash. Which display driver are you using? Are
> you using vc4 or the proprietary closed one? With vc4 using cma rather
> than gpu_mem I wonder if we can reduce the amount needed there, but in
> the interim I've at least now got picture output when using purely
> qv4l2 and a reserve of 128Mb
>
> I'm not sure quite what gstreamer1/cheese is doing to cause that crash.

Can you confirm what resolution and format they are using in your
failure case? "v4l2-ctl -V" after they've been run will tell you.

Your earlier request:
> As a side note it would be a useful debug feature from a support PoV
> if the following line could also note which firmware is loaded:
>
> [    8.087691] raspberrypi-firmware soc:firmware: Attached to firmware
> from 2019-01-09 20:07
>
> Something like "attached to extended/reduced/whatecer firmware from XXXX-XX-XX"

A very valid suggestion.
I've made the firmware changes to advertise the build variant and
firmware hash via the mailbox service, and that should be in the next
firmware release.
Pull request https://github.com/raspberrypi/linux/pull/2806 has added
the Linux kernel changes to our kernel rpi-4.19.y branch.
With the updated firmware, "vcgencmd version" will also report the
build variant for you.

  Dave

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-01-11 16:43 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-25 15:29 [PATCH RFC 00/11] staging: vc04_services: Improve driver load/unload Stefan Wahren
2018-10-25 15:29 ` [PATCH RFC 01/11] staging: bcm2835-camera: Abort probe if there is no camera Stefan Wahren
2018-12-19  8:07   ` Peter Robinson
2018-10-25 15:29 ` [PATCH RFC 02/11] staging: bcm2835-camera: fix module autoloading Stefan Wahren
2018-12-19  7:54   ` Peter Robinson
2018-10-25 15:29 ` [PATCH RFC 03/11] staging: bcm2835-camera: Move module info to the end Stefan Wahren
2018-12-19  7:53   ` Peter Robinson
2018-10-25 15:29 ` [PATCH RFC 04/11] staging: vchiq_arm: Fix platform device unregistration Stefan Wahren
2018-10-26  8:07   ` Dan Carpenter
2018-10-25 15:29 ` [PATCH RFC 05/11] staging: vchiq_arm: Fix camera device registration Stefan Wahren
2018-10-25 15:29 ` [PATCH RFC 06/11] staging: vchiq_arm: Register a platform device for audio Stefan Wahren
2018-10-26  8:09   ` Dan Carpenter
2018-10-26  8:18     ` Dan Carpenter
2018-10-25 15:29 ` [PATCH RFC 07/11] staging: bcm2835-audio: Enable compile test Stefan Wahren
2018-10-25 15:29 ` [PATCH RFC 08/11] staging: bcm2835-audio: use module_platform_driver() macro Stefan Wahren
2018-10-25 15:29 ` [PATCH RFX 09/11] staging: bcm2835-audio: Drop DT dependency Stefan Wahren
2018-10-25 15:29 ` [PATCH RFC 10/11] staging: bcm2835-camera: Provide more specific probe error messages Stefan Wahren
2018-10-25 15:29 ` [PATCH RFC 11/11] staging: bcm2835-camera: Add hint about possible faulty config Stefan Wahren
2018-10-26 10:55   ` Nicolas Saenz Julienne
2018-10-26 11:06 ` [PATCH RFC 00/11] staging: vc04_services: Improve driver load/unload Nicolas Saenz Julienne
2018-10-28 20:10   ` Stefan Wahren
2019-01-08  7:21 ` Peter Robinson
2019-01-08  8:48   ` Stefan Wahren
2019-01-08  8:56     ` Peter Robinson
2019-01-08 10:20       ` Stefan Wahren
2019-01-10  5:09         ` Peter Robinson
2019-01-10  6:24           ` Stefan Wahren
2019-01-10  6:34             ` Peter Robinson
2019-01-10 18:48               ` Stefan Wahren
2019-01-11  6:10                 ` Peter Robinson
2019-01-11 16:43                   ` Dave Stevenson [this message]
2019-01-12  5:26                     ` Peter Robinson
2019-01-10  7:05             ` Peter Robinson
2019-01-08 17:10   ` Dave Stevenson
2019-01-09  8:33     ` Stefan Wahren
2019-01-09 11:58       ` Nicolas Saenz Julienne
2019-01-10  5:22     ` Peter Robinson

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=CAAoAYcNUp2fjdqHgae6wTaL6i7ztfn4zUxri1EjbBatgQb76NA@mail.gmail.com \
    --to=dave.stevenson@raspberrypi.org \
    --cc=devel@driverdev.osuosl.org \
    --cc=eric@anholt.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-rpi-kernel@lists.infradead.org \
    --cc=mikebrady@eircom.net \
    --cc=nsaenzjulienne@suse.de \
    --cc=pbrobinson@gmail.com \
    --cc=stefan.wahren@i2se.com \
    --cc=tiwai@suse.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).