[10:00] <dafna2> hverkuil: ping
[10:06] <hverkuil> dafna2: pong
[10:08] <dafna2> hi, Heiko Stuebner sent an RFC to make the rkisp1 to work on px30, the 5th patch changes the uapi, and he suggested that we send it as a fix, before 5.11 is released,
[10:09] <dafna2> since the rkisp1 is about to be destaged on 5.11 and then it will be more cumbersome to change the uapi
[10:09] <dafna2> is that justified?
[10:18] <hverkuil> This doesn't feel right. The metadata is simply different for px30, so I would expect to see a different metadata format as well.
[10:19] <hverkuil> Just increasing sizes will not tell userspace how many elements of these arrays are actually in use, and it might also break again with some future update of the IP.
[10:20] <dafna2> I commented in his patch that we should make the arraies the bigger size and in addition have a define for each version
[10:21] <dafna2> it is a bit hard to predict future update since the datasheets are not public
[10:21] <dafna2> Heiko looked at the downstream rockchip code
[10:22] <hverkuil> That's why I think it is better to make a new metadata format for px30.
[10:22] <pinchartl> hverkuil: it's more complex for both userspace and kernelspace then
[10:22] <pinchartl> the code that handles configuration of the device will have to be duplicated, for very little gain
[10:26] <hverkuil> It feels very much like a hack. Something that will work for this particular case, but will likely fail with future IP changes.
[10:27] <pinchartl> that's true, but there may be no new versions :-)
[10:27] <pinchartl> we can always add a new format for future versions if they appear
[10:27] <pinchartl> but doing so now would increase complexity when it could be avoided
[10:30] <hverkuil> Hmm, I'm not enthusiastic, but OK. You definitely need a version field (useful in any case), and good documentation that describes the differences in those fields that are affected by the version.
[10:32] <pinchartl> ideally we would have some insight into what other changes could be expected, and design the API accordingly, but without vendore cooperation, we can only work in reactive mode :-(
[10:37] <pinchartl> the IP core comes from Silicon Image if I'm not mistaken
[10:37] <pinchartl> it's called CAMERIC
[10:44] <pinchartl> (and it's used in old Intel SoCs btw)