hverkuil-: Huomenta!
sailus: hi!
hverkuil: How do you do?
Busy :-)
Which I guess is very good. Although I am looking forward to the long Easter public holiday.
Are you handling the flow of rkisp1 patches?
I could do that as well but I think only one of us should do that. :-)
sailus: yes, I am.
Ack.
What do you think of this one:
https://patchwork.linuxtv.org/patch/62569/
hverkuil: ^
sailus: looks good. I think it makes sense.
hverkuil: Does it?
I don't mind the change itself that much; it's not really necessary, but the reasoning is more worrying.
sorry, busy, I'll get back to this later.
If the kernel doesn't enable CONFIG_V4L2_MEM2MEM_DEV but an external module does, then it is totally unnecessary to have that fail due to a different v4l2_fh layout. And having the #ifdef there is IMHO not worth it.
I have something similar in the cec subsystem, I'm considering removing those #ifdefs as well. I've experience similar problems with out-of-tree CEC drivers.
hverkuil: pinchartl
oops
I meant ping :-)
pingchartl :)
hverkuil: Hello, @koike and I have a question regarding authorship of https://patchwork.linuxtv.org/patch/62865/. The submitter mentioned that he based his work on https://github.com/TinkerBoard/debian_kernel, which instead has the patches from Rockchip's work for ChromiumOS kernel.
Should we ask the submitter to mention this somewhere? I am honestly lost here, as he is not taking patches as-is, but porting the code from downstream to upstream.
pinchartl: maybe you can provide some pointers ^ ?
ezequielg: I think it is sufficient if he adds something like this to the commit message:
"This code is based on <file> in <git repo>, branch <b>"
After all, that's what drivers/staging/media/phy-rockchip-dphy-rx0/phy-rockchip-dphy-rx0.c says as well.
hverkuil: sounds good to me. it's enough in the commit message?
or also at the top of file, as a small addition?
That whole source has rockchip copyright, so adding more rockchip code doesn't change that.
rk3288 support comes from...
hverkuil: indeed, that's why I was dubious.
It doesn't hurt to do that. In fact, it's best to just add it there and not in the commit log.
+1
pinchartl: did you have a question?
pinchartl: try tomorrow :-)
hverkuil: thanks for reply regarding rk3288 support
hverkuil: yes, I wanted to ask if you could have a look at the VIDIOC_ENUM_FMT extensions. let's try tomorrow indeed :-)