<!-- 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>
***: agd5f has quit IRC (Ping timeout: 260 seconds)
<br> neg has quit IRC (Read error: Connection reset by peer)
<br> ndufresne has quit IRC (Ping timeout: 268 seconds)
<br> rshanmu has quit IRC (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
hverkuil: <u>koike</u>: ping
<br> <u>kbingham</u>: ping
kbingham: <u>hverkuil</u>: Pong :)
hverkuil: It's patch-Monday for me, and you're up next! :-)
<br> I'm (still) very confused about the status of your pending patches.
<br> Can you go here: https://patchwork.linuxtv.org/project/linux-media/list/?order=submitter
<br> Your patches are on the second page.
kbingham: <u>hverkuil</u>: I can do that now.
<br> <u>hverkuil</u>: I worked through some of them, and then I created a branch locally to retest.
hverkuil: I just marked as Superseded those patches that are, well, superseded, but the remaining patches are messy. A lot are delegated to Laurent as well.
<br> I'm also not sure if there are other vsp1 patches from Laurent that I should pick up.
kbingham: one patch fails our tests locally, due to bitrot. pinchart1 added code which causes my patches to break :)
hverkuil: Can you also take a look at this one from Laurent: https://patchwork.linuxtv.org/patch/41900/
<br> I had a question about that, but you might know the answer as well.
<br> That's one patch series I can take, once I have the answer. It would likely be in time for 4.13.
pinchart1: <u>hverkuil</u>: I'll perform more tests (I only came back home yesterday) to double-check that patch, and will then reply
hverkuil: <u>pinchart1</u>: welcome back!
kbingham: <u>hverkuil</u>: IMO I don't see any reason why it couldn't go to older Kernels.
<br> <u>hverkuil</u>: But pinchart1 can answer the question himself for definite :)
hverkuil: and if it can go to older kernels, then I need to know from which kernel upwards, of course.
<br> <u>kbingham</u>: I am holding off merging your patches until you let me know what I can and cannot take.
kbingham: <u>hverkuil</u>: should patches for other subsystems (such as DT) just be set as not applicable.
hverkuil: <u>kbingham</u>: yes, that's what I do.
kbingham: <u>hverkuil</u>: Is there a way on patchwork to mark patches as ready for integration?
hverkuil: I don't think so. At least not unless you are maintainer.
<br> Easier to mark those that are NOT ready as Superseded or Not Applicable.
<br> or Obsoleted
kbingham: All the VSP-DU patches are going through the DRM tree. So that clears those down.
<br> I'll work through the list and let you know when it's updated.
hverkuil: thanks!
<br> I hope in the future I'll be able to stay on top of this.
kbingham: it helps that I realised patchwork wasn't showing me all of the patches I've submitted :) (now fixed)
<br> seems a shame PW doesn't let us do bulk updates ... :(
hverkuil: <u>kbingham</u>: maintainers can, but not others. I wish we had someone who would be willing to improve patchwork.
kbingham: <u>hverkuil</u>: is patchwork not in active development elsewhere?
hverkuil: yes, but you would need someone who would write patches adding the things we want and generally stay on top of things. I'm just an end-user :-)
kbingham: <u>hverkuil</u>: Ok - refresh now - list is a lot smaller. <until I repost patches>
<br> <u>hverkuil</u>: The "[v2] media: fdp1: Support ES2 platforms" and "rcar-vin: Use of_nodes as specified by the subdev" patches look IMO ready to go upstream - but are lacking some reviewed-by tags...
hverkuil: <u>kbingham</u>: I now count 6 patches from you in patchwork, that's correct?
<br> BTW, reviewed the adv7482 driver. Small stuff mostly, but I am mystified by the lack of EDID handling.
kbingham: <u>hverkuil</u>: Yes. I've removed all the outdated patches. I thought there were some that I had already posted updates for - but I have everything locally so reposts can go out after retests.
<br> Lack of edid handling is due to lack of ability to test EDID on a subdev :)
<br> <u>hverkuil</u>: Hence our discussion the other week about getting query support on subdevs :)
<br> <u>hverkuil</u>: my next task I believe is to add EDID, + whatever is required to support.
hverkuil: I am not sure I can accept this driver without EDID support. The HDMI part is useless without that.
<br> Let me rephrase that: I won't accept this driver without EDID support.
kbingham: <u>hverkuil</u>: Ok - I have local patches to add that - but as yet they are untested.
hverkuil: How do you test HDMI now? With a hacked v4l2-ctl to allow you to set the edid through a v4l-subdev node?
kbingham: <u>hverkuil</u>: No, it's functional without EDID.
hverkuil: How? Without an EDID sources won't know what to send.
kbingham: <u>hverkuil</u>: My current testing is by plugging an Amazon Fire HD stick in, and a sony BluRay/DVD player.
<br> They both transmit whatever they are configured to transmit - and the ADV detects the resolution just fine.
hverkuil: Does the driver set the hotplug signal high?
***: pinchart1 is now known as pinchartl
hverkuil: (I assume the adv7482 hardware controls the hotplug pin)
kbingham: <u>hverkuil</u>: Yes, probably - I don't know the answer yet- I don't set the pin myself, but it could be default - or set in one of the ADI required settings tables.
pinchartl: <u>hverkuil</u>: EDID support is on the todo list, but given that the device is currently functional without it (at least with some HDMI sources), I don't think it should be a blocker
hverkuil: <u>kbingham</u>: sorry, but this really needs a bit more work. HPD and EDID handling are critical to HDMI receivers and I don't want to merge an HDMI receiver driver without support this. It's really not hard to implement (the adv748x probably reuses the same EDID IP as in the adv7604/adv7842). You just need to hack v4l2-ctl so you can use it to set the edid (or copy-and-paste it to a test utility).
pinchartl: <u>kbingham</u>: http://git.ideasonboard.com/xilinx/edid.git
hverkuil: If this was a huge amount of work to implement, then I might be convinced, but this is probably one day of work and the driver will be much more useful.
pinchartl: hmmmm not publicly available
<br> let me fix that
hverkuil: I'm surprised sources will send video without an EDID over HDMI. I'm not actually sure they are allowed to do that.
pinchartl: <u>hverkuil</u>: the device might have a default EDID
hverkuil: That would be a first, The other adv's I've worked with don't have that.
kbingham: No, I don't believe there is a default edid.
hverkuil: <u>kbingham</u>: oops, I reviewed v4 adv748x instead of the latest v5. Luckily it doesn't seem v5 is much different from v4.
<br> I think a workaround was removed in v5, so you can ignore my comment about that.
kbingham: <u>hverkuil</u>: hehe yes I noticed that ... but correct - there aren't many changes to v4->v5.
hverkuil: So three of your patches are delegated to sailus, I'll leave those to him.
<br> If pinchartl can give his ack to https://patchwork.linuxtv.org/patch/41780/ and https://patchwork.linuxtv.org/patch/40965/, then I can merge those.
<br> <u>neg</u>: ping
***: andrey_utkin has quit IRC (Excess Flood)
<br> m4t has left
neg: <u>hverkuil</u>: pong
hverkuil: <u>neg</u>: Re: https://patchwork.linuxtv.org/patch/41742/
<br> this depends on gen3 code that hasn't been merged yet, right?
<br> What is the status of gen3?
neg: <u>hverkuil</u>: yes it depends on the Gen3 patches
<br> Status is I need to resolve the life time issues so that the video device can be registerd at probe time (Needed on Gen3 but protyping it on Gen2 since it will "solve" the i2c bind/unbind issue)
hverkuil: OK. So there is nothing to do for me in that case.
<br> I've delegated this particular patch to me, but it will just be sitting in my todo list until gen3 support has arrived.
neg: Yes, I'm currently focus on the CSI-2 code which I think is alsmot in shape to be picked up
hverkuil: <u>mszyprow</u>: oops, I was a bit too quick accepting that maintainers patch. A file match for Documentation/devicetree/bindings/media/s5p-cec.txt is a good idea.
mszyprow: <u>hverkuil</u>: okay, I will resend updated version
hverkuil: thanks.
mszyprow: <u>hverkuil</u>: done
hverkuil: <u>koike</u>: ping
<br> <u>koike</u>: in case you read this later: what is the status of the vimc patches? I found a few smatch/sparse things you should look at, but once a v5 is posted, is there anything that prevents it from being merged?
<br> You mentioned that "vimc: Optimize frame generation through the pipe" was dropped in v4. Is that something that should be fixed before it is ready for merging?
<br> Ideally I would like to get this in for v4.13, but there is little time left.
***: snawrocki has quit IRC (Remote host closed the connection)
koike: <u>hverkuil</u>: pong. I will check those warning you mentioned in a jiffy, I didn't catch those, I need to check my building environment so this doesn't happen again
hverkuil: ok
koike: <u>hverkuil</u>: there was a bug in the Optimization commit when there is more then one link enabled going to the same sink pad, so I dropped it as I need to re-factor it a bit
<br> I'll just go lunch and I'll fix those warnings when I came back
hverkuil: I haven't looked at the validity of the warnings. sparse is usually right, but smatch can give wrong warnings.
<br> just so you know :-)
***: _abbenormal has quit IRC (Quit: Yup Im Leaving)
<br> binchen has left "Leaving"
<br> koike has quit IRC (*.net *.split)
<br> mort has quit IRC (*.net *.split)
<br> posciak has quit IRC (*.net *.split)
<br> hfr has quit IRC (*.net *.split)
hverkuil: <u>mchehab</u>: there is something weird going on with the media_build. If I do this:
<br> cd media_build/linux
<br> make tar DIR=<path-to-my-media-tree>
<br> make untar
<br> cd ..
<br> make stagingconfig
<br> make prepare
<br> make -jN
<br> Now everything builds and all the modules are all built in parallel.
<br> But once it reached stage 2:
<br> Â LD [M] Â /home/hans/work/src/v4l/media_build/v4l/altera-stapl.o
<br> Â Building modules, stage 2.
<br> Â MODPOST 636 modules
<br> Â CC Â Â Â Â Â /home/hans/work/src/v4l/media_build/v4l/a8293.mod.o
<br> all the mod.o files are compiled serially instead of in parallel. This takes ages during the daily build.
<br> I'm sure that never was the case before, but I don't see where things went wrong.
<br> You know make and the kernel build system a bit better than I do, so it would be great if you could take a look.
<br> I've added KBUILD_MODPOST_NOFINAL=1 for now to skip the final link of the modules in the daily build.
***: larsc has quit IRC (*.net *.split)
<br> Elladan has quit IRC (*.net *.split)
<br> ezequielg has quit IRC (*.net *.split)
<br> hnrk has quit IRC (*.net *.split)
<br> thiblahute has quit IRC (*.net *.split)
<br> ribalda_ has quit IRC (*.net *.split)
<br> Bladelouse has quit IRC (*.net *.split)