<!-- 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>
crope: <u>mchehab</u>: because I added only one hour
sailus: Huomenta!
hverkuil: morning
sailus: <u>hverkuil</u>: How are you doing?
hverkuil: good, you?
sailus: Fine, too, thanks!
<br> pinchartl should join us in a minute or two.
pinchartl: I'm here
<br> sorry, I'm late
sailus: No problem!
<br> Well, I'm not sure if anyone else wishes to join, but I think we could start.
<br> On sub-device naming.
<br> Or, rather, entities.
<br> We don't really have any rules for naming them, but the established practice appears to be that i2c devices have the bus ID at the end of the name, whereas the rest do not.
pinchartl: I see three questions about entity names
<br> 1. do they have to be unique ?
<br> 2. how are they supposed to be used ?
<br> 3. how are they supposed to be constructed ?
<br> the first and third questions likely depend on the second one
hverkuil: Actually, I think it depends on the first question. If 1. is 'No', then they can't be used other than as a human readable string.
sailus: I think this name should be a human-readable name that refers to an entity, and this should be unique in the sysstem.
hverkuil: I agree with that.
pinchartl: here's what we currently do, please correct me if I'm forgetting anything
<br> 1. we don't enforce uniqueness in the code
sailus: As these names are referred to by the user space, they have to be stable as well.
<br> <u>pinchartl</u>: Correct. Perhaps we should.
pinchartl: 2. we use the names to print kernel log messages, to print userspace messages (command line or GUI), and to address entities in media-ctl
sailus: There should be no clashes though.
pinchartl: (media-ctl supports addressing an entity by name or by id)
<br> 3. we usually construct entity names from the Linux kernel device name
<br> for i2c devices that is
hverkuil: I think it is overkill to test for uniqueness in the kernel. That's more for a v4l2-compliance like tool.
pinchartl: for platform devices, drivers choose the names pretty much freely
sailus: The reason for the lack of bus information there is that there's typically a single ISP-like device on an SoC.
<br> I'm not sure if that's globally true, and I might not want to rely on a driver to know that.
pinchartl: <u>sailus</u>: another reason is that names uniqueness is only guaranteed in the context of a media device (that is, if at all)
<br> so there's no issue with multiple identical ISPs
sailus: Well, currently no.
pinchartl: <u>hverkuil</u>: agreed, testing for uniqueness in the kernel is probably not the best idea
sailus: But if you think of having a system-wide media device in the system, then they have to be unique in the system.
pinchartl: <u>sailus</u>: correct
hverkuil: agreed
sailus: And we couldn't later change that.
<br> These names cannot be changed, that'd break the user space.
pinchartl: we also need to consider that the name is currently 32 bytes long
<br> that's usually too short to encode a platform device name plus an entity-specific part
sailus: For i2c it works, but for e.g. PCI it'd be a bit painful.
<br> How about platform devices?
<br> Could the base address be used for the purpose?
pinchartl: yes. i2c device names are short, PCI or platform device names can be longer
sailus: This makes me think of a new IOCTL for obtaining information on entities. :-)
pinchartl: yes, that's certainly needed
<br> but that's a separate issue I believe
hverkuil: Re PCI naming: many of the current PCI drivers construct a unique name by the driver name + instance ID.
sailus: It is.
hverkuil: E.g. ivtv0, ivtv1, etc.
pinchartl: how is the instance ID obtained ?
hverkuil: Usually because the full device name (PCI bus string) is unwieldy.
<br> driver-global atomic counter.
pinchartl: that doesn't sound stable across reboots
<br> especially for platform devices
sailus: Well, a PCI bus:slot.function is seven characters.
<br> On i2c that's six.
<br> Not so much of a difference.
<br> Hm, well, lspci and Linux appear to be using different notations. The kernel has more information.
hverkuil: Right.
sailus: That'd add five characters which wouldn't be that nice.
hverkuil: Example of a kernel-constructed PCI prefix: 'solo6x10 0000:87:05.0'
sailus: That's a big longish, I agree.
hverkuil: So 13 chars for the bus name, that leaves 18 for the entity name. Should be enough, I would say.
<br> It's similar to the bus_info as returned by querycap.
<br> Well, not quite, since that only contains the bus info, not the name.
pinchartl: do we need to ensure uniqueness system-wide, or in the context of a media device ?
sailus: <u>pinchartl</u>: I'd prefer system wide uniqueness.
hverkuil: Only in the context of the media device.
<br> :-)
sailus: That was not the original goal, though.
pinchartl: in the later case, the pci or platform device prefix could be omitted
<br> why would you prefer system-wide uniqueness ?
sailus: <u>pinchartl</u>: System wide media device would later on make implementing support for cross-device pipelines easier, for instance.
<br> I'm not sure how much there's need for them though.
pinchartl: probably not much on PCI, but for platform devices, I agree
sailus: And deep tunneling of buffers (through e.g. firmware) might benefit of that, too.
pinchartl: through firmware ?
hverkuil: how would you connect two entities if they aren't in the same media device? If they are connected, then they belong to the same MC.
pinchartl: <u>hverkuil</u>: they need to be in the same media device, yes
<br> currently a media device spans a single PCI or platform device
<br> but in the future we might need to combine them
hverkuil: I think that in practice the names will turn out to be unique for the system.
sailus: I'd prefer to have the CPU in between, but this could gain some benefits in e.g. power consumption.
pinchartl: I know of an ISP that has two separate pipelines as two separate IP cores
<br> with a connection between the two
<br> there's one platform device per pipeline
<br> and they need to be part of the same media device
<br> which we currently don't support, but should soon
<br> (that's the media device registry we've discussed at fosdem)
sailus: <u>pinchartl</u>: Do you have notes / other material on this?
pinchartl: <u>sailus</u>: not really, just a couple of ideas
sailus: :-)
pinchartl: I wonder whether a userspace API extension wouldn't make sense to support this
hverkuil: Note that we can construct system-wide unique names for entities by prefixing it by the media controller device bus_info string.
pinchartl: if we have several platform (or PCI) devices exposed through a single media device
hverkuil: (BTW, the spec should be updated that bus_info in media_device_info must be unique)
pinchartl: then the media controller bus_info string will be pointless
<br> I wonder whether we shouldn't report the list of hardware devices (with names) part of the media device
<br> and which hardware device an entity belongs to
hverkuil: It's like bus_info in querycap: while usually it will refer to an actual bus, for platform devices it is just a unique string.
pinchartl: I believe such an extension could be done in a backward compatible way without too much issues
<br> and it would allow moving the potentially long hardware device name out of the media entity name to the new hardware device reported by the API
<br> only the combination of the two would then need to be unique
hverkuil: It seems overkill to me. Doing all that just because the PCI bus info is relatively long? Isn't it easier to just keep the entity name short for such devices?
pinchartl: no
<br> the main reason is because media devices will be made of multiple platform devices in the future
<br> and it could be useful for userspace to know which hardware device an entity belongs to in that case
sailus: The bus information field in the media device is a funny one to begin with, it should have been related to entities instead.
pinchartl: the design idea was that a media controller device was tied to a single platform or PCI device
<br> hence the bus info
hverkuil: <u>pinchartl</u>: so, isn't that an entity property?
sailus: It was so, indeed.
<br> From a certain angle it was a sound decision at the time. :-)
pinchartl: yes, it's an entity property
<br> there are several ways to report it
hverkuil: bus_info is an unfortunate name, it should be called just 'name' IMHO. It's basically copied from querycap.
pinchartl: one of them is to report a list of hardware devices with ids, and report the hw device id for each entity
sailus: How many name clashes do we actually have at the moment?
pinchartl: another one is to report the hw device string for each entity
<br> I'm sure there are other ones
hverkuil: We need properties anyway, and this would fit right into that.
pinchartl: I'm not sure about that
<br> it's quite a core information
<br> I wonder whether it wouldn't be better reported through the existing media entity enumeration ioctl
sailus: Using new drivers could require using new IOCTLs, so we could require using the extended media entity IOCTL support from all new drivers.
hverkuil: <u>sailus</u>: the DVB MC additions may cause duplicate names (although Mauro posted patches I think to resolve that).
pinchartl: my idea is to add a new ioctl to report hardware devices with ids + names + whatever
<br> and to add a field to the existing media entity info structure for the hw dev id
sailus: <u>pinchartl</u>: I support that.
pinchartl: but other implementations are possible
<br> through properties for instance, as hverkuil mentioned, even though I don't like that too much as I believe it's a core property that should be available through media_entity_desc
hverkuil: So does this mean that if we have HW device information, that the entity name only has to be unique within a singe HW device?
pinchartl: that's my idea at least
<br> userspace could then compose the full entity name from hw dev name + entity name
sailus: How would the user space refer to the entities then?
<br> Using both bus + name always?
pinchartl: hwdev name + entity name, yes
<br> well, it depends on what userspace needs
sailus: Would the hwdev name be the bus string in general, or something else?
pinchartl: if it needs to refer to an entity in the context of a media device, it should use that name
<br> for instance media-ctl would do on the command line
<br> but if you want to display mc topology in a GUI
sailus: The user space must use an unique way in order to avoid issues if we don't guarantee name uniqueness.
pinchartl: you could group entities together in hw devices in a graphical way
<br> and avoid displaying the full name everywhere
sailus: <u>pinchartl</u>: grouping sounds good, yes.
hverkuil: This seems overkill to me. For SPI/I2C/PCI the entity name is always unique since the bus info included in the name is unique system-wide.
pinchartl: I like the hwdev name being the bus string
hverkuil: For platform entities the entity driver knows the hw device and can include that in the entity name.
sailus: That could be used to avoid putting even i2c device information to the names for new drivers.
pinchartl: <u>hverkuil</u>: for platform devices at least the entity name won't be long enough to store them
hverkuil: Why not?
sailus: Could e.g. the MMIO base address be used for platform devices?
pinchartl: because platform device names can be pretty long
<br> <u>sailus</u>: on 64-bit systems that's 16 characters just for the base address
sailus: Or, do you have better human-readable unique names for them?
<br> <u>pinchartl</u>: True.
pinchartl: even dev->of_node->name isn't unique
<br> or isn't guaranteed to be unique at least
hverkuil: I feel that if it becomes longer than 31 chars you should think about a better alias anyway, since such long names are very user-unfriendly. And what is long enough? 32 chars? 64? 128?
pinchartl: but even regardless of the name, doesn't it make sense to report to which hw device entities belong to ?
<br> that's really part of the hardware topology
hverkuil: Sure, I've no problem with that.
pinchartl: and as a side effect it could solve the naming issue
<br> two birds with one stone
<br> except I don't kill birds
<br> but you get the idea
hverkuil: That's where I have a problem: it's changing the API.
pinchartl: it's extending it
<br> and for backward compatibility is should be easy
<br> if we add a hw dev id to struct media_entity_desc
<br> if that id is zero, there's no hw dev name
<br> if the id isn't zero, the full entity name is made by the hw dev name and the entity name
hverkuil: What would be the HW device name for e.g. a standalone flash controller?
sailus: The i2c bus address?
pinchartl: the hw dev name should depend on the device type
<br> it should be unique system-wide
<br> identify the hw device
<br> and be stable
hverkuil: <u>sailus</u>: but that's already part of the entity name (and can't be changed since that would break backwards compatibility)
pinchartl: we could also report the hw model name (DT compatible string, platform dev id, ...), but that's just extra information that wouldn't be used in entity names
sailus: <u>hverkuil</u>: How about new devices?
<br> In that case we're not breaking something since it didn't exist. :-)
hverkuil: <u>sailus</u>: what do you mean?
<br> oh, ok
<br> let's go back to basics: what is a hardware device? Is an i2c device a HW device? If yes, then any i2c entity is its own HW device, right?
pinchartl: a hw device is a chip or IP core
<br> and i2c device is a hwdev, yes
<br> s/and/and an/
sailus: <u>pinchartl</u>: Do you have an example of that for platform devices?
hverkuil: So for an IP core, what makes it an HW device? I mean, say I have two pipelines, each consisting of various other IP cores, each with its own entity, is the HW device the top-level pipeline IP core, or just the IP core the entity drives?
pinchartl: that will depend on your hardware
<br> if you have two instances of an OMAP3 ISP for instance
<br> then that would be two hw devices
<br> in the Xilinx case, on the other hand, each entity is an IP core
<br> I don't believe it would make sense to create one hw device per entity in that case
sailus: <u>pinchartl</u>: How would such a name look like?
pinchartl: coming from DT, something like omap3isp@480bc000
<br> that would be the node name
sailus: And on 64-bit systems, somewhat longer?
pinchartl: but the node name isn't not guaranteed to be unique, so some mangling would be required to ensure the name is unique
hverkuil: it's one of the reasons I'm reluctant: this only works if there are very precise guidelines what constitutes a HW device.
pinchartl: by translation the bus address into a CPU physical address for instance
<br> on 64-bit, that could be longer, yes
<br> don't we need equaly precise guidelines on how to create names ?
hverkuil: The current rule is very easy: generate a unique entity name (unique within the MC). I don't care how you do it, that's the driver's responsibility.
sailus: Is it that there's no global requirement for these names to be unique, or do we know a case where they are not?
pinchartl: <u>hverkuil</u>: and that doesn't scale for media devices made of multiple platform devices
<br> like in the iMX.6 dual IPU case
<br> we need more precise guidelines
<br> as the drivers currently consider they can choose names freely, without caring about other drivers
<br> it won't be the case anymore in the future
<br> <u>sailus</u>: the node names in DT are only unique in the context of their parent node
<br> so if you have two identical platform devices on different buses, they could have the same node name
sailus: Right.
<br> But the MMIO base address would still have to be different for the CPU to access both, wouldn't it?
<br> Even if DT wouldn't as such guarantee it.
pinchartl: yes
<br> the addresses of the two devices could be identical on their bus
<br> but when translated to CPU physical addresses, they would be unique
<br> this is why I mentioned that some mangling might be needed
hverkuil: Every entity representing an IP core will have a unique ID (e.g. address), so why can't it just say "ipu@<physaddr>"?
pinchartl: that would already be 20 characters on a 64-bit system
hverkuil: even at 64 bit addresses you are still left with 14 characters for the entity name.
pinchartl: that's becoming pretty short
sailus: 14 characters is not much.
pinchartl: "OMAP3 ISP CCDC output" is 21 characters long
sailus: If you have things like "OMAP 3 ISP preview" for instance, you have to make some serious adjustments.
pinchartl: it could be argued that "OMAP3 ISP" shouldn't be repeated in each entity name though, but I believe it should be present somewhere
<br> possibly not in the entity name
sailus: Hmm.
pinchartl: actually probably not in the entity name
<br> "omap3isp@480bc000:preview" seems like a better name
hverkuil: isn't the entity ID always unique? So in that case you can use the entity ID in the entity name if that's needed to make it unique.
sailus: I think I agree with that.
pinchartl: but it still wouldn't work well
sailus: The PCI and I2C devices will need more than just the bus address though.
pinchartl: omap3isp@480bc000:preview.out is 29 characters long
<br> on a 64-bits system we're screwed
<br> the entity ID isn't stable
<br> we need names to be stable
<br> if entity IDs were stable in the first place we wouldn't need names
sailus: <u>pinchartl</u>: Do you think we could have a scheme that wouldn't involve ramming this all into the name field, at least for new devices?
pinchartl: yes we could
<br> what is needed is a stable way to refer to an entity in userspace
<br> and the name has been used for that so far
<br> we can decide on a scheme to construct userspace stable IDs from entity name + other information
sailus: What would you think of adding a new field for the hwdev information?
<br> All new drivers would be required to make use of it.
pinchartl: that would be the stable name that userspace can use to uniquely refer to an entity
<br> it's possible, yes
<br> I'm not keen on adding a new char[largish number] array there though
sailus: Should this be done using the existing struct media_entity_desc, or require using a new IOCTL for the purpose?
hverkuil: What about adding a 'u64 instance;'?
sailus: In that case the existing drivers could start using it as well.
hverkuil: That could be an address, it could be a counter, whatever. Or 0 for existing drivers.
sailus: As long as the information they report using existing MEDIA_IOC_ENUM_ENTITIES stays the same.
hverkuil: So the unique name would be <name>.<instance>
pinchartl: <u>hverkuil</u>: I'd but the instance first
<br> instance.name
<br> and
<br> a u64 address is fine for platform devices
sailus: Should we do that, I'd rather make it a string.
pinchartl: but for I2C you can't encode the device bus info into a u64
sailus: Or, you could, but that'd be quite confusing to the users.
<br> Same for PCI.
hverkuil: for i2c the bus info fits fine in the entity name. I wouldn't change that.
pinchartl: I'd rather make that instance a string as well
<br> and call it a hw dev name :-)
<br> <u>hverkuil</u>: I don't like using totally different methods for different hw device types
<br> I'd much prefer deciding on something standard for new drivers, and sticking to that
hverkuil: I really don't like hw dev since there are already so many 'devices' and it's very vague what it means, esp. when related to IP cores.
pinchartl: should we sleep over this ?
<br> or possibly lunch over this :-)
sailus: <u>hverkuil</u>: There are different ways to split things into devices. If we decide exactly what it means we could have issues later with hardware that doesn't match well with the definition in a way or another. In most cases this would be just bus information still.
<br> I'll skip the lunch today.
<br> Tomorrow, the same time?
hverkuil: To summarize my stand: for i2c/pci/spi entities I see no problems. There aren't any today, and I don't expect to see them in the future. The current scheme works IMHO.
<br> For platform devices I agree that we need something to make it more unique, but I am not convinced that calling it a 'HW device name' or bus is the right approach since I think that is actually very fuzzy in practice.
<br> Tomorrow same time would work for me.
pinchartl: for me as well
sailus: Ack.
hverkuil: <u>pinchartl</u>: the spec should be updated to mention that the entity ID is unique but not stable.
sailus: <u>hverkuil</u>: Ugh.
<br> <u>hverkuil</u>: Right, I agree.
pinchartl: what ?
sailus: Unless it's already there, it must be added.
pinchartl: shouldn't it be stable ?
<br> that's the whole point
janaszewski: hi all, I'd also consider devices which are not bound to any bus, but are driven through GPIOS in a one-way direction manner, i.e. they can't read any information from the device
sailus: ID, not name.
pinchartl: I mean shouldn't we make it stable ?
<br> ah, yes
<br> ID
<br> indeed, sorry
janaszewski: like aat1290 driver from my LED/flash integration patch set
pinchartl: <u>janaszewski</u>: good point
<br> those are platform devices without a CPU address
janaszewski: in this case only DT property could work somehow IMO
pinchartl: dev->of_node->full_name would possibly work
<br> but that's pretty long
sailus: We could use just gpio:first GPIO used by the chip, or such.
pinchartl: <u>sailus</u>: gpio numbers are not stable
hverkuil: Hmm, so Linus decided on 4.0 for the next version...
sailus: <u>pinchartl</u>: Good point.
<br> That should be prefixed by the GPIO controller name.
janaszewski: for such devices it is also possible that GPIO signal can be routed through muxes, i.e. many devices can be controller from one GPIO
pinchartl: now this is getting really out of hands :-)
sailus: I hope we'll never see those boards. :-)
janaszewski: :)
<br> It is conceivable for me in case we would like to control rear and front camera flash from common GPIO - on exynos4412-trats2 board a mux is used for switching software/external strobe source
pinchartl: lunch time, I'll be back in a bit
sailus: <u>janaszewski</u>: Have you seen a front camera with a flash? :-)
janaszewski: not really :)
<br> but it doesn't mean that it will not appear in the future :)
pinchartl: <u>hverkuil</u>: btw, it will be e-mail time after lunch, I'll review your video/pad ops patches
<br> and Mauro's DVB patches
hverkuil: thanks!
<br> fixed two tiny bugs in media_build to make it compile a 4.0 kernel.
robstr: do i need to convert to received memory to write out with opencv ?
<br> and is it possible to run v4l2 on mac os x ?
pinchartl: <u>hverkuil</u>: when you send patch series, it would be useful if you could include the diffstat in the cover letter
prabhakarlad: <u>pinchartl</u>: ping
pinchartl: <u>prabhakarlad</u>: pong
prabhakarlad: I had 3 patches for omap3isp
<br> since I dont have the h/w I cannot test them :(
<br> can I send you the patches so that you can test them prior to posting to ML
pinchartl: you can post them to the mailing list at the same time
<br> what do they do ?
irgendwer4711: hi, I got an "Unknown symbol vb2_dma_sg_memops (err 0) " error while loading cx23885 with my new kernel. any idea?
prabhakarlad: <u>pinchartl</u>: I did send you the patches
<br> and not the ML
<br> I am leaving for the day now from office will be back once I reach home!
pinchartl: <u>prabhakarlad</u>: 1/3 looks good to me
<br> I'll double-check 3/3
<br> but 2/3 isn't acceptable as-is
<br> there's a reason why the omap3isp driver stores the buffer queue in the file handle
<br> it should be fixed
<br> but we first need to make the use cases that drove that design supported through a different mean
<br> so please send the 3 patches to the mailing list and CC me and Sakari
mchehab: <u>hverkuil</u>: btw, just merged from v4.0-rc1.. better double check if media build will still work after that.
-: mchehab needs to double-check my scripts too
***: irgendwer4711 has quit IRC (Quit: irgendwer4711)
mchehab: <u>crope</u>: just committed the fix on the DVB core
crope: <u>mchehab</u>: ok
mchehab: <u>pinchartl</u>: had some time to review the patches?
<br> I'm about to merge the second set of patches with the fixes requested by hverkuil, plus the siano support for MC
pinchartl: <u>mchehab</u>: it's ongoing
<br> I've just started actually
mchehab: ok. please ping me when you finish
prabhakarlad|hom: <u>pinchartl</u>: back
pinchartl: <u>mchehab</u>: patches have been posted in different series, I might be missing some. in the dvb-media-ctl branch of your experimental tree, do you need a review for everything between linuxtv/master and experimental/dvb-media-ctl ?
mchehab: <u>pinchartl</u>: not all... there are, for example, 8 patches there that are just replacing a custom printk macro to pr_foo() stuff
<br> other patches are just adding the needed binding stuff for using the ML
<br> s/ML/MC/
<br> while it would be good to have a second pair of eyes on them, you may skip those patches if you're too busy
pinchartl: there are several points I want to comment on, I'll find appropriate patches to reply to, I'll tell you when I'll be done
mchehab: I have a few changes, on my TODO list:
<br> 1) to be sure that the names will be unique;
<br> 2) to support dvb-usb/dvb-usb-v2 cards with multiple adapters - should we use just one MC or one per adapter
pinchartl: I've discussed names this morning with hverkuil and sailus in here, you might have seen the discussion
<br> it's ongoing, we haven't reached a conclusion
mchehab: actually, I didn't, but I'll take a look at the backlog
<br> with regards of the devices with multiple DVB adapters, on all current devices there, right now, each adapter is independent
pinchartl: what kind of device is that ?
mchehab: for example, WinTV Nova-TD
pinchartl: (tea time, I'll multitask between preparing tea and discussing here, there might be a bit of lag)
<br> is that a usb device ?
mchehab: yes. Nova-TDt supports to receive 2 different DVB-T physical channels at the same time
<br> s/TDt/TD/
pinchartl: from the same antenna ?
mchehab: different antenna connectors, although it provides a cable that allows to connect both at the same antenna
pinchartl: ok
<br> how about the usb side ?
mchehab: one USB
pinchartl: with a single interface, or one interface per "device" ?
mchehab: Bus 001 Device 006: ID 2040:5200 Hauppauge
<br> one USB ID
<br> let me check it logically
pinchartl: can you post the lsusb -v -d 2040:5200 output somewhere ?
mchehab: one interface...
<br> http://pastebin.com/rYJr7ZnE
<br> yet, there are several USB devices that use multiple interfaces, but share components...
<br> cx231xx and em28xx are good examples
<br> cx231xx has 4 interfaces, em28xx has 3 interfaces
<br> each type (IR, analog TV, digital TV) has a different interface. Don't remember what's the 4th interface on cx231xx has
<br> I think it is just reserved for future usage
<br> anyway, on those devices, there is typically just one tuner...
<br> that could be used either by analog or digital stream
<br> and sometimes just one DMA
<br> for analog or digital
pinchartl: so for the 2040:5200 everything is separate up to the USB bridge
<br> other devices can sure tuners or other components
<br> correct ?
mchehab: <u>pinchartl</u>: yes, that's true on 2040:5200, as far as I can tell
pinchartl: I've replied to one e-mail, preparing a second reply now
mchehab: at least from userspace PoV, they're independent. I'm not aware of any issues related to shared...
<br> for DVB, the USB bandwidth should be enough for both devices to work at the same time
<br> as the video is compressed
<br> max bitrate is 19Mbps, using USB bulk transfers
<br> for DVB-T
crope: max it is more than 19Mbit/sec, maybe 25 or so. for USB1.1 whole stream is always too much => PID filters *required* (PID filtering is optional for USB2.0)
<br> max bitrate is ~32Mbit/sec (see http://en.wikipedia.org/wiki/DVB-T)
pinchartl: <u>mchehab</u>: can you remind me where the DVB .ps graph you have showed me can be found ?
<br> ok, found it in one of your cover letters
<br> sorry about the noise
mchehab: np
pinchartl: <u>mchehab</u>: I've replied to what I think were the most important points
<br> number of media devices, struct dev in struct media_entity_desc, and DVB entity types
<br> there's also the question of entity names, that discussion will continue tomorrow here with Hans and Sakari