| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| *** | arnd has quit IRC (Ping timeout: 260 seconds) | [04:13] |
| ....... (idle for 31mn) | ||
| cybrNaut has quit IRC (Ping timeout: 250 seconds) | [04:44] | |
| ..... (idle for 22mn) | ||
| teemu_ | Hi, I have application that uses v4l through ioctl calls to show analog video on imx6 based hw. It all works well ie. I have video showing properly etc. Except that once I start the video I cannot move/resize the video anymore. I use ioctl VIDIOC_S_FMT type V4L2_BUF_TYPE_VIDEO_OVERLAY and set new top/left/width/height.
should that be sufficient or am I missing something? the video freezes after that call repeating 4 frames or when using it bit differently it just don't do anything. either way the result is not what excected. | [05:06] |
| ....................... (idle for 1h52mn) | ||
| *** | larsc has quit IRC (Remote host closed the connection)
r0kc4t has quit IRC (Remote host closed the connection) | [07:00] |
| ..................... (idle for 1h40mn) | ||
| binchen has quit IRC (Ping timeout: 240 seconds) | [08:40] | |
| ......... (idle for 42mn) | ||
| _franck__ | pinchartl: have you seen my message on the mailing list about using Xilinx video drivers as platform devices without using OF properties ? | [09:22] |
| pinchartl | _franck__: yes, but haven't had time to answer yet
the use case is interesting I believe we should get Xilinx in the loop | [09:23] |
| _franck___ | pinchartl: ok great, at least I'm not off topic | [09:24] |
| *** | teob1 has left | [09:37] |
| _franck__ | pinchartl: that would be great to have your/Xilinx feelings in the next days because I'll start to work on it very soon | [09:39] |
| pinchartl | _franck__: do you have contacts with Xilinx ? | [09:40] |
| _franck__ | no | [09:40] |
| pinchartl | _franck__: replied to your e-mail | [09:45] |
| *** | WeaselSoup has quit IRC (Read error: Connection reset by peer) | [09:47] |
| _franck__ | pinchartl: thanks. "MFD decide driver could create a DT fragment" ->is it supported already ? | [09:48] |
| pinchartl | not that I know of, but it's an interesting project :-) | [09:49] |
| _franck__ | ah ok :) I think it is. I was wondering why it didn't exist
I think I'll go in this direction | [09:49] |
| pinchartl | it wouldn't require changing all the drivers | [09:50] |
| _franck__ | yep. Plus there is a lot of other platform drivers in the same situation | [09:51] |
| ...... (idle for 27mn) | ||
| *** | groleo has quit IRC (Quit: Leaving.) | [10:18] |
| ..... (idle for 20mn) | ||
| pocek has quit IRC (Read error: Connection reset by peer) | [10:38] | |
| .......... (idle for 46mn) | ||
| broonie | Why would you create a DT fragment? | [11:24] |
| teemu_ | simple question that seems I cannot find answer myself. Is there ioctl-call to check if overlay is on/off? | [11:25] |
| ..... (idle for 21mn) | ||
| pinchartl | broonie: isn't that what I proposed ? :-)
teemu_: I'll put my "V4L2 overlays are deprecated in favour of using dmabuf" hat :-) | [11:46] |
| broonie | pinchartl: I dunno, I'm just looking at the backlog here. It seems like a backwards idea.
Normally we'd convert the DT to an internal representation and just make the IR the platform data. | [11:47] |
| pinchartl | broonie: sorry, I had misread you
the issue isn't as much per-device platform data there we could indeed convert DT to in IR the issue comes from description of the connections between devices this is done in DT using phandles today | [11:48] |
| teemu_ | pinchartl: I have no experience of v4l2 so I have no idea how things _should_ do. I'm just doing things like they've been done before and worked ;)
and even now they work okay except that resize/move thing that seems to work if I turn overlay off, first and back on after | [11:49] |
| pinchartl | another interesting point it that the FPGA synthesis tools (at least some of them) can produce a .dts that describes the FPGA | [11:50] |
| teemu_ | which doesn't really provide good result | [11:50] |
| pinchartl | teemu_: you're using an out-of-tree driver, right ? | [11:51] |
| broonie | pinchartl: I'd expect that to come in as a DT overlay along with the FPGA image. | [11:51] |
| larsc | well, they can generate a dts. Whether it's correct or not is something else | [11:51] |
| pinchartl | broonie: the problem at hand is how to reuse the existing infrastructure (possibly modifying it) with a non-SoC FPGA | [11:51] |
| teemu_ | pinchartl: v4l2 is part of the kernel. only out-of-the-tree driver is the decoder chip driver. then again if freescale/nxp have done some own modifications there
the hw is imx6 based | [11:52] |
| larsc | pinchartl: somebody told me the other day they got that working. I'm still waiting for the reply on how they did it | [11:52] |
| broonie | pinchartl: I'm surprised that'd make a difference TBH. | [11:52] |
| pinchartl | teemu_: which driver it the one that implements the overlay API ?
broonie: it does, the SoC-FPGA is ARM-based, the standalone FPGA is connected to x86 through PCIe | [11:52] |
| broonie | pinchartl: So the problem is getting the base points to glue the DT overlay onto? | [11:53] |
| larsc | I think the ability to load a DT overlay if there is no base DT in general | [11:54] |
| pinchartl | broonie: that's my proposal. another option would be to come up with a non-DT description of the FPGA and modify the individual IP core registers to support it
bbiab | [11:54] |
| broonie | Right, I see now. | [11:54] |
| teemu_ | pinchartl: erm.. the decoder driver only controls the input part. i'm guessing its the mxc_v4l2_overlay.c that does some hw specific but I really don't know that much in detail of the structure since those drivers where part of the kernel i'm using (yocto with meta-fsl-arm -layer)
ah.. mxc_v4l2_capture. that is | [11:54] |
| larsc | I have the very same issue with one of our boards. There is a DT description for all the peripherals on the board and the drivers support DT, but the board has a PCIe header and can plug into any system with a PCIe host
how do I attach the DT fragment to the PCIe host | [11:56] |
| broonie | Fixed function or a FPGA?
If it's fixed function I'd expect the PCI driver to just instantiate stuff. | [11:58] |
| larsc | FPGA + fixed function
having the PCI driver instatiate stuff means I have to write a board file like driver would be nice to just use DT | [11:59] |
| broonie | If you have to load a DT from userspace to get a fixed function device working that seems like a failure.
You're much more into the DT as an ABI thing than you would be otherwise and we're not doing to well at that. | [12:01] |
| larsc | not necessarily from userspace
same way we attach DT blobs to kernels these days to describe the whole system you could attach a DT blob to a driver to describe a MFD | [12:01] |
| broonie | You *could* but that's such a depressing idea.
Given the state of DT tooling (and the fact that we still haven't even got to the point where we're handling the base SoCs like that). Ideally the board DTs would just say they've got a given SoC and how it's plumbed into the rest of the system and then we'd have a separate DT for the SoC (ie, do the includes at runtime) but we're nowhere near that yet. | [12:04] |
| ......... (idle for 40mn) | ||
| _franck__ | larsc: I like your idea | [12:46] |
| *** | enyc has quit IRC (Ping timeout: 240 seconds) | [12:53] |
| bparrot has quit IRC (Quit: Leaving) | [13:00] | |
| larsc | I think is unavoidable goind forward, if we ant to properly support these kind of systems. But as broonie said there are some technical hurdles to climb before we get there | [13:03] |
| _franck__ | I don't get why the current DT tool could not do the job | [13:05] |
| larsc | there is no support for hybrid systems
either it's DT or not | [13:06] |
| *** | bparrot_ has quit IRC (Quit: Leaving) | [13:06] |
| _franck__ | dont we just compile a simple device tree with only board (i mean MFD device) nodes and then compile it and some way get the result into the MFD core ?
s/dont/can't | [13:07] |
| javier__ | _franck__: I believe the problem is how do you manage the dependencies. For example if your MFD device is controlled over I2C, you need to place the node in a I2C bus and so you need a I2C controller -> SoC
_franck__: same if you have some GPIO connected to the pins, you will need a phandle to the GPIO controller which is a package in the SoC so basically you need to describe the whole system or that is what I understood from the discussion | [13:11] |
| _franck__ | but in a PCI board for example, everything is behind the PCI device endpoint so the whole thing is independant ans separated from the SoC. So if there is an I2C controller it would be on the PCI board
the board is like a SoC and the devicetree is for this new SoC | [13:14] |
| larsc | yeah, you just need to implement it
so that the devicetree does not have to have a root node and the parent devices are correctly set | [13:15] |
| *** | awalls has quit IRC (Ping timeout: 250 seconds) | [13:17] |
| _franck__ | I'll try to do somehting. I _need_ to do something anyway :)
so I would prefer do it the good way | [13:20] |
| larsc | good :) | [13:21] |
| _franck__ | I just need to read "Device Tree for dummies" :) | [13:24] |
| larsc | what kind of system are you working on? | [13:29] |
| _franck__ | x86 with a PCIe FPGA board (Xilinx)
it's about video capture | [13:30] |
| larsc | yeah, I have a similar setup, just with SDR instead of Video | [13:33] |
| _franck__ | I need some days to decide if I go to the "grand plan" way or the "hacky" way
larsc: how did you do to initialize your DT only device drivers ? | [13:37] |
| larsc | at the moment it's all running on a DT only system | [13:41] |
| _franck__ | ok, good for you ;) | [13:41] |
| larsc | well, except that the new board has PCIe device support
but its still a few months away on the schedule | [13:41] |
| ....... (idle for 32mn) | ||
| *** | capOM has quit IRC (Read error: Connection reset by peer) | [14:14] |
| ...... (idle for 28mn) | ||
| Wakandaa has quit IRC (Ping timeout: 276 seconds) | [14:42] | |
| pinchartl | larsc: ping | [14:50] |
| larsc | pinchartl: pong | [14:51] |
| pinchartl | could you point me to the patch series you mentioned during FOSDEM about HDMI audio + DT ? | [14:51] |
| larsc | there is http://mailman.alsa-project.org/pipermail/alsa-devel/2016-January/102605.html, this http://mailman.alsa-project.org/pipermail/alsa-devel/2016-January/102654.html and this http://mailman.alsa-project.org/pipermail/alsa-devel/2016-January/103240.html
potentially even more broonie will be very happy to tell you all about it, I'm sure | [14:55] |
| pinchartl | larsc: thanks
broonie: ping :-) | [14:58] |
| broonie | pinchartl: The big thing I'm looking for is for multiple people working on HDMI to talk to each other and agree on a way forward rather than just individually proposing things with lots of similarity/overlap.
Arnaud and Jyri's things are basically very similar and so we just need to pick one AFAICT. | [15:11] |
| pinchartl | broonie: gotcha. Morimoto-san and I will look at the proposals
and hopefully not propose yet another implementation :-) | [15:16] |
| *** | _franck_ has quit IRC (Ping timeout: 272 seconds) | [15:30] |
| seanvk has quit IRC (Quit: WeeChat 1.4) | [15:37] | |
| ................. (idle for 1h20mn) | ||
| bparrot | hverkuil, ping on the TI CAL patches? | [16:57] |
| *** | benjiG has left | [17:05] |
| .................................... (idle for 2h57mn) | ||
| jpabq has quit IRC (Remote host closed the connection) | [20:02] | |
| .......... (idle for 45mn) | ||
| arnd has quit IRC (*.net *.split)
jmleo has quit IRC (*.net *.split) smartin has quit IRC (*.net *.split) debris` has quit IRC (*.net *.split) kbingham has quit IRC (*.net *.split) qbasicer_ has quit IRC (Ping timeout: 240 seconds) | [20:47] | |
| .... (idle for 15mn) | ||
| awalls has left | [21:07] | |
| ........... (idle for 51mn) | ||
| fullstop has left "Leaving" | [21:58] | |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |