[07:58] <sailus> janaszewski: I believe came across the same problem you've had in the past --- one struct device but two sub-devices.
[08:10] <janaszewski> sailus: please elaborate :)
[08:10] <sailus> There are two LEDs and the async sub-devices are matched to the OF node.
[08:11] <sailus> But the OF node isn't the OF node of the device, but its child (a LED's OF node).
[08:12] <janaszewski> the of_node related to child LED node has to be assigned in the LED driver to the of_node property of struct led_classdev_flash
[08:13] <janaszewski> led_cdev->dev->of_node = sub_node
[08:13] <janaszewski> actually
[08:14] <janaszewski> so, to the struct device aggregated by struct led_classdev_flash
[08:15] <sailus> I think it'd be cleaner to add the of_node pointer to struct v4l2_subdev, and match based on that.
[08:15] <pinchartl> janaszewski: what does v4l2_subdev->dev point to in that case ? the physical device or the led_classdev_flash->dev ?
[08:16] <janaszewski> the latter
[08:16] <janaszewski> this device is created by device_create_with_groups in led_classdev_register
[08:16] <janaszewski> it has its of_node field not initialized (NULL)
[08:19] <janaszewski> I mean initially initialized, therefore it can be utilized for assigning child DT node related to sub-LED
[08:19] <janaszewski> s/initialized/uninitialized/
[08:21] <pinchartl> hmmmmm...
[08:21] <pinchartl> isn't v4l2_subdev.dev supposed to point to a physical device ?
[08:22] <janaszewski> but what in case we have many sub-device per physical device, but still we want to be able to match them by of_node?
[08:23] <pinchartl> how about adding a struct device_node *of_node to struct v4l2_subdev ?
[08:24] <janaszewski> well, it would do I think
[08:25] <pinchartl> in the LED case we have a led class device per LED
[08:25] <pinchartl> but in the general case we might not have more than one struct device
[08:27] <janaszewski> I still don't quite understand how current approach could be harmful
[08:29] <janaszewski> we only break the contract saying that v4l2_subdev->dev field is related to the physical device, but in case of LEDs there are struct devices created per subLEDs, not per physical devices
[08:30] <janaszewski> this is perfectly consistent on the line LED subsystem - V4L2
[08:30] <janaszewski> where we have one v4l2_subdev per sub-LED , not per physical device
[08:32] <janaszewski> and allows for exploiting current infrastructure for sub-device matching without adding new matching type or relying on custom ones
[08:32] <sailus> janaszewski: Even the matching type doesn't need to change, the same OF matching can be used.
[08:33] <janaszewski> sailus: that's the main benefit
[08:33] <sailus> Just the argument to the match functions need to be made struct v4l2_subdev...
[08:34] <pinchartl> janaszewski: could there be side effects of breaking the contract saying that v4l2_subdev->dev field is related to the physical device ?
[08:34] <sailus> I think that's nicer than assigning the OF node to struct device in a driver. Not sure how much though --- the OF node still needs to be explicitly assigned to the sub-device.
[08:36] <janaszewski> pinchartl: I cannot see any in case of LEDs, I haven't come across any while testing it with max77693-flash driver
[08:39] <janaszewski> sailus: what actually do you have on mind? How would you match by of_node otherwise?
[08:40] <sailus> Add the of_node field to struct v4l2_subdev, and match based on that.
[08:41] <janaszewski> pinchartl: almost all fields of struct device are copied to the new struct device created per sub-LED, but of_node remains uninitialized and thus can be used for conveying information about sub_node
[08:42] <janaszewski> sailus: how about adding the struct device_node argument to v4l2_flash_init and do the assignment inside?
[08:43] <sailus> Sounds good.
[08:43] <sailus> I actually had a patch which added struct dev to the arguments.
[08:44] <sailus> But then realised it wouldn't work for your other LED chip...
[08:44] <janaszewski> The V4L2 part of drivers hasn't been merged yet
[08:45] <sailus> Indeed.
[08:45] <sailus> So it's better to make possible changes now than later. :-)
[08:45] <janaszewski> I'm fine with it
[08:46] <janaszewski> do you have some other issues with the wrapper?
[08:47] <sailus> I don't think I have other major concerns.
[08:47] <sailus> I have one other patch you could merge though.
[08:47] <sailus> If the wrapper is disabled, the use of macros will cause compiler warnings if the variables aren't used for other purposes.
[08:47] <sailus> I have a patch for that.
[08:48] <janaszewski> hmm, interesting, I was paying attention to this
[08:49] <janaszewski> please send me the patches directly or through the lists and I will produce v8
[08:49] <sailus> Sure.
[08:50] <sailus> That was my intention last night but then I realised the OF node problem. :-)
[08:50] <sailus> I'll do that a bit later today, if that's ok for you.
[08:50] <janaszewski> that's fine
[08:52] <sailus> Thanks!
[08:53] <janaszewski> you're welcomed :)
[09:15] <mchehab> sailus, pinchartl, hverkuil: do you have some time today for the MC discussions?
[09:19] <sailus> mchehab: I do.
[09:20] <robtaylo1> hverkuil: it seems like we may need it for rcar_vin. Just testing now
[09:22] <hverkuil> mchehab: I have, but I have to leave at 4pm (about 4.5 hours from now)
[09:24] <robtaylo1> or maybe not
[09:26] <hverkuil> robtaylo1: One of the reasons I want to test it first is that I am not 100% certain that the current soc-camera implementation is correct w.r.t. the spec.
[09:27] <hverkuil> My time unfortunately is limited due to the fact that I am working on too many v4l projects at the same time and it's gotten busier at work as well.
[09:27] <pinchartl> mchehab: I don't :-/
[09:28] <hverkuil> mchehab: sailus: pinchartl: what about tomorrow? (would work better for me as well)
[09:28] <pinchartl> I'll be traveling from tomorrow to Saturday evening
[09:28] <hverkuil> ah
[09:29] <hverkuil> An alternative might be for mchehab to just try it: try implementing it by using a new ioctl to enumerate device nodes, and try it using control pads. Just see which works best.
[09:30] <hverkuil> and then we can discuss based on those experiences.
[09:30] <pinchartl> Sakari told me he has read the logs of our irc conversations
[09:30] <hverkuil> obviously it would be a hack, but that's OK.
[09:30] <pinchartl> but hasn't given me feedback yet
[09:30] <pinchartl> other than "ouch, it seemed painful" :-)
[09:31] <hverkuil> ha!
[09:31] <hverkuil> Perhaps sailus can give his feedback here today. You can read it later.
[09:33] <hverkuil> lunch
[09:36] <mchehab> hverkuil: please ping after lunch... let's try to do some meeting, even if pinchartl won't be able to fully participate
[09:36] <robtaylo1> hverkuil: yeah, we'll rebase without it and see how we go. FWIW, it's working to the extent we're testing (which isn't specifically excercising that functionality)
[09:49] <sailus> hverkuil: Tomorrow is fine as well.
[09:49] <snawrocki> sailus, janaszewski: you might be already aware of struct fwnode_handle, AFAIU if we were to add any firmware related pointer to (generic) struct v4l2_subdev it should be independent of the firmware type, so struct fwnode_handle instead of struct device_node *, since it is supposed to abstract OF, ACPI and any other future firmware types.
[09:50] <sailus> snawrocki: Correct.
[09:50] <pinchartl> snawrocki: agreed
[09:51] <sailus> We should move over to use fwnode_handle and device_property_* at some point.
[09:51] <sailus> I don't think it's required to merge the patches though.
[09:52] <sailus> I believe there's additional work that needs to be done on device property (and ACPI) side as well.
[09:52] <snawrocki> yes, I've noticed subsystems are updated already
[09:53] <snawrocki> sailus: right, I don't think we should postpone merging patches because of that
[09:58] <janaszewski> snawrocki: I will look into that, thanks
[10:03] <hverkuil> mchehab: sailus: ping
[10:06] <sailus> hverkuil: Pong.
[10:07] <hverkuil> sailus: let's wait for mchehab
[10:07] <snawrocki> [s/subsystems/some subsystems] janaszewski: sure, you're welcome
[10:08] <hverkuil> mchehab: sailus: we either discuss it now, or we set up a time for tomorrow. I'd like to work uninterrupted (well, try anyway) for the rest of the day.
[10:09] <sailus> hverkuil: I'm fine with both.
[10:10] <sailus> If we are to continue, I think it'd good to have pinchartl with us.
[10:10] <sailus> Should we agree on a time tomorrow?
[10:10] <sailus> I have a meeting from 13:00 until 15:00 Finnish time, otherwise I'm available.
[10:11] <pinchartl> sailus: I won't be available tomorrow either
[10:11] <sailus> :-P
[10:12] <sailus> pinchartl: Then, the day after? No? :-)
[10:12] <hverkuil> I am available the whole day tomorrow. Note that I am just interested in your opinion. That way once Laurent is back he can just read the log of the conversation.
[10:12] <sailus> hverkuil: Right, then we could discuss today.
[10:12] <sailus> I'm a bit busy with other work now; would 14:30 Finnish time (13:30 Norwegian) be ok for you?
[10:13] <hverkuil> sure
[10:14] <sailus> mchehab: How about you?
[10:19] <pinchartl> sailus: not before Sunday I'm afraid
[10:20] <sailus> pinchartl: Ack.
[10:29] <mchehab> hverkuil: pong
[10:30] <hverkuil> mchehab: would one hour from now work for you? sailus is available then.
[10:30] <mchehab> yes, it works for me
[10:30] <hverkuil> ok
[10:48] <ribalda> hverkuil: Hello! Could you take a look to https://patchwork.linuxtv.org/patch/29376/ . Is there something that I need to add? Thanks!
[11:30] <sailus> Hello!
[11:33] <hverkuil> hi
[11:34] <mchehab> sailus, hverkuil: ready?
[11:35] <hverkuil> I am
[11:36] <sailus> Yes!
[11:36] <sailus> I read the discussion yesterday.
[11:37] <mchehab> ok
[11:37] <sailus> Perhaps it'd be good to take a small step back to agree on the problem that needs a solution.
[11:38] <mchehab> well, we're doing that on the last n meetings... but ok, let's do it again
[11:38] <sailus> Back in the old days when the MC was designed, one of the intents intent was to allow explicit hardware pipeline configuration.
[11:38] <sailus> Before that V4L2 was data AND control interface.
[11:38] <sailus> On the current MC based drivers (at least those I know) V4L2 is data ONLY interface.
[11:39] <mchehab> sailus: MC discussions started back in 2007 at 1st LPC...
[11:39] <mchehab> one of the problems that we wanted MC to address were to point the device nodes that userspace would need to know to control a given hardware
[11:39] <sailus> mchehab: Those were perhaps the original discussions, but the implementation started later than that.
[11:40] <mchehab> sailus: yes. somewhere between 2007 and the implementation, something got lost/misused/abused
[11:40] <sailus> Right.
[11:40] <sailus> I don't think anything was lost, that's exactly what it does now.
[11:40] <hverkuil> The MC was always meant to be able to handle any type of flow, either video, audio, control messages or anything else. I know nobody believes me, but when I designed it I always had that in mind. But video was most urgent, so that was done first, and until now is the only thing that has been implemented.
[11:40] <sailus> With some limitations, or incompatibility, if you like.
[11:41] <mchehab> sailus: the V4L2 data is called ENT_T_DEVNODE_V4L2
[11:41] <sailus> I think the case with DVB is pretty similar than it was with V4L2 on the omap3isp device.
[11:42] <mchehab> but the real /dev/video, /dev/vbi, /dev/radio (the V4L2 devnodes) may not have data
[11:42] <sailus> Albeit with DVB there's perhaps less variability.
[11:42] <mchehab> /dev/radio (with is a V4L2 DEVNODE) doesn't have data
[11:42] <sailus> Nevertheless, the problem was that the pipeline is too complex to be fully configured through a single video device, the API wasn't expressive enough for that purpose.
[11:43] <mchehab> sailus: yes...
[11:43] <sailus> The DVB case looks quite similar to me --- if you have a traditional device with a linear pipeline, there's nothing you can configure with links.
[11:44] <sailus> And for that reason there's not much interest in having the MC interface in the first place.
[11:44] <mchehab> as you said, the problem that MC is meant to solve is to configure the pipeline via devices
[11:44] <sailus> But when you add, say, another tuner, then you need to pick either of the tuners.
[11:44] <mchehab> what's missing right now is that MC misses a representation to the control points(entities)
[11:45] <mchehab> when those don't carry data
[11:46] <sailus> Where is there control without data?
[11:46] <mchehab> /dev/radio
[11:46] <sailus> With the possible exception of a single device node used to control multiple entities?
[11:46] <mchehab> the data flow comes via the ALSA devnodes
[11:46] <mchehab> /dev/radio just controls the radio device. nothing else
[11:46] <sailus> Hmm, isn't that data, even if it's analogue? :-)
[11:47] <mchehab> not at the V4L2 devnode
[11:47] <mchehab> there is data, but it doesn't pass though the V4L2 devnode
[11:47] <hverkuil> radio, video as well if you use it to just do the control part and are forced to use other mechanisms for the DMA (TI crap), vbi (sliced vbi data you get by reading i2c registers, is that control or data?), alsa mixers, etc.
[11:47] <sailus> This is a media controller pipeline, it doesn't need to pass through V4L2 device node.
[11:48] <sailus> So you have a radio entity which would expose a V4L2 device node?
[11:48] <mchehab> sailus: true, but userspace needs to know what /dev/radio controls each part of the pipeline
[11:48] <sailus> And the audio comes out of an ALSA device?
[11:48] <mchehab> imagine, for example, a teoretical device with 4 radios...
[11:48] <hverkuil> alsa or a simple line-out connector
[11:48] <mchehab> what /dev/radio is associated to each part of the pipeline from the control standpoint?
[11:48] <sailus> This isn't different from the omap3isp case. :-)
[11:49] <sailus> That information is already available over the MC interface, i.e. device nodes, in principle.
[11:49] <sailus> What's not supported is multiple device nodes exposed by a single entity.
[11:49] <mchehab> sailus: where?
[11:50] <mchehab> pinchartl defends that ENT_T_DEVNODE_V4L2 is actually either DMA or PIO
[11:50] <sailus> MEDIA_IOC_ENUM_ENTITIES
[11:50] <mchehab> sailus: I think you're not getting...
[11:50] <mchehab> let me draw one example
[11:50] <mchehab> a typical radio is:
[11:51] <hverkuil> sailus: there is an entity for the i2c radio tuner, there is an entity for the radio device node, but no link since the radio device node doesn't stream any data.
[11:51] <sailus> That radio entity would have two device nodes, one V4L2 device to control it, and an ALSA device for the data, unless I'm mistaken. That's not supported yet.
[11:51] <hverkuil> So you don't see the link between the two.
[11:51] <mchehab> /dev/radio0: [tuner] ---> [mixer] ---> [alsa or some output connector]
[11:51] <mchehab> there's no devnode on the pipeline...
[11:52] <mchehab> because the radio just controls the device as a hole
[11:52] <hverkuil> whole :-)
[11:52] <sailus> mchehab: Ah, that's also what's not supported.
[11:52] <sailus> I thought you would record the audio.
[11:52] <sailus> Pipelines that have no memory inputs or outputs also cannot be started currently, be that audio or video.
[11:52] <sailus> For video related use cases for that exist as well.
[11:52] <mchehab> sailus: recording or not, this is at ALSA side of the pipeline
[11:53] <sailus> mchehab: Isn't that the same pipeline?
[11:53] <mchehab> yes, but /dev/radio is not part of the data pipeline
[11:53] <sailus> I know ALSA doesn't use MC yet, but we should not base a design on that.
[11:53] <mchehab> it will only appear if we represent control entities
[11:53] <sailus> /dev/radio isn't as it's a software interface, isn't it?
[11:53] <pinchartl> (for the record, I claimed that ENT_T_DEVNODE_V4L2 is DMA or PIO in existing MC devices, not in the general case. for radio devices or other devices without DMA or PIO there should simply be no ENT_T_DEVNODE_V4L2 entity, it should be reported as a property of other entities)
[11:53] <sailus> There's no hardware device /dev/radio.
[11:54] <mchehab> sailus: there is
[11:54] <mchehab> just the pipeline doesn't pass though it
[11:54] <sailus> /dev/radio is entirely software. :-)
[11:54] <mchehab> it is, at some extend, similar to the flash entity
[11:55] <mchehab> the flash exists, but it is not part of the pipeline
[11:55] <sailus> My view is that this is a software interface to a hardware device.
[11:55] <mchehab> sailus: everything on Linux is a software interface to a hardware device
[11:55] <sailus> But it is not a hardware device by itself.
[11:55] <hverkuil> :-)
[11:55] <sailus> mchehab: Yes. :-)
[11:56] <mchehab> a sensor entity is a software interface to some hardware
[11:56] <mchehab> the radio entity is a software interface to some hardware
[11:56] <sailus> The entity still describes a hardware device.
[11:56] <mchehab> the radio entity describes some hardware
[11:56] <pinchartl> none of you will attend LinuxCon Japan, right ? I'll be there and a face to face discussion would really help
[11:56] <sailus> Device nodes may exist independently of hardware.
[11:56] <sailus> /dev/zero for instance.
[11:57] <sailus> pinchartl: I fully agree with that.
[11:57] <hverkuil> pinchartl: no.
[11:57] <mchehab> no, I won't be there
[11:57] <pinchartl> too bad :-/
[11:57] <hverkuil> I've no plans for travel until the ELCE
[11:57] <mchehab> sailus: hardware may exist independently of device nodes too
[11:57] <sailus> mchehab: Yes.
[11:57] <sailus> I'll be in ELc-E.
[11:57] <mchehab> can't see your point
[11:58] <hverkuil> although a brainstorm meeting somewhere in Europe could be done
[11:58] <pinchartl> hverkuil: I could visit Norway but Mauro won't be there :-/
[11:58] <sailus> The idea of an entity was, when MC was initially written, to describe a hardware device.
[11:58] <hverkuil> I think Mauro and myself are on the same wavelength.
[11:58] <hverkuil> sailus: NO!
[11:58] <sailus> I could almost hear that all the way from Norway.
[11:59] <mchehab> pinchartl: if needed, I can go anywhere
[11:59] <hverkuil> It was designed to describe an abstract block of functionality, whether HW, SW, FPGA, whatever
[11:59] <mchehab> pinchartl: btw, I have a bridge available for audiconf, with access on both Norway and Finland (and even in Japan)
[12:00] <sailus> hverkuil: Well, in some cases the line between hardware and software could be finer than in others, but still I'd say that software programs should not exist as entities in an MC graph.
[12:00] <mchehab> we can do an audioconf anytime, if you think this would help
[12:00] <sailus> I mean generic programs, I understand there may be use for very specific ones.
[12:00] <sailus> Ones that the user space already exects to be there, for instance.
[12:01] <hverkuil> programs in general not, of course. The MC does not extend outside the kernel (there might be exceptions, but those need to be really convincing).
[12:01] <mchehab> sailus: what MC actually represents is not the hardware, but the linux software that it is associated with the hardware (or sometimes firmware or software embedded on some hardware)
[12:01] <sailus> hverkuil: Imagine a device which runs a program that processes data.
[12:01] <hverkuil> Device nodes however are very much part of the MC as entities in their own right.
[12:02] <hverkuil> sailus: such as any device running firmware?
[12:02] <mchehab> sailus: you just described most V4L hardware
[12:02] <mchehab> and dvb as well
[12:02] <mchehab> most of them has either a FPGA or a micro-controller that runs some software there to do video streaming functions
[12:03] <mchehab> even the really old ones, like bt878 are like that
[12:03] <sailus> hverkuil: Device nodes are important, but for purely practical point I don't see a need for entities for every device node.
[12:03] <sailus> We don't have entities for V4L2 sub-devices either.
[12:03] <sailus> (There are V4L2 sub-devices that are exposed by entities though.)
[12:03] <larsc> the MC graph is supposed to accurately describe the data flow (and possible control flow)
[12:04] <larsc> from source to sink
[12:04] <mchehab> sailus: did you ever see how the DMA engines happen inside bt878 driver?
[12:04] <hverkuil> we should have a separate entity for a v4l-subdev device node IMHO, but there is a clear 1-1 relationship between the two, so I consider it a shortcut :-)
[12:05] <mchehab> it is a piece of software that the bt8xx driver produces in runtime and sends to bt878 chip
[12:05] <mchehab> see drivers/media/pci/bt8xx/btcx-risc.c
[12:05] <mchehab> bt848/bt878/cx2388x risc code generator.
[12:06] <hverkuil> note that there is a media_entity inside the video_device struct, it is just not initialized for a v4l2-subdev. Somewhat ugly I think.
[12:07] <sailus> mchehab: How about an example related to... DVB? :-)
[12:07] <sailus> Are there cases where there is control but no flow of data in DVB hardware pipeline?
[12:07] <mchehab> DVB has several device nodes that are just control points...
[12:07] <mchehab> like the /dev/dvb/adapter/net?
[12:07] <sailus> mchehab: The same with sub-devices. No difference there.
[12:08] <mchehab> sailus: if the MC is meant to represent only the data flow, this shoudn't appear there
[12:08] <mchehab> nor flash sub-device
[12:08] <mchehab> as this won't be an entity
[12:08] <sailus> The implicit control is there in some cases in camera pipelines, it's just on the same pipeline as the data.
[12:08] <mchehab> so, either we allow control entities or not
[12:09] <sailus> Stream starting and stopping, to name the obvious one.
[12:09] <sailus> mchehab: These are devices nodes that act as control points to the hardware devices.
[12:09] <mchehab> ok, so you're actually agreeing that we should then represent control entities?
[12:10] <sailus> It's very similar to V4L2 sub-device nodes, isn't it?
[12:10] <sailus> mchehab: Could you elaborate the idea of a control entity in the DVB context?
[12:11] <hverkuil> with the exception that a v4l-subdev controls only the subdev and nothing else. Whereas radio/dvb/etc. nodes can control multiple entities.
[12:11] <mchehab> sailus, hverkuil: I'll need to do another meeting... be back in ~30 mins
[12:11] <hverkuil> OK
[12:11] <sailus> mchehab: Ack.
[12:12] <sailus> hverkuil: So that e.g. a frontend device controls tuner and demod, for instance?
[12:12] <hverkuil> right
[12:13] <hverkuil> many of the non-MC v4l drivers control multiple subdevs through a single video node.
[12:14] <sailus> In a similar way, a sensor can be controlled through a video node, if you like, on V4L2 devices (as "data only" interface).
[12:14] <sailus> s/V4L2 devices/video nodes/
[12:14] <sailus> Stream start and stop are an example.
[12:17] <hverkuil> that is an implicit assumption that only works if the control and data paths are identical. But when they are different, then that assumption no longer holds and you need to be explicit.
[12:17] <sailus> The bridge driver will also need information from the sensor device to properly configure the CSI2 bus timing as well.
[12:17] <sailus> hverkuil: Could you give an example on the differences on DVB?
[12:18] <hverkuil> Take the ivtv driver: it has a passthrough mode where the video goes from the video input to the video output. If that is enabled, then the control of the tuner is still via /dev/video0, even though the data no longer ends up there.
[12:18] <sailus> How do you start it in this case?
[12:19] <sailus> I think we need a generic way to do that, and not every driver exposes a video node (for a reason) in this case.
[12:20] <larsc> one way to implement this is to add the ability to disconnect a flow in the graph
[12:21] <hverkuil> I think you just set it in passthrough mode and it starts automatically. Note that this driver was made years before the MC was designed.
[12:22] <sailus> Ok. I think a proper solution would be needed for that.
[12:22] <sailus> You can't disable an active link in MC, well, unless it was dynamic.
[12:23] <hverkuil> sure, but it is completely unrelated to the current problem.
[12:23] <sailus> Suppose that you also added a memory sink to the pipeline; it'd be unpleasant to configure.
[12:23] <sailus> hverkuil: Do you have an example related to the current problem. :-)
[12:25] <hverkuil> a radio is still the easiest and best example. DVB has similar problems, but with some effort you can work around it (I forgot the details, we discussed that in San Jose), but that workaround does not extend to a radio device.
[12:26] <hverkuil> So I have /dev/radio, I have a tuner subdev and the output either goes to an alsa device or a line-out connector.
[12:27] <hverkuil> In the MC you need to see that /dev/radio controls the tuner.
[12:28] <hverkuil> the same problem occurs elsewhere in varying degrees of complexity, but this is a good minimal problem description.
[12:29] <sailus> hverkuil: Wouldn't you have links between these entities then?
[12:29] <sailus> To describe the flow of data?
[12:29] <sailus> It does not have to be digital. :-)
[12:29] <hverkuil> Not today because there is no data flow between the two, only control (typically an i2c bus).
[12:30] <sailus> But the audio has to go somewhere, doesn't it?
[12:30] <sailus> Otherwise it'd be pointless.
[12:30] <larsc> sailus: I think you should specify what you mean by "these entities"
[12:30] <sailus> Radio, mixer and a connector.
[12:31] <hverkuil> It either goes to an alsa pcm device, or (very common as well) straight to a line-out connector on the device. The end-user is supposed to loop that back to a line-in on the motherboard in order to play the music.
[12:31] <sailus> http://www.retiisi.org.uk/v4l2/tmp/esimerkki.txt
[12:31] <sailus> Would that describe it?
[12:32] <hverkuil> Do you mean with 'radio' the /dev/radio device node or a tuner i2c sub-device?
[12:32] <sailus> Tuner.
[12:32] <sailus> Fixed.
[12:32] <hverkuil> OK, then yes, that
[12:32] <hverkuil> that's the HW description.
[12:32] <hverkuil> But apps need to know that there is a /dev/radio device as well, otherwise it is just an expensive paperweight.
[12:33] <hverkuil> Sort of like a normal radio without the tuner knob.
[12:33] <larsc> properties!
[12:33] <larsc> ;)
[12:33] <sailus> If you add the device nodes, would they look like I added them?
[12:33] <sailus> (Please reload.)
[12:33] <hverkuil> yup.
[12:34] <hverkuil> (although in this case the mixer would most likely controlled by /dev/radio as well, that's more common)
[12:34] <sailus> So, in fact it should be relatively clear to figure out which radio and which mixer are related, shouldn't it?
[12:35] <hverkuil> if it is an alsa device, then there would be a /dev/mixer and the connector would be replaced by /dev/pcm.
[12:35] <sailus> Ok.
[12:35] <hverkuil> And if it is a combined radio/TV tuner, then the graph becomes a lot more complex.
[12:35] <hverkuil> or radio/tv/dvb :-)
[12:37] <sailus> Please reload again.
[12:37] <sailus> Does the second example describe a case where the audio is captured through an ALSA PCM device?
[12:37] <hverkuil> in example 1 replace /dev/mixer by /dev/radio (same radio device)
[12:37] <hverkuil> the second example is correct.
[12:38] <sailus> hverkuil: Let's make that the third example, ok?
[12:38] <hverkuil> make what the 3rd example?
[12:38] <sailus> Where the mixer is controlled through /dev/radio.
[12:39] <larsc> what's the mixer anyway in this example?
[12:39] <hverkuil> I'd make an explicit link from /dev/radio to mixer instead of having two /dev/radio's.
[12:40] <hverkuil> larsc: mute, volume control, sometimes bass/treble control
[12:40] <hverkuil> Usually very primitive and often in the same chip as the tuner.
[12:40] <sailus> hverkuil: This just describes the hardware (upper part of the diagram), and below that there are the device nodes (if any).
[12:40] <sailus> hverkuil: I.e. it's the same /dev/radio.
[12:40] <hverkuil> right
[12:41] <sailus> How does a driver control this in the first place?
[12:41] <sailus> Isn't that a single hardware device in this case?
[12:41] <larsc> hverkuil: and /dev/mixer is that v4l or alsa?
[12:41] <sailus> Or do you have cases where you have a tuner and a mixer separately?
[12:41] <sailus> larsc: ALSA.
[12:42] <sailus> That'd be control something in fact I guess.
[12:42] <hverkuil> tuner: VIDIOC_G/S_FREQUENCY, G/S_TUNER and a few other related ioctls. Mixer: audio controls (http://hverkuil.home.xs4all.nl/spec/media.html#control)
[12:42] <larsc> k, the alsa mixer devices are called /dev/snd/control/
[12:43] <hverkuil> in the past we never used alsa for the audio, that came later. Whether the mixer is a separate chip or not depends on the hardware: generally radio-only cards combine them while the more complex radio/TV cards have a separate mixer chip.
[12:43] <sailus> Fixed.
[12:44] <sailus> hverkuil: So, in fact, in this diagram the tuner and the mixer should be a single hardware device?
[12:45] <hverkuil> It could be either. For the simple radio-only devices that we have today it is a single hw device as far as I know.
[12:45] <sailus> hverkuil: Ok.
[12:46] <sailus> But if they were separate, there would have to be some driver exposing the /dev/radio device, right?
[12:46] <sailus> But this wouldn't be the driver for either of tuner or mixer?
[12:46] <hverkuil> Yes, a platform, USB or PCI or ISA bridge driver.
[12:47] <hverkuil> Of course, with a USB device you often don't see what is behind the USB bus, it looks like a single device to the kernel.
[12:47] <hverkuil> so many options...
[12:48] <sailus> Let's call that example 4. :-)
[12:48] <hverkuil> (And I haven't even started describing RDS!)
[12:49] <sailus> :-D
[12:49] <hverkuil> and that's just for a 'simple' radio-only device.
[12:50] <hverkuil> I think we all agree that you need to be able to find the device nodes needed by applications using the MC.
[12:50] <sailus> (The arrows describe the flow of data.)
[12:50] <sailus> Where in these examples can the "control without data" be seen?
[12:51] <hverkuil> All examples. In all cases the radio device just controls something, there is never any data arriving there.
[12:51] <hverkuil> ditto for /dev/snd/control
[12:51] <hverkuil> only pcm gets data.
[12:53] <hverkuil> the problem with associating device nodes are properties or using some similar mechanism is that it doesn't scale in a case like example 3:
[12:54] <sailus> hverkuil: There *is* data flowing there. It may just happen to be analogue, not digital.
[12:54] <hverkuil> there is no way we can expect apps to enumerate all entities, find all associated device nodes and figure out which device nodes are actually the same.
[12:54] <mchehab> sailus, hverkuil: the examples there at http://www.retiisi.org.uk/v4l2/tmp/esimerkki.txt are not actually right
[12:54] <mchehab> the /dev/radio interface doesn't just control the tuner...
[12:54] <hverkuil> If you want, you can call it control data. It's also bidirectional (in general), whereas media is unidirectional.
[12:54] <sailus> hverkuil: I'd expect the tuner and the mixer could be the same entity if they share a device node.
[12:54] <sailus> There's a single driver for them after all.
[12:54] <mchehab> it controls other parts of the H/W, like A/D sampling rate...
[12:55] <mchehab> the input mixer select, etc
[12:56] <hverkuil> sailus: not at all true for more complex cards that include TV capture: the mixer is usually a separate chip.
[12:56] <sailus> hverkuil: What is bi-directional here?
[12:56] <sailus> Please do not mix control and data, but be explicit on which one it is.
[12:57] <hverkuil> control data: you write to a device and read from a device.
[12:57] <hverkuil> sorry, my sentence was a bit ambiguous
[12:57] * mchehab is still reading the backlogs...
[12:57] <hverkuil> s/control data/control/
[12:57] <sailus> hverkuil: Agreed.
[12:58] <hverkuil> you could make a case for a master/slave relationship w.r.t. control links.
[12:59] <hverkuil> but I think that is not needed.
[12:59] <sailus> hverkuil: We have established so far that a /dev/radio device node is used to control both the tuner and the mixer.
[12:59] <sailus> In examples 3 and 4, that is.
[12:59] <sailus> Agreed?
[13:00] <hverkuil> yes.
[13:00] <sailus> What is bi-directional in the data flow, if I call the audio signal as such?
[13:00] <hverkuil> the dataflow is unidirectional.
[13:00] <mchehab> sailus: a more complete description of the hardware is at: http://blogs.s-osg.org/media-controller-support-for-dvb-part-1/
[13:00] <mchehab> see figure 1
[13:01] <mchehab> it shows a complex customer PC device
[13:01] <mchehab> an embedded device will have multiple HW entities of all sorts
[13:01] <mchehab> multiple tuners, demods, audio/video encoders, decoders, etc
[13:02] <sailus> mchehab: Thanks for resending the link.
[13:02] <mchehab> Figure 1 shows the control pipeline
[13:02] <hverkuil> mchehab: we've been discussing the humble radio for an hour, discussing that will take months! :-)
[13:02] <mchehab> e. g. the I2C bus and the Bridge to CPU bus
[13:03] <sailus> We've been just discussing simple analogue radios so for in order to find a simple example of... control being applied to hardware devices that cannot be deduced from the data pipeline.
[13:03] <mchehab> the point I want to bold is that, on a complex hardware, the tuner is not the same as the /dev/radio devnode
[13:03] <mchehab> there will be a tuner subdev
[13:03] <mchehab> and a /dev/radio devnode
[13:03] <sailus> mchehab: Right.
[13:04] <mchehab> the tuner subdev controls just the tuning part
[13:04] <mchehab> with is actually an analog stage of the device
[13:05] <mchehab> at some part of the hardware, there's the A/D (a radio decoder)
[13:05] <sailus> mchehab: Could we go to the DVB part after a bit? I think we haven't finished the analogue radio yet. :-)
[13:05] <mchehab> I'm talking just about radio
[13:05] <mchehab> and, as hverkuil, mixers
[13:05] <sailus> mchehab: Ok. :-)
[13:06] <mchehab> both tuner, AM/FM demod, A/D and mixers are controlled by /dev/radio
[13:06] <mchehab> while the tuner subdev controls just the tuning part
[13:06] <mchehab> what I'm saying is that we can't associate /dev/radio with just the tuner
[13:06] <sailus> mchehab: Where does the tuner sub-device come into play in this setup?
[13:07] <mchehab> there is a 1:n mapping between the devnode and the device
[13:07] <sailus> (Let me try to add such a case to the list of examples.)
[13:07] <mchehab> the tuner can either be connected to an AM/FM demod...
[13:07] <mchehab> to a TV demod...
[13:07] <mchehab> or to a DVB demod
[13:08] <mchehab> so, it should be a separate entity
[13:08] <mchehab> as we should be able to reroute the pipelines there
[13:08] <sailus> mchehab: Reload, please.
[13:09] <mchehab> ?
[13:09] <sailus> Does example 5 describe the data flow, as you see it?
[13:09] <sailus> http://www.retiisi.org.uk/v4l2/tmp/esimerkki.txt
[13:09] <mchehab> yes, that's the data pipeline, when it has DMA
[13:09] <sailus> mchehab: Ack.
[13:10] <sailus> If it didn't have DMA, how would it be different?
[13:10] <mchehab> instead of DMA, a connector
[13:10] <mchehab> well...
[13:10] <sailus> Ah, right.
[13:10] <mchehab> acutually:
[13:10] <sailus> That doesn't change much though, there are similar (but simpler examples) above.
[13:10] <mchehab> tuner ------> FM/AM demod ------> A/D conv. ------> mixer ------> D/A ------> connector
[13:11] <mchehab> the same device may actually have both connectors and DMA
[13:11] <sailus> Ah, in that case, yes, if the mixer is digital indeed. :-)
[13:11] <sailus> I guess we could leave that case out for now, as I don't think it's in the core of the problem area?
[13:11] <mchehab> sailus: we're trying to add support for hybrid devices
[13:12] <mchehab> so, radio is still a left over
[13:12] <mchehab> almost all hybrid device drivers have radio
[13:12] <sailus> Yes, but having an audio output connector doesn't make it a hybrid device, does it?
[13:12] <mchehab> (the real hardware may eventually not have, as the vendor may opt to not wire the radio components)
[13:13] <mchehab> no
[13:13] <sailus> Good.
[13:13] <mchehab> what we call hybrid is analog TV/digital TV
[13:13] <hverkuil> mchehab: I think it is basically similar to example 3, just more subdevs to control through /dev/radio, but not really different.
[13:13] <sailus> Then, how do you control this pipeline?
[13:13] <sailus> The tuner has a V4L2 sub-device, right?
[13:13] <mchehab> yes
[13:14] <mchehab> the question is where /dev/radio devnode will be represented?
[13:14] <mchehab> we don't want to have different representations if the device has or not DMA
[13:15] <mchehab> as this would be crazy for both apps and kernel drivers to implement
[13:15] <mchehab> as we also don't want to have different representations when a device has a /dev/video node that doesn't have DMA
[13:16] <sailus> mchehab: I agree in principle.
[13:16] <sailus> The tuner in this case is however controlled through its V4L2 sub-device.
[13:16] <sailus> 1. Should it be allowed to be controlled through /dev/radio as well?
[13:16] <sailus> 2. Which driver exposes /dev/radio node?
[13:16] <mchehab> yes
[13:17] <mchehab> I meant to say:
[13:17] <mchehab> 1) yes
[13:17] <sailus> A lot of these driver (all of them) shouldn't have explicit knowledge of each other I presume.
[13:17] <mchehab> 2. the driver that exposes /dev/radio node is either the bridge driver or the platform driver
[13:18] <mchehab> the tuner driver doesn't have the knowledge if /dev/radio will be exposed or not
[13:18] <hverkuil> that's the only one that knows all subdevs and how they relate to one another. Often based on USB or PCI IDs.
[13:18] <sailus> So we'd give the user a possibility to basically perform the same task over the tuner's sub-device an /dev/radio?
[13:18] <mchehab> this knowledge is only at the bridge/platform driver
[13:18] <sailus> Right.
[13:19] <mchehab> the tuner subdev is actually a subset
[13:19] <mchehab> of the things that can/should be done at /dev/radio devnode
[13:19] <sailus> What can be done using the tuner sub-device that cannot be done through /dev/radio?
[13:19] <sailus> I'd suppose /dev/radio be related to analogue radio only, right?
[13:19] <hverkuil> I don't think that today we ever create a v4l-subdev device node for a tuner device.
[13:19] <mchehab> tuner subdev would see just the tuned frequency, bandwidth, lowpass/bandpass filters, etc)
[13:20] <sailus> I.e. if you capture a DVB stream you're not interested in /dev/radio for instance?
[13:20] <mchehab> /dev/radio controls A/D, mixers and other things
[13:20] <sailus> hverkuil: Suppose we did. :-)
[13:20] <mchehab> but may not control directly very low level parameters of the tuner
[13:21] <sailus> mchehab: On bandwidth etc. --- is that something the user would do?
[13:21] <mchehab> sailus: depends on the app
[13:21] <mchehab> usual radio app won't give a dime for that
[13:21] <mchehab> but an embedded app may require a finer control
[13:21] <mchehab> that's why MC subdev came after all...
[13:22] <mchehab> to give more low level control over the hardware
[13:22] <mchehab> not to replace V4L2
[13:22] <sailus> A minute.
[13:23] <mchehab> if I capture a DVB stream, the pipeline should tell that the tuner connected to DVB... so the radio devnode is busy
[13:23] <mchehab> (or can't be used)
[13:25] <sailus> Back.
[13:26] <sailus> mchehab: Is there any important functionality that such a "master" would have, other than providing a /dev/radio device node to access the sub-devices? (Assume the connector instead of DMA for now.)
[13:27] <hverkuil> brb
[13:28] <mchehab> sailus: you can't live without the master :)
[13:28] <mchehab> on platform drivers, the "master" is simple...
[13:28] <sailus> Assume there was also a system-wide media device.
[13:29] <mchehab> but on other devices, the "master" is actually the main part of the hardware...
[13:29] <mchehab> that links everything
[13:29] <sailus> What functionality does it have?
[13:29] <sailus> DMA or something else?
[13:29] <mchehab> as it contains the I2C bus, the PCI/USB bus, etc
[13:29] <sailus> Ah, sure. It binds it all together.
[13:29] <mchehab> on several cases, the A/D and D/A are also there
[13:30] <mchehab> and DMA engines - or some RISC/FPGA stuff that can be used as a data transfer engine
[13:31] <hverkuil> back
[13:31] <sailus> Those would be additional entities in the pipeline with their own drivers, wouldn't they?
[13:31] <mchehab> it will all depends on the level of detail that the MC will expose
[13:31] <sailus> But from driver point of view?
[13:32] <sailus> We don't want to add dependencies to software that do not exist in hardware, at least in principle, right?
[13:32] <sailus> Sometimes the practice is less clear than that though. :-)
[13:33] <mchehab> sailus: in practice, the A/D, D/A, mixers, CPU, etc is bundled on a single chip, most of the time
[13:33] <sailus> Ok.
[13:34] <mchehab> on some cases, it will be exposed as multiple entities
[13:34] <mchehab> on others, there's no need
[13:34] <sailus> In order to control that from the user space, the user does need to know which roles the entities have, and which device nodes they expose?
[13:35] <mchehab> that depends on the usage
[13:36] <sailus> But in general, if the user does not have detailed knowledge of any particular entity, some role or capability information would be needed.
[13:36] <mchehab> for example, a very simple analog TV demod is: http://www.semiconductorstore.com/images/Promo_Landing/Trident_Announcement/SAA7115_BlockDiagram.JPG
[13:36] <mchehab> we won't be exposing all internal components of it via MC
[13:36] <sailus> Such as the V4L2 device profiles that haven't been implemented yet. :-)
[13:36] <mchehab> usually, just one entity is enough for all that stuff
[13:37] <hverkuil> sailus: profiles are actually implemented implicitly by v4l2-compliance. Just never written down (volunteers are welcome)
[13:37] <hverkuil> s/implemented/checked/
[13:37] <mchehab> on several chips (like bt878), that diagram is just an IP block of the chip
[13:38] <mchehab> sailus: but I'm still missing the point.... where you're trying to go?
[13:38] <mchehab> it sounds to me that we're losing the focus
[13:38] <sailus> I'd like to understand do we need multiple sets of device nodes to control the device.
[13:38] <mchehab> the problem is: there are entities that controls the device but aren't always part of the pipeline
[13:39] <mchehab> how to represent them?
[13:39] <mchehab> sailus: the answer is YES
[13:39] <mchehab> (otherwise, we won't need MC)
[13:39] <sailus> The tuner sub-device (and other control device nodes) makes /dev/radio redundant, doesn't it?
[13:39] <mchehab> NO!!!
[13:39] <mchehab> (10:10:44) mchehab: tuner ------> FM/AM demod ------> A/D conv. ------> mixer ------> D/A ------> connector
[13:40] <sailus> I'm not saying the *functionality* shouldn't be provided, but does the same driver need to implement it?
[13:40] <mchehab> tuner != radio
[13:40] <sailus> That's how it's in V4L2 as well when V4L2 acts as a data-only interface.
[13:40] <sailus> mchehab: I don't argue it would be.
[13:40] <mchehab> radio IS V4L2
[13:41] <hverkuil> sailus: you've lost me as well.
[13:41] <mchehab> tuner is typically a different driver
[13:42] <hverkuil> (have to leave in 15 min)
[13:42] <mchehab> tuner drivers are under drivers/media/tuners
[13:42] <sailus> Unfortunately I haven't had time to continue the work on the automatic pipeline configuration library. That would essentially give a traditional V4L2 data/control interface on devices that implement V4L2 as data-only interface.
[13:42] <mchehab> bridge/platform drivers are under drivers/media/[platform|usb|pci]
[13:42] <sailus> The problem domain is more simple in this case, that's why I'd at least consider virtual devices instead, and keeping things simple in the kernel.
[13:42] <mchehab> sailus: the problem is not about data
[13:43] <mchehab> it is about control
[13:43] <mchehab> how to map control points
[13:43] <sailus> Assume you had two tuners in example 5.
[13:43] <sailus> You couldn't select the tuner using /dev/radio, could you?
[13:44] <mchehab> no
[13:44] <mchehab> well... it may
[13:44] <sailus> Instead, you'd disable the link to tuner A and enable the link to tuner B.
[13:44] <sailus> (Let me add one more example for this case.)
[13:44] <mchehab> there's one ioctl to select the input
[13:44] <mchehab> and to enumerate tuners
[13:45] <mchehab> this is used on radio devices that have AM and FM bands
[13:45] <mchehab> with is sometimes provided by different radio chips
[13:45] <sailus> There.
[13:45] <mchehab> that's possible
[13:46] <mchehab> (on most modern cases, the AM/FM demod would actually be an IP block integrated with the tuner chip)
[13:47] <hverkuil> This is going nowhere. We keep getting bogged down in specific examples. None of this addresses the core issue of how to represent control-only device nodes.
[13:47] <mchehab> yes, I have the same feeling
[13:47] <sailus> Please bear with me still.
[13:47] <hverkuil> There is no point trying to find a workaround for a specific example only to find another example where that doesn't work.
[13:47] <mchehab> I guess I'll have to use my maintainer's power to dictate something...
[13:47] <hverkuil> sailus: you got 10 min.
[13:48] <sailus> So far I haven't seen the use case for those.
[13:48] <mchehab> as it seems that the discussions will lead nowere
[13:48] <hverkuil> mchehab: why not implement it as we both think it should be done. See what happens. Implement it in DVB and one non-trivial v4l device driver.
[13:49] <mchehab> hverkuil: yes, it seems to be the way to go
[13:49] <mchehab> and if someone has a different opinion, he can write a patch with his approach
[13:49] <hverkuil> if it fits cleanly, then that's a good indicator that we are on the right path, if it introduces weird problems, then perhaps it isn't as good as we thing it is.
[13:49] <sailus> hverkuil, mchehab: Please first outline what is the exact problem what needs to be resolved.
[13:50] <mchehab> sailus: we're doing that since January
[13:50] <sailus> I asked for a use case where the control path is different from the data path, i.e. where the control entities would be needed.
[13:50] <sailus> I haven't seen one yet.
[13:51] <mchehab> sailus: there's no /dev/radio on the data pipeline
[13:51] <sailus> mchehab: Because that's a software interface.
[13:51] <sailus> It's not part of the pipeline.
[13:51] <mchehab> but userspace needs to know
[13:51] <mchehab> and there's no way to put it there
[13:52] <sailus> mchehab: Why not?
[13:52] <sailus> We need a new IOCTL to better describe entities anyway.
[13:52] <mchehab> because there's no way to associate it with the current API
[13:52] <mchehab> I and hverkuil are telling this for a long time...
[13:53] <mchehab> but we're yet waiting to see a proposal addressing it...
[13:53] <hverkuil> Example 1 is exactly about that. /dev/radio is an entity, but it is not in the data path and you want to expose that it is linked through a control link to the tuner (and demod, and muxer, and whatever other entities there are). Currently links in the MC are data-only.
[13:53] <mchehab> nothing proposed right now, except for representing devnodes as entities seem to fit
[13:54] <sailus> /dev/radio is a Linux specific interface to access a radio. I don't think it should be part of the MC graph. But we need a solution to the problem, I agree.
[13:54] <mchehab> yes, on all examples 1 to 5, you're representing entities and control inks
[13:54] <sailus> mchehab: The links in the example describe the data flow.
[13:55] <sailus> I.e. the audio signal.
[13:55] <mchehab> you can't actually understand the mapping without adding the devnodes and the control links
[13:55] <mchehab> /dev/radio, /dev/snd/control, /dev/snd/pcm devnodes
[13:55] <hverkuil> userspace needs that information (the linux specific interfaces), otherwise it is just a pretty picture. Without those the MC is pointless.
[13:55] <mchehab> are linked to the data flow entities
[13:56] <mchehab> on example 5, the /dev/radio will be linked to tuner, FM/AM demod, A/D conv
[13:56] <mchehab> and may or may not be linked to mixer
[13:56] <mchehab> as the mixer can either be controlled by ALSA or by V4L2, depending on the device
[13:57] <sailus> How do you decide how many radio devices do you have, if they're *not* related to the data paths, i.e. concurrent audio streams on hardware?
[13:57] <hverkuil> got to go. I recommend just trying it out.
[13:57] <hverkuil> ttyl
[13:57] <mchehab> the radio devnodes is associated to the group of entities it controls
[13:58] <mchehab> hverkuil: yes, I'll do it. It seems to be the only way to solve it
[13:59] <mchehab> the devnodes are always associated to a one or to a set of hardware components it controls
[13:59] <sailus> What is a radio device node associated with then?
[13:59] <sailus> It's not the tuner, is it?
[13:59] <pinchartl> mchehab: I'm afraid I'll nack any patch that add devnode entities until we reach a consensus on an API
[14:00] <mchehab> pinchartl: I don't think we'll ever reach a consensus
[14:01] <mchehab> you and sailus seem to lack experience with the type of hardware I and hverkuil need to deal with...
[14:01] <mchehab> and it seems you're failing to understand the needs
[14:02] <mchehab> we can't keep discussing forever without seeing any light at the end of the darkness
[14:02] <mchehab> I'm all for discussions, provided that they lead somewhere
[14:03] <mchehab> but that doesn't seem to be the case
[14:04] <mchehab> so, I agree with hverkuil... the best seems to write a patch...
[14:05] <mchehab> and if you have a better idea, you can submit your approach
[14:05] <mchehab> if we have just one approach to address the issue, then we'll merge.
[14:05] <mchehab> otherwise, we'll then discuss about two concrete solutions to the problem
[14:06] <mchehab> with will acutally means that one solution or the other will be merged - with is a way better than what we have now
[14:07] <mchehab> sailus: a radio devnode is an entity linked with all those 3 entities: tuner -----> FM/AM demod -----> A/D conv.
[14:08] <mchehab> or, on other devices, with:
[14:08] <mchehab> tuner -----> FM/AM demod -----> A/D conv. ------> mixer
[14:08] <mchehab> or, yet
[14:08] <mchehab> tuner -----> FM/AM demod -----> A/D conv. ------> mixer ----> D/A ----> connector
[14:08] <mchehab> that's why a graph is needed
[14:09] <mchehab> as different devices will have a different graph for the control plane
[14:09] <mchehab> anyway, I've to go
[14:09] <pinchartl> I could consider an ioctl specific to devnodes though
[14:09] <sailus> mchehab: Don't be so sure about it.
[14:09] <mchehab> bbl
[14:09] <sailus> mchehab: You and hverkuil lack experience in drivers that implement an MC pipeline. :-)
[14:10] <pinchartl> mchehab: I think the problem can be solved without devnode entities
[14:10] <sailus> An example of how control entities would work might be useful. The real problems still might be elsewhere.
[14:10] <pinchartl> mchehab: there's definitely communication issues
[14:10] <sailus> mchehab: The previous discussion did help, believe it or not.
[14:10] <sailus> It's a very similar problem which was related to video nodes in the omap3isp driver long, long time ago. The solution back then was to make them a data-only interface.
[14:10] <pinchartl> mchehab: we've made lots of progress in San Jose. I think communicating online now doesn't work very well
[14:13] <mchehab> pinchartl: we can try an audioconf. do you/sailus have time?
[14:13] <mchehab> I'll be back in ~45 mins
[14:14] <sailus> But I'm not sure we could do just that since there are lots of programs that are using these drivers. We need to address how existing programs can work, too. Control entities would also be something new to existing programs.
[14:14] <mchehab> need to go now
[14:14] <mchehab> I'll work on a patchset with my proposal
[14:14] <mchehab> feel free to work on another patchset with your approach
[14:15] <mchehab> then we can discuss about the possible solutions and see what fits best
[14:15] <mchehab> now I'm really leaving
[14:15] <mchehab> bbl
[14:20] <pinchartl> mchehab: not today I'm afraid :-/
[15:11] <pinchartl> mszyprow: I know your secret plan is to burry me under IOMMU patches :-)
[19:04] <bparrot> prabhakarlad, ping
[22:43] <stormer> posciak: while discussing how to properly implement m2m driver for decoder, I realised that there is an inconsistancy between the slides from ELCE2014 workshop, and what we actually do
[22:43] <VladolfPutler> hi stormer
[22:44] <stormer> posciak: the slide says to STREAMON, and then queue buffers ou output, but in real life, we queue the header, and then STREAMON
[22:44] <stormer> I guess that would be worth having a chat
[22:45] <stormer> I don't remember if that was intentionnal (and we wanted to port the driver to that), but it feels like we wanted to make use of the source change event
[22:45] <stormer> anyway, let me know