<!-- 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>
***: cybrNaut has quit IRC (Ping timeout: 250 seconds)
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.
<br> should that be sufficient or am I missing something?
<br> 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.
***: larsc has quit IRC (Remote host closed the connection)
<br> r0kc4t has quit IRC (Remote host closed the connection)
<br> binchen has quit IRC (Ping timeout: 240 seconds)
_franck__: <u>pinchartl</u>: have you seen my message on the mailing list about using Xilinx video drivers as platform devices without using OF properties ?
pinchartl: <u>_franck__</u>: yes, but haven't had time to answer yet
<br> the use case is interesting
<br> I believe we should get Xilinx in the loop
_franck___: <u>pinchartl</u>: ok great, at least I'm not off topic
***: teob1 has left
_franck__: <u>pinchartl</u>: that would be great to have your/Xilinx feelings in the next days because I'll start to work on it very soon
pinchartl: <u>_franck__</u>: do you have contacts with Xilinx ?
_franck__: no
pinchartl: <u>_franck__</u>: replied to your e-mail
***: WeaselSoup has quit IRC (Read error: Connection reset by peer)
_franck__: <u>pinchartl</u>: thanks. "MFD decide driver could create a DT fragment" ->is it supported already ?
pinchartl: not that I know of, but it's an interesting project :-)
_franck__: ah ok :) I think it is. I was wondering why it didn't exist
<br> I think I'll go in this direction
pinchartl: it wouldn't require changing all the drivers
_franck__: yep. Plus there is a lot of other platform drivers in the same situation
***: groleo has quit IRC (Quit: Leaving.)
<br> pocek has quit IRC (Read error: Connection reset by peer)
broonie: Why would you create a DT fragment?
teemu_: simple question that seems I cannot find answer myself. Is there ioctl-call to check if overlay is on/off?
pinchartl: <u>broonie</u>: isn't that what I proposed ? :-)
<br> <u>teemu_</u>: I'll put my "V4L2 overlays are deprecated in favour of using dmabuf" hat :-)
broonie: <u>pinchartl</u>: I dunno, I'm just looking at the backlog here. It seems like a backwards idea.
<br> Normally we'd convert the DT to an internal representation and just make the IR the platform data.
pinchartl: <u>broonie</u>: sorry, I had misread you
<br> the issue isn't as much per-device platform data
<br> there we could indeed convert DT to in IR
<br> the issue comes from description of the connections between devices
<br> this is done in DT using phandles today
teemu_: <u>pinchartl</u>: 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 ;)
<br> 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
pinchartl: another interesting point it that the FPGA synthesis tools (at least some of them) can produce a .dts that describes the FPGA
teemu_: which doesn't really provide good result
pinchartl: <u>teemu_</u>: you're using an out-of-tree driver, right ?
broonie: <u>pinchartl</u>: I'd expect that to come in as a DT overlay along with the FPGA image.
larsc: well, they can generate a dts. Whether it's correct or not is something else
pinchartl: <u>broonie</u>: the problem at hand is how to reuse the existing infrastructure (possibly modifying it) with a non-SoC FPGA
teemu_: <u>pinchartl</u>: 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
<br> the hw is imx6 based
larsc: <u>pinchartl</u>: somebody told me the other day they got that working. I'm still waiting for the reply on how they did it
broonie: <u>pinchartl</u>: I'm surprised that'd make a difference TBH.
pinchartl: <u>teemu_</u>: which driver it the one that implements the overlay API ?
<br> <u>broonie</u>: it does, the SoC-FPGA is ARM-based, the standalone FPGA is connected to x86 through PCIe
broonie: <u>pinchartl</u>: So the problem is getting the base points to glue the DT overlay onto?
larsc: I think the ability to load a DT overlay if there is no base DT in general
pinchartl: <u>broonie</u>: 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
<br> bbiab
broonie: Right, I see now.
teemu_: <u>pinchartl</u>: 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)
<br> ah.. mxc_v4l2_capture. that is
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
<br> how do I attach the DT fragment to the PCIe host
broonie: Fixed function or a FPGA?
<br> If it's fixed function I'd expect the PCI driver to just instantiate stuff.
larsc: FPGA + fixed function
<br> having the PCI driver instatiate stuff means I have to write a board file like driver
<br> would be nice to just use DT
broonie: If you have to load a DT from userspace to get a fixed function device working that seems like a failure.
<br> 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.
larsc: not necessarily from userspace
<br> 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
broonie: You *could* but that's such a depressing idea.
<br> 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).
<br> 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.
_franck__: <u>larsc</u>: I like your idea
***: enyc has quit IRC (Ping timeout: 240 seconds)
<br> bparrot has quit IRC (Quit: Leaving)
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
_franck__: I don't get why the current DT tool could not do the job
larsc: there is no support for hybrid systems
<br> either it's DT or not
***: bparrot_ has quit IRC (Quit: Leaving)
_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 ?
<br> s/dont/can't
javier__: <u>_franck__</u>: 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
<br> <u>_franck__</u>: 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
<br> so basically you need to describe the whole system or that is what I understood from the discussion
_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
<br> the board is like a SoC and the devicetree is for this new SoC
larsc: yeah, you just need to implement it
<br> so that the devicetree does not have to have a root node
<br> and the parent devices are correctly set
***: awalls has quit IRC (Ping timeout: 250 seconds)
_franck__: I'll try to do somehting. I _need_ to do something anyway :)
<br> so I would prefer do it the good way
larsc: good :)
_franck__: I just need to read "Device Tree for dummies" :)
larsc: what kind of system are you working on?
_franck__: x86 with a PCIe FPGA board (Xilinx)
<br> it's about video capture
larsc: yeah, I have a similar setup, just with SDR instead of Video
_franck__: I need some days to decide if I go to the "grand plan" way or the "hacky" way
<br> <u>larsc</u>: how did you do to initialize your DT only device drivers ?
larsc: at the moment it's all running on a DT only system
_franck__: ok, good for you ;)
larsc: well, except that the new board has PCIe device support
<br> but its still a few months away on the schedule
***: capOM has quit IRC (Read error: Connection reset by peer)
<br> Wakandaa has quit IRC (Ping timeout: 276 seconds)
pinchartl: <u>larsc</u>: ping
larsc: <u>pinchartl</u>: pong
pinchartl: could you point me to the patch series you mentioned during FOSDEM about HDMI audio + DT ?
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
<br> potentially even more
<br> broonie will be very happy to tell you all about it, I'm sure
pinchartl: <u>larsc</u>: thanks
<br> <u>broonie</u>: ping :-)
broonie: <u>pinchartl</u>: 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.
<br> Arnaud and Jyri's things are basically very similar and so we just need to pick one AFAICT.
pinchartl: <u>broonie</u>: gotcha. Morimoto-san and I will look at the proposals
<br> and hopefully not propose yet another implementation :-)
***: _franck_ has quit IRC (Ping timeout: 272 seconds)
<br> seanvk has quit IRC (Quit: WeeChat 1.4)
bparrot: hverkuil, ping on the TI CAL patches?
***: benjiG has left
<br> jpabq has quit IRC (Remote host closed the connection)
<br> arnd has quit IRC (*.net *.split)
<br> jmleo has quit IRC (*.net *.split)
<br> smartin has quit IRC (*.net *.split)
<br> debris` has quit IRC (*.net *.split)
<br> kbingham has quit IRC (*.net *.split)
<br> qbasicer_ has quit IRC (Ping timeout: 240 seconds)
<br> awalls has left
<br> fullstop has left "Leaving"