<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>
hverkuil: <u>pinchartl</u>: pong
pinchartl: have you had time to review the documentation patch I've submitted ?
hverkuil: No, my planned schedule for today didn't survive reality :-)
<br> I've printed it and plan to read it while traveling to the Netherlands tonight. Either that or it will be Monday.
pinchartl: ok
<br> I'd really like to get it merged before leaving for vacation on Thursday next week
<br> the driver patches have been held back for too long
<br> if there's anything you have seen that I should already change feel free to tell me
hverkuil: I'll try to get this reviewed by tomorrow.
pinchartl: thank you
bparrot: hverkuil, mchehab, I sent 2 ti-vpe patches a while back that I was hoping would make it in 4.11, is that still possible?
***: benjiG has left
pinchartl: <u>hverkuil</u>: "[RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging" needs urgent review too
mchehab: <u>bparrot</u>: only if they're re regression fixes
<br> <u>bparrot</u>: are you referring to those two patches?
<br> <u>Subject</u>: [1/2] media: ti-vpe: vpdma: add support for user specified stride
<br> <u>Subject</u>: [2/2] media: ti-vpe: vpe: allow use of user specified stride
bparrot: mchehab, so not before 4.12 then?
<br> mchehab, yes
<br> mchehab, and yes they are not regression fixes
pinchartl: <u>mchehab</u>: I have a patch that touches both the media and drm subsystems. should I try to get it merged on one side in the -rc cycle to avoid risk of conflicts, or do I need to request a stable branch again ? it's a small patch that changes an API between two drivers, converting one function to take parameters in a struct instead of individually, to make future changes to that API easier
mchehab: if I understood patch 2/2, you're using bytesperline specified by userspace
bparrot: I should really start to overlay my calendar with the kernel release date
mchehab: this is supposed to be a returned only value, as far as I remember
bparrot: mchehab, no, for instance yavta support passing arbitrary "stride"
mchehab: <u>pinchartl</u>: the right way would be to use a stable branch, but we could try to send it on an early -rc too
<br> send me the patch, I'll take a look
<br> <u>bparrot</u>: what do you mean?
bparrot: mchehab, v4l2-ctl also allows bytesperline to be specified This is needed when passing a DMABUF allocated by a display entity for instance
pinchartl: <u>mchehab</u>: sent, you're CC'ed
mchehab: <u>bparrot</u>: hmm... the spec is actually not clear about that
<br> hmm... misread
<br> yeah, this is allowed
bparrot: right, we need that support to allow usage of buffers which will be fed to a Tiler unit for rotation which only works with specific size buffer
mchehab: ok
bparrot: but anyway, so 4.12 timeframe, correct?
mchehab: yes
<br> if you want to have something that it is not a regression, it shoud be applied on my tree up to -rc6
bparrot: alright i guess i missed the rc4 date by a week or something
mchehab: as I usually close submissions on -rc7, to give janitors some time to do their work
bparrot: right so for it to be in your tree by rc6 you must have seen it by rc3 at the latest?
mchehab: that depends ;)
<br> I usually get most of V4L2 stuff from hverkuil's tree
bparrot: Ah, and with all of travel recently....
mchehab: yep
<br> usually, end of year is harder for everybody
<br> too many trips in Oct/Nov...
<br> plus holidays and vacations
bparrot: btw are you planning on attending ELCE?
mchehab: yes, I'll likely be there
bparrot: I am planning to attend as well.
mchehab: <u>bparrot</u>: patches applied
bparrot: mchehab, thanks.
hverkuil: <u>pinchartl</u>: reviewed the documentation, will post a reply tomorrow morning (too late & tired to do that now).
<br> Found a few inconsistencies in the documentation that need clarification.
<br> Main thing though (and that would take a lot more time) is that S_SELECTION isn't mentioned at all. Is that intentional? To be added later?
<br> BTW, my plan was to review patches today for a new pull request, but work intervened. I hope to catch up on that next week.
pinchartl: I didn't want to solve every problem on earth in one go :-)
<br> but can S_SELECTION influence the buffer size ?
<br> it can certainly change where an image is composed in the buffer
<br> or change the scaling ratio
<br> but it doesn't change the format
<br> I've limited the patch to the ioctls that can influence the buffer size
<br> that's intentional
<br> other ioctls that can influence the buffer layout, but not its size, are fine from a buffer allocation point of view
<br> of course if you want to synchronize them with buffers, you'll need requests
<br> but as long as the stream is stopped, I think it should be fine
hverkuil: It can affect the buffer size as well (depending on the hw capabilities)
pinchartl: only if it results in the format being changed
hverkuil: I.e. if you crop the sensor or video input and there is no HW scaler, then the width/height will change to that of the crop rectangle.
pinchartl: but the format, as reported by G_FMT, will change too
<br> S_SELECTION can contain an implicit S_FMT
<br> I can mention that, but I don't think we need to document it further than that
<br> is there any blocker, or do you think we could get it merged after one more cycle ?
hverkuil: one more cycle is probably sufficient.
pinchartl: \o/
<br> that's great news :-)
<br> then I'll also resubmit the histogram patches on top of that