On Fri, Oct 6, 2017 at 3:14 AM, Philipp Zabel <p.za...@pengutronix.de> wrote: > > On Fri, 2017-10-06 at 10:49 +0300, Sakari Ailus wrote: > > On Thu, Oct 05, 2017 at 10:21:16AM -0700, Tim Harvey wrote: > > > Greetings, > > > > > > I'm working on a HDMI receiver driver for the TDA1997x > > > (https://lwn.net/Articles/734692/) and wanted to throw an error if > > > the > > > detected input resolution/vidout-output-bus-format exceeded the max > > > pixel rate of the SoC capture bus the chip connects to (in my case > > > is > > > the IMX6 CSI which has a limit of 180MP/sec). > > Where does this number come from? I see there are 180 MP/s advertised > for burst mode still image capture (with up to 35% blanking overhead) in > the i.MX6Q reference manual. For continuous still image capture, only > 160 MP/s are advertised. The CSI really supports up to about 240 MHz > pixel clock (assuming the IPU is clocked at 264 MHz), so MP/s for video > really depends a lot on the blanking.
I got the number from the ref manual section 9.2.1.1 Camera ports which says: The input rate supported by the camera port is as follows: - Peak: up to 240 MHz (values/sec) - Average (assuming 35% blanking overhead), for YUV 4:2:2 - Pixel in one cycle (e.g. BT.1120): up to 180 MP/sec, e.g. 12M pixels @ 15 fps - Pixel on two cycles (e.g. BT.656): up to 90 MP/sec, e.g. 6M pixels @ 15 fps. - On-the-fly processing may be restricted to a lower input rate - see below. I would agree that it appears 240MHz is the important limit here and I'm not clear how they get 180/90 MP/sec from this assuming 35% blanking - seems to me that should be 156MP/sec or 180MP/sec with 25% blanking for single-cycle max. The only place I've run into this is the 2-cycle BT656 case where 1080p@60 would exceed the input rate (1920*1080*60fps*2cycles=248.8MHz). Tim
