| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| *** | jj-_ is now known as jj- | [01:38] |
| .......................................................................................... (idle for 7h29mn) | ||
| svarbanov | mchehab: Hi, do you have time for one question? | [09:07] |
| ..... (idle for 20mn) | ||
| mchehab | sure | [09:27] |
| svarbanov | mchehab: I'm worried about qualcomm video codec driver PULL request, do you see some obstacles with merging it? because the merge window knocks on the door, do you it can be at least go in -next | [09:30] |
| mchehab | I'm doing patch handling today
I had two business trips on the last two weeks plus some issues on my building environment everything is back to normal this week :-) | [09:30] |
| svarbanov | mchehab: huh, ok I'm feeling better :) | [09:32] |
| mchehab | :-) | [09:32] |
| svarbanov | mchehab: the problem is that the firmware side of the driver is delayed from qcom legal, but the process is on its way | [09:33] |
| mchehab | hmm... that can be a problem
having a driver without a way for the user to have its firmware is an issue when do you expect to get an answer from legal? | [09:34] |
| svarbanov | mchehab: actually the firmware can be downloaded from qualcomm developer site, but the license there do not permit re-distribution (like linux-firmware git) and we asked qcom to re-write the license
mchehab: the answer is up to two weeks, I hope mchehab: this is the link with the firmware: https://developer.qualcomm.com/hardware/dragonboard-410c/tools mchehab: so it is publicly available | [09:36] |
| mchehab | ok
ideally, the best would be to merge the driver after having the firmware... as 2 weeks will be -rc6, it won't hurt delaying merging it I'll review the patches anyway, when I pick from my queue, to be sure that there aren't any other issues on it | [09:42] |
| svarbanov | mchehab: great, thanks. if you see something please write me an email | [09:45] |
| mchehab | sure | [09:46] |
| sailus | mchehab: Bom dia! | [09:48] |
| mchehab | sailus: moikka! | [09:50] |
| hverkuil | mchehab: I'm missing a bunch of other 4.12 fixes:
https://patchwork.linuxtv.org/patch/41155/ https://patchwork.linuxtv.org/patch/41304/ | [09:52] |
| mchehab | I expect to handle all pull requests today, plus handling not-delegated patches
btw, the best is to use GIT FIXES to put the patches on my higher priority queue | [09:54] |
| hverkuil | Also this one from Sean: https://patchwork.linuxtv.org/patch/41315/ | [09:55] |
| sailus | mchehab: Oh, that I was actually going to ask you --- the V4L2 fwnode pull request. :-) | [09:55] |
| mchehab | I handle first patches with [GIT FIXES] at the subject, then [GIT], then usual patches | [09:55] |
| sailus | A number of patches depend on that one, and it'd be nice to get it in. | [09:55] |
| hverkuil | The two I pointed to have been accepted, but only in our master and they didn't go to 4.12.
(that also explained the linux-next 'manual merge' email from Stephen from today) | [09:55] |
| mchehab | yeah, I had to manually fix that patch when applied, because it was not based on 4.12 | [09:57] |
| hverkuil | I expected that the earlier patch from https://patchwork.linuxtv.org/patch/41304/ was already queued up for 4.12. | [09:57] |
| mchehab | it was queued for 4.13 | [09:58] |
| hverkuil | then there was a communication mishap, it was intended for 4.12. | [09:58] |
| mchehab | yeah
I likely missed the "for v4.12". | [09:59] |
| hverkuil | and I missed that it was committed to master, not fixes. | [10:01] |
| mchehab | anyway, my plan is to merge back from Linus after he pulls the pending pull request
we can then cherry-pick the patches that are needed for 4.12 sailus: anyway, I should be looking at the fwnode pull request likely today hverkuil: on the above pull requests, what patches are really needed for 4.12? there are some patches there that are just warning fixes and "improve dependencies" that could easily go to 4.13 and remove unused includes | [10:02] |
| hverkuil | This one MUST go in: https://patchwork.linuxtv.org/patch/41155/
from https://patchwork.linuxtv.org/patch/41304/: rainshadow-cec: Fix missing spin_lock_init() vb2: Fix an off by one error in 'vb2_plane_vaddr' cec: improve MEDIA_CEC_RC dependencies cec-notifier.h: handle unreachable CONFIG_CEC_CORE But that last one is now really messed up. Where can I find the git repo branch for the patches you've asked Linux to full from for rc5? I want to check what is going to be merged. | [10:07] |
| mchehab | just rebased this one on the top of the fixes branch
ssh://linuxtv.org/git/media_tree.git branch fixes please check | [10:15] |
| sailus | mchehab: Ack. Thanks! | [10:16] |
| mchehab | I cherry-picked the patches you pointed me and solved the conflict with "cec-notifier.h: handle unreachable CONFIG_CEC_CORE"
if this is OK, I'll send a pull request tomorrow with the remaining patches, after having them merged on -next | [10:17] |
| hverkuil | OK, looks good. | [10:18] |
| mchehab | I'll then pull back on our tree, and that should solve the -next conflict | [10:18] |
| hverkuil | Excellent.
BTW: I think moving CEC_CORE outside the MEDIA_SUPPORT section is something that can be done for RC_CORE as well. RC_CORE has similar properties as CEC_CORE in that it is pretty much media independent. | [10:18] |
| mchehab | added this one to -fixes too:
f8c627fbabbe [media] sir_ir: infinite loop in interrupt handler yeah, that makes sense and will likely simplify even further the CEC dependencies | [10:19] |
| hverkuil | Perhaps Sean can look into that. | [10:21] |
| mchehab | It is probably a good idea to either ping Sean or to submit some patches for him
RC_CORE dependencies is simpler than CEC_CORE. I guess the patch would touch just Kconfig gah, I "love" automatic answering machines: Subject: Réponse automatique : [git:media_tree/master] [media] stm32-dcmi: STM32 DCMI camera interface driver just today, I received two of those crap from different machines | [10:22] |
| .............. (idle for 1h6mn) | ||
| hverkuil | mchehab: I hope the stm32 dcmi driver doesn't cause a conflict with Sakari's fwnode patches. | [11:31] |
| mchehab | sailus: ^ | [11:31] |
| hverkuil | For the same reason I recommend postponing the venus driver until the fwnode patch series is in in case of conflicts. I can always ask the venus driver author to respin on top of Sakari's patches. | [11:32] |
| mchehab | as it depends on some linux-firmware stuff, I ended by postponing reviewing the series
for the venus driver my idea is to take a look a the patches later this week, but wait for a while until they manage to get the firmware added to linux-firmware | [11:33] |
| hverkuil | sailus: yes, there is a conflict with the just-merged stm32-dcmi driver. | [11:34] |
| mchehab | hopefully, by -rc6
if the conflict is trivial, I can solve when pulling from sailus series... otherwise it would be better if sailus can handle it | [11:34] |
| sailus | mchehab: Ack.
I'll check that right away. | [11:35] |
| mchehab | ok, thanks! | [11:36] |
| sailus | There was no conflict but the stm32 driver still uses V4L2 OF. I'll convert it as well --- it's fairly trivial. | [11:44] |
| hverkuil | thanks!
I'm sure the venus driver has the same problem. | [11:44] |
| sailus | That's not merged yet, is it? (I ignore whether it was discussed above.) | [11:45] |
| hverkuil | No, not yet.
https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=venus | [11:45] |
| ...... (idle for 28mn) | ||
| sailus | mchehab: Just sent v3 pull request for V4L2 fwnode which also converts stm32-dcmi. | [12:14] |
| mchehab | sailus: ok. be sure to mark the old one as superseded | [12:14] |
| sailus | mchehab: Done. | [12:17] |
| mchehab | your pull request is the next one on my queue :-)
please interact with svarbanov for him to fix the needed bits at the venus driver, after I pull from your series - assuming that everything is ok there ;-) | [12:19] |
| sailus | mchehab: Ack. Obrigado!
mchehab, hverkuil: The venus driver does not use V4L2 OF. I.e. no changes are needed for V4L2 fwnode framework merge. | [12:21] |
| mchehab | OK, good!
mchehab is still on patch 1... had you add the header/c code with kerneldoc markups to Documentation/media? | [12:24] |
| hverkuil | sailus: of course, it's a codec without subdevs. Sorry for the noise. | [12:25] |
| sailus | mchehab: The documentation is switched from v4l2-of simply to v4l2-fwnode.
So if there were issues in V4L2 OF documentation, they have a good chance of being present in V4L2 fwnode as well. | [12:27] |
| mchehab | well, we'll know only if some of your patches at the series is adding them to Documentation/media/kapi
mchehab is still on patch 4 | [12:29] |
| benjiG | hverkuil: hello, do a chance exits to have stm32 dcmi and cec in kernel 4.13 ? or I should I log them for 4.14 ? | [12:31] |
| hverkuil | benjiG: stm32 dcmi was just merged for 4.13. | [12:31] |
| benjiG | great :-) | [12:31] |
| hverkuil | for cec I want to wait until the CEC config patches for 4.12 are merged back in our tree. | [12:32] |
| sailus | I'm leaving the office but I'll be online some time later this evening. | [12:33] |
| svarbanov | mchehab: could you answer to the GIT PULL request for the venus driver that you are waiting for the firmware side, then I can use this as a reason to escalate further | [12:33] |
| sailus | Bye! | [12:33] |
| mchehab | svarbanov: sure | [12:33] |
| benjiG | hverkuil: ok so cec driver will be on 4.14, right ? | [12:34] |
| mchehab | svarbanov: done | [12:35] |
| hverkuil | benjiG: no, it's still planned for 4.13. | [12:36] |
| svarbanov | mchehab: thanks! | [12:36] |
| benjiG | hverkuil: that even better
hverkuil: I notice that you are adding cec notifier in adv7533, that exactly what I need to test for my stm32 cec driver with notifier | [12:37] |
| hverkuil | benjiG: I can't give a 100% guarantee, but 4.13 is still my plan. I have to wait until the patches that make it possible to do 'select CEC_CORE' are merged back into our media master.
benjiG: I'm not using a cec notifier in the adv7533. You mean cec support in general? the adv7533 reads the edid by itself, so there is no need for a notifier. I'm not sure what adv7533 has to do with the stm32 cec driver. | [12:39] |
| benjiG | hverkuil: adv7533 could be be one of the hdmi adapter on stm32 boards | [12:42] |
| hverkuil | but then you wouldn't use the stm32 cec since the adv7533 has that already. | [12:43] |
| benjiG | the bard allow to select how cec signal is routed either on adv either in stm32 | [12:44] |
| hverkuil | very strange.
Anyway, I'm not planning any cec notifier support in adv7511/33. That is something that you can do better since you have the hardware to test that. | [12:45] |
| benjiG | I will add that in my todo list :-) | [12:46] |
| hverkuil | cec adv7511/33 support won't go in for 4.13 anyway. | [12:46] |
| .................................. (idle for 2h45mn) | ||
| kbingham | How does one set an edid on a subdev? I assumed I could "v4l2-ctl --set-edid=edid=hdmi -d /dev/v4l-subdev1" as v4l-subdev1 is my hdmi subdev where I have added the edid hooks ...
I get : "VIDIOC_QUERYCAP: failed: Inappropriate ioctl for device /dev/v4l-subdev1: not a v4l2 node " | [15:31] |
| hverkuil | v4l2-ctl doesn't work with v4l-subdevX due to the lack of QUERYCAP.
Or really, due to the lack of *any* ioctl that will uniquely identify a v4l-subdevX as being a subdev. | [15:32] |
| kbingham | hverkuil: Ahh - ok - so the same as the issue for setting controls. | [15:33] |
| hverkuil | yes. I really, really would like to see a VIDIOC_SUBDEV_QUERYCAP ioctl.
I proposed that in the past, but it was shot down and I haven't gotten around to try this again. | [15:33] |
| kbingham | VIDIOC_SUBDEV_QUERYCAP doesn't sound too controversial?
There is a node - and you want to know what it can do :) | [15:34] |
| hverkuil | Last patch series was called '[RFCv3 PATCH 0/2] Add VIDIOC_SUBDEV_QUERYCAP', posted July 2nd 2015. | [15:35] |
| kbingham | hverkuil: I'll check it out :) | [15:36] |
| hverkuil | There where no comments, so it could also be that I just ran out of time/interest/whatever. | [15:36] |
| kbingham | hverkuil: Could you bounce the mails to me please? Or do you have a branch to fetch from?
spinics and mail-archive aren't all that useful for extracting patches. :( kbingham misses gmane | [15:37] |
| hverkuil | https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=subdev-querycap
still have it :-) | [15:38] |
| kbingham | hverkuil: Thankyou :) | [15:39] |
| hverkuil | I'll forward the cover email and some of the replies to older versions of the patch series to you as well.
it would be very nice to get this in. Then I can work on improving v4l2-ctl and later v4l2-compliance. | [15:39] |
| *** | benjiG has left | [15:53] |
| kbingham | hverkuil: I've run out of time for the day - so I'll resume tomorrow. I had to adapt the entitiy parent and id fields to refer to the graph_obj to rebase to mainline :) | [16:01] |
| .................... (idle for 1h36mn) | ||
| syoung | hverkuil: moving RC_CORE outside MEDIA_SUPPORT makes a lot of sense. Have you done this for CEC_CORE already? | [17:37] |
| hverkuil | syoung: yes, although the patches doing that are not yet in master. They've just been merged in mainline.
they'll be merged back after the next rcX. | [17:39] |
| syoung | hverkuil: ah, I was not expecting them to be there :) I can do that, I'll add it to my todo list for v4.14. | [17:44] |
| hverkuil | I was thinking that media/Kconfig includes media/rc/Kconfig and media/cec/Kconfig at the top. | [17:46] |
| syoung | should cec and rc have their own menuconfig then? | [17:52] |
| hverkuil | yes. CEC may select RC_CORE in case it is configured to pass through the CEC remote control messages to the RC subsystem.
Really, both RC and CEC are independent of V4L2/DVB. Frankly, the media controller bits don't belong in the media menuconfig either. But one thing at a time :-) | [17:55] |
| .................... (idle for 1h36mn) | ||
| mchehab | changing media controller Kconfig can be a bit more complex :-)
it probably easier to start such patch by renaming MEDIA_CONTROLLER to MEDIA_CONTROLLER_V4L2... then add a new MEDIA_CONTROLLER and adjusting MEDIA_CONTROLLER_DVB to point to it, instead of pointing to MEDIA_CONTROLLER_V4L2 some care should be taken on hybrid devices that can have both V4L2 and DVB media controller dependencies hverkuil: ^ | [19:32] |
| ......... (idle for 42mn) | ||
| hverkuil | sailus: $ git grep v4l2-of.h
drivers/media/platform/davinci/vpif_capture.c:#include <media/v4l2-of.h> You missed one :-) No, false alarm. I'm applying a patch that adds it back, I'll figure this out. | [20:18] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |