| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| *** | indy has quit IRC (Ping timeout: 245 seconds) | [03:42] |
| .......................................................... (idle for 4h47mn) | ||
| jmleo | hverkuil, ping ?
I can see that several dv timings have the vic parameter, but not all. Where can I find more information about this vic ? | [08:29] |
| ....................... (idle for 1h52mn) | ||
| *** | snawrocki has quit IRC (Quit: Leaving) | [10:23] |
| ....... (idle for 31mn) | ||
| hverkuil | jmleo: the CEA-861 standard gives the VICs. They only apply to timings that follow CEA-861.
VESA timings don't have a VIC. | [10:54] |
| jmleo | hverkuil, thx | [10:56] |
| ................... (idle for 1h30mn) | ||
| mchehab | sailus: from your comments about patch 00/21, it seems that you're trying to fix a driver's bug with a very complex approach... instead, why you don't just stop streaming before destroying the media controller? | [12:26] |
| ...... (idle for 29mn) | ||
| javier___ | pinchartl, mchehab: the tvp5150 currently uses DEMOD_PAD_IF_INPUT for its sink pad. But according to what we discussed yesterday, the tvp5150 should have 2 sink pads so composite over s-video can be done
should I refresh this old patch? https://patchwork.kernel.org/patch/8548671/ last time that sparked a long discussion another option is to not try to standarize and make each driver to define their own pads (and numbers) | [12:55] |
| mchehab | javier___: yeah, you likely need two input pads, but you need to check what impact such change will do on drivers that use it | [12:57] |
| pinchartl | javier___: demod_pad_index is a bad idea
we can't standardize pad numbers | [12:58] |
| mchehab | agreed. we need a way to allow caller drivers to discover it
something like enum_pads | [12:59] |
| pinchartl | no
why would we need that ? drivers can already access the pad array directly we don't need a new operation | [12:59] |
| mchehab | how?
this should be passed to userspace too drivers currently have no ways to know what PADs are inside each subdev nor userspace | [12:59] |
| pinchartl | if you have a pointer to the subdev, subdev->entity.pads | [13:01] |
| mchehab | that's why right now this is hardcoded | [13:01] |
| pinchartl | (and subdev->entity.num_pads) | [13:01] |
| mchehab | pinchartl: yes, but what pads[0], pads[1]... means? | [13:02] |
| javier___ | pinchartl: I think that Mauro means is that user-space has no way to know that pad 0 is video out and pad 1 is vbi out, etc | [13:02] |
| mchehab | just knowing if it is a sink or source is not enough | [13:02] |
| pinchartl | if we need to describe pads with more information, that should be added to struct media_pad | [13:02] |
| mchehab | userspace and kernelspace needs to know what a pad sink or source has inside, specially as they may be providing completely different kind of signals
for example, a xc3028 has 3 source pads, each with a different signal: VBI, video and radio IF | [13:03] |
| pinchartl | we've discussed adding label to pads in the past, and I'm certainly open to add other information as well (we of course need to design that properly and not add random fields) | [13:03] |
| mchehab | tvp5150 has 3 possible sources: raw VBI, sliced VBI and video
(I'm not sure if sliced VBI is currently implemented) | [13:04] |
| pinchartl | no no no
there's no source pad for VBI in tvp5150 there's a single source pad the bus can carry both video and VBI but there's a single bus there should not be multiple source pads | [13:05] |
| mchehab | yes, you're right: the same source pad carries both VBI and video...
although it also supports sliced VBI | [13:06] |
| pinchartl | and I assume it's the same for xc3028, or does that chip have a separate bus for VBI information ? | [13:06] |
| mchehab | with is provided via some special registers
it has a separate bus for audio IF | [13:06] |
| pinchartl | an audio pad makes sense
no issue with that | [13:07] |
| mchehab | (actually, audio I2S, I guess - need to check xc3028 datasheet to be sure)
some tuners provide IF audio output, while others provide I2S | [13:07] |
| pinchartl | javier___: so, instead of adding more entries to the demod_pad_index enum, let's try to make it go away instead
I2S is a bit annoying to describe given that it supports multiple masters we haven't standardized a solution for that yet | [13:08] |
| mchehab | in the case of the media devices I know, they only have one master
I2S is used as just a point to point connection between a PAD source and a PAD sink that's the case of devices with msp3400, for example | [13:09] |
| javier___ | pinchartl: Ok, then we need to fix the driver since is currently using the enum http://hastebin.com/evosanuwuf.pl | [13:11] |
| mchehab | javier___: such change will affect all em28xx devices and subdevs | [13:11] |
| javier___ | mchehab: I see, the em28xx driver is relying on these pad numbers? | [13:12] |
| mchehab | (and other drivers too - saa7134 I guess)
yes | [13:12] |
| pinchartl | mchehab: when I2S is used in point-to-point mode with a single master and a single slave that's easy. it's the multi-master case that is hard to handle | [13:12] |
| javier___ | each time I try to push the tvp5150 input signals change, I find that's a rabbit hole... | [13:12] |
| mchehab | yes, the I2S cases we have are the easy ones ;) | [13:13] |
| javier___ | pinchartl: btw, is something like this what you had in mind from the DT pov? http://hastebin.com/suvehiwoci.diff
it's not a real HW description since the IGEPv2 doesn't have a four-pin mini-DIN connector but will allow me to test the composite over s-video case and IIUC mchehab has HW where both a four-pin mini-DIN connector and RCA connector pins are wired to the tvp5150 pins | [13:13] |
| mchehab | javier___: it is likely easier for me to try to get rid of PAD hardcoded numbers outside the platform drivers | [13:15] |
| pinchartl | javier___: do you need the csiphy supplies ? | [13:15] |
| mchehab | at least from Kernel PoV
doing that change on userspace will likely rise some questions | [13:15] |
| pinchartl | javier___: I would name the tvp5150_1 label tvp5150_out instead | [13:16] |
| mchehab | I would likely add something like: enum pad_type { COMPOSITE, VIDEO, AUDIO_IF, AUDIO_I2s, };
to the pads struct | [13:17] |
| pinchartl | I would probably not have named the connector compat strings composite-video-connector and svideo-connector, but given that we have established bindings for them we can live with that | [13:17] |
| javier___ | pinchartl: good question, the N9 uses them and since the supplies are from the twl I thought all omap3 board would need it | [13:17] |
| pinchartl | javier___: you're missing reg properties for the svideo connector ports
the rest looks good to me although labels should only be specified when they exist | [13:17] |
| javier___ | pinchartl: ah, right. I shold build dtc with warnings enabled to find those mismatches
pinchartl: I was thinking in using the labels to name the connectors media entities, or should I hardcode to Composite and S-Video depending on the connector type? | [13:18] |
| pinchartl | see https://git.linuxtv.org/pinchartl/media.git/commit/?h=drm/du/hdmi&id=a7667eb3839499b83c4001bec909a02214676185
and the description of the label property there | [13:19] |
| javier___ | yes, already reading it | [13:19] |
| mchehab | pinchartl, javier___: would something like: enum pad_type { COMPOSITE, VIDEO, AUDIO_IF, AUDIO_I2S, } work for you? | [13:20] |
| javier___ | mchehab: yes, although for COMPOSITE we will need to split in Y + C | [13:20] |
| pinchartl | mchehab: I think that requires a bit more thinking
sailus: ^^ | [13:20] |
| mchehab | pinchartl: certainly, but just need something to start with | [13:21] |
| pinchartl | yes, but let's not get stuck with a userspace API we'll regret later :-) | [13:21] |
| mchehab | IMHO, the easiest way would be to add an enum describing what's there at the PAD | [13:21] |
| pinchartl | I believe this approach will have the same issue as the subdev type field | [13:21] |
| mchehab | I'm talking about Kernelspace only
for now | [13:21] |
| pinchartl | that we later decided to turn into a list of functions
ah, for kernelspace | [13:21] |
| mchehab | yeah, it could be a bitmask instead...
on that case, I would be using a bit to indicate if a video has VBI or not | [13:22] |
| pinchartl | for kernelspace we have a bit more room for experimentation | [13:22] |
| mchehab | yes | [13:22] |
| pinchartl | but I'd like to see how the pad type will be used
how it would be exposed is easy to understand, but how will it be used by bridge drivers ? | [13:23] |
| mchehab | it will be used to create the links
for example, a demod with 3 source pads: video+vbi, audio IF, sliced VBI when attached to a driver, the driver will call a function that will generate the links connecting each of those 3 pads to different PAD sinks, on different devices for example, the audio IF source would be linked to a msp3400 sink the video+vbi to the video+vbi sink at the bridge driver, and the sliced VBI to the sliced VBI sink, also at the bridge driver | [13:23] |
| pinchartl | so your issue is that PCI or USB devices don't provide you with the same internal connectivity information as the devices described in DT ? | [13:26] |
| mchehab | no. my issue is that PCI/USB devices need to create their own graphs...
and the same bridge can be used with different arrangements em28xx is an interesting example... there are dozens of different combinations... with msp3400... or without it with a tuner that provides audio IF... | [13:27] |
| pinchartl | what I mean is | [13:28] |
| mchehab | with a tuner that provides audio via I2S
... | [13:28] |
| pinchartl | a driver, when creating the MC graph, needs to know how the pieces are connected in the hardware
DT provides that information | [13:28] |
| mchehab | yes
there's no DT on such devices the build logic should be inside it... | [13:28] |
| pinchartl | but for PCI or USB devices, there's no such data coming from the firmware | [13:28] |
| mchehab | or, ideally, on a generic function, capable of doing the right thing
(that's by the way the approach we took) | [13:29] |
| javier___ | mchehab: but that generic function currently needs a standarized pad numbering | [13:29] |
| mchehab | on *all* PCI devices I'm aware of, the same logic will work | [13:29] |
| javier___ | that's why you added the enum then | [13:30] |
| mchehab | yes, because there's no field describing the type of signal that is travelling on a PAD | [13:30] |
| pinchartl | I hate to state the unpleasant obvious, but shouldn't that routing information be included in the PCI and USB drivers ?
that's your source of device information already | [13:30] |
| mchehab | the information that it is missing is actually what signal a PAD provides | [13:30] |
| pinchartl | you already have a bunch of structures describing the devices, what tuners they have, how GPIOs are connected, all that
I understand it would be a difficult change though let me think about it | [13:31] |
| mchehab | pinchartl: you're talking about adding a lot of complexity on the drivers and creating information that doesn't exist anyware
nobody knows that as this is *probed* on PCI/USB drivers, there's a scan procedure that probes the sub-devices the internal arrangements are generated dynamically from the probe it is not hardcoded this is not the approach that DT took what we need is to provide enough info for the probe routines to be able to identify what PAD numbers were used by each subdev | [13:31] |
| pinchartl | I was looking at the em28xx driver the other day
and you have em28xx-cards.c there | [13:33] |
| mchehab | yes. It describes the info that can't be probed | [13:34] |
| pinchartl | which contains a very big table of hardware description data
routing information, if it can't be probed, would naturally belong to such data tables but again I understand it would be painful to change so I'll see if I can find clean alternatives | [13:34] |
| mchehab | but it *can* be probed
and it can't be hardcoded even if we wanted to hardcode it, there's no way. *all* a PCI/USB device usually knows is their PCI/USB IDs | [13:35] |
| pinchartl | it can't be probed from the hardware, can it ? | [13:36] |
| mchehab | it is quite common that the same USB ID to be used on different hardware
that's why the hardware is probed depending on the probe, the hardware links are different we need a consistent way for subdevices to expose such information | [13:36] |
| pinchartl | I think you're mixing several unrelated concepts | [13:37] |
| mchehab | no | [13:37] |
| pinchartl | but I need to move to something else now
as I said, I'll think about it | [13:37] |
| mchehab | for example, a TV tuner either provides I2S or IF for audio
if it provides IF, an audio demod (msp34xx, for example) is needed if I2S, it is connected to the bridge (em28xx, for example) the probe logic is quite simple, provided that it is able to know the type of signal each PAD provides | [13:38] |
| pinchartl | I know all that. don't assume that people are stupid or ignorant just because they disagree with you :-) | [13:40] |
| mchehab | OK, some vendor might come with something that won't fit on a generic connector, but, on such case (with we currently don't have), the driver will need to have its own MC probing logic
well, if you have another alternative that would actually work (if possible with patches), I'm all ears | [13:40] |
| sailus | Are signal types more relevant on pads or on connectors... just wondering. | [13:41] |
| javier___ | pinchartl, mchehab: I don't think I'll be able to continue with the tvp5150 input connectors work until we sort out the source/sink pads issue | [13:41] |
| mchehab | sailus: connectors may need it too | [13:42] |
| javier___ | I thought the re-spin would be more easy so I only dedicated yesterday and today to this work since I'm quite busy with other internal tasks | [13:42] |
| sailus | Different pads may have different functionality and usually do, but I don't think we've really needed to know the types of signals before. We haven't had support for connectors either. | [13:42] |
| pinchartl | mchehab: certainly not with patches. I can help finding a proper solution, but don't expect me to fix every problem myself for hardware I don't even have :-) | [13:42] |
| mchehab | but, for the issue we're discussing, I'm more concerned about tvp5150 source pads | [13:42] |
| pinchartl | and once again, I'll think about it
javier___: ok, then we should just revert the patches that broke operation with the omap3 and fix it properly later | [13:42] |
| sailus | mchehab: What would the signal type information for a pad be used for? | [13:43] |
| javier___ | pinchartl: yes, I'll post a patch that partially reverts 7b4b54e6364 ("[media] tvp5150: add HW input connectors support") | [13:44] |
| pinchartl | javier___: thanks | [13:44] |
| mchehab | sailus: I guess that the way userspace currently works is that they hardcode PAD numbers | [13:44] |
| pinchartl | and regarding the respin | [13:44] |
| mchehab | e. g. if some patch change the PAD numbers, userspace will break | [13:44] |
| pinchartl | I think it would still make sense to post it, even if the pad number issue isn't solved yet
especially if you can also test it on IGEPv2 | [13:44] |
| mchehab | (on devices with multiple sources and/or multiple sinks) | [13:44] |
| pinchartl | mchehab: no, userspace shouldn't hardcode pad numbers
they have never been guaranteed to be stable | [13:45] |
| mchehab | javier___: are you sure that reverting 7b4b54e6364 ("[media] tvp5150: add HW input connectors support") won't break tvp5150-based USB and PCI drivers? | [13:46] |
| sailus | mchehab: That's right. But the signal type is certainly not enough for that. It might be actually nice to have someone write an RFC on the subject. | [13:46] |
| javier___ | mchehab: no, that's only DT parsing logic from a now undocumented DT binding | [13:46] |
| sailus | On V4L2, media bus formats provide some information. | [13:46] |
| javier___ | pinchartl: what I don't understand is why you said the omap3 is too broken, AFAICT the current documented DT binding should work and that commit should be a no-op if a "connectors" sub-node is not found | [13:47] |
| sailus | pinchartl: I'm not really advocating hardcoding stuff, but I presume pretty much all existing user space relies on static pad numbering. | [13:48] |
| mchehab | sailus: afaict, media bus is used only for subdev API | [13:49] |
| pinchartl | sailus: most of the userspace logic I've seen don't. it instead checks pad types, whether links are enabled, the number of pads, ... instead of hardcoding pad numbers
mchehab: no, media bus is used in DRM too | [13:49] |
| mchehab | I mean, inside V4L2 | [13:49] |
| pinchartl | javier___: because it was broken when I tested tvp5150 + beagle board xm :-) I had to revert a few patches to fix it | [13:50] |
| mchehab | it doesn't have any way to describe audio or VBI, for example | [13:50] |
| sailus | mchehab: Yes, it's V4L2 sub-device specific. If the interface is on the level of MC, can it be expressive enough? I presume we could have classes of different uses for pads but different subsystems could have different needs for that.
The property API would certainly help here, I think. | [13:50] |
| pinchartl | sailus: I have refrained from mentioning it, but I think that's part of the solution, yes | [13:51] |
| mchehab | pinchartl, sailus: the way I see, property API is only a dream... We've been talking about that for almost two years... no patch was sent with that | [13:52] |
| javier___ | pinchartl: hmm, this worked for me with no reverts on media/master http://hastebin.com/yizoferuye.hs | [13:52] |
| mchehab | it would solve the issue, if someone would implement the property API | [13:53] |
| javier___ | pinchartl: but I agree with you that undocumented (and wrong) DT parsing logic should be removed
just trying to understand what else is broken to fix it and leave mainline in a working state | [13:53] |
| pinchartl | javier___: I don't remember what broke, but with the existing .dts, tvp5150 didn't work | [13:55] |
| sailus | mchehab: It's been mentioned as a concept to provide additional information to the user space, and there's an RFC:
https://www.spinics.net/lists/linux-media/msg90160.html | [13:55] |
| javier___ | pinchartl: yes, but could be that you just needed to update your media-ctl pipeline to use pad 1 instead of pad 0? | [13:55] |
| sailus | The fact that it's not implemented does not mean it shouldn't be the solution of choice. | [13:55] |
| pinchartl | javier___: no, there was more than that | [13:56] |
| sailus | I would appreciate feedback on that btw., the examples are just examples to show how the data structure could look like. That's far away from the core concepts of the API. | [13:56] |
| javier___ | pinchartl: Ok, I'll post what I think are the left overs of the previous input approach and you could test it on your board | [13:58] |
| pinchartl | javier___: thanks | [13:59] |
| mchehab | sailus: everybody agreed with the concept
what we need are patches implementing it | [14:01] |
| sailus | mchehab: Oh. I'm happy to hear that. :-) | [14:03] |
| mchehab | sailus, you heard that before... actuall, a the media controller's action plan from Aug, 2015, you were supposed to write such patches: https://linuxtv.org/news.php?entry=2015-08-17.mchehab
media_properties: RFC userspace API: Sakari s/actuall, a/actually, at/ mchehab seems to have a problem on his keyboard ;) | [14:07] |
| sailus | mchehab: An RFC does not necessarily include code. | [14:09] |
| mchehab | true. Still, I think that RFC as code works best ;) | [14:10] |
| sailus | I'd prefer to get comments on the current RFC before continuing. | [14:10] |
| mchehab | I made some comments on that RFC
if you want more comments, you likely need to respin it, addressing the comments written on that time and rebasing it on the top of the current code as a lot has changed since then If you prefer to write a text instead of code, just to make sure that everybody is at the same page, I'm OK with that although I would actually prefer if you could write some code about how do you intend to store properties at the Kernel side that would IMHO make easier to identify the issues before we set an userspace API at the stone | [14:11] |
| sailus | The API will be only stabilised when the patches hit the mainline kernel. :-) | [14:15] |
| mchehab | true, but experimenting the properties API inside the Kernel would help to identify issues | [14:16] |
| sailus | It would, indeed.
But, for instance, would we prefer a binary or text-only user space interface? | [14:16] |
| mchehab | that's a good question
I don't have a pre-defined opinion about that as both have advantages and disadvantages inside the Kernel, though, I would prefer a binary interface | [14:17] |
| sailus | It might be good to have a binary interface in as the user space interface, and then a test program to convert that to e.g. json. | [14:20] |
| mchehab | for a RFC patchset, yes, this is likely better
if it ends to be too complex, then we can think on moving the binary->text convertion to Kernelspace although doing it inside a library could work better | [14:20] |
| sailus | Parsing json consumes more time than a custom binary interface, if you're looking for a particular piece of information. I would presume that in most cases the speed won't be an issue though.
At least that's my assumption. :-) | [14:21] |
| mchehab | as a general rule, I don't like slow processing routines inside the Kernel... this probably works better on userspace | [14:23] |
| javier___ | sailus: I think it would be good if is consistent with other properties API in the kernel, IIRC the KMS/DRM properties API is a binary interface? | [14:23] |
| ..................... (idle for 1h42mn) | ||
| hverkuil | Sorry guys for not being very active lately.
It's busy at work (and has been for much of this year), and I had to move to a new apartment in Oslo. This week I am trying to finish three almost-done projects. Did the atmel-isi/soc-camera patch series yesterday and the HDMI notifier series today. I have one USB CEC adapter driver to do. I hope to spend one more day this week on patch review (for 4.11 of course). and hopefully I can find time to give my comments on the kref discussion. | [16:05] |
| ............. (idle for 1h2mn) | ||
| pinchartl | hverkuil: if you don't have time to review Sakari's kref patches you can just ack them ;-) | [17:10] |
| *** | benjiG has left | [17:22] |
| .... (idle for 18mn) | ||
| marsrover | hverkuil - usb cec driver, for the pulse-eight device? if so, whats wrong with their driver? | [17:40] |
| hverkuil | marsrover: no, a different usb cec device.
http://rainshadowtech.com/HdmiCecUsb.html support for the pulse8 is already in the kernel | [17:42] |
| marsrover | nice seattle police dept ruler :) | [17:49] |
| rainshadow technology is in seattle. small world | [17:58] | |
| sailus | hverkuil: No worries. We're all involved with other tasks. Not to mention holidays. :-) | [18:01] |
| marsrover | what will you be doing for kwanzaa sailus? | [18:01] |
| sailus | Mauro did propose entirely reasonable changes to the set, let's see how those will end up to be.
marsrover: ...what? :-) | [18:01] |
| marsrover | the holidays | [18:02] |
| .............. (idle for 1h9mn) | ||
| *** | awalls1 has left
kbingham has quit IRC (Ping timeout: 240 seconds) | [19:11] |
| ...... (idle for 26mn) | ||
| pinchartl | hverkuil: is it just me, or is the HDMI notifier as very specific solution to a wider problem ? | [19:40] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |