[libcamera-devel] Need help with RaspberryPI pipeline bringup on Android
Naushir Patuck
naush at raspberrypi.com
Wed Nov 10 19:06:02 CET 2021
Hi Roman,
Thanks for the update.
Unfortunately I don't really understand why removing that change gets your
environment working. I think I probably need some guidance from the
libcamera team about buffer allocations happening in the android layer.
Perhaps you can post a log of your new errors?
The buffer allocation change, while not critical, really wants to go in
with this series. So hopefully we can come to some conclusion soon.
Regards,
Naush
On Wed, 10 Nov 2021, 4:47 pm Roman Stratiienko, <r.stratiienko at gmail.com>
wrote:
> Oh it works perfectly if I revert [PATCH 2/3] pipeline: raspberrypi:
> Rework the internal buffer allocation scheme
>
> ср, 10 нояб. 2021 г. в 18:25, Roman Stratiienko <r.stratiienko at gmail.com>:
> >
> > Hi Naush,
> >
> > Thank you for the patches.
> > I tested my setup with them and it made the behaviour slightly
> > different. Now the camera app draws the first frame and freezes.
> > I'm now playing with overallocation. Meanwhile I would like to ask one
> thing.
> > Cache hit is determined by comparing file descriptors and sizes of the
> buffers.
> > Is it safe to do in case of external buffers? FD may be different for
> > the same buffer, using inode for this purpose looks like a better
> > solution.
> > What do you think?
> >
> > вт, 9 нояб. 2021 г. в 15:39, Roman Stratiienko <r.stratiienko at gmail.com
> >:
> > >
> > > вт, 9 нояб. 2021 г. в 15:35, Naushir Patuck <naush at raspberrypi.com>:
> > > >
> > > > Hi Roman,
> > > >
> > > > On Tue, 9 Nov 2021 at 13:28, Roman Stratiienko <
> r.stratiienko at gmail.com> wrote:
> > > >>
> > > >> To make Android happy I've applied one patch:
> > > >>
> > > >> --- a/src/libcamera/pipeline/raspberrypi/raspberrypi.cpp
> > > >> +++ b/src/libcamera/pipeline/raspberrypi/raspberrypi.cpp
> > > >> @@ -429,9 +429,10 @@ CameraConfiguration::Status
> > > >> RPiCameraConfiguration::validate()
> > > >> rawCount++;
> > > >> } else {
> > > >> + cfg.bufferCount = 3;
> > > >> outSize[outCount] = std::make_pair(count,
> cfg.size);
> > > >> /* Record the largest resolution for fixups
> later. */
> > > >> if (maxSize < cfg.size) {
> > > >>
> > > >> (Similar are done in other pipelines).
> > > >>
> > > >> And it seems to me that it somehow conflicts with raspberrypi
> pipeline
> > > >> internals.
> > > >
> > > >
> > > > The problem seems to be the number of cache slots is not set up
> correctly for your usage.
> > > > From what I can gather, the Android layer allocated its own buffers
> to use by the pipeline
> > > > handler, but the number of cache slots the pipeline handler
> allocates is smaller than
> > > > the total number of buffers available. Hence the failure where the
> cache may not be able
> > > > to find a free slot to use.
> > > >
> > > > I've been meaning to address this bit of logic for a long time now,
> so perhaps this is
> > > > a good time to do this. It's not a big change, but there are
> certain assumptions to be made
> > > > to balance between over allocation and loss of performance. I will
> post a patch soon, would
> > > > you be able to try it out in your environment and report if it
> solves your issue?
> > >
> > >
> > > Sure. With great pleasure.
> > >
> > >
> > > >
> > > > Thanks,
> > > > Naush
> > > >
> > > >>
> > > >>
> > > >> вт, 9 нояб. 2021 г. в 13:54, Roman Stratiienko <
> r.stratiienko at gmail.com>:
> > > >> >
> > > >> > Hi Naushir,
> > > >> >
> > > >> > Thanks a lot for your support. You were right, it returns with
> error
> > > >> > in that place. I'm correctly investigating why there is no buffer
> in
> > > >> > the cache.
> > > >> >
> > > >> > вт, 9 нояб. 2021 г. в 12:32, Naushir Patuck <
> naush at raspberrypi.com>:
> > > >> > >
> > > >> > >
> > > >> > > On Tue, 9 Nov 2021 at 10:26, Naushir Patuck <
> naush at raspberrypi.com> wrote:
> > > >> > >>
> > > >> > >> Hi Roman,
> > > >> > >>
> > > >> > >> Not sure if the email thread is the best place to discuss your
> issue, so perhaps create a bug report at bugs.libcamera.org.
> > > >> > >> Onto the actual issue - it seems like the ISP gets starved of
> request buffers and fails to produce output and the pipeline handler stalls.
> > > >> > >> The reason it gets starved is likely to be due to the
> following errors in the log:
> > > >> > >>
> > > >> > >> 10-07 14:37:46.726 360 442 D libcamera: DEBUG RPISTREAM
> rpi_stream.cpp:226 Queuing buffer 1048579 for ISP Output1
> > > >> > >> 10-07 14:37:46.727 360 442 E libcamera: ERROR RPISTREAM
> rpi_stream.cpp:231 Failed to queue buffer for ISP Output1
> > > >> > >> 10-07 14:37:46.727 360 442 D libcamera: DEBUG RPISTREAM
> rpi_stream.cpp:226 Queuing buffer 1048580 for ISP Output1
> > > >> > >> 10-07 14:37:46.727 360 442 E libcamera: ERROR RPISTREAM
> rpi_stream.cpp:231 Failed to queue buffer for ISP Output1
> > > >> > >> 10-07 14:37:46.727 360 442 D libcamera: DEBUG RPISTREAM
> rpi_stream.cpp:226 Queuing buffer 1048581 for ISP Output1
> > > >> > >> 10-07 14:37:46.728 360 442 E libcamera: ERROR RPISTREAM
> rpi_stream.cpp:231 Failed to queue buffer for ISP Output1
> > > >> > >>
> > > >> > >> I cannot tell further why the qbuf ioctl has failed. Perhaps
> something in dmesg would tell us? Could you expand on how your request
> > > >> > >> buffers have been allocated?
> > > >> > >
> > > >> > >
> > > >> > > Just a pointer for you to investigate... The logs suggest that
> V4L2VideoDevice::queueBuffer() fails at:
> > > >> > >
> > > >> > > ret = cache_->get(*buffer);
> > > >> > > if (ret < 0)
> > > >> > > return ret;
> > > >> > >
> > > >> > > as all other error paths through that function log a message,
> and we see none. So it may not necessarily be the ioctl that fails.
> > > >> > >
> > > >> > > Naush
> > > >> > >
> > > >> > >>
> > > >> > >>
> > > >> > >> Thanks,
> > > >> > >> Naush
> > > >> > >>
> > > >> > >>
> > > >> > >> On Mon, 8 Nov 2021 at 20:20, Roman Stratiienko <
> r.stratiienko at gmail.com> wrote:
> > > >> > >>>
> > > >> > >>> Yes, I am on the very latest rpi branch without any custom
> patches. I had to upgrade it because of new media control used in mainline
> libcamera.
> > > >> > >>>
> > > >> > >>> пн, 8 нояб. 2021 г., 22:12 Kieran Bingham <
> kieran.bingham at ideasonboard.com>:
> > > >> > >>>>
> > > >> > >>>> Hi Roman,
> > > >> > >>>>
> > > >> > >>>> Quoting Roman Stratiienko (2021-11-08 17:46:56)
> > > >> > >>>> > Hi guys,
> > > >> > >>>> >
> > > >> > >>>> > I have stuck with camera bring-up for Android. Could
> somebody who has
> > > >> > >>>> > experience in it help me to find a right way to solve
> this. Logs are
> > > >> > >>>> > available here:
> > > >> > >>>> > https://github.com/kbingham/libcamera/issues/31
> > > >> > >>>>
> > > >> > >>>> The RPi kernel, and pipeline handler have had a large change
> recently to
> > > >> > >>>> convert to using MediaController. It may require ensuring
> you have the
> > > >> > >>>> latest kernel from RPi, along with the latest libcamera.
> > > >> > >>>>
> > > >> > >>>> You mentioned that you have " rpi-kernel v5.10.y", do you
> know if this
> > > >> > >>>> contains the commits that update to the new MediaController
> drivers?
> > > >> > >>>>
> > > >> > >>>> I assume you are building your own kernel, so you'll want to
> make sure
> > > >> > >>>> you're on the (very, very) latest branch, and it might be
> something to
> > > >> > >>>> check on the RPi forums otherwise.
> > > >> > >>>>
> > > >> > >>>> --
> > > >> > >>>> Kieran
> > > >> > >>>>
> > > >> > >>>>
> > > >> > >>>> >
> > > >> > >>>> > Thanks in advance,
> > > >> > >>>> > Roman
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libcamera.org/pipermail/libcamera-devel/attachments/20211110/986329ec/attachment-0001.htm>
More information about the libcamera-devel
mailing list