hverkuil: hello, may I use your cec-config branch to rebase my stm32 cec driver ?
benjiG: sure
neg: ping
hverkuil: pong
neg: I've been looking at patch 15/17.
Do you really want to support this feature where a subdev is unbound while the main driver is running?
If you do want that, then you need to allocate the video_device struct.
You have to do that since someone might have the video device open, so the video_device's memory can be released until that application closes it.
However, if it is allocated, then you can do this safely.
This will never work with an embedded video_device struct.
That is what I did in the previous version of the patch but Laurent had comments on that and after talking it over with him this was our best solution. For comments see https://www.spinics.net/lists/linux-media/msg112867.html
Clearly this isn't the right solution since it doesn't work :-)
If you really want to support unbinding of subdevs then that's a lot of work, and I am not certain if it is possible at all with todays core code.
OK :-) I will think more on this and see if I can solve it some other way, feeling the jet lagged today so can't think clearly. But is it a use case that should be supported to register, unregister and later register the same video device?
Sakari made patches to improve lifetime management, but those have not been merged.
It's not a normal use-case. I don't think it is implemented in any media driver.
I see maybe this is a issue i have to leave for now and get back to later then :-) Thanks for your feedback and for looking at the VIN patches !
I can see this with reconfigurable fpgas, or with modular hardware, but outside those niches I can't see this happening.
we hit this when doing i2c bus testing (cant remeber exactly what now) but it forced all devices on the bus to be unbound/bound which triggerd this. If the test reflected a real world use-case I don't know but I will dig in to it and see what I can do
sailus: ping
hverkuil: Pong.
sailus: just got a kbuild robot mail about your "v4l: flash led class: Use fwnode_handle instead of device_node in init" patch.  Can you take a look?
I added those patches to my branch since Niklas' patch series relied on it.
Yeah, I noticed the same.
I'll see what's causing that.
Thanks.
hverkuil: I had sent a pull request to Mauro on these patches on 18th this month.
The patches are identical so I guess it shouldn't matter but there are now two pull requests on the same.
two pull requests? I haven't posted anything yet.
Oh, you haven't?
I have. :-)
I cc'd you to the fix.
And you never got a kbuild message?
No, which is odd.
You only get that if you try compiling the LED drivers supporting V4L2 with V4L2 flash class disabled.
well, if it is a random config thing, then I might just have been unlucky. Is your git tree included in the kbuild tests?
I wonder if that's just because of bad luck.
I'm not sure, I have to admit.
BTW, since your pull request hasn't been merged yet, perhaps it is better to respin it with this fix?
Oh, good point.
I'll resend.
OK.
You can send an email to fengguang.wu@intel.com asking him to add your git repo to the tests. kbuild is amazing and you want to be part of the tests.
hverkuil: Resent.
mchehab: ping
mchehab: just to make sure you are aware of this 4.12 pull request: https://patchwork.linuxtv.org/patch/41526/
mchehab: when you did the last sync for the atomisp patches, did you also update patchwork? I.e., if I look in patchwork for pending atomisp patches, then I can rely on the results?
hverkuil: I rebased russell's CEC code for Synopsys HDMI-TX here https://github.com/superna9999/linux/commits/amlogic/v4.12/rmk-dw-hdmi-cec
hverkuil: but...
hverkuil: I realized on Amlogic SoCs, the CEC is on the Synopsys HDMI-RX (not TX)
hverkuil: So it's uselessm but I did it for fame and glory... without any way to test it
hverkuil: So I'll need to add support for the Amlogic CEC custom HW
So amlogic supports both HDMI Rx and Tx?
hverkuil: They have some SoCs in the family that have dual HDMI inputs
but AFAIK not the ones supported mainline
but maybe the logic is here, with hidden pinmux, but no board to test it actually
narmstrong: so you need to turn this: https://github.com/Pivosgroup/buildroot-linux-kernel-m3/blob/master/drivers/amlogic/hdmi/hdmi_tx/hdmi_tx_cec.c
into a proper cec driver?
That code does looks pretty straightforward.
hverkuil: yes, but it depends on a weird 32K clock
but yes seems very straightforward
and there some registers to enable suspend wake up to the FW
hverkuil: If I'll need add a CEC driver for Amlogic, should a create a new directory in drivers/media/platform/meson/ and put the CEC driver in it ?
narmstrong: it depends.
I have seen two different HW implementations: either the CEC block is completely separate from the HDMI block, or the two are in the same register map.
In the first case you typically make a separate driver and rely on the cec notifier to get informed of changes in the physical address.
In the second case you implement it directly in the hdmi driver.
hverkuil: ok, in this case it's completely separate
Then use the notifier in the drm driver and a separate CEC driver in drivers/media/platform.
One important thing to look out for is whether or not CEC can be used when there is no hotplug signal.
It can be used, it in a completely separate power domain and is always active
OK, good.
Some displays remove the hotplug but can still be woken up by CEC.
Insane, but allowed.
narmstrong: BTW, if the HW supports CEC bus monitoring (aka snooping), then you should implement that. It's very useful to have.
got to go, back later.
narmstrong: ok, I'll evaluate that
hverkuil: FYI I have talk with the stm32 cec hardware block designer and now I able to implement monitor all
benjiG: nice!
That is so helpful tracking down problems.
sailus: can you answer https://www.mail-archive.com/linux-media@vger.kernel.org/msg113004.html?
I don't think we have a proper solution. Interface links should be used for this, I believe, but that might need some work.
hverkuil: The matter is discussed in another thread.
He's cc'd.
https://www.mail-archive.com/linux-media@vger.kernel.org/msg112333.html
sailus: thanks. I hadn't make the link between that thread and his question :-)
hverkuil: Hello!