On Sun, Oct 20, 2019 at 1:02 PM Laurent Pinchart
<laurent.pinchart@xxxxxxxxxxxxxxxx> wrote:
>
> Hi Adam,
>
> On Sun, Oct 20, 2019 at 09:45:25AM -0500, Adam Ford wrote:
> > I am running a DM3730 connected to an mt9p031 sensor, and the ISP is
> > running in 8-bit parallel mode.
> >
> > I have the sensor endpoint configured as:
> >
> > mt9p031_out: endpoint {
> > input-clock-frequency = <24000000>;
> > pixel-clock-frequency = <72000000>;
> > remote-endpoint = <&ccdc_ep>;
> > };
> >
> > I was looking through the datasheet, and it appears as if the pixel
> > clock frequency can go up to 96MHz, so I tried to increase the
> > pixel-clock-frequency to 96MHz, but v4l2 seems to get an out of memory
> > error.
> >
> > libv4l2: error turning on stream: No space left on device
> > ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed
> > to allocate required memory.
> > Additional debug info:
> > gstv4l2src.c(658): gst_v4l2src_decide_allocation ():
> > /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
> > Buffer pool activation failed
> > Execution ended after 0:00:00.019073486
>
> The error code may be misleading. ENOSPC is used here to report that the
> maximum CCDC bandwidth has been exceeded, not that the driver is running
> out of memory.
>
> The check is performed in isp_video_check_external_subdevs(), and the
> maximum CCDC bandwidth is calculated by omap3isp_ccdc_max_rate():
>
> /*
> * TRM says that for parallel sensors the maximum data rate
> * should be 90% form L3/2 clock, otherwise just L3/2.
> */
> if (ccdc->input == CCDC_INPUT_PARALLEL)
> rate = pipe->l3_ick / 2 * 9 / 10;
> else
> rate = pipe->l3_ick / 2;
>
> Could you point me to the part of the OMAP3 datasheet that you think
> allows for 96 MHz ?
The DM3730 TRM (SPRUGN4R – May 2010 – Revised September 2012) doesn't
use the 90% rule mentioned above from what I can see. Maybe it's
somewhere else, but I didn't see it. It does state the folllowing in
Section 6.3.1.1:
Camera ISP Clocks Parallel interface clock domain. This frequency
depends on the imaging sensor type and size, its frame rate and its
blanking time. The functional clock is required to be at least 2x
faster than the pixel clock when the bridge is disabled and a least
equal when it is enabled.
When I queried the cam_ick, it returned 100MHz, so I expected 96MHz to
be tolerated.
# cat cat /sys/kernel/debug/clk/l3_ick/clk_rate
200000000
# cat /sys/kernel/debug/clk/cam_ick/clk_rate
100000000
For what it's worth, I removed the 90% calculation and just use the L3
/ 2. With that done, I was able to push the camera to 96MHz, and the
frame rate increased
Can you point me to where this 90% requirement is located?
adam
>
> > Through trial and error, I was able to get push the sensor's
> > pixel-clock-frequency to work at 90MHz, but no higher. I have also
> > tried experimenting with the input clock frequency without success.
> >
> > If I can get the clock to run at 96MHz, which the ISP and sensor
> > documentation appears to permit, I am hoping to be able to achieve a
> > little higher frame rate.
> >
> > Is there something I need to do to allocate more memory to V4L2 or is
> > there some other limitation causing the out of memory at higher pixel
> > clock frequencies?
>
> --
> Regards,
>
> Laurent Pinchart
