i.MX6: can't capture on MIPI-CSI2 with DS90UB954
Hi there,
I am using the i.MX6D from Digi (connect core 6 sbc) with a mailine
kernel (well, 4.14 right now) and have an issue with mipi-csi2
capture.
First I will give brief explanation of my setup, and then I will
detail the issue.
I have a camera sensor (OV2732, but could be any other sensor)
connected on a DS90UB953 FPD-Link III serializer.
Then a coax cable propagates the signal to a DS90UB954 FPD-Link III
deserializer.
The DS90UB954 has the ability to work in a pattern generation mode,
and I will use it for the rest of the discussion.
It is an I²C device, and I have written a basic driver (for the moment
;)) in order to make it visible on the imx6-mipi-csi2 bus as a camera
sensor.
I can give an access to the driver if necessary.
I then program the MC pipeline :
media-ctl -l "'ds90ub954 2-0034':0 -> 'imx6-mipi-csi2':0[1]" -v
media-ctl -l "'imx6-mipi-csi2':1 -> 'ipu1_csi0_mux':0[1]" -v
media-ctl -l "'ipu1_csi0_mux':2 -> 'ipu1_csi0':0[1]" -v
media-ctl -l "'ipu1_csi0':2 -> 'ipu1_csi0 capture':0[1]"
media-ctl -V "'ds90ub954 2-0034':0 [fmt:RGB888_1X24/1280x720 field:none]"
media-ctl -V "'imx6-mipi-csi2':1 [fmt:RGB888_1X24/1280x720 field:none]"
media-ctl -V "'ipu1_csi0_mux':2 [fmt:RGB888_1X24/1280x720 field:none]"
media-ctl -V "'ipu1_csi0':2 [fmt:RGB888_1X24/1280x720 field:none]"
Everything works fine, all nodes are correctly configured, and the
DS90UB954 is normaly sending data on 2 lanes, with VC-ID=0.
The pattern is 1280x720@30 RGB888.
Then, I start a Gstreamer pipeline (I tried with v4l2-ctl and have the
same issue though) :
GST_DEBUG="v4l2:5" gst-launch-1.0 v4l2src device=/dev/video4 !
video/x-raw, width=1280, height=720, format=RGB ! fakesink
And... well, I had to use this patch
https://lkml.org/lkml/2017/3/11/270 in order to go further, but I am
finishing into :
[ 164.077302] imx-ipuv3-csi imx-ipuv3-csi.0: stream ON
[ 164.097955] imx-ipuv3-csi imx-ipuv3-csi.0: FI=3 usec
[ 165.129424] ipu1_csi0: EOF timeout
[ 165.142395] imx-ipuv3-csi imx-ipuv3-csi.0: stream OFF
[ 166.169299] ipu1_csi0: wait last EOF timeout
Sounds like a recurrent issue on this ML :).
I can think of several things which could explain this, but I tried a
lot and am a bit stuck.
The clock is set to 800MHz on DS90UB954 side.
=> Should CSI2_PHY_TST_CTRL1 be 0x32 ? 0x12 ? or 0x4a (ie 400MHz) ?
I think I have tried all but still the same issue.
Maybe this could be a hint, when booting, the first stream-on leads to:
imx6-mipi-csi2: LP-11 timeout, phy_state = 0x0200 => just a warning now
imx6-mipi-csi2: clock lane timeout, phy_state = 0x0230
The next one leads to the EOF timeout.
Here is the dts part BTW :
&i2c3 {
status = "okay";
ds90ub954: camera@34 {
compatible = "ti,ds90ub954";
status = "okay";
reg = <0x34>;
clocks = <&clks IMX6QDL_CLK_CKO>;
clock-names = "xclk";
port {
#address-cells = <1>;
#size-cells = <0>;
ds90ub954_out0: endpoint {
remote-endpoint = <&mipi_csi2_in>;
clock-lanes = <0>;
data-lanes = <1 2>;
};
};
};
};
&mipi_csi {
status = "okay";
port@0 {
reg = <0>;
mipi_csi2_in: endpoint {
remote-endpoint = <&ds90ub954_out0>;
clock-lanes = <0>;
data-lanes = <1 2>;
};
};
};
If ayone has a suggestion...
Thanks a lot !
Regards,
JM
Re: i.MX6: can't capture on MIPI-CSI2 with DS90UB954
Hi Steve, Le mer. 31 oct. 2018 à 22:52, Steve Longerbeam a écrit : > > Hi Jean-Michel, > > We've done some work with another FPD-Link de-serializer (ds90ux940) and > IIRC we had some trouble figuring out how to coax the lanes into LP-11 > state. But on the ds90ux940 it can be done by setting bit 7 in the CSI > Enable Port registers (offsets 0x13 and 0x14). But the "imx6-mipi-csi2: > clock lane timeout" message is something else and indicates the > de-serializer is not activating the clock lane during its s_stream(ON) > subdev call. I have been doing more work on the driver I have, and I had CSI enabled before the csi2_dphy_wait_stopstate() call for instance. Now, LP-11 state is ok. Then, in the s_stream subcall, I added a delay after enabling CSI (and the continuous clock) and it is better too, as the clock is seen correctly each time. But I still get into a EOF timeout, which sounds like another issue. FYI, I added the NFACK interrupt support in my local kernel just to see if New Frames are detected, and it is not the case either. Any reason for not using this interrupt (maybe in "debug" mode) ? Now, I used a scope (not very fast so I can't get into the very fast signals) and I can see some weird things. In a 1-lane configuration, and a 400MHz clock, I can get the following when looking at D0N and D0P (yellow and green, can't remember which color is which) : https://framapic.org/H65QXHvaWmao/qdyoARz12dNi.png The purple is the diff result. First I thought it was a start sequence (but with very bizarre things at the very beginning of the sequence) like described here : https://cms.edn.com/ContentEETimes/Images/EDN/Design%20How-To/MIPI_Sync-Sequence-in-the-transmitted-pattern.jpg But Jacopo remarked that the 'starting sequence' is actually sent in HS mode, so we should not be able to see it at all. He thinks that what we are looking at is actually a bad LP-11 -> LP01 -> LP00 transition. And it could be the "HS ZERO" : https://cms.edn.com/ContentEETimes/Images/EDN/Design%20How-To/MIPI_HS-Burst-on-Data-Lane.jpg What do you think of this ? We will conduce more complex measurements, with high speed analyzers in order to check everything, and we are right now focusing on a possible hardware issue (coule be the custom PCB which embeds the DS90UB954). Thanks, JM
i.MX6 RAW8 format
Hi, I am currently using an upstream kernel on a i.MX6 Quad board, and I have a strange issue. The device I am using is able to produce RGB888 MIPI data, or RAW8/RAW10. The MIPI data types are respectively 0x24, 0x2A and 0x2B. When I configure the device to produce RGB888 data, everything is fine, but when I configure it to produce RAW8 data, then the pattern is weird. I am sending the following pattern : 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88 0x99 0xAA 0xBB 0xCC 0xDD 0xEE 0x11 0x22 0x33 0x44 0x55 0x66... And I get in a raw file : 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88 0x33 0x44 0x55 0x66 0x77 0x88 0x99 ... The resulting raw file has the correct size (ie. 1280x720 bytes). I could get a logic analyzer able to decode MIPI-CSI2 protocol, and on this side, the pattern is complete, no data is lost, and the Datatype is 0x2A. It really looks like an issue on the i.MX6 side. So, looking at it, I would say than for each 8 bytes captured, a jump of 8 bytes is done ? The media-ctl is configured like this : media-ctl -l "'ds90ub954 2-0034':0 -> 'imx6-mipi-csi2':0[1]" -v media-ctl -l "'imx6-mipi-csi2':1 -> 'ipu1_csi0_mux':0[1]" -v media-ctl -l "'ipu1_csi0_mux':2 -> 'ipu1_csi0':0[1]" -v media-ctl -l "'ipu1_csi0':2 -> 'ipu1_csi0 capture':0[1]" media-ctl -V "'ds90ub954 2-0034':0 [fmt:SBGGR8_1X8/1280x720 field:none]" media-ctl -V "'imx6-mipi-csi2':1 [fmt:SBGGR8_1X8/1280x720 field:none]" media-ctl -V "'ipu1_csi0_mux':2 [fmt:SBGGR8_1X8/1280x720 field:none]" media-ctl -V "'ipu1_csi0':2 [fmt:SBGGR8_1X8/1280x720 field:none]" The ds90ub954 driver I wrote is very dump and just used to give I²C access and configure the deserializer to produce the pattern. I also tried to use a camera, which produces RAW8 data, but the result is the same, I don't get all my bytes, at least, not in the correct order. And the command used to capture a file is : v4l2-ctl -d4 --set-fmt-video=width=1280,height=720,pixelformat=BA81 --stream-mmap --stream-count=1 --stream-to=/root/cam.raw I can send the raw file if it is needed. I tried several configurations, changing the number of lanes, the frequency, etc. but I have the same behaviour. So, I am right now stuck with this, as I can't see anything which could explain this. IC burst ? Something else ? Thanks a lot, JM
Re: i.MX6 RAW8 format
Hi Steve !
Thanks for answering !
Le mar. 15 janv. 2019 à 01:54, Steve Longerbeam
a écrit :
>
> Hi JM,
>
> On 1/14/19 1:52 AM, Jean-Michel Hautbois wrote:
> > Hi,
> >
> > I am currently using an upstream kernel on a i.MX6 Quad board, and I
> > have a strange issue.
> > The device I am using is able to produce RGB888 MIPI data, or RAW8/RAW10.
> > The MIPI data types are respectively 0x24, 0x2A and 0x2B.
> > When I configure the device to produce RGB888 data, everything is
> > fine, but when I configure it to produce RAW8 data, then the pattern
> > is weird.
> >
> > I am sending the following pattern :
> > 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88 0x99 0xAA 0xBB 0xCC 0xDD 0xEE
> > 0x11 0x22 0x33 0x44 0x55 0x66...
> > And I get in a raw file :
> > 0x11 0x22 0x33 0x44 0x55 0x66 0x77 0x88 0x33 0x44 0x55 0x66 0x77 0x88 0x99
> > ...
> > The resulting raw file has the correct size (ie. 1280x720 bytes).
> >
> > I could get a logic analyzer able to decode MIPI-CSI2 protocol, and on
> > this side, the pattern is complete, no data is lost, and the Datatype
> > is 0x2A.
> > It really looks like an issue on the i.MX6 side.
> >
> > So, looking at it, I would say than for each 8 bytes captured, a jump
> > of 8 bytes is done ?
>
> Sure looks that way.
>
> > The media-ctl is configured like this :
> > media-ctl -l "'ds90ub954 2-0034':0 -> 'imx6-mipi-csi2':0[1]" -v
> > media-ctl -l "'imx6-mipi-csi2':1 -> 'ipu1_csi0_mux':0[1]" -v
> > media-ctl -l "'ipu1_csi0_mux':2 -> 'ipu1_csi0':0[1]" -v
> > media-ctl -l "'ipu1_csi0':2 -> 'ipu1_csi0 capture':0[1]"
> > media-ctl -V "'ds90ub954 2-0034':0 [fmt:SBGGR8_1X8/1280x720 field:none]"
> > media-ctl -V "'imx6-mipi-csi2':1 [fmt:SBGGR8_1X8/1280x720 field:none]"
> > media-ctl -V "'ipu1_csi0_mux':2 [fmt:SBGGR8_1X8/1280x720 field:none]"
> > media-ctl -V "'ipu1_csi0':2 [fmt:SBGGR8_1X8/1280x720 field:none]"
> >
> > The ds90ub954 driver I wrote is very dump and just used to give I²C
> > access and configure the deserializer to produce the pattern.
> > I also tried to use a camera, which produces RAW8 data, but the result
> > is the same, I don't get all my bytes, at least, not in the correct
> > order.
> >
> > And the command used to capture a file is :
> > v4l2-ctl -d4 --set-fmt-video=width=1280,height=720,pixelformat=BA81
> > --stream-mmap --stream-count=1 --stream-to=/root/cam.raw
> >
> > I can send the raw file if it is needed.
> > I tried several configurations, changing the number of lanes, the
> > frequency, etc. but I have the same behaviour.
> >
> > So, I am right now stuck with this, as I can't see anything which
> > could explain this. IC burst ? Something else ?
>
> The problem couldn't be IC burst size as the IC isn't involved in this
> pipeline.
You are right, and in fact I was thinking of IDMAC while writing :s
> One way I see this happening is that the IDMA channel burst writes 16
> bytes to memory (so that the channel's read pointer advances by 16
> bytes), but somehow the channel's write pointer has only advanced by 8
> bytes.
>
> I don't know how that could happen, but you might try reverting
>
> 37ea9830139b3 ("media: imx-csi: fix burst size")
It is the correct issue, but what I didn't mention is that I was on a
4.14, and not the most recent, and burst_size is set to 8.
The commit 37ea9830139b3 has been introduced later, and so I didn't have it...
The commit is not explicit though, as it mentions IMX219 and not i.MX6.
But it works with 16 ;).
Thanks,
JM
Re: v4l2 mem2mem compose support?
Hi Tim, Nicolas, all, Le sam. 16 févr. 2019 à 22:14, Nicolas Dufresne a écrit : > > Le sam. 16 févr. 2019 à 13:40, Hans Verkuil a écrit : > > > > On 2/16/19 4:42 PM, Nicolas Dufresne wrote: > > > Le sam. 16 févr. 2019 à 04:48, Hans Verkuil a écrit : > > >> > > >> On 2/16/19 10:42 AM, Hans Verkuil wrote: > > >>> On 2/16/19 1:16 AM, Tim Harvey wrote: > > Greetings, > > > > What is needed to be able to take advantage of hardware video > > composing capabilities and make them available in something like > > GStreamer? > > >>> > > >>> Are you talking about what is needed in a driver or what is needed in > > >>> gstreamer? Or both? > > >>> > > >>> In any case, the driver needs to support the V4L2 selection API, > > >>> specifically > > >>> the compose target rectangle for the video capture. > > >> > > >> I forgot to mention that the driver should allow the compose rectangle to > > >> be anywhere within the bounding rectangle as set by S_FMT(CAPTURE). > > >> > > >> In addition, this also means that the DMA has to be able to do > > >> scatter-gather, > > >> which I believe is not the case for the imx m2m hardware. > > > > > > I believe the 2D blitter can take an arbitrary source rectangle and > > > compose it to an arbitrary destination rectangle (a lot of these will > > > in fact use Q16 coordinate, allowing for subpixel rectangle, something > > > that V4L2 does not support). > > > > Not entirely true. I think this can be done through the selection API, > > although it would require some updating of the spec and perhaps the > > introduction of a field or flag. The original VIDIOC_CROPCAP and VIDIOC_CROP > > ioctls actually could do this since with analog video (e.g. S-Video) you > > did not really have the concept of a 'pixel'. It's an analog waveform after > > all. In principle the selection API works in the same way, even though the > > documentation always assumes that the selection rectangles map directly on > > the digitized pixels. I'm not sure if there are still drivers that report > > different crop bounds in CROPCAP compared to actual number of digitized > > pixels. > > The bttv driver is most likely to do that, but I haven't checked. > > > > Doing so made it very hard to understand, though. > > > > I don't think this driver exist in any > > > form upstream on IMX side. The Rockchip dev tried to get one in > > > recently, but the discussion didn't go so well with the rejection of > > > the proposed porter duff controls was probably devoting, as picking > > > the right blending algorithm is the basic of such driver. > > > > I tried to find the reason why the Porter Duff control was dropped in v8 > > of the rockchip RGA patch series back in 2017. > > > > I can't find any discussion about it on the mailinglist, so perhaps it > > was discussed on irc. > > > > Do you remember why it was removed? > > I'll try and retrace what happened, it was not a nack, and I realize > that "rejection" wasn't the right word, but if I remember, the focus > in the review went fully around this and the fact that it was doing > blending which such API, while the original intention with the driver > was to have CSC, so removing this was basically a way forward. > > > > > > > > > I believe a better approach for upstreaming such driver would be to > > > write an M2M spec specific to that type of m2m drivers. That spec > > > would cover scalers and rotators, since unlike the IPUv3 (which I > > > believe you are referring too) a lot of the CSC and Scaler are > > > blitters. > > > > No, I was referring to the imx m2m driver that Phillip is working on. > > I'll need to check what driver Veolab was using, but if it's the > same, then maybe it only do source-over operations using SELECTION as > you described. If I remember their use case, they where doing simple > source-over blending of two video feeds. > > Could it be this ? > https://gitlab.com/veo-labs/linux/tree/veobox/drivers/staging/media/imx6/m2m > Is it an ancester of Philipp's driver ? That's right. It is quite an old kernel, and I am confident it never has been updated. But the compositor based on this element is working fine. I am not Veo-Labs anymore, but Sebastien in cc is, so if you want to take the source code of the gstreamer elements created for the occasion and give it a try, don't hesitate to get him in copy :). This plugin should be upstreamable and as Nicolas said, it is not i.MX6 related, but v4l2 m2m related. So it should be working with every m2m element which has the SELECTION ops supported. And it was tested with the basic v4l2m2m driver on a x86 laptop just to validate the concept before getting it on an i.MX6. Good luck ! JM
Re: [RFC] ADV7604: VGA support
Hi Hans,
2015-10-12 12:22 GMT+02:00 Hans Verkuil :
> On 10/04/2015 06:17 PM, Jean-Michel Hautbois wrote:
>> Hi,
>>
>> I had another look into the ADV7604 HW manual, and I understand that
>> in automatic mode, there is 4 AIN_SEL values possible, determining the
>> connection on AIN pins.
>> Now, having a look at the current ADV76xx files, I can see that two
>> pads are there :
>> ADV7604_PAD_VGA_RGB and ADV7604_PAD_VGA_COMP.
>>
>> According to the manual, my understanding is that we should have four
>> HDMI pads and four analog pads. The latter would be configured as RGB
>> or component, which allows four analog inputs as described in the HW
>> manual.
>
> When I wrote the driver we only needed one VGA input receiving either RGB
> or YCbCr. Hence there is only one analog input and two pads. I wouldn't have
> been able to test the additional analog inputs anyway.
>
> I chose to use pads to select between the two modes, but that's something
> that can be changed (it's not something you can autodetect, unfortunately).
>
> If you want to add support for all four analog inputs, then feel free to
> do so.
OK, I don't have anything to test the additional inputs either...
Something else so, the adv7604_state struct constains two fields,
.ain_sel and .bus_order.
Should those be parsed from DT (I think so) ? If so, how should it be
named in the port{} node ?
Thanks,
JM
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add GS1662 driver (a SPI video serializer)
Hi Charles-Antoine, Thank you for the patch. FIrst of all, we, on the ML, do prefer reading patches as sent by git send-email tool. It is easier to comment the patch. Next, you should add a complete description to your commit. Just having an object and a signed-off-by line is not enough. You also have to use the scripts/checkpatch.pl script to verify that everything is ok with it. Last thing, I can't see anything related to V4L2 in your patch. It is just used to initialize the chip and the spi bus, that's all. Adding a subdev is a start, and some operations if it can do something else than just serializing. That's it for the moment, when you submit a v2, I (and others) may have some more comments :). Thanks, JM 2016-04-01 18:28 GMT+02:00 Charles-Antoine Couret : > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add GS1662 driver (a SPI video serializer)
>> Next, you should add a complete description to your commit. Just >> having an object and a signed-off-by line is not enough. > Oh, I'm sorry, I don't have any idea to explicit more details. I will > find something for that. Just get the description from the datasheet as a start ;-). >> You also have to use the scripts/checkpatch.pl script to verify that >> everything is ok with it. > I have executed this script before to send it. And it noticed nothing about > that. > >> Last thing, I can't see anything related to V4L2 in your patch. It is >> just used to initialize the chip and the spi bus, that's all. >> Adding a subdev is a start, and some operations if it can do something >> else than just serializing. > > Maybe I'm in the wrong list for that in fact. I didn't know this list was > about V4L2 and related topics. > This driver is only to configure the component to manage the video stream in > electronic card, it is not to capture video stream via V4L. > > I should improve my driver to be configurable by userspace. But maybe I > should submit my future patch in another ML. Well, I am not really sure about that. I added Hans in cc as he may have a better view. >From my point of view, it can be a V4L2 subdev, even a simple one, as you can configure outputs, etc. JM -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Streaming I/O: proposal to expose MMAP/USERPTR/DMABUF capabilities with QUERYCAP
Hi Hans, 2016-04-22 10:08 GMT+02:00 Hans Verkuil : > Hi all, > > I have always been unhappy with the fact that it is so hard to tell whether > the USERPTR and/or DMABUF modes are available with Streaming I/O. QUERYCAP > only tells you if Streaming I/O is available, but not in which flavors. > > So I propose the following: > > #define V4L2_CAP_STREAMING_MMAP V4L2_CAP_STREAMING > #define V4L2_CAP_STREAMING_USERPTR 0x0800 > #define V4L2_CAP_STREAMING_DMABUF 0x1000 > > All drivers that currently support CAP_STREAMING also support MMAP. For > userptr > and dmabuf support we add new caps. These can be set by the core if the driver > uses vb2 since the core can query the io_modes field of vb2_queue. So, you want to make it mandatory for future drivers that they support MMAP. Fine with me. BTW, dmabuf is still marked as experimental, what would make it part of the API for good ? > For the drivers that do not yet support vb2 we can add it manually. > > I was considering making it a requirement that the MMAP streaming mode is > always present, but I don't know if that works once we get drivers that > operate > on secure memory. So I won't do that for now. By using "#define V4L2_CAP_STREAMING_MMAP V4L2_CAP_STREAMING" you make it mandatory... You would need a separate bit to indicate MMAP otherwise... > Since we are looking at device caps anyway: can we just drop V4L2_CAP_ASYNCIO? > It's never been implemented, nor is it likely in the future. And we don't have > all that many bits left before we need to use one of the reserved fields for > additional capabilities. > > Regards, > > Hans > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/21] Basic i.MX IPUv3 capture support
I am so sorry... This mail wasn't send to the mailing list as this ** gmail switched back to HTML... 2016-12-29 16:08 GMT+01:00 Jean-Michel Hautbois : > Hi Philipp and al., > > > 2016-10-19 23:30 GMT+02:00 Sakari Ailus : >> >> On Fri, Oct 14, 2016 at 07:34:20PM +0200, Philipp Zabel wrote: >> > Hi, >> > >> > the second round removes the prepare_stream callback and instead lets >> > the >> > intermediate subdevices propagate s_stream calls to their sources rather >> > than individually calling s_stream on each subdevice from the bridge >> > driver. >> > This is similar to how drm bridges recursively call into their next >> > neighbor. >> > It makes it easier to do bringup ordering on a per-link level, as long >> > as the >> > source preparation can be done at s_power, and the sink can just >> > prepare, call >> > s_stream on its source, and then enable itself inside s_stream. >> > Obviously this >> > would only work in a generic fashion if all asynchronous subdevices with >> > both >> > inputs and outputs would propagate s_stream to their source subdevices. > > > What is the status of this work ? I saw Steve's patches before yours, so > both are implementing pretty much the same functionnality but differently. > Which one will be finally merged ? > I wanted to upgrade my kernel, in order to give it a try on a board with > adv7604 and adv7611 devices. > Is there a git tree somewhere integrating it too ? > > Thanks, > JM > > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/21] Basic i.MX IPUv3 capture support
Hi, 2016-12-30 21:26 GMT+01:00 Steve Longerbeam : > > > On 12/30/2016 11:06 AM, Marek Vasut wrote: >> >> On 12/29/2016 09:51 PM, Robert Schwebel wrote: >>> >>> Hi Jean-Michel, >> >> Hi, >> >>> On Thu, Dec 29, 2016 at 04:08:33PM +0100, Jean-Michel Hautbois wrote: >>>> >>>> What is the status of this work? >>> >>> Philipp's patches have been reworked with the review feedback from the >>> last round and a new version will be posted when he is back from >>> holidays. >> >> IMO Philipp's patches are better integrated and well structured, so I'd >> rather like to see his work in at some point. > > > Granted I am biased, but I will state my case. "Better integrated" - my > patches > are also well integrated with the media core infrastructure. Philipp's > patches > in fact require modification to media core, whereas mine require none. > Some changes are needed of course (more subdev type definitions for > one). > > As for "well structured", I don't really understand what is meant by that, > but my driver is also well structured. > > Philipp's driver only supports unconverted image capture from the SMFC. In > addition > to that, mine allows for all the hardware links supported by the IPU, > including routing > frames from the CSI directly to the Image converter for scaling up to > 4096x4096, > colorspace conversion, rotation, and motion compensated de-interlace. Yes > all these > conversion can be carried out post-capture via a mem2mem device, but > conversion > directly from CSI capture has advantages, including minimized CPU > utilization and > lower AXI bus traffic. In any case, Freescale added these hardware paths, > and my > driver supports them. I had a deeper look to both drivers, and I must say the features of Steve's one are really interesting. I don't think any of those has been tested with digital inputs (I have ADV76xx chips on my board, which I hope will be available one day for those interested) and so, I can test and help adding some of the missing parts. And for at least a week or two, I have all of my time for it, so it would be of great help to know which one has the bigger chance to be integrated... :) Thanks again, JM -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/21] Basic i.MX IPUv3 capture support
2017-01-02 15:45 GMT+01:00 Hans Verkuil : > On 01/02/17 14:51, Jean-Michel Hautbois wrote: >> >> Hi, >> >> 2016-12-30 21:26 GMT+01:00 Steve Longerbeam : >>> >>> >>> >>> On 12/30/2016 11:06 AM, Marek Vasut wrote: >>>> >>>> >>>> On 12/29/2016 09:51 PM, Robert Schwebel wrote: >>>>> >>>>> >>>>> Hi Jean-Michel, >>>> >>>> >>>> Hi, >>>> >>>>> On Thu, Dec 29, 2016 at 04:08:33PM +0100, Jean-Michel Hautbois wrote: >>>>>> >>>>>> >>>>>> What is the status of this work? >>>>> >>>>> >>>>> Philipp's patches have been reworked with the review feedback from the >>>>> last round and a new version will be posted when he is back from >>>>> holidays. >>>> >>>> >>>> IMO Philipp's patches are better integrated and well structured, so I'd >>>> rather like to see his work in at some point. >>> >>> >>> >>> Granted I am biased, but I will state my case. "Better integrated" - my >>> patches >>> are also well integrated with the media core infrastructure. Philipp's >>> patches >>> in fact require modification to media core, whereas mine require none. >>> Some changes are needed of course (more subdev type definitions for >>> one). >>> >>> As for "well structured", I don't really understand what is meant by >>> that, >>> but my driver is also well structured. >>> >>> Philipp's driver only supports unconverted image capture from the SMFC. >>> In >>> addition >>> to that, mine allows for all the hardware links supported by the IPU, >>> including routing >>> frames from the CSI directly to the Image converter for scaling up to >>> 4096x4096, >>> colorspace conversion, rotation, and motion compensated de-interlace. Yes >>> all these >>> conversion can be carried out post-capture via a mem2mem device, but >>> conversion >>> directly from CSI capture has advantages, including minimized CPU >>> utilization and >>> lower AXI bus traffic. In any case, Freescale added these hardware paths, >>> and my >>> driver supports them. >> >> >> I had a deeper look to both drivers, and I must say the features of >> Steve's one are really interesting. >> I don't think any of those has been tested with digital inputs (I have >> ADV76xx chips on my board, which I hope will be available one day for >> those interested) and so, I can test and help adding some of the >> missing parts. >> And for at least a week or two, I have all of my time for it, so it >> would be of great help to know which one has the bigger chance to be >> integrated... :) > > > Steve's series is definitely preferred from my point of view. The feature > set is clearly superior to Philipp's driver. > > I plan on reviewing Steve's series soonish but a quick scan didn't see > anything > suspicious. The code looks clean, and I am leaning towards getting this in > sooner > rather than later, so if you have the time to work on this, then go for it! Glad to here it ! > Steve, I have a SabreLite and a ov5642 sensor, so I should be able to test > that driver. > > There is also an ov5642 sensor driver in > drivers/media/i2/soc_camera/ov5642.c. > But nobody AFAIK is using it, so I would be inclined to take your code and > remove the soc_camera driver. Steve: which branch is the correct one on your github ? Thanks, JM -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/21] Basic i.MX IPUv3 capture support
Hi Steve and Philipp, 2017-01-11 0:52 GMT+01:00 Steve Longerbeam : > > > On 01/09/2017 04:15 PM, Steve Longerbeam wrote: >> >> Hi Philipp, >> >> >> On 01/09/2017 11:43 AM, Philipp Zabel wrote: >> >> >> >>> >>> One is the amount and organization of subdevices/media entities visible >>> to userspace. The SMFCs should not be user controllable subdevices, but >>> can be implicitly enabled when a CSI is directly linked to a camif. >> >> >> I agree the SMFC could be folded into the CSI, but I see at least one >> issue. >> >> From the dot graph you'll see that the PRPVF entity can receive directly >> from the CSI, or indirectly via the SMFC. If the SMFC entity were folded >> into the CSI entity, there would have to be a "direct to PRPVF" output pad >> and a "indirect via SMFC" output pad and I'm not sure how that info would >> be conveyed to the user. With a SMFC entity those pipelines are explicit. > > > In summary here, unless you have strong objection I'd prefer to keep a > distinct SMFC entity. It makes the pipelines more clear to the user, and it > better models the IPU internals. > >> >>> Also I'm not convinced the 1:1 mapping of IC task to subdevices is the >>> best choice. It is true that the three tasks can be enabled separately, >>> but to my understanding, the PRP ENC and PRP VF tasks share a single >>> input channel. Shouldn't this be a single PRP subdevice with one input >>> and two (VF, ENC) outputs? >> >> >> Since the VDIC sends its motion compensated frames to the PRP VF task, >> I've created the PRPVF entity solely for motion compensated de-interlace >> support. I don't really see any other use for the PRPVF task except for >> motion compensated de-interlace. >> >> So really, the PRPVF entity is a combination of the VDIC and PRPVF >> subunits. >> >> So looking at link_setup() in imx-csi.c, you'll see that when the CSI is >> linked >> to PRPVF entity, it is actually sending to IPU_CSI_DEST_VDIC. >> >> But if we were to create a VDIC entity, I can see how we could then >> have a single PRP entity. Then if the PRP entity is receiving from the >> VDIC, >> the PRP VF task would be activated. >> >> Another advantage of creating a distinct VDIC entity is that frames could >> potentially be routed directly from the VDIC to camif, for >> motion-compensated >> frame capture only with no scaling/CSC. I think that would be IDMAC >> channel >> 5, we've tried to get that pipeline to work in the past without success. >> That's >> mainly why I decided not to attempt it and instead fold VDIC into PRPVF >> entity. >> >> > > Here also, I'd prefer to keep distinct PRPENC and PRPVF entities. You are > correct > that PRPENC and PRPVF do share an input channel (the CSIs). But the PRPVF > has an additional input channel from the VDIC, and since my PRPVF entity > roles > up the VDIC internally, it is actually receiving from the VDIC channel. > > So unless you think we should have a distinct VDIC entity, I would like to > keep this > the way it is. > > Steve > That is exactly my thought. I was wondering if VDIC could be an independent entity, as it could also be used as a combiner if one adds the channels... What do you think about that ? JM PS: My phone sent the mail in HTML, again, sorry for the double mail, again... -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] coda: implement encoder stop command
Hi Philipp,
2017-03-02 10:51 GMT+01:00 Philipp Zabel :
> There is no need to call v4l2_m2m_try_schedule to kick off draining the
> bitstream buffer for the encoder, but we have to wake up the destination
> queue in case there are no new OUTPUT buffers to be encoded and userspace
> is already polling for new CAPTURE buffers.
>
> Signed-off-by: Philipp Zabel
> ---
> drivers/media/platform/coda/coda-common.c | 47
> +++
> 1 file changed, 47 insertions(+)
>
> diff --git a/drivers/media/platform/coda/coda-common.c
> b/drivers/media/platform/coda/coda-common.c
> index e1a2e8c70db01..085bbdb0d361b 100644
> --- a/drivers/media/platform/coda/coda-common.c
> +++ b/drivers/media/platform/coda/coda-common.c
> @@ -881,6 +881,47 @@ static int coda_g_selection(struct file *file, void *fh,
> return 0;
> }
>
> +static int coda_try_encoder_cmd(struct file *file, void *fh,
> + struct v4l2_encoder_cmd *ec)
> +{
> + if (ec->cmd != V4L2_ENC_CMD_STOP)
> + return -EINVAL;
> +
> + if (ec->flags & V4L2_ENC_CMD_STOP_AT_GOP_END)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static int coda_encoder_cmd(struct file *file, void *fh,
> + struct v4l2_encoder_cmd *ec)
> +{
> + struct coda_ctx *ctx = fh_to_ctx(fh);
> + struct vb2_queue *dst_vq;
> + int ret;
> +
> + ret = coda_try_encoder_cmd(file, fh, ec);
> + if (ret < 0)
> + return ret;
> +
> + /* Ignore encoder stop command silently in decoder context */
> + if (ctx->inst_type != CODA_INST_ENCODER)
> + return 0;
> +
> + /* Set the stream-end flag on this context */
> + ctx->bit_stream_param |= CODA_BIT_STREAM_END_FLAG;
Why aren't you calling coda_bit_stream_end_flag() ?
> + /* If there is no buffer in flight, wake up */
> + if (ctx->qsequence == ctx->osequence) {
> + dst_vq = v4l2_m2m_get_vq(ctx->fh.m2m_ctx,
> +V4L2_BUF_TYPE_VIDEO_CAPTURE);
> + dst_vq->last_buffer_dequeued = true;
> + wake_up(&dst_vq->done_wq);
> + }
> +
> + return 0;
> +}
> +
> static int coda_try_decoder_cmd(struct file *file, void *fh,
> struct v4l2_decoder_cmd *dc)
> {
> @@ -1054,6 +1095,8 @@ static const struct v4l2_ioctl_ops coda_ioctl_ops = {
>
> .vidioc_g_selection = coda_g_selection,
>
> + .vidioc_try_encoder_cmd = coda_try_encoder_cmd,
> + .vidioc_encoder_cmd = coda_encoder_cmd,
> .vidioc_try_decoder_cmd = coda_try_decoder_cmd,
> .vidioc_decoder_cmd = coda_decoder_cmd,
>
> @@ -1330,9 +1373,13 @@ static void coda_buf_queue(struct vb2_buffer *vb)
> mutex_lock(&ctx->bitstream_mutex);
> v4l2_m2m_buf_queue(ctx->fh.m2m_ctx, vbuf);
> if (vb2_is_streaming(vb->vb2_queue))
> + /* This set buf->sequence = ctx->qsequence++ */
> coda_fill_bitstream(ctx, true);
> mutex_unlock(&ctx->bitstream_mutex);
> } else {
> + if (ctx->inst_type == CODA_INST_ENCODER &&
> + vq->type == V4L2_BUF_TYPE_VIDEO_OUTPUT)
> + vbuf->sequence = ctx->qsequence++;
> v4l2_m2m_buf_queue(ctx->fh.m2m_ctx, vbuf);
> }
> }
> --
> 2.11.0
>
JM
Re: [PATCH] [media] coda: implement encoder stop command
> + /* If there is no buffer in flight, wake up */
> + if (ctx->qsequence == ctx->osequence) {
Not sure about this one, I would have done something like :
if (!(ctx->fh.m2m_ctx->job_flags)) {
> + dst_vq = v4l2_m2m_get_vq(ctx->fh.m2m_ctx,
> +V4L2_BUF_TYPE_VIDEO_CAPTURE);
> + dst_vq->last_buffer_dequeued = true;
> + wake_up(&dst_vq->done_wq);
> + }
> +
> + return 0;
> +}
> +
> static int coda_try_decoder_cmd(struct file *file, void *fh,
> struct v4l2_decoder_cmd *dc)
> {
> @@ -1054,6 +1095,8 @@ static const struct v4l2_ioctl_ops coda_ioctl_ops = {
>
> .vidioc_g_selection = coda_g_selection,
>
> + .vidioc_try_encoder_cmd = coda_try_encoder_cmd,
> + .vidioc_encoder_cmd = coda_encoder_cmd,
> .vidioc_try_decoder_cmd = coda_try_decoder_cmd,
> .vidioc_decoder_cmd = coda_decoder_cmd,
>
> @@ -1330,9 +1373,13 @@ static void coda_buf_queue(struct vb2_buffer *vb)
> mutex_lock(&ctx->bitstream_mutex);
> v4l2_m2m_buf_queue(ctx->fh.m2m_ctx, vbuf);
> if (vb2_is_streaming(vb->vb2_queue))
> + /* This set buf->sequence = ctx->qsequence++ */
> coda_fill_bitstream(ctx, true);
> mutex_unlock(&ctx->bitstream_mutex);
> } else {
> + if (ctx->inst_type == CODA_INST_ENCODER &&
> + vq->type == V4L2_BUF_TYPE_VIDEO_OUTPUT)
> + vbuf->sequence = ctx->qsequence++;
> v4l2_m2m_buf_queue(ctx->fh.m2m_ctx, vbuf);
> }
> }
> --
> 2.11.0
>
Re: [PATCH v3] [media] adv7604: Add support for hardware reset
Hi,
2016-06-22 13:30 GMT+02:00 Dragos Bogdan :
> The part can be reset by a low pulse on the RESET pin (i.e. a hardware
> reset) with a minimum width of 5 ms. It is recommended to wait 5 ms
> after the low pulse before an I2C write is performed to the part.
> For safety reasons, the delays will be between 5 and 10 ms.
>
> The RESET pin can be tied high, so the GPIO is optional.
>
> Signed-off-by: Dragos Bogdan
> Reviewed-by: Lars-Peter Clausen
> Acked-by: Laurent Pinchart
> ---
> Changes since v2:
> - adv76xx_reset() is now a void function (it always returned 0).
>
> Changes since v1:
> - Replace mdelay() with usleep_range();
> - Limit the comments to 75 characters per line.
>
> drivers/media/i2c/adv7604.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
> index 41a1bfc..ab4f933 100644
> --- a/drivers/media/i2c/adv7604.c
> +++ b/drivers/media/i2c/adv7604.c
> @@ -164,6 +164,7 @@ struct adv76xx_state {
> struct adv76xx_platform_data pdata;
>
> struct gpio_desc *hpd_gpio[4];
> + struct gpio_desc *reset_gpio;
>
> struct v4l2_subdev sd;
> struct media_pad pads[ADV76XX_PAD_MAX];
> @@ -2996,6 +2997,19 @@ static int configure_regmaps(struct adv76xx_state
> *state)
> return 0;
> }
>
> +static void adv76xx_reset(struct adv76xx_state *state)
> +{
> + if (state->reset_gpio) {
> + /* ADV76XX can be reset by a low reset pulse of minimum 5 ms.
> */
> + gpiod_set_value_cansleep(state->reset_gpio, 0);
> + usleep_range(5000, 1);
> + gpiod_set_value_cansleep(state->reset_gpio, 1);
> + /* It is recommended to wait 5 ms after the low pulse before
> */
> + /* an I2C write is performed to the ADV76XX. */
> + usleep_range(5000, 1);
> + }
> +}
> +
> static int adv76xx_probe(struct i2c_client *client,
> const struct i2c_device_id *id)
> {
> @@ -3059,6 +3073,12 @@ static int adv76xx_probe(struct i2c_client *client,
> if (state->hpd_gpio[i])
> v4l_info(client, "Handling HPD %u GPIO\n", i);
> }
> + state->reset_gpio = devm_gpiod_get_optional(&client->dev, "reset",
> +
> GPIOD_OUT_HIGH);
> + if (IS_ERR(state->reset_gpio))
> + return PTR_ERR(state->reset_gpio);
> +
> + adv76xx_reset(state);
>
> state->timings = cea640x480;
> state->format = adv76xx_format_info(state, MEDIA_BUS_FMT_YUYV8_2X8);
> --
> 2.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
I now have this patch in my tree and I can get into a point where
status is V4L2_IN_ST_NO_SYNC and stays there...
If I set a resolution (say, 1920x1080@60), and then use another one
without unplugging the cable, I can get into this state.
If I don't have the reset call, there is not such problem.
Any idea why ?
I tried (without a high conviction) to add i call to adv76xx_reset
inside g_input_status when there is no sync, it is better, but not
perfect (I still can get a status = 0x10003 for example).
Thanks,
JM
Re: [PATCH v3 5/5] [media] imx-ipu: Add i.MX IPUv3 scaler driver
Hi Philipp, Hans,
2015-07-24 17:12 GMT+02:00 Hans Verkuil :
> Hi Philipp,
>
> A quick review of this driver:
>
> On 07/16/2015 06:24 PM, Philipp Zabel wrote:
>> From: Sascha Hauer
>>
>> This patch adds support for hardware accelerated scaling and color
>> space conversion between memory buffers using the IPUv3 IC.
>> Since the maximum output size of the IC unit is 1024x1024 pixels, multiple
>> IC tasks with overlapping tiles are used internally to scale and convert
>> larger frames.
>>
>> The IC operates with a burst size of at least 8 pixels. Depending on the
>> frame width and scaling factor, up to 7 junk pixels may be written after
>> the end of the frame. The sizeimage is increased accordingly.
>>
>> Signed-off-by: Sascha Hauer
>> Signed-off-by: Michael Olbrich
>> Signed-off-by: Philipp Zabel
>> ---
>> Changes since v2:
>> - Disabled USERPTR memory, hardware doesn't support it.
>> - Embedded struct video_device in ipu_scale_dev.
>> - Set icc pointer to NULL on error.
>> - Fixed module description.
>> ---
>> drivers/media/platform/imx/Kconfig | 9 +
>> drivers/media/platform/imx/Makefile | 1 +
>> drivers/media/platform/imx/imx-ipu-scaler.c | 859
>>
>> drivers/media/platform/imx/imx-ipu.c| 2 +-
>> drivers/media/platform/imx/imx-ipu.h| 1 +
>> 5 files changed, 871 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/media/platform/imx/imx-ipu-scaler.c
>>
>> diff --git a/drivers/media/platform/imx/Kconfig
>> b/drivers/media/platform/imx/Kconfig
>> index a90c973..4694367 100644
>> --- a/drivers/media/platform/imx/Kconfig
>> +++ b/drivers/media/platform/imx/Kconfig
>> @@ -1,2 +1,11 @@
>> config VIDEO_IMX_IPU_COMMON
>> tristate
>> +
>> +config VIDEO_IMX_IPU_SCALER
>> + tristate "i.MX5/6 IPUv3 based image scaler driver"
>> + depends on VIDEO_DEV && IMX_IPUV3_CORE
>> + select VIDEOBUF2_DMA_CONTIG
>> + select VIDEO_IMX_IPU_COMMON
>> + select V4L2_MEM2MEM_DEV
>> + ---help---
>> + This is a v4l2 scaler video driver for the IPUv3 on i.MX5/6.
>> diff --git a/drivers/media/platform/imx/Makefile
>> b/drivers/media/platform/imx/Makefile
>> index 5de119c..f20aa0b 100644
>> --- a/drivers/media/platform/imx/Makefile
>> +++ b/drivers/media/platform/imx/Makefile
>> @@ -1 +1,2 @@
>> obj-$(CONFIG_VIDEO_IMX_IPU_COMMON) += imx-ipu.o
>> +obj-$(CONFIG_VIDEO_IMX_IPU_SCALER) += imx-ipu-scaler.o
>> diff --git a/drivers/media/platform/imx/imx-ipu-scaler.c
>> b/drivers/media/platform/imx/imx-ipu-scaler.c
>> new file mode 100644
>> index 000..6c6d0aa
>> --- /dev/null
>> +++ b/drivers/media/platform/imx/imx-ipu-scaler.c
>> @@ -0,0 +1,860 @@
>> +/*
>> + * i.MX IPUv3 scaler driver
>> + *
>> + * Copyright (C) 2011 Sascha Hauer, Pengutronix
>> + *
>> + * based on the mem2mem test driver
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License
>> + * as published by the Free Software Foundation; either version 2
>> + * of the License, or (at your option) any later version.
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + */
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include "imx-ipu.h"
>> +
>> +#define MIN_W 32
>> +#define MIN_H 32
>> +#define MAX_W 4096
>> +#define MAX_H 4096
>> +#define DIM_ALIGN_MASK 0x08 /* 8-alignment for dimensions */
>> +
>> +/* Flags that indicate a format can be used for capture/output */
>> +#define MEM2MEM_CAPTURE (1 << 0)
>> +#define MEM2MEM_OUTPUT (1 << 1)
>> +
>> +#define MEM2MEM_NAME "imx-ipuv3-scale"
>> +
>> +/* Per queue */
>> +#define MEM2MEM_DEF_NUM_BUFS VIDEO_MAX_FRAME
>> +/* In bytes, per queue */
>> +#define MEM2MEM_VID_MEM_LIMIT(64 * 1024 * 1024)
>> +
>> +#define fh_to_ctx(__fh) container_of(__fh, struct ipu_scale_ctx, fh)
>> +
>> +enum {
>> + V4L2_M2M_SRC = 0,
>> + V4L2_M2M_DST = 1,
>> +};
>> +
>> +struct ipu_scale_dev {
>> + struct v4l2_device v4l2_dev;
>> + struct video_device vfd;
>> + struct device *dev;
>> + struct ipu_soc *ipu;
>> +
>> + atomic_tnum_inst;
>> + spinlock_t irqlock;
>> +
>> + struct v4l2_m2m_dev *m2m_dev;
>> + struct mutexdev_mutex;
>> +};
>> +
>> +/* Per-queue, driver-specific private data */
>> +struct ipu_scale_q_data {
>> + struct v4l2_pix_format cur_fmt;
>> + struct v4l2_rectrect;
>> +};
>> +
>> +struct ipu_scale_ctx {
>> + struct ipu_scale_dev*ipu_scaler;
>> +
>> + struct v4l2_fh fh;
>> + struct vb2_alloc_ctx*alloc
Re: [PATCH v3 5/5] [media] imx-ipu: Add i.MX IPUv3 scaler driver
2015-10-02 10:37 GMT+02:00 Philipp Zabel : > Hi Jean-Michel, > > Am Donnerstag, den 01.10.2015, 09:55 +0200 schrieb Jean-Michel Hautbois: >> Hi Philipp, Hans, >> >> >> 2015-07-24 17:12 GMT+02:00 Hans Verkuil : > [...] >> What is the status of this driver ? >> I can test it here, Philipp, are you planning to take Hans remarks >> into account in one of your trees ? > > Thank you for the reminder! > > I have fixed most of the issues Hans pointed out, but got distracted at > some point and left for other things. I'll prepare a new version of this > series. OK, don't hesitate if you need some tests ;-). BTW, I am modifying coda support V4L2_ENC_CMD_STOP. I will propose a patch during the day, it is probably not perfect, so your review will be appreciated :). JM PS: Will you be there at ELCE next week ? -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Dublin: ELCE linux-media dinner
Hi, 2015-10-02 14:32 GMT+02:00 Hans Verkuil : > On October 2, 2015 12:05:37 PM GMT+01:00, Ricardo Ribalda Delgado > wrote: >>Hello >> >>Some of the people from this list will be in Dublin the next week for >>the ELCE, unfortunately, this year we will not have the linux-media >>summit, because it will be in Korea. >> >>Anyway, I think that it can be a great idea to meet in Dublin and have >>dinner together. >> >>At least these people will be in Dublin: >> >>Hans Verlkuil: 2-10 october >>Nicolas Dufresne: 2-10 october >>Ricardo Ribalda: 3-10 october You can add me (maybe could we have a file to summarize it) ? Jean-Michel Hautbois: 4-9 october >> >> >>Date: Hans has proposed the dates 4th (sunday) or 6th. The 6th is >>the Technical Showcase and I believe that there will be some food >>involved. Agree. >>Location: I assume most of us will have their room close to the >>conference, so we can find out a place close by. Any Dublin local in >>the list that can recommend a place? >> >>Looking forward to meet you! > > I'm no Dublin native, but I asked a taxidriver instead:-) > > Herbstreet.ie looks good, but there are a bunch of other restaurants in that > area as well. You likely need a reservation, though. I can do that if I know > how many will join in. We need to find a place with great beers ;-). JM -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Coda encoder stop
Hi Philipp,
I have tried to implement V4L2_ENC_CMD_STOP command in coda encoder
but can't make it work with gstreamer (I have modified my gst element
to use the correct command, based on your work on bug
https://bugzilla.gnome.org/show_bug.cgi?id=733864).
Here is what I have tried :
>From 1dd2f797b2b368d44c1a1bd992379c252e1b57e1 Mon Sep 17 00:00:00 2001
From: Jean-Michel Hautbois
Date: Fri, 2 Oct 2015 11:18:27 +0200
Subject: [PATCH] coda: Add support for [try]encoder_cmd ioctl
This allows userspace to ask for the encoder to stop.
When last buffer is received it sends a EOS event.
Signed-off-by: Jean-Michel Hautbois
---
drivers/media/platform/coda/coda-common.c | 58 ---
1 file changed, 53 insertions(+), 5 deletions(-)
diff --git a/drivers/media/platform/coda/coda-common.c
b/drivers/media/platform/coda/coda-common.c
index a4654e0..7dd7bd9 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -686,12 +686,23 @@ static int coda_qbuf(struct file *file, void *priv,
static bool coda_buf_is_end_of_stream(struct coda_ctx *ctx,
struct vb2_buffer *buf)
{
-struct vb2_queue *src_vq;
-
-src_vq = v4l2_m2m_get_vq(ctx->fh.m2m_ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
+int ret = false;
-return ((ctx->bit_stream_param & CODA_BIT_STREAM_END_FLAG) &&
-(buf->v4l2_buf.sequence == (ctx->qsequence - 1)));
+if (ctx->bit_stream_param & CODA_BIT_STREAM_END_FLAG) {
+switch (ctx->inst_type) {
+case CODA_INST_DECODER:
+if (buf->v4l2_buf.sequence == (ctx->qsequence - 1))
+ret = true;
+break;
+case CODA_INST_ENCODER:
+if (buf->v4l2_buf.sequence == (ctx->osequence - 1))
+ret = true;
+break;
+default:
+break;
+}
+}
+return ret;
}
void coda_m2m_buf_done(struct coda_ctx *ctx, struct vb2_buffer *buf,
@@ -702,6 +713,7 @@ void coda_m2m_buf_done(struct coda_ctx *ctx,
struct vb2_buffer *buf,
};
if (coda_buf_is_end_of_stream(ctx, buf)) {
+v4l2_dbg(1, coda_debug, &ctx->dev->v4l2_dev, "send EOS");
buf->v4l2_buf.flags |= V4L2_BUF_FLAG_LAST;
v4l2_event_queue_fh(&ctx->fh, &eos_event);
@@ -791,6 +803,40 @@ static int coda_decoder_cmd(struct file *file, void *fh,
return 0;
}
+static int coda_try_encoder_cmd(struct file *file, void *fh,
+struct v4l2_encoder_cmd *ec)
+{
+if (ec->cmd != V4L2_ENC_CMD_STOP)
+return -EINVAL;
+
+if (ec->flags & V4L2_ENC_CMD_STOP_AT_GOP_END)
+return -EINVAL;
+
+return 0;
+}
+
+static int coda_encoder_cmd(struct file *file, void *fh,
+struct v4l2_encoder_cmd *ec)
+{
+struct coda_ctx *ctx = fh_to_ctx(fh);
+int ret;
+
+ret = coda_try_encoder_cmd(file, fh, ec);
+if (ret < 0)
+return ret;
+
+/* Ignore encoder stop command silently in decoder context */
+if (ctx->inst_type != CODA_INST_ENCODER)
+return 0;
+
+/* Set the stream-end flag on this context */
+coda_bit_stream_end_flag(ctx);
+ctx->hold = false;
+v4l2_m2m_try_schedule(ctx->fh.m2m_ctx);
+
+return 0;
+}
+
static int coda_g_parm(struct file *file, void *fh, struct v4l2_streamparm *a)
{
struct coda_ctx *ctx = fh_to_ctx(fh);
@@ -928,6 +974,8 @@ static const struct v4l2_ioctl_ops coda_ioctl_ops = {
.vidioc_try_decoder_cmd= coda_try_decoder_cmd,
.vidioc_decoder_cmd= coda_decoder_cmd,
+.vidioc_try_encoder_cmd= coda_try_encoder_cmd,
+.vidioc_encoder_cmd= coda_encoder_cmd,
.vidioc_g_parm= coda_g_parm,
.vidioc_s_parm= coda_s_parm,
--
2.6.0
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Coda encoder stop
2015-10-02 16:31 GMT+02:00 Jean-Michel Hautbois
:
> Hi Philipp,
>
> I have tried to implement V4L2_ENC_CMD_STOP command in coda encoder
> but can't make it work with gstreamer (I have modified my gst element
> to use the correct command, based on your work on bug
> https://bugzilla.gnome.org/show_bug.cgi?id=733864).
>
> Here is what I have tried :
>
> From 1dd2f797b2b368d44c1a1bd992379c252e1b57e1 Mon Sep 17 00:00:00 2001
> From: Jean-Michel Hautbois
> Date: Fri, 2 Oct 2015 11:18:27 +0200
> Subject: [PATCH] coda: Add support for [try]encoder_cmd ioctl
>
> This allows userspace to ask for the encoder to stop.
> When last buffer is received it sends a EOS event.
>
> Signed-off-by: Jean-Michel Hautbois
> ---
> drivers/media/platform/coda/coda-common.c | 58
> ---
> 1 file changed, 53 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/platform/coda/coda-common.c
> b/drivers/media/platform/coda/coda-common.c
> index a4654e0..7dd7bd9 100644
> --- a/drivers/media/platform/coda/coda-common.c
> +++ b/drivers/media/platform/coda/coda-common.c
> @@ -686,12 +686,23 @@ static int coda_qbuf(struct file *file, void *priv,
> static bool coda_buf_is_end_of_stream(struct coda_ctx *ctx,
>struct vb2_buffer *buf)
> {
> -struct vb2_queue *src_vq;
> -
> -src_vq = v4l2_m2m_get_vq(ctx->fh.m2m_ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
> +int ret = false;
>
> -return ((ctx->bit_stream_param & CODA_BIT_STREAM_END_FLAG) &&
> -(buf->v4l2_buf.sequence == (ctx->qsequence - 1)));
> +if (ctx->bit_stream_param & CODA_BIT_STREAM_END_FLAG) {
> +switch (ctx->inst_type) {
> +case CODA_INST_DECODER:
> +if (buf->v4l2_buf.sequence == (ctx->qsequence - 1))
> +ret = true;
> +break;
> +case CODA_INST_ENCODER:
> +if (buf->v4l2_buf.sequence == (ctx->osequence - 1))
> +ret = true;
> +break;
> +default:
> +break;
> +}
> +}
> +return ret;
> }
>
> void coda_m2m_buf_done(struct coda_ctx *ctx, struct vb2_buffer *buf,
> @@ -702,6 +713,7 @@ void coda_m2m_buf_done(struct coda_ctx *ctx,
> struct vb2_buffer *buf,
> };
>
> if (coda_buf_is_end_of_stream(ctx, buf)) {
> +v4l2_dbg(1, coda_debug, &ctx->dev->v4l2_dev, "send EOS");
> buf->v4l2_buf.flags |= V4L2_BUF_FLAG_LAST;
>
> v4l2_event_queue_fh(&ctx->fh, &eos_event);
> @@ -791,6 +803,40 @@ static int coda_decoder_cmd(struct file *file, void *fh,
> return 0;
> }
>
> +static int coda_try_encoder_cmd(struct file *file, void *fh,
> +struct v4l2_encoder_cmd *ec)
> +{
> +if (ec->cmd != V4L2_ENC_CMD_STOP)
> +return -EINVAL;
> +
> +if (ec->flags & V4L2_ENC_CMD_STOP_AT_GOP_END)
> +return -EINVAL;
> +
> +return 0;
> +}
> +
> +static int coda_encoder_cmd(struct file *file, void *fh,
> +struct v4l2_encoder_cmd *ec)
> +{
> +struct coda_ctx *ctx = fh_to_ctx(fh);
> +int ret;
> +
> +ret = coda_try_encoder_cmd(file, fh, ec);
> +if (ret < 0)
> +return ret;
> +
> +/* Ignore encoder stop command silently in decoder context */
> +if (ctx->inst_type != CODA_INST_ENCODER)
> +return 0;
> +
> +/* Set the stream-end flag on this context */
> +coda_bit_stream_end_flag(ctx);
> +ctx->hold = false;
> +v4l2_m2m_try_schedule(ctx->fh.m2m_ctx);
> +
> +return 0;
> +}
> +
> static int coda_g_parm(struct file *file, void *fh, struct v4l2_streamparm
> *a)
> {
> struct coda_ctx *ctx = fh_to_ctx(fh);
> @@ -928,6 +974,8 @@ static const struct v4l2_ioctl_ops coda_ioctl_ops = {
>
> .vidioc_try_decoder_cmd= coda_try_decoder_cmd,
> .vidioc_decoder_cmd= coda_decoder_cmd,
> +.vidioc_try_encoder_cmd= coda_try_encoder_cmd,
> +.vidioc_encoder_cmd= coda_encoder_cmd,
>
> .vidioc_g_parm= coda_g_parm,
> .vidioc_s_parm= coda_s_parm,
> --
> 2.6.0
Oups, forgot to paste the kernel output :
[ 324.390498] [ cut here ]
[ 324.395163] WARNING: CPU: 1 PID: 1434 at
/run/media/jm/SSD_JM/Projets/git_mirrors/linux-2.6-imx/kernel/locking/lockdep.c:3382
lock_release+0x2b0/0x6d4()
[ 324.408821] DEBUG_LOCKS_WARN_ON(depth <= 0)
[ 324.412840] Modules linked in:
[ 324.415917] ath9k_htc ath9k_common ath9k_hw ath snd_soc_adv76xx
snd_soc_vbx3_fpga vbx3_fpga_vswitch smsc95xx usbnet mx6_camera(C)
imx_ipu_scaler imx_ipu vbx3_fpga adv7604 snd_soc_sgtl5000
Re: Coda encoder stop
2015-10-02 17:14 GMT+02:00 Philipp Zabel : > Am Freitag, den 02.10.2015, 16:59 +0200 schrieb Jean-Michel Hautbois: > [...] >> Oups, forgot to paste the kernel output : >> >> [ 324.390498] [ cut here ] >> [ 324.395163] WARNING: CPU: 1 PID: 1434 at >> /run/media/jm/SSD_JM/Projets/git_mirrors/linux-2.6-imx/kernel/locking/lockdep.c:3382 >> lock_release+0x2b0/0x6d4() >> [ 324.408821] DEBUG_LOCKS_WARN_ON(depth <= 0) >> [ 324.412840] Modules linked in: >> [ 324.415917] ath9k_htc ath9k_common ath9k_hw ath snd_soc_adv76xx >> snd_soc_vbx3_fpga vbx3_fpga_vswitch smsc95xx usbnet mx6_camera(C) >> imx_ipu_scaler imx_ipu vbx3_fpga adv7604 snd_soc_sgtl5000 lmh0395 >> snd_soc_vbx3sdi vbx3_sdi fbcon bitblit softcursor font >> [ 324.437279] CPU: 1 PID: 1434 Comm: video-h264:src Tainted: G >> C 4.2.0 #106 >> [ 324.445204] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) >> [ 324.451741] Backtrace: >> [ 324.454226] [<8001524c>] (dump_backtrace) from [<80015494>] >> (show_stack+0x20/0x24) >> [ 324.461804] r6:80fb1a60 r5: r4: r3: >> [ 324.467562] [<80015474>] (show_stack) from [<808fdd6c>] >> (dump_stack+0x98/0xc8) >> [ 324.474803] [<808fdcd4>] (dump_stack) from [<800304f0>] >> (warn_slowpath_common+0x8c/0xc8) >> [ 324.482902] r6:8007ffbc r5:0009 r4:a4eafab8 r3:0001 >> [ 324.488652] [<80030464>] (warn_slowpath_common) from [<8003056c>] >> (warn_slowpath_fmt+0x40/0x48) >> [ 324.497359] r8:80fb1b60 r7:80904b3c r6:a636c9c0 r5:a6c9f368 r4:80c1e150 >> [ 324.504168] [<80030530>] (warn_slowpath_fmt) from [<8007ffbc>] >> (lock_release+0x2b0/0x6d4) >> [ 324.512353] r3:80c246fc r2:80c1e150 >> [ 324.515971] r4:a6c9f32c >> [ 324.518541] [<8007fd0c>] (lock_release) from [<80904a34>] >> (__mutex_unlock_slowpath+0xc4/0x1b4) >> [ 324.527160] r10: r9:a4531281 r8: r7:8185231c >> r6:80904b3c r5:600f0013 >> [ 324.535091] r4:a6c9f32c >> [ 324.537657] [<80904970>] (__mutex_unlock_slowpath) from >> [<80904b3c>] (mutex_unlock+0x18/0x1c) >> [ 324.546189] r7: r6:a4eafcd4 r5:0041 r4:a5e1b000 >> [ 324.551945] [<80904b24>] (mutex_unlock) from [<80602fe8>] >> (v4l2_m2m_fop_poll+0x5c/0x64) >> [ 324.559970] [<80602f8c>] (v4l2_m2m_fop_poll) from [<805ec694>] >> (v4l2_poll+0x6c/0xa0) >> [ 324.567722] r6:a4eafbec r5: r4:a6c9e090 r3:80602f8c >> [ 324.573481] [<805ec628>] (v4l2_poll) from [<80174d04>] >> (do_sys_poll+0x230/0x4d0) >> [ 324.580886] r5: r4:a4eafbe4 >> [ 324.584515] [<80174ad4>] (do_sys_poll) from [<801752e0>] >> (SyS_ppoll+0x1d4/0x1fc) >> [ 324.591917] r10: r9:a4eae000 r8: r7: >> r6:74a14790 r5:0002 >> [ 324.599846] r4: >> [ 324.602419] [<8017510c>] (SyS_ppoll) from [<80010b00>] >> (ret_fast_syscall+0x0/0x54) >> [ 324.609996] r8:80010ce4 r7:0150 r6:74a14790 r5:0002 r4:0008 >> [ 324.616798] ---[ end trace 0012dc3dcc1c27d5 ]--- > > Hm, that looks very similar to the issue Zahari's "[media] m2m: fix bad > unlock balance" is supposed to fix: > https://patchwork.linuxtv.org/patch/30906/ > > regards > Philipp > Thanks for that ! I am on 4.2, not media-tree, this is why I didn't have it. JM -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] ADV7604: VGA support
Hi, I had another look into the ADV7604 HW manual, and I understand that in automatic mode, there is 4 AIN_SEL values possible, determining the connection on AIN pins. Now, having a look at the current ADV76xx files, I can see that two pads are there : ADV7604_PAD_VGA_RGB and ADV7604_PAD_VGA_COMP. According to the manual, my understanding is that we should have four HDMI pads and four analog pads. The latter would be configured as RGB or component, which allows four analog inputs as described in the HW manual. I don't know if you agree with that or if you had something else in mind when designing it in the first place, I may have missed something (Lars :) ?). Thanks, JM -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: coda: not generating EOS event
Hi all, 2015-01-22 15:58 GMT+01:00 Philipp Zabel : > Hi, > > Am Donnerstag, den 11.12.2014, 15:47 +0100 schrieb Hans Verkuil: >> Hi Pawel, >> >> On 12/11/14 15:42, Nicolas Dufresne wrote: >> > Le jeudi 11 décembre 2014 à 11:00 -0200, Fabio Estevam a écrit : >> >> Hi, >> >> >> >> I am running Gstreamer 1.4.4 with on a imx6q-sabresd board and I am >> >> able to decode a video through the coda driver. >> >> >> >> The pipeline I use is: >> >> gst-launch-1.0 filesrc >> >> location=/home/H264_test1_Talkinghead_mp4_480x360.mp4 ! qtdemux ! >> >> h264parse ! v4l2video1dec ! videoconvert ! fbdevsink >> > >> > This is a known issue. The handling of EOS and draining is ill defined >> > in V4L2 specification. We should be clarifying this soon. Currently >> > GStreamer implements what was originally done in Exynos MFC driver. This >> > consist of sending empty buffer to the V4L2 Output (the input), until we >> > get an empty buffer (bytesused = 0) on the V4L2 Capture (output). >> > >> > The CODA driver uses the new method to initiate the drain, which is to >> > send V4L2_DEC_CMD_STOP, this was not implemented by any driver when GST >> > v4l2 support was added. This is the right thing to do. This is tracked >> > at (contribution welcome of course): >> > >> > https://bugzilla.gnome.org/show_bug.cgi?id=733864 >> > >> > Finally, CODA indicate that all buffer has been sent through an event, >> > V4L2_EVENT_EOS. This event was designed for another use case, it should >> > in fact be sent when the decoder is done with the encoded buffers, >> > rather then when the last decoded buffer has been queued. When correctly >> > implemented, this event cannot be used to figure-out when the last >> > decoded buffer has been dequeued. >> > >> > During last workshop, it has been proposed to introduce a flag on the >> > last decoded buffer, _LAST. This flag could also be put on an empty >> >> Are you planning to work on this? That was my assumption, but it's probably >> a good idea to check in case we are waiting for one another :-) > > I had another look at the ELC-E 2014 V4L2 codec API document and have > tried to implement the proposed decoder draining flow in an RFC: > "Signalling last decoded frame by V4L2_BUF_FLAG_LAST and -EPIPE": > > http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/87152 > > Are you planning to pour the workshop's codec API document into a V4L2 > documentation patch? I am now working on the encoder part (for coda) which should do the same. But everything is documented from a decoder POV, not the encoder's... Is the mecanism already there, and the only thing which should be added is the ENC_CMD_STOP command ? Thanks, JM -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] DocBook media: Fix a typo in encoder cmd
A copy-paste from DECODER_CMD : replace decoded by encoded. Signed-off-by: Jean-Michel Hautbois --- Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml b/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml index fc1d462..70a4a08 100644 --- a/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml +++ b/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml @@ -130,7 +130,7 @@ encoding will continue until the end of the current Group Of Pictures, otherwise encoding will stop immediately. When the encoder is already stopped, this command does nothing. mem2mem encoders will send a V4L2_EVENT_EOS event -when the last frame has been decoded and all frames are ready to be dequeued and +when the last frame has been encoded and all frames are ready to be dequeued and will set the V4L2_BUF_FLAG_LAST buffer flag on the last buffer of the capture queue to indicate there will be no new buffers produced to dequeue. This buffer may be empty, indicated by the driver setting the -- 2.6.0 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Is IIO the appropriate subsystem for a thermal camera sensor?
Hi Lucas, 2015-10-26 8:53 GMT+01:00 Daniel Baluta : > Hi Lucas, > > Adding linux-iio and linux-media, I hope you don't mind. > > On 10/23/2015 06:58 PM, Lucas Magasweran wrote: >> >> Hi Daniel, >> >> My colleague, Roberto Cornetti, attended your IIO talk at LinuxCon >> recently and is using the IIO subsystem for an I2C IMU. >> > > Glad to hear that :) > >> My question is if IIO the appropriate subsystem for a thermal camera >> sensor. The driver needs to acquire frames over SPI and configure the >> sensor via I2C. It also has to respond to a GPIO interrupt to >> synchronize with the camera. > > > I am not sure exactly about this. My feeling is that this should go with the > v4l subsystem thus Cc-ing linux-media. This is definitely a V4L2 driver. Note however that AFAIK, no sensor is currently sending frames from SPI right now... Nothing impossible though :). > Do you have any datasheet for this sensor? > > At some point [1] we considered introducing the fingerprint sensor as an IIO > device, but that didn't quite fit. So, we reconsidered using v4l. > I this is your case too :). > > Hope this helps. > Daniel. > > > [1] http://marc.info/?l=linux-kernel&m=141769805614596&w=2 > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PCIe capture driver
Hi Ran, 2015-10-26 18:04 GMT+01:00 Ran Shalit : > On Mon, Oct 26, 2015 at 1:46 PM, Steven Toth wrote: >>> No, use V4L2. What you do with the frame after it has been captured >>> into memory has no relevance to the API you use to capture into memory. >> >> Ran, I've built many open and closed source Linux drivers over the >> last 10 years - so I can speak with authority on this. >> >> Hans is absolutely correct, don't make the mistake of going >> proprietary with your API. Take advantage of the massive amount of >> video related frameworks the kernel has to offer. It will get you to >> market faster, assuming your goal is to build a driver that is open >> source. If your licensing prohibits an open source driver solution, >> you'll have no choice but to build your own proprietary API. >> >> -- >> Steven Toth - Kernel Labs >> http://www.kernellabs.com > > Hi, > > Thank you very much for these valuable comments. > If I may ask one more on this issue: > Is there an example in linux tree, for a pci device which is used both > as a capture and a display device ? (I've made a search but did not > find any) > The PCIe device we are using will be both a capture device and output > video device (for display). Is is a custom card ? If not, which one is it ? And if it is a custom board, then maybe can you at least describe the inputs and outputs exactly (ideally, the chips used) ? This would help understand what you problem really is :). JM -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] v4l2-mem2mem: allow reqbufs(0) with "in use" MMAP buffers
Hi, 2015-11-02 19:31 GMT+01:00 Nicolas Dufresne : > Le mardi 08 avril 2014 à 12:51 +0200, Marek Szyprowski a écrit : >> Hello, >> >> On 2014-04-07 16:41, Kamil Debski wrote: >> > Pawel, Marek, >> > >> > Before taking this to my tree I wanted to get an ACK from one of >> > the >> > videobuf2 maintainers. Could you spare a moment to look through >> > this >> > patch? >> >> It's not a bug, it is a feature. This was one of the fundamental >> design >> requirements to allow applications to track if the memory is used or >> not. > > I still have the impression it is not fully correct for the case > buffers are exported using DMABUF. Like if the dmabuf was owning the > vb2 buffer instead of the opposite ... I am observing this behaviour too... Tried it, but seems to not do the job on dmabuf buffers... with gstreamer at least ;-). JM -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Coda : QP rate control encoding
Hi, I am playing a bit with the coda encoder on i.MX6 and try to get the most quality out of it. So, I am trying to use the controls of the driver, in particular h264_i_frame_qp_value and h264_p_frame_qp_value. I can get something with the following pipeline : gst-launch-1.0 -evvv v4l2src num-buffers=2000 device=/dev/v4l/by-path/ipu1-capture io-mode=dmabuf ! "video/x-raw,width=1280,height=720,framerate=25/1,format=YUY2" ! v4l2convert device=/dev/v4l/by-path/ipu1-scaler capture-io-mode=dmabuf output-io-mode=dmabuf-import ! 'video/x-raw,width=640,height=360,format=NV12' ! v4l2video0h264enc output-io-mode=dmabuf-import extra-controls="controls,h264_i_frame_qp_value=24,h264_p_frame_qp_value=30,video_gop_size=32" ! queue ! progressreport name=p2 ! h264parse ! matroskamux ! filesink location=/data/test_encode_360p.mkv With those values, I get ~800kbps for a 360p converted frame. This is nice :). The same video as an input with only the "bitrate" parameter set is not visually similar. But, when trying to encode a 720p video with the same QP parameters, it is not working (the first keyframe is not ok, seems to be a P frame instead of I, as it is 2000 bits and should be ~4). I am keeping the videoscaler in this second case, as it should be used as a color converter. Philipp, did you do some tests like this one ? Did you observe that the encoder can maybe be too long to get a frame encoded when desired quality is "high" ? Maybe do you have some ideas about this ? Thanks, JM -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Coda : QP rate control encoding
Hi ! 2015-05-07 15:53 GMT+02:00 Jean-Michel Hautbois : > > Hi, > > I am playing a bit with the coda encoder on i.MX6 and try to get the > most quality out of it. So, I am trying to use the controls of the > driver, in particular h264_i_frame_qp_value and h264_p_frame_qp_value. > > I can get something with the following pipeline : > gst-launch-1.0 -evvv v4l2src num-buffers=2000 > device=/dev/v4l/by-path/ipu1-capture io-mode=dmabuf ! > "video/x-raw,width=1280,height=720,framerate=25/1,format=YUY2" ! > v4l2convert device=/dev/v4l/by-path/ipu1-scaler capture-io-mode=dmabuf > output-io-mode=dmabuf-import ! > 'video/x-raw,width=640,height=360,format=NV12' ! v4l2video0h264enc > output-io-mode=dmabuf-import > extra-controls="controls,h264_i_frame_qp_value=24,h264_p_frame_qp_value=30,video_gop_size=32" > ! queue ! progressreport name=p2 ! h264parse ! matroskamux ! filesink > location=/data/test_encode_360p.mkv > > With those values, I get ~800kbps for a 360p converted frame. This is nice :). > The same video as an input with only the "bitrate" parameter set is > not visually similar. > > But, when trying to encode a 720p video with the same QP parameters, > it is not working (the first keyframe is not ok, seems to be a P frame > instead of I, as it is 2000 bits and should be ~4). I am keeping > the videoscaler in this second case, as it should be used as a color > converter. > > Philipp, did you do some tests like this one ? Did you observe that > the encoder can maybe be too long to get a frame encoded when desired > quality is "high" ? I have done more tests, and it seems to be related to the bitrate we asked, and the input resolution... Right now, I have a 360p@5Mbps, which works perfectly, and the same source, in 720p with a bitrate up to 3Mbps is ok. But when I go higher, I miss the I frames on some GOPs (very frequently the second one). I don't know if there is some limitations to what the CODA can do, but 1080p30 seems impossible @4Mbps at least... ? Thanks for your advices ! JM -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/5] gpu: ipu-v3: Add mem2mem image conversion support to IC
Hi Philipp, Lucas and Sascha,
Thanks for that patch series.
2015-03-18 11:22 GMT+01:00 Philipp Zabel :
>
> This patch adds support for mem2mem scaling and colorspace conversion
> using the IC module's post-processing task.
>
> Scaling images larger than 1024x1024 is supported by tiling over multiple
> IC scaling runs. Since the IDMAC and IC units have interesting and different
> alignment limitations for buffer base addresses (left edges) and burst size
> (row lengths), depending on input and output pixel formats, the tile
> rectangles
> and scaling coefficients are chosen to minimize distortion. Due to possible
> overlap, the tiles have to be rendered right to left and bottom to top.
> Up to 7 pixels (depending on frame sizes and scaling factor) have to be
> available after the end of the frame if the width is not burst size aligned.
> The tiling code has a parameter to optionally round frame sizes up or down
> and avoid overdraw in compositing scenarios.
Can you detail what you call "compositing scenarios" ?
>
> Signed-off-by: Sascha Hauer
> Signed-off-by: Lucas Stach
> Signed-off-by: Philipp Zabel
> ---
> Changes since v1:
> - Removed deinterlacer support left-overs
> ---
> drivers/gpu/ipu-v3/ipu-ic.c | 787
> +++-
> include/video/imx-ipu-v3.h | 34 +-
> 2 files changed, 804 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
> index ad75588..984f68f 100644
> --- a/drivers/gpu/ipu-v3/ipu-ic.c
> +++ b/drivers/gpu/ipu-v3/ipu-ic.c
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include "ipu-prv.h"
> @@ -96,6 +97,15 @@ struct ic_task_bitfields {
> u32 ic_cmb_galpha_bit;
> };
>
> +struct ic_task_channels {
> + u8 in;
> + u8 out;
> + u8 rot_in;
> + u8 rot_out;
> + u8 in_prev;
> + u8 in_next;
> +};
> +
> static const struct ic_task_regoffs ic_task_reg[IC_NUM_TASKS] = {
> [IC_TASK_ENCODER] = {
> .rsc = IC_PRP_ENC_RSC,
> @@ -138,12 +148,53 @@ static const struct ic_task_bitfields
> ic_task_bit[IC_NUM_TASKS] = {
> },
> };
>
> +static const struct ic_task_channels ic_task_ch[IC_NUM_TASKS] = {
> + [IC_TASK_ENCODER] = {
> + .in = IPUV3_CHANNEL_MEM_IC_PRP_VF,
> + .out = IPUV3_CHANNEL_IC_PRP_ENC_MEM,
> + .rot_in = IPUV3_CHANNEL_MEM_ROT_ENC,
> + .rot_out = IPUV3_CHANNEL_ROT_ENC_MEM,
> + },
> + [IC_TASK_VIEWFINDER] = {
> + .in = IPUV3_CHANNEL_MEM_VDI_CUR,
> + .out = IPUV3_CHANNEL_IC_PRP_VF_MEM,
> + .rot_in = IPUV3_CHANNEL_MEM_ROT_VF,
> + .rot_out = IPUV3_CHANNEL_ROT_VF_MEM,
> + .in_prev = IPUV3_CHANNEL_MEM_VDI_PREV,
> + .in_next = IPUV3_CHANNEL_MEM_VDI_NEXT,
> + },
> + [IC_TASK_POST_PROCESSOR] = {
> + .in = IPUV3_CHANNEL_MEM_IC_PP,
> + .out = IPUV3_CHANNEL_IC_PP_MEM,
> + .rot_in = IPUV3_CHANNEL_MEM_ROT_PP,
> + .rot_out = IPUV3_CHANNEL_ROT_PP_MEM,
> + },
> +};
> +
> +struct image_convert_ctx {
> + void (*complete)(void *ctx, int err);
> + void *complete_context;
> +
> + struct list_head list;
> + struct ipu_image in;
> + struct ipu_image in_n;
> + struct ipu_image in_p;
> + struct ipu_image out;
> +
> + void *freep;
> +
> + bool rotate:1;
> +
> + u32 rsc;
> +};
> +
> struct ipu_ic_priv;
>
> struct ipu_ic {
> enum ipu_ic_task task;
> const struct ic_task_regoffs *reg;
> const struct ic_task_bitfields *bit;
> + const struct ic_task_channels *ch;
>
> enum ipu_color_space in_cs, g_in_cs;
> enum ipu_color_space out_cs;
> @@ -152,6 +203,19 @@ struct ipu_ic {
> bool in_use;
>
> struct ipu_ic_priv *priv;
> +
> + struct ipuv3_channel *input_channel_p;
> + struct ipuv3_channel *input_channel;
> + struct ipuv3_channel *input_channel_n;
> + struct ipuv3_channel *output_channel;
> + struct ipuv3_channel *rotation_input_channel;
> + struct ipuv3_channel *rotation_output_channel;
> +
> + struct list_head image_list;
> +
> + struct workqueue_struct *workqueue;
> + struct work_struct work;
> + struct completion complete;
> };
As this is a workqueue, it can sleep, and you don't know when it is
called exactly.
Can we be sure that it is "real-time" compatible ? If you have this
scaler after a capture source, and before the coda driver, you can be
starved of buffers ?
And you can even have multiple instances of the scaler, so you
probably can get into troubles if there is not enough buffers on the
capture and output queues, right ?
I have played with it a bit and have been successful having two
instances on IPU1 and two other on IPU2.
But I don't know if there can be side effects...
JM
>
> st
Re: coda: Unable to use encoder video_bitrate
Hi Philipp, 2014-12-18 17:52 GMT+01:00 Philipp Zabel : > Hi Frédéric, > > Am Donnerstag, den 18.12.2014, 17:44 +0100 schrieb Frédéric Sureau: >> Hi >> >> I am trying to use the coda encoder through Gstreamer on an iMX6-based >> board. >> >> I use the (rebased and slightly modified) gstv4l2h264enc plugin from: >> https://github.com/hizukiayaka/gst-plugins-good >> >> This pipeline works fine: >> gst-launch-1.0 -vvv v4l2src device=/dev/video4 ! >> "video/x-raw,width=1280,height=720" ! videoconvert ! v4l2video0h264enc ! >> h264parse ! mp4mux ! filesink location=test.mp4 >> >> When encoder has no bitrate param set (default=0), video encoding works >> well, but bitrate reaches ~2.5Mbps >> >> When I try to set the bitrate with whatever value like 100,000 or >> 1,000,000, the encoder produces video with bitrate around 480kbps and a >> very poor quality. >> >> Here is the gstreamer pipeline I use with bitrate set: >> gst-launch-1.0 -vvv v4l2src device=/dev/video4 ! >> "video/x-raw,width=1280,height=720" ! videoconvert ! v4l2video0h264enc >> extra-controls="controls,video_bitrate=100;" ! h264parse ! mp4mux ! >> filesink location=test.mp4 >> >> The video_bitrate control seems to be correctly passed to the driver by >> GStreamer since I can see the VIDIOC_S_CTRL call. >> >> Any idea ? > > There is a bug in the register definitions that causes the driver to > apply a wrong mask before writing the bitrate to the register. > I've got a fix for this in the pipeline, sending it right now. Where can we find the register definitions ? In order to look at it before asking you :) ? Thanks, JM -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: coda: Unable to use encoder video_bitrate
2014-12-18 18:09 GMT+01:00 Philipp Zabel : > Hi Jean-Michel, > > Am Donnerstag, den 18.12.2014, 17:55 +0100 schrieb Jean-Michel Hautbois: >> Hi Philipp, >> >> 2014-12-18 17:52 GMT+01:00 Philipp Zabel : >> > Hi Frédéric, >> > >> > Am Donnerstag, den 18.12.2014, 17:44 +0100 schrieb Frédéric Sureau: >> >> Hi >> >> >> >> I am trying to use the coda encoder through Gstreamer on an iMX6-based >> >> board. >> >> >> >> I use the (rebased and slightly modified) gstv4l2h264enc plugin from: >> >> https://github.com/hizukiayaka/gst-plugins-good >> >> >> >> This pipeline works fine: >> >> gst-launch-1.0 -vvv v4l2src device=/dev/video4 ! >> >> "video/x-raw,width=1280,height=720" ! videoconvert ! v4l2video0h264enc ! >> >> h264parse ! mp4mux ! filesink location=test.mp4 >> >> >> >> When encoder has no bitrate param set (default=0), video encoding works >> >> well, but bitrate reaches ~2.5Mbps >> >> >> >> When I try to set the bitrate with whatever value like 100,000 or >> >> 1,000,000, the encoder produces video with bitrate around 480kbps and a >> >> very poor quality. >> >> >> >> Here is the gstreamer pipeline I use with bitrate set: >> >> gst-launch-1.0 -vvv v4l2src device=/dev/video4 ! >> >> "video/x-raw,width=1280,height=720" ! videoconvert ! v4l2video0h264enc >> >> extra-controls="controls,video_bitrate=100;" ! h264parse ! mp4mux ! >> >> filesink location=test.mp4 >> >> >> >> The video_bitrate control seems to be correctly passed to the driver by >> >> GStreamer since I can see the VIDIOC_S_CTRL call. >> >> >> >> Any idea ? >> > >> > There is a bug in the register definitions that causes the driver to >> > apply a wrong mask before writing the bitrate to the register. >> > I've got a fix for this in the pipeline, sending it right now. >> >> Where can we find the register definitions ? In order to look at it >> before asking you :) ? > > Sorry, forgot to put all of you on Cc: for the "[media] coda: fix > encoder rate control parameter masks" patch. The coda driver is in > drivers/media/platform/coda, register definitions in coda_regs.h. > The CODA_RATECONTROL_BITRATE_MASK is 0x7f, but it should be 0x7fff. > Well, I meant, the datasheet of the CODA960 because we don't know, just by reading the coda_regs.h which register is where and does what. But it may be confidential ? JM -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: coda: Unable to use encoder video_bitrate
2014-12-19 11:28 GMT+01:00 Philipp Zabel : > Hi Jean-Michel, > > Am Donnerstag, den 18.12.2014, 18:10 +0100 schrieb Jean-Michel Hautbois: >> > Sorry, forgot to put all of you on Cc: for the "[media] coda: fix >> > encoder rate control parameter masks" patch. The coda driver is in >> > drivers/media/platform/coda, register definitions in coda_regs.h. >> > The CODA_RATECONTROL_BITRATE_MASK is 0x7f, but it should be 0x7fff. >> > >> >> Well, I meant, the datasheet of the CODA960 because we don't know, >> just by reading the coda_regs.h which register is where and does what. > > I wish. If you search for "cnm-codadx6-datasheet-v2.9.pdf" with a search > engine of your choice, on chipsnmedia.com you can get documentation for > the very oldest coda version supported by the driver. That's all I have > in addition to the old GPLed Freescale imx-vpu-lib for reference. Uh, ok, didn't think about this. Thx a lot ! JM -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] vb2: Add VB2_FILEIO_ALLOW_ZERO_BYTESUSED flag to vb2_fileio_flags
Hi Kamil,
2014-12-16 12:36 GMT+01:00 Kamil Debski :
> The vb2: fix bytesused == 0 handling (8a75ffb) patch changed the behavior
> of __fill_vb2_buffer function, so that if bytesused is 0 it is set to the
> size of the buffer. However, bytesused set to 0 is used by older codec
> drivers as as indication used to mark the end of stream.
>
> To keep backward compatibility, this patch adds a flag passed to the
> vb2_queue_init function - VB2_FILEIO_ALLOW_ZERO_BYTESUSED. If the flag is
> set upon initialization of the queue, the videobuf2 keeps the value of
> bytesused intact and passes it to the driver.
Nice, this is something we were planning to do :).
But I would split this patch and the second which is specific to
s5p-mfc as this is core specific and should be independant.
> Reported-by: Nicolas Dufresne
> Signed-off-by: Kamil Debski
> ---
> drivers/media/v4l2-core/videobuf2-core.c | 33
> --
> include/media/videobuf2-core.h |3 +++
> 2 files changed, 30 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/v4l2-core/videobuf2-core.c
> b/drivers/media/v4l2-core/videobuf2-core.c
> index d09a891..1068dbb 100644
> --- a/drivers/media/v4l2-core/videobuf2-core.c
> +++ b/drivers/media/v4l2-core/videobuf2-core.c
> @@ -1276,13 +1276,23 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb,
> const struct v4l2_buffer *b
> * userspace clearly never bothered to set it and
> * it's a safe assumption that they really meant to
> * use the full plane sizes.
> +*
> +* Some drivers, e.g. old codec drivers, use bytesused
> +* == 0 as a way to indicate that streaming is
> finished.
> +* In that case, the driver should use the following
> +* io_flag VB2_FILEIO_ALLOW_ZERO_BYTESUSED to keep old
> +* userspace applications working.
Not sure if this comment is necessary, as this is already in the commit ?
> */
> for (plane = 0; plane < vb->num_planes; ++plane) {
> struct v4l2_plane *pdst = &v4l2_planes[plane];
> struct v4l2_plane *psrc = &b->m.planes[plane];
>
> - pdst->bytesused = psrc->bytesused ?
> - psrc->bytesused : pdst->length;
> + if (vb->vb2_queue->io_flags &
> + VB2_FILEIO_ALLOW_ZERO_BYTESUSED)
> + pdst->bytesused = psrc->bytesused;
> + else
> + pdst->bytesused = psrc->bytesused ?
> + psrc->bytesused :
> pdst->length;
> pdst->data_offset = psrc->data_offset;
> }
> }
> @@ -1295,6 +1305,12 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb,
> const struct v4l2_buffer *b
> *
> * If bytesused == 0 for the output buffer, then fall back
> * to the full buffer size as that's a sensible default.
> +*
> +* Some drivers, e.g. old codec drivers, use bytesused == 0
> +* as a way to indicate that streaming is finished. In that
> +* case, the driver should use the following io_flag
> +* VB2_FILEIO_ALLOW_ZERO_BYTESUSED to keep old userspace
> +* applications working.
Again, not sure this is useful.
> */
> if (b->memory == V4L2_MEMORY_USERPTR) {
> v4l2_planes[0].m.userptr = b->m.userptr;
> @@ -1306,11 +1322,16 @@ static void __fill_vb2_buffer(struct vb2_buffer *vb,
> const struct v4l2_buffer *b
> v4l2_planes[0].length = b->length;
> }
>
> - if (V4L2_TYPE_IS_OUTPUT(b->type))
> - v4l2_planes[0].bytesused = b->bytesused ?
> - b->bytesused : v4l2_planes[0].length;
> - else
> + if (V4L2_TYPE_IS_OUTPUT(b->type)) {
> + if (vb->vb2_queue->io_flags &
> + VB2_FILEIO_ALLOW_ZERO_BYTESUSED)
> + v4l2_planes[0].bytesused = b->bytesused;
> + else
> + v4l2_planes[0].bytesused = b->bytesused ?
> + b->bytesused : v4l2_planes[0].length;
> + } else {
> v4l2_planes[0].bytesused = 0;
> + }
>
> }
>
> diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
> index bd2cec2..0540bc3 100644
> --- a/include/media/videobuf2-core.h
> +++
Re: [PATCH 1/2] vb2: Add VB2_FILEIO_ALLOW_ZERO_BYTESUSED flag to vb2_fileio_flags
2014-12-19 17:03 GMT+01:00 Kamil Debski :
> Hi Jean,
>
>> From: Jean-Michel Hautbois [mailto:jhautb...@gmail.com]
>> Sent: Friday, December 19, 2014 3:36 PM
>> To: Kamil Debski
>> Cc: Linux Media Mailing List; m.szyprow...@samsung.com; Hans Verkuil;
>> Nicolas Dufresne
>> Subject: Re: [PATCH 1/2] vb2: Add VB2_FILEIO_ALLOW_ZERO_BYTESUSED flag
>> to vb2_fileio_flags
>>
>> Hi Kamil,
>>
>> 2014-12-16 12:36 GMT+01:00 Kamil Debski :
>> > The vb2: fix bytesused == 0 handling (8a75ffb) patch changed the
>> > behavior of __fill_vb2_buffer function, so that if bytesused is 0 it
>> > is set to the size of the buffer. However, bytesused set to 0 is used
>> > by older codec drivers as as indication used to mark the end of
>> stream.
>> >
>> > To keep backward compatibility, this patch adds a flag passed to the
>> > vb2_queue_init function - VB2_FILEIO_ALLOW_ZERO_BYTESUSED. If the
>> flag
>> > is set upon initialization of the queue, the videobuf2 keeps the
>> value
>> > of bytesused intact and passes it to the driver.
>>
>> Nice, this is something we were planning to do :).
>> But I would split this patch and the second which is specific to s5p-
>> mfc as this is core specific and should be independant.
>
> This patch contains only changes in the videobuf2-core.c file. The next
> patch in the series contains changes in the s5p-mfc driver. There is
> another patch sent today that adds this flag to coda.
>
> These are all separate patches, two of them are in a single patchset.
> Actually, I would send all of them in one patchset, but initially I missed
> that the coda driver should also have this change applied. (Nicolas, thank
> you for reminding me to do this on IRC).
OK, This is why I have been confused. Well, I still think that core
modification should be a separate patch, and maybe s5f-mpc and coda be
in the same patchset. Not a problem.
>>
>>
>> > Reported-by: Nicolas Dufresne
>> > Signed-off-by: Kamil Debski
>> > ---
>> > drivers/media/v4l2-core/videobuf2-core.c | 33
>> --
>> > include/media/videobuf2-core.h |3 +++
>> > 2 files changed, 30 insertions(+), 6 deletions(-)
>> >
>> > diff --git a/drivers/media/v4l2-core/videobuf2-core.c
>> > b/drivers/media/v4l2-core/videobuf2-core.c
>> > index d09a891..1068dbb 100644
>> > --- a/drivers/media/v4l2-core/videobuf2-core.c
>> > +++ b/drivers/media/v4l2-core/videobuf2-core.c
>> > @@ -1276,13 +1276,23 @@ static void __fill_vb2_buffer(struct
>> vb2_buffer *vb, const struct v4l2_buffer *b
>> > * userspace clearly never bothered to set it
>> and
>> > * it's a safe assumption that they really
>> meant to
>> > * use the full plane sizes.
>> > +*
>> > +* Some drivers, e.g. old codec drivers, use
>> bytesused
>> > +* == 0 as a way to indicate that streaming
>> is finished.
>> > +* In that case, the driver should use the
>> following
>> > +* io_flag VB2_FILEIO_ALLOW_ZERO_BYTESUSED to
>> keep old
>> > +* userspace applications working.
>>
>> Not sure if this comment is necessary, as this is already in the
>> commit ?
>
> The comment were present in the file already, I expanded them to cover the
> exception when the VB2_FILEIO_ALLOW_ZERO_BYTESUSED flag is set.
> It is also explained in the commit, I agree, but in the end one usually
> looks in the source code.
OK
>>
>> > */
>> > for (plane = 0; plane < vb->num_planes;
>> ++plane) {
>> > struct v4l2_plane *pdst =
>> &v4l2_planes[plane];
>> > struct v4l2_plane *psrc =
>> > &b->m.planes[plane];
>> >
>> > - pdst->bytesused = psrc->bytesused ?
>> > - psrc->bytesused : pdst-
>> >length;
>> > + if (vb->vb2_queue->io_flags &
>> > +
>> VB2_FILEIO_ALLOW_ZERO_BYTESUSED)
>> > + pdst->bytesused = psrc-
>> >bytesused;
>> > + else
>> > + pdst->bytesused = psrc
Using CSI1 on i.MX6
Hi all, First of all, happy new year :). Next, I am trying to use the second CSI on i.MX6 (still based on media tree and Steve's work, "slightly" modified ;-)). I am using the following lines in order to configure my adv7604 correctly, and running it in free run mode in order to get something reliable : DEVICE=4 INPUT=0 SUBDEV=3 v4l2-ctl -d$DEVICE --set-edid=pad=0,edid=hdmi -i$INPUT v4l2-ctl -d$DEVICE --set-fmt-video=width=1280,height=720,pixelformat=YUYV,field=none,bytesperline=2560 v4l2-ctl -d$DEVICE --set-dv-bt-timings index=4 v4l2-dbg -d$DEVICE -c subdev$SUBDEV -s 0x03 0x80 v4l2-dbg -d$DEVICE -c subdev$SUBDEV -s 0x02 0x35 And then, I launch this simple line, which gets stuck : v4l2-ctl -d$DEVICE --stream-mmap --stream-to /data/x.raw --stream-count=1 The exact same sequence on CSI0 is working fine. I added the dynamic debug messages and here is the configuration (from my point of view, it seems to be ok, but I may have miss a bit here or there) : [ 131.963122] mx6-camera-encoder: Direct CSI -> SMFC -> MEM [ 131.968568] mx6-camera-encoder: CSI channel 1 on IPU 2 [ 131.973856] imx-ipuv3 280.ipu: ipu_idmac_get 3 [ 131.973880] mx6-camera-encoder: Preview is off [ 131.978380] imx-ipuv3 280.ipu: CSI_SENS_CONF = 0x0950 [ 131.978410] imx-ipuv3 280.ipu: CSI_ACT_FRM_SIZE = 0x02CF04FF [ 131.987448] ipu_cpmem_set_image: resolution: 1280x720 stride: 2560 [ 131.987467] ipu_ch_param_write_field 0 125 13 [ 131.987482] ipu_ch_param_write_field 0 138 12 [ 131.987495] ipu_ch_param_write_field 1 102 14 [ 131.987507] ipu_ch_param_write_field 0 107 3 [ 131.987520] ipu_ch_param_write_field 1 85 4 [ 131.987531] ipu_ch_param_write_field 1 78 7 [ 131.987544] ipu_ch_param_write_field 1 0 29 [ 131.987554] ipu_ch_param_write_field 1 29 29 [ 131.987568] ipu_ch_param_write_field 1 78 7 [ 131.987591] ipu_ch_param_write_field 1 93 2 [ 131.987997] mx6-camera-encoder: Enable CSI [ 131.992125] imx-ipuv3 280.ipu: ch 3 word 0 - E0001800 000B3C9F [ 131.992146] imx-ipuv3 280.ipu: ch 3 word 1 - 0906 01214000 0103C000 00027FC0 [ 131.992159] ipu_ch_param_read_field 1 85 4 [ 131.992173] imx-ipuv3 280.ipu: PFS 0x8, [ 131.992185] ipu_ch_param_read_field 0 107 3 [ 131.992199] imx-ipuv3 280.ipu: BPP 0x3, [ 131.992209] ipu_ch_param_read_field 1 78 7 [ 131.99] imx-ipuv3 280.ipu: NPB 0xf [ 131.992234] ipu_ch_param_read_field 0 125 13 [ 131.992248] imx-ipuv3 280.ipu: FW 1279, [ 131.992259] ipu_ch_param_read_field 0 138 12 [ 131.992271] imx-ipuv3 280.ipu: FH 719, [ 131.992283] ipu_ch_param_read_field 1 0 29 [ 131.992296] imx-ipuv3 280.ipu: EBA0 0x4830 [ 131.992307] ipu_ch_param_read_field 1 29 29 [ 131.992320] imx-ipuv3 280.ipu: EBA1 0x4850 [ 131.992331] ipu_ch_param_read_field 1 102 14 [ 131.992344] imx-ipuv3 280.ipu: Stride 2559 [ 131.992355] ipu_ch_param_read_field 0 113 1 [ 131.992367] imx-ipuv3 280.ipu: scan_order 0 [ 131.992378] ipu_ch_param_read_field 1 128 14 [ 131.992390] imx-ipuv3 280.ipu: uv_stride 0 [ 131.992401] ipu_ch_param_read_field 0 46 22 [ 131.992413] imx-ipuv3 280.ipu: u_offset 0x0 [ 131.992425] ipu_ch_param_read_field 0 68 22 [ 131.992438] imx-ipuv3 280.ipu: v_offset 0x0 [ 131.992448] ipu_ch_param_read_field 1 116 3 [ 131.992460] imx-ipuv3 280.ipu: Width0 0+1, [ 131.992472] ipu_ch_param_read_field 1 119 3 [ 131.992485] imx-ipuv3 280.ipu: Width1 0+1, [ 131.992496] ipu_ch_param_read_field 1 122 3 [ 131.992509] imx-ipuv3 280.ipu: Width2 0+1, [ 131.992519] ipu_ch_param_read_field 1 125 3 [ 131.992531] imx-ipuv3 280.ipu: Width3 0+1, [ 131.992543] ipu_ch_param_read_field 1 128 5 [ 131.992556] imx-ipuv3 280.ipu: Offset0 0, [ 131.992566] ipu_ch_param_read_field 1 133 5 [ 131.992579] imx-ipuv3 280.ipu: Offset1 0, [ 131.992589] ipu_ch_param_read_field 1 138 5 [ 131.992602] imx-ipuv3 280.ipu: Offset2 0, [ 131.992613] ipu_ch_param_read_field 1 143 5 [ 131.992626] imx-ipuv3 280.ipu: Offset3 0 [ 131.992641] imx-ipuv3 280.ipu: IPU_CONF =0x0102 [ 131.992654] imx-ipuv3 280.ipu: IDMAC_CONF = 0x002F [ 131.992667] imx-ipuv3 280.ipu: IDMAC_CHA_EN1 = 0x0008 [ 131.992679] imx-ipuv3 280.ipu: IDMAC_CHA_EN2 = 0x [ 131.992691] imx-ipuv3 280.ipu: IDMAC_CHA_PRI1 = 0x0008 [ 131.992704] imx-ipuv3 280.ipu: IDMAC_CHA_PRI2 = 0x [ 131.992718] imx-ipuv3 280.ipu: IDMAC_BAND_EN1 = 0x [ 131.992731] imx-ipuv3 280.ipu: IDMAC_BAND_EN2 = 0x [ 131.992743] imx-ipuv3 280.ipu: IPU_CHA_DB_MODE_SEL0 =0x0008 [ 131.992756] imx-ipuv3 280.ipu: IPU_CHA_DB_MODE_SEL1 =0x [ 131.992769] imx-ipuv3 280.ipu: IPU_FS_PROC_FLOW1 = 0x [ 131.992782] imx-ipuv3 280.ipu: IPU_FS_PROC_FLOW2 = 0x [ 131.992794] imx-ipuv3 280.ipu: IPU_FS_PROC_FLOW3 = 0x [ 131.992806] imx-ipuv3 280.ipu: IPU_FS_D
HDMI input on i.MX6 using IPU
Hi,
I have modified both Steve's and Philipp's code, in order to get
something able to get frames from an ADV7611.
Right now, I am back to Philipp's base of code, rebased on top of
media-tree, and everything works fine, except the very last link
between SFMC and IDMAC (using media controller).
Here is a status.
The code is here :
https://github.com/Vodalys/linux-2.6-imx/tree/media-tree-zabel
I am using a DT with this simple connection between adv7611 and IPU :
&ipu1_csi0 {
csi0_from_hdmi: endpoint {
remote-endpoint = <&hdmi0_out>;
};
};
hdmiin1: adv7611@4c {
compatible = "adi,adv7611";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_csi0>;
reset-gpios = <&gpio1 20 GPIO_ACTIVE_LOW>;
reg = <0x4c 0x68 0x66 0x64 0x62
0x60 0x5e 0x5c 0x5a 0x58 0x56
0x54 0x52>;
reg-names = "main", "avlink", "cec", "infoframe", "esdp",
"dpp", "afe", "rep", "edid", "hdmi", "test",
"cp", "vdp";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
};
port@1 {
reg = <1>;
hdmi0_out: endpoint@1 {
remote-endpoint = <&csi0_from_hdmi>;
bus-width = <16>;
};
};
};
};
It seems to be pretty good, I can configure mbus format, etc.
$> media-ctl -v --set-v4l2 '"adv7611 1-004c":1 [fmt: YUYV/1280x720]
Opening media device /dev/media0
Enumerating entities
Found 33 entities
Enumerating pads and links
Setting up format YUYV 1280x720 on pad adv7611 1-004c/1
Format set: YUYV 1280x720
Setting up format YUYV 1280x720 on pad /soc/ipu@0240/port@0/0
Format set: YUYV 1280x720
Here is the complete topology right now.
Device topology
- entity 1: /soc/ipu@0240/port@0 (5 pads, 10 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev0
pad0: Sink
[fmt:YUYV/1280x720]
<- "adv7611 1-004c":1 [ENABLED,IMMUTABLE]
pad1: Source
[fmt:unknown/0x0]
-> "IPU0 SMFC0":0 [ENABLED]
-> "IPU0 SMFC1":0 []
-> "IPU0 SMFC2":0 []
-> "IPU0 SMFC3":0 []
-> "IPU0 IC PRP":0 []
-> "IPU0 VDIC":0 []
pad2: Source
[fmt:unknown/0x0]
-> "IPU0 SMFC0":0 []
pad3: Source
[fmt:unknown/0x0]
-> "IPU0 SMFC0":0 []
pad4: Source
[fmt:unknown/0x0]
-> "IPU0 SMFC0":0 []
- entity 2: imx-ipuv3-camera.2 (1 pad, 9 links)
type Node subtype V4L flags 0
device node name /dev/video0
pad0: Sink
<- "IPU0 SMFC0":1 []
<- "IPU0 SMFC1":1 []
<- "IPU0 SMFC2":1 []
<- "IPU0 SMFC3":1 []
<- "IPU0 IC PRP":1 []
<- "IPU0 IC PRP ENC":1 []
<- "IPU0 IC PRP VF":1 []
<- "IPU0 IRT ENC":1 []
<- "IPU0 IRT VF":1 []
- entity 3: /soc/ipu@0240/port@1 (5 pads, 9 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev1
pad0: Sink
[fmt:unknown/0x0]
pad1: Source
[fmt:unknown/0x0]
-> "IPU0 SMFC0":0 []
-> "IPU0 SMFC1":0 []
-> "IPU0 SMFC2":0 [ENABLED]
-> "IPU0 SMFC3":0 []
-> "IPU0 IC PRP":0 []
-> "IPU0 VDIC":0 []
pad2: Source
[fmt:unknown/0x0]
-> "IPU0 SMFC0":0 []
pad3: Source
[fmt:unknown/0x0]
-> "IPU0 SMFC0":0 []
pad4: Source
[fmt:unknown/0x0]
-> "IPU0 SMFC0":0 []
- entity 4: imx-ipuv3-camera.3 (1 pad, 9 links)
type Node subtype V4L flags 0
device node name /dev/video1
pad0: Sink
<- "IPU0 SMFC0":1 []
<- "IPU0 SMFC1":1 []
<- "IPU0 SMFC2":1 []
<- "IPU0 SMFC3":1 []
<- "IPU0 IC PRP":1 []
<- "IPU0 IC PRP ENC":1 []
<- "IPU0 IC PRP VF":1 []
<- "IPU0 IRT ENC":1 []
<- "IPU0 IRT VF":1 []
- entity 5: IPU0 SMFC0 (2 pads, 15 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev2
pad0: Sink
<- "/soc/ipu@0240/port@0":1 [ENABLED]
<- "/soc/ipu@0240/port@0":2 []
<- "/soc/ipu@0240/port@0":3 []
<- "/soc/ipu@0240/port@0":4 []
<- "/soc/ipu@0240/port@1":1 []
<- "/soc/ipu@0240/port@1":2 []
<- "/soc/ipu@0240/port@1":3 []
<- "/soc/ipu@0240/port@1":4 []
pad1: Source
-> "IPU0 IC PRP":0 []
-> "IPU0 IC PP":0 []
-> "IPU0 IRT ENC":0 []
-> "IPU0 IRT VF":0 []
-> "IPU0 IRT PP":0 []
-> "imx-ipuv3-camera.3":0 []
-> "imx-ipuv3-camera.2":0 []
- entity 6: IPU0 SMFC1 (2 pads, 6 links)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev3
pad0: Sink
<- "/soc/ipu@0240/port@0":1 []
<- "/soc/ipu@0240/port@1":1 []
pad1: Source
-> "IPU0 IRT ENC":0 []
-> "IPU0 IRT VF":0 []
-> "imx-ipuv3-cam
Re: [PATCH] adv7604: Add DT parsing support
Hi, 2014-10-27 0:30 GMT+01:00 Laurent Pinchart : > Hi Jean-Michel, > > On Thursday 23 October 2014 07:51:50 Jean-Michel Hautbois wrote: >> 2014-10-23 1:53 GMT+02:00 Laurent Pinchart: >> > On Wednesday 22 October 2014 17:34:21 Jean-Michel Hautbois wrote: >> >> This patch adds support for DT parsing of ADV7604 as well as ADV7611. >> >> It needs to be improved in order to get ports parsing too. >> > >> > Let's improve it then :-) The DT bindings as proposed by this patch are >> > incomplete, that's just asking for trouble. >> > >> > How would you model the adv7604 ports ? >> >> I am opened to suggestions :). >> But it has to remain as simple as possible, ideally allowing for giving >> names to the ports. >> As done today, it works, ports are parsed but are all the same... > > The ADV7611 was easy, it had a single HDMI input only. The ADV7612 is easy as > well as it just has two separate HDMI inputs. > > The ADV7604 is a more complex beast. The HDMI inputs shouldn't be much of an > issue as they're independent and multiplexed internally. You can just create > one pad per HDMI input. > > The analog inputs, however, can't be modeled as easily. A naive approach would > be to create one pad for each of the 12 analog inputs, but the chip has three > separate ADCs and can combine 3 inputs in a single digital video stream. I > don't know how we should model support for that. Lars-Peter, Hans, would you > have a revolutionary idea to same the world today ? I get back to working on this specific part, but I don't know how these analog inputs should be modeled. On page 68 of ADV7604_HW_RevF there is Figure 11 showing typical configurations using AIN_SEL[2:0]. I can see 4 inputs muxed : this would suggest to have 4 pads for analog inputs. Not sure it makes sense though... Thanks, JM -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] media: spi: Add support for LMH0395
Hi Laurent,
Thanks for the review.
2014-11-03 14:13 GMT+01:00 Laurent Pinchart :
> Hi Jean-Michel,
>
> Thank you for the patch.
>
> On Wednesday 10 September 2014 11:43:54 Jean-Michel Hautbois wrote:
>> This device is a SPI based device from TI.
>> It is a 3 Gbps HD/SD SDI Dual Output Low Power
>> Extended Reach Adaptive Cable Equalizer.
>>
>> LMH0395 enables the use of up to two outputs.
>> These can be configured using DT.
>>
>> Controls should be accessible from userspace too.
>> This will have to be done later.
>>
>> v2: Add DT support
>> v3: Change the bit set/clear in output_type as disabled means 'set the bit'
>> v4: Clearer description of endpoints usage in Doc, and some init changes.
>> Add a dependency on OF and don't test CONFIG_OF anymore.
>>
>> Signed-off-by: Jean-Michel Hautbois
>> ---
>> .../devicetree/bindings/media/spi/lmh0395.txt | 48 +++
>> MAINTAINERS| 6 +
>> drivers/media/spi/Kconfig | 14 +
>> drivers/media/spi/Makefile | 1 +
>> drivers/media/spi/lmh0395.c| 354 ++
>> 5 files changed, 423 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/media/spi/lmh0395.txt
>> create mode 100644 drivers/media/spi/Kconfig
>> create mode 100644 drivers/media/spi/Makefile
>> create mode 100644 drivers/media/spi/lmh0395.c
>>
>> diff --git a/Documentation/devicetree/bindings/media/spi/lmh0395.txt
>> b/Documentation/devicetree/bindings/media/spi/lmh0395.txt new file mode
>> 100644
>> index 000..7cc0026
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/spi/lmh0395.txt
>> @@ -0,0 +1,48 @@
>> +* Texas Instruments lmh0395 3G HD/SD SDI equalizer
>> +
>> +The LMH0395 3 Gbps HD/SD SDI Dual Output Low Power Extended Reach Adaptive
>> +Cable Equalizer is designed to equalize data transmitted over cable (or any
>> +media with similar dispersive loss characteristics).
>> +The equalizer operates over a wide range of data rates from 125 Mbps to
>> 2.97 Gbps
>> +and supports SMPTE 424M, SMPTE 292M, SMPTE344M, SMPTE 259M, and DVB-ASI
>> standards.
>
> That's copied verbatim from the datasheet and not very relevant from a DT
> bindings point of view. I would rather explain what the chip does. Something
> like
>
> "The LMH0395 is an SDI equalizer designed to extend the reach of SDI signals
> transmitted over cable by equalizing the input signal and generating clean
> outputs. It has one differential input and two differential output that can be
> independently controlled."
OK, applied.
>> +
>> +Required Properties :
>> +- compatible: Must be "ti,lmh0395"
>> +
>> +The device node must contain one 'port' child node per device input and
>> output
>> +port, in accordance with the video interface bindings defined in
>> +Documentation/devicetree/bindings/media/video-interfaces.txt. The port
>> nodes
>> +are numbered as follows.
>> +
>> + Port LMH0395
>> +
>> + SDI input 0
>> + SDI output 1,2
>
> While there shouldn't be much doubt about SDO0 corresponding to port 1 and
> SDO1 to port 2, I'd like that to be mentioned explicitly.
>
> The device node must contain one 'port' child node per device input and output
> port, in accordance with the video interface bindings defined in
> Documentation/devicetree/bindings/media/video-interfaces.txt.
>
> The LMH0395 has three ports numbered as follows.
>
> DescriptionNumber
>
> SDI (SDI input) 0
> SDO0 (SDI output 0) 1
> SDO1 (SDI output 1) 2
OK.
>> +Example:
>> +
>> +ecspi@0201 {
>> + ...
>> + ...
>> +
>> + lmh0395@1 {
>> + compatible = "ti,lmh0395";
>> + reg = <1>;
>> + spi-max-frequency = <2000>;
>> + ports {
>
> You need to add
>
> #address-cells = <1>;
> #size-cells = <0>;
>
> here.
>
Of course, applied.
>> + port@0 {
>> + reg = <0>;
>> + sdi0_in: endpoint {};
>> + };
>> + port@1 {
>> + reg = <1>;
>> +
Re: HDMI input on i.MX6 using IPU
Hi, 2015-01-08 17:53 GMT+01:00 Jean-Michel Hautbois : > Hi, > > I have modified both Steve's and Philipp's code, in order to get > something able to get frames from an ADV7611. > Right now, I am back to Philipp's base of code, rebased on top of > media-tree, and everything works fine, except the very last link > between SFMC and IDMAC (using media controller). > Here is a status. > > The code is here : > https://github.com/Vodalys/linux-2.6-imx/tree/media-tree-zabel Right now, I can go further. I added support for BT.1120 in order to get the correct video format, and I am able to start a streaming, but I can't get an interrupt on IDMAC. I am starting with setting DV timings on adv7611 input, and then, I am using 4l2-compliance in order to test streaming. It has shown several things, most of them are corrected, sometimes in a hacky way. Right now, I can do the following : $> media-ctl --set-dv '"adv7611 1-004c":1 [fmt:YUYV/1280x720]' && media-ctl --set-v4l2 '"adv7611 1-004c":1 [fmt:YUYV/1280x720]' $> echo -n 'module imx_ipuv3_csi +p' > /sys/kernel/debug/dynamic_debug/control $> v4l2-compliance -v -s Driver Info: Driver name : imx-ipuv3-csi Card type : imx-ipuv3-camera Bus info : platform:imx-ipuv3-csi Driver version: 3.19.0 Capabilities : 0x8421 Video Capture Streaming Extended Pix Format Device Capabilities Device Caps : 0x0421 Video Capture Streaming Extended Pix Format Compliance test for device /dev/video0 (not using libv4l2): Required ioctls: test VIDIOC_QUERYCAP: OK Allow for multiple opens: test second video open: OK test VIDIOC_QUERYCAP: OK test VIDIOC_G/S_PRIORITY: OK Debug ioctls: test VIDIOC_DBG_G/S_REGISTER: OK test VIDIOC_LOG_STATUS: OK Input ioctls: test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) test VIDIOC_ENUMAUDIO: OK (Not Supported) test VIDIOC_G/S/ENUMINPUT: OK (Not Supported) test VIDIOC_G/S_AUDIO: OK (Not Supported) Inputs: 0 Audio Inputs: 0 Tuners: 0 Output ioctls: test VIDIOC_G/S_MODULATOR: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_ENUMAUDOUT: OK (Not Supported) test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) test VIDIOC_G/S_AUDOUT: OK (Not Supported) Outputs: 0 Audio Outputs: 0 Modulators: 0 Input/Output configuration ioctls: test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported) test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) test VIDIOC_G/S_EDID: OK (Not Supported) Control ioctls: info: checking v4l2_queryctrl of control 'User Controls' (0x00980001) info: checking v4l2_queryctrl of control 'Brightness' (0x00980900) info: checking v4l2_queryctrl of control 'Contrast' (0x00980901) info: checking v4l2_queryctrl of control 'Saturation' (0x00980902) info: checking v4l2_queryctrl of control 'Hue' (0x00980903) info: checking v4l2_queryctrl of control 'Image Processing Controls' (0x009f0001) info: checking v4l2_queryctrl of control 'Test Pattern' (0x009f0903) info: checking v4l2_queryctrl of control 'Brightness' (0x00980900) info: checking v4l2_queryctrl of control 'Contrast' (0x00980901) info: checking v4l2_queryctrl of control 'Saturation' (0x00980902) info: checking v4l2_queryctrl of control 'Hue' (0x00980903) test VIDIOC_QUERYCTRL/MENU: OK info: checking control 'User Controls' (0x00980001) info: checking control 'Brightness' (0x00980900) info: checking control 'Contrast' (0x00980901) info: checking control 'Saturation' (0x00980902) info: checking control 'Hue' (0x00980903) info: checking control 'Image Processing Controls' (0x009f0001) info: checking control 'Test Pattern' (0x009f0903) test VIDIOC_G/S_CTRL: OK info: checking extended control 'User Controls' (0x00980001) info: checking extended control 'Brightness' (0x00980900) info: checking extended control 'Contrast' (0x00980901) info: checking extended control 'Saturation' (0x00980902) info: checking extended control 'Hue' (0x00980903) info: checking extended control 'Image Processing Controls' (0x009f0001) info: checking extended control 'Test Pattern' (0x009f0903) test VIDIOC_G/S/TRY_EXT_CTRLS: OK info: checking control event 'User Con
[PATCH] media: adv7604: CP CSC uses a different register on adv7604 and adv7611
The bits are the same, but register is 0xf4 on ADV7611 instead of 0xfc. When reading back the value in log_status, differentiate both. Signed-off-by: Jean-Michel Hautbois --- drivers/media/i2c/adv7604.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c index e43dd2e..32e53e0 100644 --- a/drivers/media/i2c/adv7604.c +++ b/drivers/media/i2c/adv7604.c @@ -2310,8 +2310,12 @@ static int adv7604_log_status(struct v4l2_subdev *sd) (reg_io_0x02 & 0x04) ? "(16-235)" : "(0-255)", ((reg_io_0x02 & 0x04) ^ (reg_io_0x02 & 0x01)) ? "enabled" : "disabled"); - v4l2_info(sd, "Color space conversion: %s\n", + if (state->info->type == ADV7604) + v4l2_info(sd, "Color space conversion: %s\n", csc_coeff_sel_rb[cp_read(sd, 0xfc) >> 4]); + else + v4l2_info(sd, "Color space conversion: %s\n", + csc_coeff_sel_rb[cp_read(sd, 0xf4) >> 4]); if (!is_digital_input(sd)) return 0; -- 2.2.2 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] Add ability to read default input port from DT
2015-01-29 17:19 GMT+01:00 William Towle : > From: Ian Molton > > --- > Documentation/devicetree/bindings/media/i2c/adv7604.txt |3 +++ > drivers/media/i2c/adv7604.c |8 +++- > 2 files changed, 10 insertions(+), 1 deletion(-) Is this really passing through checkpatch ? Without a proper signed-off-by ? > diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt > b/Documentation/devicetree/bindings/media/i2c/adv7604.txt > index c27cede..bc50da2 100644 > --- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt > +++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt > @@ -33,6 +33,9 @@ Optional Properties: > >- reset-gpios: Reference to the GPIO connected to the device's reset pin. > > + - default-input: Reference to the chip's default input port. This value > +should match the pad number for the intended device > + > Optional Endpoint Properties: > >The following three properties are defined in video-interfaces.txt and are > diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c > index e43dd2e..803 100644 > --- a/drivers/media/i2c/adv7604.c > +++ b/drivers/media/i2c/adv7604.c > @@ -2686,6 +2686,7 @@ static int adv7604_parse_dt(struct adv7604_state *state) > struct device_node *endpoint; > struct device_node *np; > unsigned int flags; > + u32 v; Could be named default_input ? > np = state->i2c_clients[ADV7604_PAGE_IO]->dev.of_node; > > @@ -2695,6 +2696,12 @@ static int adv7604_parse_dt(struct adv7604_state > *state) > return -EINVAL; > > v4l2_of_parse_endpoint(endpoint, &bus_cfg); > + > + if (!of_property_read_u32(endpoint, "default-input", &v)) > + state->pdata.default_input = v; > + else > + state->pdata.default_input = -1; > + OK, so, whatever the value I put in DT, it will be put in the pdata ? No test against max_port ? > of_node_put(endpoint); > > flags = bus_cfg.bus.parallel.flags; > @@ -2733,7 +2740,6 @@ static int adv7604_parse_dt(struct adv7604_state *state) > /* Hardcode the remaining platform data fields. */ > state->pdata.disable_pwrdnb = 0; > state->pdata.disable_cable_det_rst = 0; > - state->pdata.default_input = -1; > state->pdata.blank_data = 1; > state->pdata.alt_data_sat = 1; > state->pdata.op_format_mode_sel = ADV7604_OP_FORMAT_MODE0; > -- > 1.7.10.4 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html JM -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/8] WmT: m-5mols_core style pad handling for adv7604
First of all, this subject puzzles me... What means WmT ??
2015-01-29 17:19 GMT+01:00 William Towle :
> ---
> drivers/media/i2c/adv7604.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
Again, it it passing checkpatch without signed-off-by ? And a little
description does not hurt :).
> diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
> index 30bbd9d..6ed9303 100644
> --- a/drivers/media/i2c/adv7604.c
> +++ b/drivers/media/i2c/adv7604.c
> @@ -1976,7 +1976,11 @@ static int adv7604_get_format(struct v4l2_subdev *sd,
> struct v4l2_subdev_fh *fh,
> if (format->which == V4L2_SUBDEV_FORMAT_TRY) {
> struct v4l2_mbus_framefmt *fmt;
>
> - fmt = v4l2_subdev_get_try_format(fh, format->pad);
> + fmt = (fh == NULL) ? NULL
> + : v4l2_subdev_get_try_format(fh, format->pad);
> + if (fmt == NULL)
> + return EINVAL;
> +
Mmmh, Hans probably has an explanation on this, I just don't get a use
case where fh can be NULL... So can't see the point of this patch ?
> format->format.code = fmt->code;
> } else {
> format->format.code = state->format->code;
> @@ -2008,7 +2012,11 @@ static int adv7604_set_format(struct v4l2_subdev *sd,
> struct v4l2_subdev_fh *fh,
> if (format->which == V4L2_SUBDEV_FORMAT_TRY) {
> struct v4l2_mbus_framefmt *fmt;
>
> - fmt = v4l2_subdev_get_try_format(fh, format->pad);
> + fmt = (fh == NULL) ? NULL
> + : v4l2_subdev_get_try_format(fh, format->pad);
> + if (fmt == NULL)
> + return -EINVAL;
> +
> fmt->code = format->format.code;
> } else {
> state->format = info;
Same comment as above.
Thanks,
JM
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: i2c: ADV7604: Migrate to regmap
This is a preliminary patch in order to add support for ALSA.
It replaces all current i2c access with regmap.
Add the registers which will then be used too, as these are declared at init.
Signed-off-by: Pablo Anton
Signed-off-by: Jean-Michel Hautbois
---
drivers/media/i2c/adv7604.c | 428 +---
include/media/adv7604.h | 129 +
2 files changed, 455 insertions(+), 102 deletions(-)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index e43dd2e..af19544 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -43,6 +43,8 @@
#include
#include
+#include
+
static int debug;
module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, "debug level (0-2)");
@@ -165,6 +167,9 @@ struct adv7604_state {
/* i2c clients */
struct i2c_client *i2c_clients[ADV7604_PAGE_MAX];
+ /* Regmaps */
+ struct regmap *regmap[ADV7604_PAGE_MAX];
+
/* controls */
struct v4l2_ctrl *detect_tx_5v_ctrl;
struct v4l2_ctrl *analog_sampling_phase_ctrl;
@@ -353,84 +358,53 @@ static inline unsigned vtotal(const struct
v4l2_bt_timings *t)
return V4L2_DV_BT_FRAME_HEIGHT(t);
}
-/* --- */
-
-static s32 adv_smbus_read_byte_data_check(struct i2c_client *client,
- u8 command, bool check)
-{
- union i2c_smbus_data data;
-
- if (!i2c_smbus_xfer(client->adapter, client->addr, client->flags,
- I2C_SMBUS_READ, command,
- I2C_SMBUS_BYTE_DATA, &data))
- return data.byte;
- if (check)
- v4l_err(client, "error reading %02x, %02x\n",
- client->addr, command);
- return -EIO;
-}
-
-static s32 adv_smbus_read_byte_data(struct adv7604_state *state,
- enum adv7604_page page, u8 command)
-{
- return adv_smbus_read_byte_data_check(state->i2c_clients[page],
- command, true);
-}
-
-static s32 adv_smbus_write_byte_data(struct adv7604_state *state,
-enum adv7604_page page, u8 command,
-u8 value)
+static int regmap_read_check(struct adv7604_state *state,
+int client_page, u8 reg)
{
- struct i2c_client *client = state->i2c_clients[page];
- union i2c_smbus_data data;
+ struct i2c_client *client = state->i2c_clients[client_page];
int err;
- int i;
+ unsigned int val;
- data.byte = value;
- for (i = 0; i < 3; i++) {
- err = i2c_smbus_xfer(client->adapter, client->addr,
- client->flags,
- I2C_SMBUS_WRITE, command,
- I2C_SMBUS_BYTE_DATA, &data);
- if (!err)
- break;
+ err = regmap_read(state->regmap[client_page], reg, &val);
+
+ if (err) {
+ v4l_err(client, "error reading %02x, %02x\n",
+ client->addr, reg);
+ return err;
}
- if (err < 0)
- v4l_err(client, "error writing %02x, %02x, %02x\n",
- client->addr, command, value);
- return err;
+ return val;
}
-static s32 adv_smbus_write_i2c_block_data(struct adv7604_state *state,
- enum adv7604_page page, u8 command,
- unsigned length, const u8 *values)
+/* regmap_write_block(): Write raw data with a maximum of I2C_SMBUS_BLOCK_MAX
+ * size to one or more registers.
+ *
+ * A value of zero will be returned on success, a negative errno will
+ * be returned in error cases.
+ */
+static int regmap_write_block(struct adv7604_state *state, int client_page,
+ unsigned int init_reg, const void *val,
+ size_t val_len)
{
- struct i2c_client *client = state->i2c_clients[page];
- union i2c_smbus_data data;
+ struct regmap *regmap = state->regmap[client_page];
- if (length > I2C_SMBUS_BLOCK_MAX)
- length = I2C_SMBUS_BLOCK_MAX;
- data.block[0] = length;
- memcpy(data.block + 1, values, length);
- return i2c_smbus_xfer(client->adapter, client->addr, client->flags,
- I2C_SMBUS_WRITE, command,
- I2C_SMBUS_I2C_BLOCK_DATA, &data);
-}
+ if (val_len > I2C_SMBUS_BLOCK_MAX)
+ val_len = I2C_SMBUS_BLOCK_MAX;
-/* --- */
+ return regmap_raw_write(regmap, init_reg, val, val_len);
+}
static inline int io_read(struct
Re: [PATCH] media: i2c: ADV7604: Rename adv7604 prefixes.
Hi Hans, and thanks for reviewing.
2015-02-04 10:55 GMT+01:00 Hans Verkuil :
> On 02/03/15 18:13, Pablo Anton wrote:
>> It is confusing which parts of the driver are adv7604 specific, adv7611
>> specific or common for both.
>> This patch renames any adv7604 prefixes (both for functions and defines) to
>> adv76xx whenever they are common.
>>
>> Signed-off-by: Pablo Anton
>> Signed-off-by: Jean-Michel Hautbois
>
> I'm happy with this, except for three small changes:
>
> - I had to rebase
Sorry about that, not the media-tree used for implementing it but vanilla...
> - ADV76xx_fsc should be ADV76XX_FSC
> - The driver name should stay the same to keep in sync with the module name.
> Besides, we might have a future driver for the adv7622/3, so adv76xx as the
> driver name is potentially confusing.
>
> I've applied these changes and the updated patch is below. If possible I
> would like to get this in 3.20 so future patches for 3.21 can all be based
> on these renamed functions/defines.
OK for me, it makes sense to keep the driver name as is.
JM
> Acks from Lars and Laurent would be welcome, though.
>
> Regards,
>
> Hans
>
> From bff6f026de4fe276f99be6ca38206720659938dc Mon Sep 17 00:00:00 2001
> From: Pablo Anton
> Date: Tue, 3 Feb 2015 18:13:18 +0100
> Subject: [PATCH] media: i2c: ADV7604: Rename adv7604 prefixes.
>
> It is confusing which parts of the driver are adv7604 specific, adv7611
> specific or common for both.
> This patch renames any adv7604 prefixes (both for functions and defines) to
> adv76xx whenever they are common.
>
> Signed-off-by: Pablo Anton
> Signed-off-by: Jean-Michel Hautbois
> [hans.verk...@cisco.com: rebased and renamed ADV76xx_fsc to ADV76XX_FSC]
> [hans.verk...@cisco.com: kept the existing adv7604 driver name]
> Signed-off-by: Hans Verkuil
> ---
> drivers/media/i2c/adv7604.c | 898
> ++--
> include/media/adv7604.h | 83 ++--
> 2 files changed, 491 insertions(+), 490 deletions(-)
>
> diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
> index d228b7c..f294c75 100644
> --- a/drivers/media/i2c/adv7604.c
> +++ b/drivers/media/i2c/adv7604.c
> @@ -53,41 +53,41 @@ MODULE_AUTHOR("Mats Randgaard
> ");
> MODULE_LICENSE("GPL");
>
> /* ADV7604 system clock frequency */
> -#define ADV7604_fsc (28636360)
> +#define ADV76XX_FSC (28636360)
>
> -#define ADV7604_RGB_OUT(1 << 1)
> +#define ADV76XX_RGB_OUT(1 << 1)
>
> -#define ADV7604_OP_FORMAT_SEL_8BIT (0 << 0)
> +#define ADV76XX_OP_FORMAT_SEL_8BIT (0 << 0)
> #define ADV7604_OP_FORMAT_SEL_10BIT(1 << 0)
> -#define ADV7604_OP_FORMAT_SEL_12BIT(2 << 0)
> +#define ADV76XX_OP_FORMAT_SEL_12BIT(2 << 0)
>
> -#define ADV7604_OP_MODE_SEL_SDR_422(0 << 5)
> +#define ADV76XX_OP_MODE_SEL_SDR_422(0 << 5)
> #define ADV7604_OP_MODE_SEL_DDR_422(1 << 5)
> -#define ADV7604_OP_MODE_SEL_SDR_444(2 << 5)
> +#define ADV76XX_OP_MODE_SEL_SDR_444(2 << 5)
> #define ADV7604_OP_MODE_SEL_DDR_444(3 << 5)
> -#define ADV7604_OP_MODE_SEL_SDR_422_2X (4 << 5)
> +#define ADV76XX_OP_MODE_SEL_SDR_422_2X (4 << 5)
> #define ADV7604_OP_MODE_SEL_ADI_CM (5 << 5)
>
> -#define ADV7604_OP_CH_SEL_GBR (0 << 5)
> -#define ADV7604_OP_CH_SEL_GRB (1 << 5)
> -#define ADV7604_OP_CH_SEL_BGR (2 << 5)
> -#define ADV7604_OP_CH_SEL_RGB (3 << 5)
> -#define ADV7604_OP_CH_SEL_BRG (4 << 5)
> -#define ADV7604_OP_CH_SEL_RBG (5 << 5)
> +#define ADV76XX_OP_CH_SEL_GBR (0 << 5)
> +#define ADV76XX_OP_CH_SEL_GRB (1 << 5)
> +#define ADV76XX_OP_CH_SEL_BGR (2 << 5)
> +#define ADV76XX_OP_CH_SEL_RGB (3 << 5)
> +#define ADV76XX_OP_CH_SEL_BRG (4 << 5)
> +#define ADV76XX_OP_CH_SEL_RBG (5 << 5)
>
> -#define ADV7604_OP_SWAP_CB_CR (1 << 0)
> +#define ADV76XX_OP_SWAP_CB_CR (1 << 0)
>
> -enum adv7604_type {
> +enum adv76xx_type {
>
[PATCH v2] media: adv7604: CP CSC uses a different register on adv7604 and adv7611
The bits are the same, but register is 0xf4 on ADV7611 instead of 0xfc.
When reading back the value in log_status, differentiate both.
Signed-off-by: Jean-Michel Hautbois
---
v2: Use adv7604_chip_info to get register instead of testing the chip ID
drivers/media/i2c/adv7604.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index e43dd2e..0ee1255 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -109,6 +109,7 @@ struct adv7604_chip_info {
unsigned int cable_det_mask;
unsigned int tdms_lock_mask;
unsigned int fmt_change_digital_mask;
+ unsigned int cp_csc;
const struct adv7604_format_info *formats;
unsigned int nformats;
@@ -2311,7 +2312,7 @@ static int adv7604_log_status(struct v4l2_subdev *sd)
((reg_io_0x02 & 0x04) ^ (reg_io_0x02 & 0x01)) ?
"enabled" : "disabled");
v4l2_info(sd, "Color space conversion: %s\n",
- csc_coeff_sel_rb[cp_read(sd, 0xfc) >> 4]);
+ csc_coeff_sel_rb[cp_read(sd, info->cp_csc) >> 4]);
if (!is_digital_input(sd))
return 0;
@@ -2615,6 +2616,7 @@ static const struct adv7604_chip_info adv7604_chip_info[]
= {
.tdms_lock_mask = 0xe0,
.cable_det_mask = 0x1e,
.fmt_change_digital_mask = 0xc1,
+ .cp_csc = 0xfc,
.formats = adv7604_formats,
.nformats = ARRAY_SIZE(adv7604_formats),
.set_termination = adv7604_set_termination,
@@ -2648,6 +2650,7 @@ static const struct adv7604_chip_info adv7604_chip_info[]
= {
.tdms_lock_mask = 0x43,
.cable_det_mask = 0x01,
.fmt_change_digital_mask = 0x03,
+ .cp_csc = 0xf4,
.formats = adv7611_formats,
.nformats = ARRAY_SIZE(adv7611_formats),
.set_termination = adv7611_set_termination,
--
2.2.2
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: i2c: ADV7604: In free run mode, signal is locked
The CP_NON_STD_VIDEO bit indicates an input not aligned with DV timings.
If there is no input, and chip is in free run mode, consider we are locked.
Signed-off-by: Jean-Michel Hautbois
---
drivers/media/i2c/adv7604.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index e43dd2e..24fb342 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -1329,13 +1329,21 @@ static inline bool no_lock_cp(struct v4l2_subdev *sd)
return io_read(sd, 0x12) & 0x01;
}
+static inline bool in_free_run(struct v4l2_subdev *sd)
+{
+ return cp_read(sd, 0xff) & 0x10;
+}
+
static int adv7604_g_input_status(struct v4l2_subdev *sd, u32 *status)
{
*status = 0;
*status |= no_power(sd) ? V4L2_IN_ST_NO_POWER : 0;
*status |= no_signal(sd) ? V4L2_IN_ST_NO_SIGNAL : 0;
- if (no_lock_cp(sd))
- *status |= is_digital_input(sd) ? V4L2_IN_ST_NO_SYNC :
V4L2_IN_ST_NO_H_LOCK;
+ if (!in_free_run(sd))
+ if (no_lock_cp(sd))
+ *status |= is_digital_input(sd)
+ ? V4L2_IN_ST_NO_SYNC
+ : V4L2_IN_ST_NO_H_LOCK;
v4l2_dbg(1, debug, sd, "%s: status = 0x%x\n", __func__, *status);
@@ -2276,7 +2284,7 @@ static int adv7604_log_status(struct v4l2_subdev *sd)
v4l2_info(sd, "STDI locked: %s\n", no_lock_stdi(sd) ? "false" : "true");
v4l2_info(sd, "CP locked: %s\n", no_lock_cp(sd) ? "false" : "true");
v4l2_info(sd, "CP free run: %s\n",
- (!!(cp_read(sd, 0xff) & 0x10) ? "on" : "off"));
+ (in_free_run(sd)) ? "on" : "off");
v4l2_info(sd, "Prim-mode = 0x%x, video std = 0x%x, v_freq = 0x%x\n",
io_read(sd, 0x01) & 0x0f, io_read(sd, 0x00) & 0x3f,
(io_read(sd, 0x01) & 0x70) >> 4);
--
2.2.2
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 06/32] [media] coda: Add encoder/decoder support for CODA960
Hi, 2014-07-30 14:32 GMT+02:00 Philipp Zabel : > Am Mittwoch, den 30.07.2014, 20:16 +0800 schrieb Shawn Guo: >> On Tue, Jul 29, 2014 at 07:06:25PM +0200, Philipp Zabel wrote: >> > > I followed the step to generate the firmware v4l-coda960-imx6q, and >> > > tested it on next-20140725 with patch 'ARM: dts: imx6qdl: Enable CODA960 >> > > VPU' applied on top of it. But I got the error of 'Wrong firmwarel' as >> > > below. >> > > >> > > [2.582837] coda 204.vpu: requesting firmware >> > > 'v4l-coda960-imx6q.bin' for CODA960 >> > > [2.593344] coda 204.vpu: Firmware code revision: 0 >> > > [2.598649] coda 204.vpu: Wrong firmware. Hw: CODA960, Fw: >> > > (0x), Version: 0.0.0 >> > >> > I just tried with the same kernel, and the above download, converted >> > with the program in the referenced mail, and I get this: >> > >> > coda 204.vpu: Firmware code revision: 36350 >> > coda 204.vpu: Initialized CODA960. >> > coda 204.vpu: Unsupported firmware version: 2.1.9 >> > coda 204.vpu: codec registered as /dev/video0 >> >> Okay, the reason I'm running into the issue is that I'm using the FSL >> U-Boot which turns off VDDPU at initialization. > > In that case you need to also apply the "Generic Device Tree based power > domain look-up" and "i.MX6 PU power domain support series". I'll have to > check the current state of that. I am having the same issue with firmware 3.1.1 and can't find version 2.1.5. Is there a way to make it work ? Does anybody has news from Freescale and official support for firmwares in mainline ? This is (as Robert Schwebel said) unusable with a recent kernel, and that's a shame... Thx, JM -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[media] CODA960: Fails to allocate memory
Hi,
I am trying to use the CODA960 driver on a 3.18 kernel.
It seems pretty good when the module is probed (appart from the
unsupported firmware version) but when I try using the encoder, it
fails allocating dma buffers.
Here is the DT part I added :
&vpu {
compatible = "fsl,imx6q-vpu";
clocks = <&clks 168>, <&clks 140>, <&clks 142>;
clock-names = "per", "ahb", "ocram";
iramsize = <0x21000>;
iram = <&ocram>;
resets = <&src 1>;
status = "okay";
};
When booting, I see :
[4.410645] coda 204.vpu: Firmware code revision: 46056
[4.416312] coda 204.vpu: Initialized CODA960.
[4.421123] coda 204.vpu: Unsupported firmware version: 3.1.1
[4.483577] coda 204.vpu: codec registered as /dev/video[0-1]
I can start v4l2-ctl and it shows that the device seems to be ok :
v4l2-ctl --all -d /dev/video1
Driver Info (not using libv4l2):
Driver name : coda
Card type : CODA960
Bus info : platform:coda
Driver version: 3.18.0
Capabilities : 0x84208000
Video Memory-to-Memory
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04208000
Video Memory-to-Memory
Streaming
Extended Pix Format
Priority: 2
Format Video Capture:
Width/Height : 1920/1088
Pixel Format : 'YU12'
Field : None
Bytes per Line: 1920
Size Image: 3133440
Colorspace: HDTV and modern devices (ITU709)
Flags :
Format Video Output:
Width/Height : 1920/1088
Pixel Format : 'H264'
Field : None
Bytes per Line: 0
Size Image: 1048576
Colorspace: HDTV and modern devices (ITU709)
Flags :
Selection: compose, Left 0, Top 0, Width 1920, Height 1088
Selection: compose_default, Left 0, Top 0, Width 1920, Height 1088
Selection: compose_bounds, Left 0, Top 0, Width 1920, Height 1088
Selection: compose_padded, Left 0, Top 0, Width 1920, Height 1088
Selection: crop, Left 0, Top 0, Width 1920, Height 1088
Selection: crop_default, Left 0, Top 0, Width 1920, Height 1088
Selection: crop_bounds, Left 0, Top 0, Width 1920, Height 1088
User Controls
horizontal_flip (bool) : default=0 value=0
vertical_flip (bool) : default=0 value=0
Codec Controls
video_gop_size (int): min=1 max=60 step=1
default=16 value=16
video_bitrate (int): min=0 max=32767000 step=1
default=0 value=0
number_of_intra_refresh_mbs (int): min=0 max=8160 step=1
default=0 value=0
sequence_header_mode (menu) : min=0 max=1 default=1 value=1
maximum_bytes_in_a_slice (int): min=1 max=1073741823 step=1
default=500 value=500
number_of_mbs_in_a_slice (int): min=1 max=1073741823 step=1
default=1 value=1
slice_partitioning_method (menu) : min=0 max=2 default=0 value=0
h264_i_frame_qp_value (int): min=0 max=51 step=1
default=25 value=25
h264_p_frame_qp_value (int): min=0 max=51 step=1
default=25 value=25
h264_maximum_qp_value (int): min=0 max=51 step=1
default=51 value=51
h264_loop_filter_alpha_offset (int): min=0 max=15 step=1 default=0 value=0
h264_loop_filter_beta_offset (int): min=0 max=15 step=1 default=0 value=0
h264_loop_filter_mode (menu) : min=0 max=1 default=0 value=0
mpeg4_i_frame_qp_value (int): min=1 max=31 step=1 default=2 value=2
mpeg4_p_frame_qp_value (int): min=1 max=31 step=1 default=2 value=2
horizontal_flip (bool) : default=0 value=0
vertical_flip (bool) : default=0 value=0
But when I try to get a file outputed, it fails :
v4l2-ctl -d1 --stream-out-mmap --stream-mmap --stream-to x.raw
[ 1197.292256] coda 204.vpu: dma_alloc_coherent of size 1048576 failed
VIDIOC_REQBUFS: failed: Cannot allocate memory
Did I forget to do something ?
Thanks,
JM
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [media] CODA960: Fails to allocate memory
Hi Hans,
2014-10-21 15:27 GMT+02:00 Hans Verkuil :
>
>
> On 10/21/2014 03:16 PM, Jean-Michel Hautbois wrote:
>>
>> Hi,
>>
>> I am trying to use the CODA960 driver on a 3.18 kernel.
>> It seems pretty good when the module is probed (appart from the
>> unsupported firmware version) but when I try using the encoder, it
>> fails allocating dma buffers.
>>
>> Here is the DT part I added :
>> &vpu {
>> compatible = "fsl,imx6q-vpu";
>> clocks = <&clks 168>, <&clks 140>, <&clks 142>;
>> clock-names = "per", "ahb", "ocram";
>> iramsize = <0x21000>;
>> iram = <&ocram>;
>> resets = <&src 1>;
>> status = "okay";
>> };
>>
>> When booting, I see :
>> [4.410645] coda 204.vpu: Firmware code revision: 46056
>> [4.416312] coda 204.vpu: Initialized CODA960.
>> [4.421123] coda 204.vpu: Unsupported firmware version: 3.1.1
>> [4.483577] coda 204.vpu: codec registered as /dev/video[0-1]
>>
>> I can start v4l2-ctl and it shows that the device seems to be ok :
>> v4l2-ctl --all -d /dev/video1
>> Driver Info (not using libv4l2):
>> Driver name : coda
>> Card type : CODA960
>> Bus info : platform:coda
>> Driver version: 3.18.0
>> Capabilities : 0x84208000
>> Video Memory-to-Memory
>> Streaming
>> Extended Pix Format
>> Device Capabilities
>> Device Caps : 0x04208000
>> Video Memory-to-Memory
>> Streaming
>> Extended Pix Format
>> Priority: 2
>> Format Video Capture:
>> Width/Height : 1920/1088
>> Pixel Format : 'YU12'
>> Field : None
>> Bytes per Line: 1920
>> Size Image: 3133440
>> Colorspace: HDTV and modern devices (ITU709)
>> Flags :
>> Format Video Output:
>> Width/Height : 1920/1088
>> Pixel Format : 'H264'
>> Field : None
>> Bytes per Line: 0
>> Size Image: 1048576
>> Colorspace: HDTV and modern devices (ITU709)
>> Flags :
>> Selection: compose, Left 0, Top 0, Width 1920, Height 1088
>> Selection: compose_default, Left 0, Top 0, Width 1920, Height 1088
>> Selection: compose_bounds, Left 0, Top 0, Width 1920, Height 1088
>> Selection: compose_padded, Left 0, Top 0, Width 1920, Height 1088
>> Selection: crop, Left 0, Top 0, Width 1920, Height 1088
>> Selection: crop_default, Left 0, Top 0, Width 1920, Height 1088
>> Selection: crop_bounds, Left 0, Top 0, Width 1920, Height 1088
>>
>> User Controls
>>
>> horizontal_flip (bool) : default=0 value=0
>>vertical_flip (bool) : default=0 value=0
>>
>> Codec Controls
>>
>> video_gop_size (int): min=1 max=60 step=1
>> default=16 value=16
>>video_bitrate (int): min=0 max=32767000 step=1
>> default=0 value=0
>> number_of_intra_refresh_mbs (int): min=0 max=8160 step=1
>> default=0 value=0
>> sequence_header_mode (menu) : min=0 max=1 default=1 value=1
>> maximum_bytes_in_a_slice (int): min=1 max=1073741823 step=1
>> default=500 value=500
>> number_of_mbs_in_a_slice (int): min=1 max=1073741823 step=1
>> default=1 value=1
>>slice_partitioning_method (menu) : min=0 max=2 default=0 value=0
>>h264_i_frame_qp_value (int): min=0 max=51 step=1
>> default=25 value=25
>>h264_p_frame_qp_value (int): min=0 max=51 step=1
>> default=25 value=25
>>h264_maximum_qp_value (int): min=0 max=51 step=1
>> default=51 value=51
>>h264_loop_filter_alpha_offset (int): min=0 max=15 step=1 default=0
>> value=0
>> h264_loop_filter_beta_offset (int): min=0 max=15 step=1 default=0
>> value=0
>>h264_loop_filter_mode (menu) : min=0 max=1 default=0 value=0
>> mpeg4_i_frame_qp_value (int): min=1 max=31 step=1 default=2
>> value=2
>> mpeg4_p_frame_qp_value (int): min=1 max=31 step=1 default=2
>> value=2
>> horizontal_flip (bool) : default=0 value=0
>>vertical_flip (bool)
Re: [media] CODA960: Fails to allocate memory
2014-10-21 15:49 GMT+02:00 Hans Verkuil :
>
>
> On 10/21/2014 03:42 PM, Jean-Michel Hautbois wrote:
>>
>> Hi Hans,
>>
>> 2014-10-21 15:27 GMT+02:00 Hans Verkuil :
>>>
>>>
>>>
>>> On 10/21/2014 03:16 PM, Jean-Michel Hautbois wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> I am trying to use the CODA960 driver on a 3.18 kernel.
>>>> It seems pretty good when the module is probed (appart from the
>>>> unsupported firmware version) but when I try using the encoder, it
>>>> fails allocating dma buffers.
>>>>
>>>> Here is the DT part I added :
>>>> &vpu {
>>>> compatible = "fsl,imx6q-vpu";
>>>> clocks = <&clks 168>, <&clks 140>, <&clks 142>;
>>>> clock-names = "per", "ahb", "ocram";
>>>> iramsize = <0x21000>;
>>>> iram = <&ocram>;
>>>> resets = <&src 1>;
>>>> status = "okay";
>>>> };
>>>>
>>>> When booting, I see :
>>>> [4.410645] coda 204.vpu: Firmware code revision: 46056
>>>> [4.416312] coda 204.vpu: Initialized CODA960.
>>>> [4.421123] coda 204.vpu: Unsupported firmware version: 3.1.1
>>>> [4.483577] coda 204.vpu: codec registered as /dev/video[0-1]
>>>>
>>>> I can start v4l2-ctl and it shows that the device seems to be ok :
>>>>v4l2-ctl --all -d /dev/video1
>>>> Driver Info (not using libv4l2):
>>>> Driver name : coda
>>>> Card type : CODA960
>>>> Bus info : platform:coda
>>>> Driver version: 3.18.0
>>>> Capabilities : 0x84208000
>>>> Video Memory-to-Memory
>>>> Streaming
>>>> Extended Pix Format
>>>> Device Capabilities
>>>> Device Caps : 0x04208000
>>>> Video Memory-to-Memory
>>>> Streaming
>>>> Extended Pix Format
>>>> Priority: 2
>>>> Format Video Capture:
>>>> Width/Height : 1920/1088
>>>> Pixel Format : 'YU12'
>>>> Field : None
>>>> Bytes per Line: 1920
>>>> Size Image: 3133440
>>>> Colorspace: HDTV and modern devices (ITU709)
>>>> Flags :
>>>> Format Video Output:
>>>> Width/Height : 1920/1088
>>>> Pixel Format : 'H264'
>>>> Field : None
>>>> Bytes per Line: 0
>>>> Size Image: 1048576
>>>> Colorspace: HDTV and modern devices (ITU709)
>>>> Flags :
>>>> Selection: compose, Left 0, Top 0, Width 1920, Height 1088
>>>> Selection: compose_default, Left 0, Top 0, Width 1920, Height 1088
>>>> Selection: compose_bounds, Left 0, Top 0, Width 1920, Height 1088
>>>> Selection: compose_padded, Left 0, Top 0, Width 1920, Height 1088
>>>> Selection: crop, Left 0, Top 0, Width 1920, Height 1088
>>>> Selection: crop_default, Left 0, Top 0, Width 1920, Height 1088
>>>> Selection: crop_bounds, Left 0, Top 0, Width 1920, Height 1088
>>>>
>>>> User Controls
>>>>
>>>> horizontal_flip (bool) : default=0 value=0
>>>> vertical_flip (bool) : default=0 value=0
>>>>
>>>> Codec Controls
>>>>
>>>>video_gop_size (int): min=1 max=60 step=1
>>>> default=16 value=16
>>>> video_bitrate (int): min=0 max=32767000 step=1
>>>> default=0 value=0
>>>> number_of_intra_refresh_mbs (int): min=0 max=8160 step=1
>>>> default=0 value=0
>>>> sequence_header_mode (menu) : min=0 max=1 default=1
>>>> value=1
>>>> maximum_bytes_in_a_slice (int): min=1 max=1073741823 step=1
>>>> default=500 value=500
>>>> number_of_mbs_in_a_slice (int): min=1 max=1073741823 step=1
>>>> default=1 value=1
>>>> slice_partitioning_method (menu) : min
Re: [media] CODA960: Fails to allocate memory
Hi Philipp, 2014-10-21 18:21 GMT+02:00 Philipp Zabel : > Hi Jean-Michel, > > Am Dienstag, den 21.10.2014, 17:39 +0200 schrieb Jean-Michel Hautbois: > [...] >> And the output is now : >> v4l2-ctl -d1 --stream-out-mmap --stream-mmap --stream-to x.raw >> [ 6208.240919] coda 204.vpu: Not output type >> [ 6208.245316] coda 204.vpu: streamon_out (N), streamon_cap (Y) >> [ 6208.251353] coda 204.vpu: fill bitstream >> [ 6208.255653] coda 204.vpu: fill bitstream payload : 0 >> VIDIOC_STREAMON: failed: Invalid argument >> >> Any idea ? >> JM > > $ trace-cmd record -e v4l2* v4l2-ctl -d13 --stream-out-mmap --stream-mmap > --stream-to x.raw > [...] > $ trace-cmd report -R | grep bytesused > [...] > v4l2-ctl-308 [003] 1030.861067: v4l2_qbuf: minor=44 > index=0 type=1 bytesused=0 flags=16387 field=0 timestamp=0 timecode_type=0 > timecode_flags=0 timecode_frames=0 timecode_seconds=0 timecode_minutes=0 > timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 > timecode_userbits2=0 timecode_userbits3=0 sequence=0 > v4l2-ctl-308 [003] 1030.861292: v4l2_qbuf: minor=44 > index=1 type=1 bytesused=0 flags=16387 field=0 timestamp=0 timecode_type=0 > timecode_flags=0 timecode_frames=0 timecode_seconds=0 timecode_minutes=0 > timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 > timecode_userbits2=0 timecode_userbits3=0 sequence=0 > v4l2-ctl-308 [003] 1030.861471: v4l2_qbuf: minor=44 > index=2 type=1 bytesused=0 flags=16387 field=0 timestamp=0 timecode_type=0 > timecode_flags=0 timecode_frames=0 timecode_seconds=0 timecode_minutes=0 > timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 > timecode_userbits2=0 timecode_userbits3=0 sequence=0 > v4l2-ctl-308 [003] 1030.861638: v4l2_qbuf: minor=44 > index=3 type=1 bytesused=0 flags=16387 field=0 timestamp=0 timecode_type=0 > timecode_flags=0 timecode_frames=0 timecode_seconds=0 timecode_minutes=0 > timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 > timecode_userbits2=0 timecode_userbits3=0 sequence=0 > v4l2-ctl-308 [003] 1030.862301: v4l2_qbuf: minor=44 > index=0 type=2 bytesused=3133440 flags=16387 field=1 timestamp=1030852944000 > timecode_type=0 timecode_flags=0 timecode_frames=0 timecode_seconds=0 > timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 > timecode_userbits2=0 timecode_userbits3=0 sequence=0 > v4l2-ctl-308 [003] 1030.862490: v4l2_qbuf: minor=44 > index=1 type=2 bytesused=3133440 flags=16387 field=1 timestamp=1030853139000 > timecode_type=0 timecode_flags=0 timecode_frames=0 timecode_seconds=0 > timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 > timecode_userbits2=0 timecode_userbits3=0 sequence=0 > v4l2-ctl-308 [003] 1030.862672: v4l2_qbuf: minor=44 > index=2 type=2 bytesused=3133440 flags=16387 field=1 timestamp=1030853322000 > timecode_type=0 timecode_flags=0 timecode_frames=0 timecode_seconds=0 > timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 > timecode_userbits2=0 timecode_userbits3=0 sequence=0 > v4l2-ctl-308 [003] 1030.862841: v4l2_qbuf: minor=44 > index=3 type=2 bytesused=3133440 flags=16387 field=1 timestamp=1030853491000 > timecode_type=0 timecode_flags=0 timecode_frames=0 timecode_seconds=0 > timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 > timecode_userbits2=0 timecode_userbits3=0 sequence=0 > > The decoder is fed ~ 3 MiB input buffers, which it tries (and fails) to > copy into the 1 MiB bitstream ringbuffer (currently hard-coded via the > badly named CODA_MAX_FRAME_SIZE constant), so the bitstream payload in > the ringbuffer is 0 during start_streaming. Mmmh, nice, didn't thought to get perf out of there :). Well, I understand it can't feed the ringbuffer, but is there a way to make the encoder work ? I could of course modify CODA_MAX_FRAME_SIZE but this is clearly not the good thing to do... Thanks, JM -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [media] CODA960: Fails to allocate memory
Hi Philipp, > > 2014-10-21 18:21 GMT+02:00 Philipp Zabel : >> Hi Jean-Michel, >> >> Am Dienstag, den 21.10.2014, 17:39 +0200 schrieb Jean-Michel Hautbois: >> [...] >>> And the output is now : >>> v4l2-ctl -d1 --stream-out-mmap --stream-mmap --stream-to x.raw >>> [ 6208.240919] coda 204.vpu: Not output type >>> [ 6208.245316] coda 204.vpu: streamon_out (N), streamon_cap (Y) >>> [ 6208.251353] coda 204.vpu: fill bitstream >>> [ 6208.255653] coda 204.vpu: fill bitstream payload : 0 >>> VIDIOC_STREAMON: failed: Invalid argument >>> >>> Any idea ? >>> JM >> >> $ trace-cmd record -e v4l2* v4l2-ctl -d13 --stream-out-mmap --stream-mmap >> --stream-to x.raw >> [...] >> $ trace-cmd report -R | grep bytesused >> [...] >> v4l2-ctl-308 [003] 1030.861067: v4l2_qbuf: minor=44 >> index=0 type=1 bytesused=0 flags=16387 field=0 timestamp=0 timecode_type=0 >> timecode_flags=0 timecode_frames=0 timecode_seconds=0 timecode_minutes=0 >> timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 >> timecode_userbits2=0 timecode_userbits3=0 sequence=0 >> v4l2-ctl-308 [003] 1030.861292: v4l2_qbuf: minor=44 >> index=1 type=1 bytesused=0 flags=16387 field=0 timestamp=0 timecode_type=0 >> timecode_flags=0 timecode_frames=0 timecode_seconds=0 timecode_minutes=0 >> timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 >> timecode_userbits2=0 timecode_userbits3=0 sequence=0 >> v4l2-ctl-308 [003] 1030.861471: v4l2_qbuf: minor=44 >> index=2 type=1 bytesused=0 flags=16387 field=0 timestamp=0 timecode_type=0 >> timecode_flags=0 timecode_frames=0 timecode_seconds=0 timecode_minutes=0 >> timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 >> timecode_userbits2=0 timecode_userbits3=0 sequence=0 >> v4l2-ctl-308 [003] 1030.861638: v4l2_qbuf: minor=44 >> index=3 type=1 bytesused=0 flags=16387 field=0 timestamp=0 timecode_type=0 >> timecode_flags=0 timecode_frames=0 timecode_seconds=0 timecode_minutes=0 >> timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 >> timecode_userbits2=0 timecode_userbits3=0 sequence=0 >> v4l2-ctl-308 [003] 1030.862301: v4l2_qbuf: minor=44 >> index=0 type=2 bytesused=3133440 flags=16387 field=1 timestamp=1030852944000 >> timecode_type=0 timecode_flags=0 timecode_frames=0 timecode_seconds=0 >> timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 >> timecode_userbits1=0 timecode_userbits2=0 timecode_userbits3=0 sequence=0 >> v4l2-ctl-308 [003] 1030.862490: v4l2_qbuf: minor=44 >> index=1 type=2 bytesused=3133440 flags=16387 field=1 timestamp=1030853139000 >> timecode_type=0 timecode_flags=0 timecode_frames=0 timecode_seconds=0 >> timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 >> timecode_userbits1=0 timecode_userbits2=0 timecode_userbits3=0 sequence=0 >> v4l2-ctl-308 [003] 1030.862672: v4l2_qbuf: minor=44 >> index=2 type=2 bytesused=3133440 flags=16387 field=1 timestamp=1030853322000 >> timecode_type=0 timecode_flags=0 timecode_frames=0 timecode_seconds=0 >> timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 >> timecode_userbits1=0 timecode_userbits2=0 timecode_userbits3=0 sequence=0 >> v4l2-ctl-308 [003] 1030.862841: v4l2_qbuf: minor=44 >> index=3 type=2 bytesused=3133440 flags=16387 field=1 timestamp=1030853491000 >> timecode_type=0 timecode_flags=0 timecode_frames=0 timecode_seconds=0 >> timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 >> timecode_userbits1=0 timecode_userbits2=0 timecode_userbits3=0 sequence=0 >> I may have misunderstand something... I try to encode, and modified the CODA_MAX_FRAME_SIZE to 0x50 just to see. And here is the trace-cmd : $> trace-cmd record -e v4l2* v4l2-ctl -d1 --stream-out-mmap --stream-mmap --stream-to x.raw [...] $> trace-cmd report -R | grep bytesused v4l2-ctl-1162 [000] 324.061644: v4l2_qbuf: minor=1 index=0 type=1 bytesused=0 flags=16387 field=0 timestamp=0 timecode_type=0 timecode_flags=0 timecode_frames=0 timeco de_seconds=0 timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 timecode_userbits2=0 timecode_userbits3=0 sequence=0 v4l2-ctl-1162 [000] 324.062207: v4l2_qbuf: minor=1 index=1 type=1 bytesused=0 flags=16387 field=0 timestamp=0 timecode_type=0 timecode_flags=0 timecode_frames=0 timeco de_seconds=0 timecode_minutes=0 timecode_hours=0 timecode_userbits0=0 timecode_userbits1=0 timecode_userbits2=0 timecode_userbits3=0 sequence=0 v4l2-ctl-1162 [000] 324.
Re: [media] CODA960: Fails to allocate memory
2014-10-22 11:29 GMT+02:00 Philipp Zabel :
> Hi Jean-Michel,
>
> Am Mittwoch, den 22.10.2014, 11:21 +0200 schrieb Jean-Michel Hautbois:
>> I may have misunderstand something...
>> I try to encode, and modified the CODA_MAX_FRAME_SIZE to 0x50 just to
>> see.
>>
>> And here is the trace-cmd :
>>
>> $> trace-cmd record -e v4l2* v4l2-ctl -d1 --stream-out-mmap
>> --stream-mmap --stream-to x.raw
>
> Are you sure /dev/video1 is the encoder device?
>
> $ cat /sys/class/video4linux/video12/name
> coda-encoder
>
> $ cat /sys/class/video4linux/video13/name
> coda-decoder
Ahem you are right... :/
So, here is the trace-cmd with device 0 which is the encoder... and
this is pretty bad :(
$> trace-cmd record -e v4l2* v4l2-ctl -d0 --stream-out-mmap
--stream-mmap --stream-to x.raw
[ 1429.222887] cma: cma_alloc(cma 814923f8, count 3, align 2)
[ 1429.223856] cma: cma_alloc(): returned b7eb8f80
[ 1429.224073] cma: cma_alloc(cma 814923f8, count 1280, align 8)
[ 1429.224579] cma: cma_alloc(): returned b7ebe000
[ 1429.256453] cma: cma_alloc(cma 814923f8, count 1280, align 8)
[ 1429.258174] cma: cma_alloc(): memory range at b7ec8000 is busy, retrying
[ 1429.259623] cma: cma_alloc(): memory range at b7eca000 is busy, retrying
[ 1429.261581] cma: cma_alloc(): returned b7ecc000
[ 1429.279247] cma: cma_alloc(cma 814923f8, count 1280, align 8)
[ 1429.279618] cma: cma_alloc(): returned b7ed6000
[ 1429.293288] cma: cma_alloc(cma 814923f8, count 1280, align 8)
[ 1429.295417] cma: cma_alloc(): returned b7ee
[ 1429.309931] cma: cma_alloc(cma 814923f8, count 1280, align 8)
[ 1429.312176] cma: cma_alloc(): returned b7eea000
[ 1429.326262] cma: cma_alloc(cma 814923f8, count 765, align 8)
[ 1429.328392] cma: cma_alloc(): returned b7ef4000
[ 1429.339247] cma: cma_alloc(cma 814923f8, count 765, align 8)
[ 1429.339453] cma: cma_alloc(): returned b7efa000
[ 1429.349290] cma: cma_alloc(cma 814923f8, count 765, align 8)
[ 1429.350072] cma: cma_alloc(): returned b7f0
[ 1429.359980] cma: cma_alloc(cma 814923f8, count 765, align 8)
[ 1429.361497] cma: cma_alloc(): returned b7f06000
[ 1429.373118] coda 204.vpu: Not output type
[ 1429.377539] coda 204.vpu: streamon_out (N), streamon_cap (Y)
[ 1429.383950] coda 204.vpu: Not H264 pix fmt
[ 1429.388526] cma: cma_alloc(cma 814923f8, count 20, align 5)
[ 1429.390033] cma: cma_alloc(): returned b7ebd400
[ 1429.391953] ==
[ 1429.398137] [ INFO: possible circular locking dependency detected ]
[ 1429.404410] 3.18.0-rc1+yocto+gc943ff8 #2 Not tainted
[ 1429.409378] ---
[ 1429.415648] v4l2-ctl/1179 is trying to acquire lock:
[ 1429.420617] (&sb->s_type->i_mutex_key#3){+.+.+.}, at: [<802d7d9c>]
__create_file+0x70/0x21c
[ 1429.429157]
but task is already holding lock:
[ 1429.434996] (&dev->dev_mutex){+.+.+.}, at: [<8052be98>]
v4l2_ioctl+0x60/0x17c
[ 1429.442294]
which lock already depends on the new lock.
[ 1429.450477]
the existing dependency chain (in reverse order) is:
[ 1429.457964]
-> #2 (&dev->dev_mutex){+.+.+.}:
[ 1429.462473][<807879ec>] mutex_lock_interruptible_nested+0x6c/0x454
[ 1429.469379][<7f000e3c>] v4l2_m2m_fop_mmap+0x34/0x90 [v4l2_mem2mem]
[ 1429.476291][<8052b9a8>] v4l2_mmap+0x64/0x9c
[ 1429.481191][<80113de8>] mmap_region+0x380/0x6a0
[ 1429.486440][<80114428>] do_mmap_pgoff+0x320/0x3b8
[ 1429.491859][<800fe504>] vm_mmap_pgoff+0x74/0xa4
[ 1429.497115][<80112868>] SyS_mmap_pgoff+0xa4/0xcc
[ 1429.502449][<8000fa40>] ret_fast_syscall+0x0/0x48
[ 1429.507875]
-> #1 (&mm->mmap_sem){++}:
[ 1429.512208][<8010bb28>] might_fault+0x70/0x98
[ 1429.517290][<8013e6a0>] filldir64+0x7c/0x194
[ 1429.522279][<80153020>] dcache_readdir+0x1a4/0x25c
[ 1429.527787][<8013e41c>] iterate_dir+0x90/0x110
[ 1429.532946][<8013e934>] SyS_getdents64+0x84/0xf8
[ 1429.538278][<8000fa40>] ret_fast_syscall+0x0/0x48
[ 1429.543700]
-> #0 (&sb->s_type->i_mutex_key#3){+.+.+.}:
[ 1429.549180][<8006cc3c>] lock_acquire+0xb0/0x118
[ 1429.554427][<80786dd4>] mutex_lock_nested+0x60/0x3d4
[ 1429.560110][<802d7d9c>] __create_file+0x70/0x21c
[ 1429.565445][<802d7f7c>] debugfs_create_file+0x34/0x40
[ 1429.571212][<802d830c>] debugfs_create_blob+0x24/0x30
[ 1429.576981][<7f022ef4>] coda_alloc_aux_buf+0xa4/0x100 [coda]
[ 1429.583372][<7f025080>] coda_alloc_context_buffers+0xa4/0x20c [coda]
[ 1429.590451][<7f026068>] coda_start_encoding+0x2c/0x88c [coda]
[ 1429.596921][<7f021f44>] coda_start_streaming+0xb8/0x268 [coda]
[ 1429.603474]
[PATCH 2/2] adv7604: Add support for i2c_new_secondary_device
The ADV7604 has thirteen 256-byte maps that can be accessed via the main
I²C ports. Each map has it own I²C address and acts
as a standard slave device on the I²C bus.
If nothing is defined, it uses default addresses.
The main purpose is using two adv76xx on the same i2c bus.
Signed-off-by: Jean-Michel Hautbois
---
.../devicetree/bindings/media/i2c/adv7604.txt | 16 +-
drivers/media/i2c/adv7604.c| 59 ++
2 files changed, 53 insertions(+), 22 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
index 5c8b3e6..8486b5c 100644
--- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
+++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
@@ -12,7 +12,10 @@ Required Properties:
- "adi,adv7611" for the ADV7611
- "adi,adv7604" for the ADV7604
- - reg: I2C slave address
+ - reg: I2C slave addresses
+The ADV7604 has thirteen 256-byte maps that can be accessed via the main
+I²C ports. Each map has it own I²C address and acts
+as a standard slave device on the I²C bus.
- hpd-gpios: References to the GPIOs that control the HDMI hot-plug
detection pins, one per HDMI input. The active flag indicates the GPIO
@@ -33,6 +36,12 @@ The digital output port node must contain at least one
endpoint.
Optional Properties:
- reset-gpios: Reference to the GPIO connected to the device's reset pin.
+ - reg-names : Names of maps with programmable addresses.
+ It can contain any map needing another address than default one.
+ Possible maps names are :
+ADV7604 : "main", "avlink", "cec", "infoframe", "esdp", "dpp", "afe", "rep",
+ "edid", "hdmi", "test", "cp", "vdp"
+ADV7611 : "main", "cec", "infoframe", "afe", "rep", "edid", "hdmi", "cp"
Optional Endpoint Properties:
@@ -51,7 +60,10 @@ Example:
hdmi_receiver@4c {
compatible = "adi,adv7611";
- reg = <0x4c>;
+ /* edid page will be accessible @ 0x66 on i2c bus */
+ /* other maps keep their default addresses */
+ reg = <0x4c 0x66>;
+ reg-names = "main", "edid";
reset-gpios = <&ioexp 0 GPIO_ACTIVE_LOW>;
hpd-gpios = <&ioexp 2 GPIO_ACTIVE_HIGH>;
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 421035f..e4e30a2 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -326,6 +326,27 @@ static const struct adv7604_video_standards
adv7604_prim_mode_hdmi_gr[] = {
{ },
};
+struct adv7604_register {
+ const char *name;
+ u8 default_addr;
+};
+
+static const struct adv7604_register adv7604_secondary_names[] = {
+ [ADV7604_PAGE_IO] = { "main", 0x4c },
+ [ADV7604_PAGE_AVLINK] = { "avlink", 0x42 },
+ [ADV7604_PAGE_CEC] = { "cec", 0x40 },
+ [ADV7604_PAGE_INFOFRAME] = { "infoframe", 0x3e },
+ [ADV7604_PAGE_ESDP] = { "esdp", 0x38 },
+ [ADV7604_PAGE_DPP] = { "dpp", 0x3c },
+ [ADV7604_PAGE_AFE] = { "afe", 0x26 },
+ [ADV7604_PAGE_REP] = { "rep", 0x32 },
+ [ADV7604_PAGE_EDID] = { "edid", 0x36 },
+ [ADV7604_PAGE_HDMI] = { "hdmi", 0x34 },
+ [ADV7604_PAGE_TEST] = { "test", 0x30 },
+ [ADV7604_PAGE_CP] = { "cp", 0x22 },
+ [ADV7604_PAGE_VDP] = { "vdp", 0x24 },
+};
+
/* --- */
static inline struct adv7604_state *to_state(struct v4l2_subdev *sd)
@@ -2528,13 +2549,26 @@ static void adv7604_unregister_clients(struct
adv7604_state *state)
}
static struct i2c_client *adv7604_dummy_client(struct v4l2_subdev *sd,
- u8 addr, u8 io_reg)
+ unsigned int i)
{
struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct adv7604_platform_data *pdata = client->dev.platform_data;
+ unsigned int io_reg = 0xf2 + i;
+ unsigned int default_addr = io_read(sd, io_reg) >> 1;
+ struct i2c_client *new_client;
+
+ if (pdata && pdata->i2c_addresses[i])
+ new_client = i2c_new_dummy(client->adapter,
+ pdata->i2c_addresses[i]);
+ else
+ new_client = i2c_new_secondary_device(client,
+ adv7604_secondary_names[i].name,
+ adv7604_secondary_names[i].default_add
[PATCH 1/2] i2c: Add generic support passing secondary devices addresses
Some I2C devices have multiple addresses assigned, for example each address
corresponding to a different internal register map page of the device.
So far drivers which need support for this have handled this with a driver
specific and non-generic implementation, e.g. passing the additional address
via platform data.
This patch provides a new helper function called i2c_new_secondary_device()
which is intended to provide a generic way to get the secondary address
as well as instantiate a struct i2c_client for the secondary address.
The function expects a pointer to the primary i2c_client, a name
for the secondary address and an optional default address. The name is used
as a handle to specify which secondary address to get.
The default address is used as a fallback in case no secondary address
was explicitly specified. In case no secondary address and no default
address were specified the function returns NULL.
For now the function only supports look-up of the secondary address
from devicetree, but it can be extended in the future
to for example support board files and/or ACPI.
Signed-off-by: Jean-Michel Hautbois
---
drivers/i2c/i2c-core.c | 40
include/linux/i2c.h| 8
2 files changed, 48 insertions(+)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 2f90ac6..fd3b07c 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -1166,6 +1166,46 @@ struct i2c_client *i2c_new_dummy(struct i2c_adapter
*adapter, u16 address)
}
EXPORT_SYMBOL_GPL(i2c_new_dummy);
+/**
+ * i2c_new_secondary_device - Helper to get the instantiated secondary address
+ * @client: Handle to the primary client
+ * @name: Handle to specify which secondary address to get
+ * @default_addr: Used as a fallback if no secondary address was specified
+ * Context: can sleep
+ *
+ * This returns an I2C client bound to the "dummy" driver based on DT parsing.
+ *
+ * This returns the new i2c client, which should be saved for later use with
+ * i2c_unregister_device(); or NULL to indicate an error.
+ */
+struct i2c_client *i2c_new_secondary_device(struct i2c_client *client,
+ const char *name,
+ u16 default_addr)
+{
+ int i;
+ u32 addr;
+ struct device_node *np;
+
+ np = client->dev.of_node;
+
+ if (np) {
+ i = of_property_match_string(np, "reg-names", name);
+ if (i >= 0)
+ of_property_read_u32_index(np, "reg", i, &addr);
+ else if (default_addr != 0)
+ addr = default_addr;
+ else
+ addr = NULL;
+ } else {
+ addr = default_addr;
+ }
+
+ dev_dbg(&client->adapter->dev, "Address for %s : 0x%x\n", name, addr);
+ return i2c_new_dummy(client->adapter, addr);
+}
+EXPORT_SYMBOL_GPL(i2c_new_secondary_device);
+
+
/* - */
/* I2C bus adapters -- one roots each I2C or SMBUS segment */
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index b556e0a..8629287 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -322,6 +322,14 @@ extern int i2c_probe_func_quick_read(struct i2c_adapter *,
unsigned short addr);
extern struct i2c_client *
i2c_new_dummy(struct i2c_adapter *adap, u16 address);
+/* Helper function providing a generic way to get the secondary address
+ * as well as a client handle to this extra address.
+ */
+extern struct i2c_client *
+i2c_new_secondary_device(struct i2c_client *client,
+ const char *name,
+ u16 default_addr);
+
extern void i2c_unregister_device(struct i2c_client *);
#endif /* I2C */
--
2.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] adv7604: Add DT parsing support
This patch adds support for DT parsing of ADV7604 as well as ADV7611.
It needs to be improved in order to get ports parsing too.
Signed-off-by: Jean-Michel Hautbois
---
Documentation/devicetree/bindings/media/i2c/adv7604.txt | 1 +
drivers/media/i2c/adv7604.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
index c27cede..5c8b3e6 100644
--- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
+++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
@@ -10,6 +10,7 @@ Required Properties:
- compatible: Must contain one of the following
- "adi,adv7611" for the ADV7611
+- "adi,adv7604" for the ADV7604
- reg: I2C slave address
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 47795ff..421035f 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -2677,6 +2677,7 @@ MODULE_DEVICE_TABLE(i2c, adv7604_i2c_id);
static struct of_device_id adv7604_of_id[] __maybe_unused = {
{ .compatible = "adi,adv7611", .data = &adv7604_chip_info[ADV7611] },
+ { .compatible = "adi,adv7604", .data = &adv7604_chip_info[ADV7604] },
{ }
};
MODULE_DEVICE_TABLE(of, adv7604_of_id);
--
2.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] adv7604: Add DT parsing support
Hi Laurent,
Thank you for reviewing,
2014-10-23 1:53 GMT+02:00 Laurent Pinchart :
> Hi Jean-Michel,
>
> Thank you for the patch.
>
> On Wednesday 22 October 2014 17:34:21 Jean-Michel Hautbois wrote:
>> This patch adds support for DT parsing of ADV7604 as well as ADV7611.
>> It needs to be improved in order to get ports parsing too.
>
> Let's improve it then :-) The DT bindings as proposed by this patch are
> incomplete, that's just asking for trouble.
>
> How would you model the adv7604 ports ?
I am opened to suggestions :).
But it has to remain as simple as possible, ideally allowing for
giving names to the ports.
As done today, it works, ports are parsed but are all the same...
>> Signed-off-by: Jean-Michel Hautbois
>> ---
>> Documentation/devicetree/bindings/media/i2c/adv7604.txt | 1 +
>> drivers/media/i2c/adv7604.c | 1 +
>> 2 files changed, 2 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
>> b/Documentation/devicetree/bindings/media/i2c/adv7604.txt index
>> c27cede..5c8b3e6 100644
>> --- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
>> +++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
>> @@ -10,6 +10,7 @@ Required Properties:
>>
>>- compatible: Must contain one of the following
>> - "adi,adv7611" for the ADV7611
>> +- "adi,adv7604" for the ADV7604
>
> Please switch the two lines to keep them alphabetically sorted.
>>
>>- reg: I2C slave address
>>
>> diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
>> index 47795ff..421035f 100644
>> --- a/drivers/media/i2c/adv7604.c
>> +++ b/drivers/media/i2c/adv7604.c
>> @@ -2677,6 +2677,7 @@ MODULE_DEVICE_TABLE(i2c, adv7604_i2c_id);
>>
>> static struct of_device_id adv7604_of_id[] __maybe_unused = {
>> { .compatible = "adi,adv7611", .data = &adv7604_chip_info[ADV7611] },
>> + { .compatible = "adi,adv7604", .data = &adv7604_chip_info[ADV7604] },
>
> Same comment here.
Done on my side, but will wait for your suggestions, in order to add
ports parsing ;-).
Thanks,
JM
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] i2c: Add generic support passing secondary devices addresses
Hi Laurent,
Thank you for your review,
2014-10-23 1:37 GMT+02:00 Laurent Pinchart :
> Hi Jean-Michel,
>
> Thank you for the patch.
>
> On Wednesday 22 October 2014 17:30:47 Jean-Michel Hautbois wrote:
>> Some I2C devices have multiple addresses assigned, for example each address
>> corresponding to a different internal register map page of the device.
>> So far drivers which need support for this have handled this with a driver
>> specific and non-generic implementation, e.g. passing the additional address
>> via platform data.
>>
>> This patch provides a new helper function called i2c_new_secondary_device()
>> which is intended to provide a generic way to get the secondary address
>> as well as instantiate a struct i2c_client for the secondary address.
>>
>> The function expects a pointer to the primary i2c_client, a name
>> for the secondary address and an optional default address. The name is used
>> as a handle to specify which secondary address to get.
>>
>> The default address is used as a fallback in case no secondary address
>> was explicitly specified. In case no secondary address and no default
>> address were specified the function returns NULL.
>>
>> For now the function only supports look-up of the secondary address
>> from devicetree, but it can be extended in the future
>> to for example support board files and/or ACPI.
>
> As this is core code I believe the DT bindings should be documented somewhere
> in Documentation/devicetree/bindings/i2c/.
Mmh, probably yes, but I don't know where precisely, as all the
bindings are devices specific here...
>> Signed-off-by: Jean-Michel Hautbois
>> ---
>> drivers/i2c/i2c-core.c | 40
>> include/linux/i2c.h| 8
>> 2 files changed, 48 insertions(+)
>>
>> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
>> index 2f90ac6..fd3b07c 100644
>> --- a/drivers/i2c/i2c-core.c
>> +++ b/drivers/i2c/i2c-core.c
>> @@ -1166,6 +1166,46 @@ struct i2c_client *i2c_new_dummy(struct i2c_adapter
>> *adapter, u16 address) }
>> EXPORT_SYMBOL_GPL(i2c_new_dummy);
>>
>> +/**
>> + * i2c_new_secondary_device - Helper to get the instantiated secondary
>> address
>
> It does more than that, it also creates the device.
Right, how about :
+ * i2c_new_secondary_device - Helper to get the instantiated secondary address
+ * and create the associated device
>> + * @client: Handle to the primary client
>> + * @name: Handle to specify which secondary address to get
>> + * @default_addr: Used as a fallback if no secondary address was specified
>> + * Context: can sleep
>> + *
>> + * This returns an I2C client bound to the "dummy" driver based on DT
>> parsing.
>
> Could you elaborate on that ? I would explain that the address is retrieved
> from the firmware based on the name, and that default_addr is used in case the
> firmware doesn't provide any information.
Something like that ?
+ * This returns an I2C client bound to the "dummy" driver based on DT parsing.
+ * It retrieves the address based on the name.
+ * It uses default_addr if no information is provided by firmware.
>> + *
>> + * This returns the new i2c client, which should be saved for later use
>> with
>> + * i2c_unregister_device(); or NULL to indicate an error.
>> + */
>> +struct i2c_client *i2c_new_secondary_device(struct i2c_client *client,
>> + const char *name,
>> + u16 default_addr)
>> +{
>> + int i;
>> + u32 addr;
>> + struct device_node *np;
>> +
>> + np = client->dev.of_node;
>> +
>> + if (np) {
>> + i = of_property_match_string(np, "reg-names", name);
>> + if (i >= 0)
>> + of_property_read_u32_index(np, "reg", i, &addr);
>
> This call could fail in which case addr will be uninitialized.
>
>> + else if (default_addr != 0)
>> + addr = default_addr;
>> + else
>> + addr = NULL;
>
> addr isn't a pointer. I'm surprised the compiler hasn't warned you.
It has, just didn't notice it, sorry fir the noise.
>> + } else {
>> + addr = default_addr;
>> + }
>
> The whole logic can be simplified to
>
> struct device_node *np = client->dev.of_node;
> u32 addr = default_addr;
> int i;
>
> if (np) {
> i = of_property_match_string(np, "reg-names", name);
> if (i >= 0)
> of_property_read_u32_index(np, "reg", i, &addr);
> }
>
OK, applied on my side.
Thanks,
JM
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] adv7604: Add support for i2c_new_secondary_device
Hi Laurent,
Thank you for reviewing,
2014-10-23 1:44 GMT+02:00 Laurent Pinchart :
> Hi Jean-Michel,
>
> Thank you for the patch.
>
> On Wednesday 22 October 2014 17:30:48 Jean-Michel Hautbois wrote:
>> The ADV7604 has thirteen 256-byte maps that can be accessed via the main
>> I²C ports. Each map has it own I²C address and acts
>> as a standard slave device on the I²C bus.
>>
>> If nothing is defined, it uses default addresses.
>> The main purpose is using two adv76xx on the same i2c bus.
>>
>> Signed-off-by: Jean-Michel Hautbois
>> ---
>> .../devicetree/bindings/media/i2c/adv7604.txt | 16 +-
>> drivers/media/i2c/adv7604.c| 59 ---
>> 2 files changed, 53 insertions(+), 22 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
>> b/Documentation/devicetree/bindings/media/i2c/adv7604.txt index
>> 5c8b3e6..8486b5c 100644
>> --- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
>> +++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
>> @@ -12,7 +12,10 @@ Required Properties:
>> - "adi,adv7611" for the ADV7611
>> - "adi,adv7604" for the ADV7604
>
> Given that I'll have comment on the independent patch that adds support for
> the adv7604, you should rebase this series to remote that dependency if you
> want to get it merged now, otherwise it will get delayed.
Oh, you are right, of course, I forgot rebasing (as well as numbering
the patch as v2)...
>>
>> - - reg: I2C slave address
>> + - reg: I2C slave addresses
>> +The ADV7604 has thirteen 256-byte maps that can be accessed via the
>> main
>> +I²C ports. Each map has it own I²C address and acts
>> +as a standard slave device on the I²C bus.
>>
>>- hpd-gpios: References to the GPIOs that control the HDMI hot-plug
>> detection pins, one per HDMI input. The active flag indicates the GPIO
>> @@ -33,6 +36,12 @@ The digital output port node must contain at least one
>> endpoint. Optional Properties:
>>
>>- reset-gpios: Reference to the GPIO connected to the device's reset pin.
>> + - reg-names : Names of maps with programmable addresses.
>> + It can contain any map needing another address than default
>> one.
>> + Possible maps names are :
>> +ADV7604 : "main", "avlink", "cec", "infoframe", "esdp", "dpp", "afe",
>> "rep",
>> + "edid", "hdmi", "test", "cp", "vdp"
>
> If you rebase the series in order to avoid depending on the adv7604 DT support
> patch this line should be moved to "adv7604: Add DT parsing support".
>
>> +ADV7611 : "main", "cec", "infoframe", "afe", "rep", "edid", "hdmi", "cp"
>>
>> Optional Endpoint Properties:
>>
>> @@ -51,7 +60,10 @@ Example:
>>
>> hdmi_receiver@4c {
>> compatible = "adi,adv7611";
>> - reg = <0x4c>;
>> + /* edid page will be accessible @ 0x66 on i2c bus */
>> + /* other maps keep their default addresses */
>> + reg = <0x4c 0x66>;
>> + reg-names = "main", "edid";
>>
>> reset-gpios = <&ioexp 0 GPIO_ACTIVE_LOW>;
>> hpd-gpios = <&ioexp 2 GPIO_ACTIVE_HIGH>;
>> diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
>> index 421035f..e4e30a2 100644
>> --- a/drivers/media/i2c/adv7604.c
>> +++ b/drivers/media/i2c/adv7604.c
>> @@ -326,6 +326,27 @@ static const struct adv7604_video_standards
>> adv7604_prim_mode_hdmi_gr[] = { { },
>> };
>>
>> +struct adv7604_register {
>> + const char *name;
>> + u8 default_addr;
>> +};
>> +
>> +static const struct adv7604_register adv7604_secondary_names[] = {
>> + [ADV7604_PAGE_IO] = { "main", 0x4c },
>> + [ADV7604_PAGE_AVLINK] = { "avlink", 0x42 },
>> + [ADV7604_PAGE_CEC] = { "cec", 0x40 },
>> + [ADV7604_PAGE_INFOFRAME] = { "infoframe", 0x3e },
>> + [ADV7604_PAGE_ESDP] = { "esdp", 0x38 },
>> + [ADV7604_PAGE_DPP] = { "dpp", 0x3c },
>> + [ADV7604_PAGE_AFE] = { "afe", 0x26 },
>> + [ADV7604_PAGE_REP] = { "rep", 0x32 },
>> + [ADV7604_PAGE_EDID] = { "edid", 0x
Re: i.MX6 status for IPU/VPU/GPU
Hi Philipp, 2014-09-15 16:13 GMT+02:00 Jean-Michel Hautbois : > 2014-09-11 15:26 GMT+02:00 Philipp Zabel : >> Hi Steve, >> >> Am Mittwoch, den 10.09.2014, 18:17 -0700 schrieb Steve Longerbeam: >> [...] >>> On 09/09/2014 10:40 AM, Philipp Zabel wrote: >> [...] >>> > I have in the meantime started to >>> > implement everything that has a source or destination selector in the >>> > Frame Synchronization Unit (FSU) as media entity. I wonder which of >>> > these parts should reasonably be unified into a single entity: >> [...] >>> > SMFC0 >>> > SMFC1 >>> > SMFC2 >>> > SMFC3 >>> >>> I don't really see the need for an SMFC entity. The SMFC control can >>> be integrated into the CSI subdev. >> >> Granted, this is currently is a theoretical question, but could we >> handle a single MIPI link that carries two or more virtual channels with >> different MIPI IDs this way? >> >>> > IC preprocessor (input to VF and ENC, if I understood correctly) >>> > IC viewfinder task (scaling, csc) >>> > IC encoding task >>> > IC post processing task >>> >>> I see either three different IC subdev entities (IC prpenc, IC prpvf, >>> IC pp), or a single IC entity with three sink pads for each IC task. >> >> The former could work, the latter won't allow to have pre and post >> processing on separate pipelines. >> >>> > IRT viewfinder task (rotation) >>> > IRT encoding task >>> > IRT post processing task >>> >>> well, the IRT is really just a submodule enable bit, I see no need >>> for an IRT subdev, in fact IRT has already been folded into ipu-ic.c >>> as a simple submodule enable/disable. Rotation support can be >>> implemented as part of the IC entities. >> >> My current understanding is that the IRT is strictly a mem2mem device >> using its own DMA channels, which can be channel-linked to the IC (and >> other blocks) in various ways. >> >>> > VDIC (deinterlacing, combining) >>> >>> I am thinking VDIC support can be part of the IC prpvf entity (well, >>> combining is not really on my radar, I haven't given that much thought). >>> >>> > (and probably some entry for DP/DC/DMFC for the direct >>> > viewfinder path) >>> >>> Ugh, I've been ignoring that path as well. Freescale's BSP releases >>> and sample code from their SDK's have no example code for the >>> direct-to-DP/DC/DMFC camera viewfinder path, so given the quality >>> of the imx TRM, this could be a challenge to implement. Have you >>> gotten this path to work? >> >> Not yet, no. >> >>> > I suppose the SMFC channels need to be separate because they can belong >>> > to different pipelines (and each entity can only belong to one). >>> >>> I see the chosen SMFC channel as an internal decision by the >>> CSI subdev. >> >> Can we handle multiple outputs from a single CSI this way? >> >>> > The three IC task entities could probably be combined with their >>> > corresponding IRT task entity somehow, but that would be at the cost of >>> > not being able to tell the kernel whether to rotate before or after >>> > scaling, which might be useful when handling chroma subsampled formats. >>> >>> I'm fairly sure IC rotation must always occur _after_ scaling. I.e. >>> raw frames are first passed through IC prpenc/prpvf/pp for scaling/CSC, >>> then EOF completion of that task is hardware linked to IRT. >> >> There could be good reasons to do the rotation on the input side, for >> example when upscaling or when the output is 4:2:2 subsampled. At least >> the FSU registers suggest that channel linking the rotator before the IC >> is possible. This probably won't be useful for the capture path in most >> cases, but it might be for rotated playback. >> >>> > I have put my current state up here: >>> > >>> > git://git.pengutronix.de/git/pza/linux.git test/nitrogen6x-ipu-media >>> > >>> > So far I've captured video through the SMFC on a Nitrogen6X board with >>> > OV5652 parallel camera with this. >>> >>> Thanks Phillip, I'll take a look! Sounds like a good place to start. >>> I assume this is with the video mux entity and CSI driver? I.e. n
[PATCH] media: adv7604: Correct G/S_EDID behaviour
In order to have v4l2-compliance tool pass the G/S_EDID some modifications
where needed in the driver.
In particular, the edid.reserved zone must be blanked.
Signed-off-by: Jean-Michel Hautbois
---
drivers/media/i2c/adv7604.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 47795ff..0848ee7 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -1997,16 +1997,23 @@ static int adv7604_get_edid(struct v4l2_subdev *sd,
struct v4l2_edid *edid)
struct adv7604_state *state = to_state(sd);
u8 *data = NULL;
+ memset(edid->reserved, 0, sizeof(edid->reserved));
if (edid->pad > ADV7604_PAD_HDMI_PORT_D)
return -EINVAL;
- if (edid->blocks == 0)
- return -EINVAL;
- if (edid->blocks > 2)
- return -EINVAL;
- if (edid->start_block > 1)
+
+ if (edid->start_block == 0 && edid->blocks == 0) {
+ edid->blocks = state->edid.blocks;
+ return 0;
+ }
+
+ if (state->edid.blocks == 0)
+ return -ENODATA;
+
+ if (edid->start_block >= state->edid.blocks)
return -EINVAL;
- if (edid->start_block == 1)
- edid->blocks = 1;
+
+ if (edid->start_block + edid->blocks > state->edid.blocks)
+ edid->blocks = state->edid.blocks - edid->start_block;
if (edid->blocks > state->edid.blocks)
edid->blocks = state->edid.blocks;
@@ -2068,6 +2075,8 @@ static int adv7604_set_edid(struct v4l2_subdev *sd,
struct v4l2_edid *edid)
int err;
int i;
+ memset(edid->reserved, 0, sizeof(edid->reserved));
+
if (edid->pad > ADV7604_PAD_HDMI_PORT_D)
return -EINVAL;
if (edid->start_block != 0)
@@ -2164,7 +2173,6 @@ static int adv7604_set_edid(struct v4l2_subdev *sd,
struct v4l2_edid *edid)
return -EIO;
}
-
/* enable hotplug after 100 ms */
queue_delayed_work(state->work_queues,
&state->delayed_work_enable_hotplug, HZ / 10);
--
2.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] adv: fix G/S_EDID behavior
2014-11-07 13:34 GMT+01:00 Hans Verkuil : > This patch series fixes the adv7604, adv7842 and adv7511 G/S_EDID behavior. > All three have been tested with v4l2-compliance and pass. > > Jean-Michel, I based the adv7604 patch on your patch, but I reworked it a bit. > I hope you don't mind. No problem for me, I applied your version and it works on my board. Thanks, JM -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] adv7604: Correct G/S_EDID behaviour
Hi Hans,
2014-11-07 13:34 GMT+01:00 Hans Verkuil :
> From: Hans Verkuil
>
> In order to have v4l2-compliance tool pass the G/S_EDID some modifications
> where needed in the driver.
> In particular, the edid.reserved zone must be blanked.
>
> Based on a patch from Jean-Michel Hautbois ,
> but reworked it a bit. It should use edid.present instead of edid.blocks as
> the
> check whether edid data is present.
I may have missed it, but you did not implement it using edid.present
in the code below... ?
> Signed-off-by: Hans Verkuil
> ---
> drivers/media/i2c/adv7604.c | 37 ++---
> 1 file changed, 18 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
> index 47795ff..d64fbd9 100644
> --- a/drivers/media/i2c/adv7604.c
> +++ b/drivers/media/i2c/adv7604.c
> @@ -1997,19 +1997,7 @@ static int adv7604_get_edid(struct v4l2_subdev *sd,
> struct v4l2_edid *edid)
> struct adv7604_state *state = to_state(sd);
> u8 *data = NULL;
>
> - if (edid->pad > ADV7604_PAD_HDMI_PORT_D)
> - return -EINVAL;
> - if (edid->blocks == 0)
> - return -EINVAL;
> - if (edid->blocks > 2)
> - return -EINVAL;
> - if (edid->start_block > 1)
> - return -EINVAL;
> - if (edid->start_block == 1)
> - edid->blocks = 1;
> -
> - if (edid->blocks > state->edid.blocks)
> - edid->blocks = state->edid.blocks;
> + memset(edid->reserved, 0, sizeof(edid->reserved));
>
> switch (edid->pad) {
> case ADV7604_PAD_HDMI_PORT_A:
> @@ -2021,14 +2009,24 @@ static int adv7604_get_edid(struct v4l2_subdev *sd,
> struct v4l2_edid *edid)
> break;
> default:
> return -EINVAL;
> - break;
> }
> - if (!data)
> +
> + if (edid->start_block == 0 && edid->blocks == 0) {
> + edid->blocks = state->edid.blocks;
> + return 0;
> + }
> +
> + if (data == NULL)
> return -ENODATA;
>
> - memcpy(edid->edid,
> - data + edid->start_block * 128,
> - edid->blocks * 128);
> + if (edid->start_block >= state->edid.blocks)
> + return -EINVAL;
> +
> + if (edid->start_block + edid->blocks > state->edid.blocks)
> + edid->blocks = state->edid.blocks - edid->start_block;
> +
> + memcpy(edid->edid, data + edid->start_block * 128, edid->blocks *
> 128);
> +
> return 0;
> }
>
> @@ -2068,6 +2066,8 @@ static int adv7604_set_edid(struct v4l2_subdev *sd,
> struct v4l2_edid *edid)
> int err;
> int i;
>
> + memset(edid->reserved, 0, sizeof(edid->reserved));
> +
> if (edid->pad > ADV7604_PAD_HDMI_PORT_D)
> return -EINVAL;
> if (edid->start_block != 0)
> @@ -2164,7 +2164,6 @@ static int adv7604_set_edid(struct v4l2_subdev *sd,
> struct v4l2_edid *edid)
> return -EIO;
> }
>
> -
> /* enable hotplug after 100 ms */
> queue_delayed_work(state->work_queues,
> &state->delayed_work_enable_hotplug, HZ / 10);
> --
> 2.1.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Connecting ADV76xx to CSI via SFMC
Hi, I am working on using the CSI bus of i.MX6 with a adv7611 chip. I started to work with Steve Longerbeam's tree, and here is the current tree I am using : https://github.com/Vodalys/linux-2.6-imx/tree/mx6-camera-staging-v2-vbx This is a WiP tree, and not intended to be complete right now. But at least, it should be possible to get a picture. I will try to be as complete and synthetic as possible... Right now, I am configuring the ADV7611 in "16-Bit SDR ITU-R BT.656 4:2:2 Mode 0" (Table 73 in Appendix C of the Reference Manual). This means that I have pins [15:8] = [Y7..Y0] and [7:0]=[Cb7,Cr7..Cb0,Cr0]. On my board, thanks to a FPGA, pin 15 is connected to MX6QDL_PAD_CSI0_DAT19__IPU1_CSI0_DATA19 and pin 0 to MX6QDL_PAD_CSI0_DAT4__IPU1_CSI0_DATA04. In the source code, I am asking for a 4:2:2 YUYV packed format. Then, when starting the board, I am doing the following : $> v4l2-ctl -d2 --set-fmt-video=width=1280,height=720,pixelformat=YUYV,field=none,bytesperline=2560 -i3 $> v4l2-ctl -d2 --set-dv-bt-timings index=4 -i3 $> [ 69.360256] adv7611 1-004c: -Chip status- [ 69.365652] adv7611 1-004c: Chip power: on [ 69.370446] adv7611 1-004c: EDID enabled port A: No, B: No, C: No, D: No [ 69.378110] adv7611 1-004c: CEC: disabled [ 69.382132] adv7611 1-004c: -Signal status- [ 69.387722] adv7611 1-004c: Cable detected (+5V power) port A: No, B: No, C: No, D: No [ 69.396344] adv7611 1-004c: TMDS signal detected: false [ 69.402245] adv7611 1-004c: TMDS signal locked: false [ 69.408015] adv7611 1-004c: SSPD locked: true [ 69.413047] adv7611 1-004c: STDI locked: false [ 69.417529] adv7611 1-004c: CP locked: true [ 69.422402] adv7611 1-004c: CP free run: on [ 69.429013] adv7611 1-004c: Prim-mode = 0x5, video std = 0x13, v_freq = 0x1 [ 69.436022] adv7611 1-004c: -Video Timings- [ 69.441594] adv7611 1-004c: STDI: not locked [ 69.449212] adv7611 1-004c: No video detected [ 69.453587] adv7611 1-004c: Configured format: 1280x720p50 (1980x750) [ 69.460066] adv7611 1-004c: horizontal: fp = 440, +sync = 40, bp = 220 [ 69.466637] adv7611 1-004c: vertical: fp = 5, +sync = 5, bp = 20 [ 69.472653] adv7611 1-004c: pixelclock: 7425 [ 69.477300] adv7611 1-004c: flags (0x0): [ 69.481233] adv7611 1-004c: standards (0x1): CEA [ 69.490112] adv7604 1-0020: -Chip status- I keep the ADV7611 running in Free mode, which produces a blue frame, with Y=0x23 and Cr=0x72, Cb=0xD4. Now, I try to capture a frame : $> v4l2-ctl -d2 --stream-mmap --stream-to x.raw --stream-count=1 I don't get anything, and here is the dmesg : [ 187.191644] imx-ipuv3 240.ipu: CSI_SENS_CONF = 0x4920 [ 187.191849] imx-ipuv3 240.ipu: CSI_ACT_FRM_SIZE = 0x02CF04FF [ 187.200454] ipu_cpmem_set_image: resolution: 1280x720 stride: 2560 [ 187.200472] ipu_ch_param_write_field 0 125 13 [ 187.200486] ipu_ch_param_write_field 0 138 12 [ 187.200498] ipu_ch_param_write_field 1 102 14 [ 187.200510] ipu_ch_param_write_field 0 107 3 [ 187.200521] ipu_ch_param_write_field 1 85 4 [ 187.200532] ipu_ch_param_write_field 1 78 7 [ 187.200543] ipu_ch_param_write_field 1 0 29 [ 187.200554] ipu_ch_param_write_field 1 29 29 [ 187.200566] ipu_ch_param_write_field 1 78 7 [ 187.200586] ipu_ch_param_write_field 1 93 2 [ 187.201077] mx6-camera-encoder: Enable CSI [ 187.205206] imx-ipuv3 240.ipu: ch 0 word 0 - E0001800 000B3C9F [ 187.205226] imx-ipuv3 240.ipu: ch 0 word 1 - 09E6 013D4000 0103C000 00027FC0 [ 187.205240] ipu_ch_param_read_field 1 85 4 [ 187.205254] imx-ipuv3 240.ipu: PFS 0x8, [ 187.205265] ipu_ch_param_read_field 0 107 3 [ 187.205278] imx-ipuv3 240.ipu: BPP 0x3, [ 187.205289] ipu_ch_param_read_field 1 78 7 [ 187.205302] imx-ipuv3 240.ipu: NPB 0xf [ 187.205313] ipu_ch_param_read_field 0 125 13 [ 187.205326] imx-ipuv3 240.ipu: FW 1279, [ 187.205337] ipu_ch_param_read_field 0 138 12 [ 187.205350] imx-ipuv3 240.ipu: FH 719, [ 187.205361] ipu_ch_param_read_field 1 0 29 [ 187.205374] imx-ipuv3 240.ipu: EBA0 0x4f30 [ 187.205385] ipu_ch_param_read_field 1 29 29 [ 187.205398] imx-ipuv3 240.ipu: EBA1 0x4f50 [ 187.205409] ipu_ch_param_read_field 1 102 14 [ 187.205422] imx-ipuv3 240.ipu: Stride 2559 [ 187.205433] ipu_ch_param_read_field 0 113 1 [ 187.205445] imx-ipuv3 240.ipu: scan_order 0 [ 187.205456] ipu_ch_param_read_field 1 128 14 [ 187.205469] imx-ipuv3 240.ipu: uv_stride 0 [ 187.205480] ipu_ch_param_read_field 0 46 22 [ 187.205492] imx-ipuv3 240.ipu: u_offset 0x0 [ 187.205541] ipu_ch_param_read_field 0 68 22 [ 187.205557] imx-ipuv3 240.ipu: v_offset 0x0 [ 187.205568] ipu_ch_param_read_field 1 116 3 [ 187.205581] imx-ipuv3 240.ipu: Width0 0+1, [ 187.205592] ipu_ch_param_read_field 1 119 3 [ 187.205604] imx-ipuv3 240.ipu: Width1 0+1, [ 187.205615] ipu_ch_param_read_field 1 12
Re: Connecting ADV76xx to CSI via SFMC
Hi Philipp,
Thanks for answering.
2014-11-25 9:16 GMT+01:00 Philipp Zabel :
> Hi Jean-Michel,
>
> Am Montag, den 24.11.2014, 16:19 +0100 schrieb Jean-Michel Hautbois:
>> Hi,
>>
>> I am working on using the CSI bus of i.MX6 with a adv7611 chip.
>> I started to work with Steve Longerbeam's tree, and here is the
>> current tree I am using :
>> https://github.com/Vodalys/linux-2.6-imx/tree/mx6-camera-staging-v2-vbx
>>
>> This is a WiP tree, and not intended to be complete right now.
>> But at least, it should be possible to get a picture.
>> I will try to be as complete and synthetic as possible...
>>
>> Right now, I am configuring the ADV7611 in "16-Bit SDR ITU-R BT.656
>> 4:2:2 Mode 0" (Table 73 in Appendix C of the Reference Manual).
>
> ITU-R BT.656 only specifies 8-bit (or 10-bit) streams, the 16-bit BT.656
> SDR/DDR modes with two values on the bus at the same time are somewhat
> nonstandard. As far as I can tell, this mode should correspond to the
> CSI's BT.1120 SDR mode (Figure 37-20 in MX6DQ Reference Manual v1), so
> I'd expect CSI_SENS_CONF to be configured as DATA_WIDTH=1 (8-bit
> components), SENS_DATA_FORMAT=1 (YUV422), SENS_PRCTL=5 (progressive
> BT.1120 SDR).
OK, so I tested in a brutal way :
diff --git a/drivers/gpu/ipu-v3/ipu-csi.c b/drivers/gpu/ipu-v3/ipu-csi.c
index 293262d..ff48819 100644
--- a/drivers/gpu/ipu-v3/ipu-csi.c
+++ b/drivers/gpu/ipu-v3/ipu-csi.c
@@ -342,10 +342,16 @@ static void fill_csi_bus_cfg(struct
ipu_csi_bus_config *csicfg,
break;
case V4L2_MBUS_BT656:
csicfg->ext_vsync = 0;
- if (V4L2_FIELD_HAS_BOTH(mbus_fmt->field))
- csicfg->clk_mode = IPU_CSI_CLK_MODE_CCIR656_INTERLACED;
+ if (mbus_fmt->code == V4L2_MBUS_FMT_YUYV8_2X8)
+ if (V4L2_FIELD_HAS_BOTH(mbus_fmt->field))
+ csicfg->clk_mode =
IPU_CSI_CLK_MODE_CCIR1120_PROGRESSIVE_SDR;
+ else
+ csicfg->clk_mode =
IPU_CSI_CLK_MODE_CCIR1120_INTERLACED_SDR;
else
- csicfg->clk_mode = IPU_CSI_CLK_MODE_CCIR656_PROGRESSIVE;
+ if (V4L2_FIELD_HAS_BOTH(mbus_fmt->field))
+ csicfg->clk_mode =
IPU_CSI_CLK_MODE_CCIR656_INTERLACED;
+ else
+ csicfg->clk_mode =
IPU_CSI_CLK_MODE_CCIR656_PROGRESSIVE;
break;
case V4L2_MBUS_CSI2:
And before launching capture, I configure manually register 0x3 of
ADV7611 in order to have the SDR 4:2:2 mode I want.
It works better, but still have a little issue :
I am expecting : 0x23 0x72 0x23 0xd4 ...
I am getting : 0x23 0xc8 0x23 0x50
If I take binary values :
0x72 => 01110010b
0xc8 => 11001000b => 0x72 << 2
0xd4 => 11010100
0x50 => 0101 => 0xd4 << 2
In my DT, I have specified :
csi0: endpoint@0 {
reg = <0>;
bus-width = <16>;
data-shift = <4>; /* Lines 19:4 used */
};
pinctrl_ipu1_csi0: ipu1_csi0grp {
fsl,pins = <
MX6QDL_PAD_EIM_D27__IPU1_CSI0_DATA00 0x8000
MX6QDL_PAD_EIM_D26__IPU1_CSI0_DATA01 0x8000
MX6QDL_PAD_EIM_D30__IPU1_CSI0_DATA03 0x8000
MX6QDL_PAD_EIM_D31__IPU1_CSI0_DATA02 0x8000
MX6QDL_PAD_CSI0_DAT4__IPU1_CSI0_DATA04 0x8000
MX6QDL_PAD_CSI0_DAT5__IPU1_CSI0_DATA05 0x8000
MX6QDL_PAD_CSI0_DAT6__IPU1_CSI0_DATA06 0x8000
MX6QDL_PAD_CSI0_DAT7__IPU1_CSI0_DATA07 0x8000
MX6QDL_PAD_CSI0_DAT8__IPU1_CSI0_DATA08 0x8000
MX6QDL_PAD_CSI0_DAT9__IPU1_CSI0_DATA09 0x8000
MX6QDL_PAD_CSI0_DAT10__IPU1_CSI0_DATA10 0x8000
MX6QDL_PAD_CSI0_DAT11__IPU1_CSI0_DATA11 0x8000
MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA12 0x8000
MX6QDL_PAD_CSI0_DAT13__IPU1_CSI0_DATA13 0x8000
MX6QDL_PAD_CSI0_DAT14__IPU1_CSI0_DATA14 0x8000
MX6QDL_PAD_CSI0_DAT15__IPU1_CSI0_DATA15 0x8000
MX6QDL_PAD_CSI0_DAT16__IPU1_CSI0_DATA16 0x8000
MX6QDL_PAD_CSI0_DAT17__IPU1_CSI0_DATA17 0x8000
MX6QDL_PAD_CSI0_DAT18__IPU1_CSI0_DATA18 0x8000
MX6QDL_PAD_CSI0_DAT19__IPU1_CSI0_DATA19 0x8000
/* Clock and Data only : BT.656 mode */
MX6QDL_PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK 0x8000
/*MX6QDL_PAD_CSI0_MCLK__IPU1_CSI0_HSYNC 0x8000
MX6QDL_PAD_CSI0_VSYNC__IPU1_CSI0_VSYNC 0x8000
MX6QDL_PAD_CSI0_DATA_EN__IPU1_CSI0_DATA_EN 0x8000*/
>;
i.MX6 CODA960 encoder
Hi, We are writing a gstreamer plugin to support CODA960 encoder on i.MX6, and it is not working so now trying to use v4l2-ctl for the moment. As I am asking about encoder, is there a way to make it support YUYV as input or is the firmware not able to do it ? I could not find a reference manual about that... So back to the issue. $> cat /sys/class/video4linux/video0/name coda-encoder $> v4l2-ctl -d0 --list-formats ioctl: VIDIOC_ENUM_FMT Index : 0 Type: Video Capture Pixel Format: 'H264' (compressed) Name: H264 Encoded Stream Index : 1 Type: Video Capture Pixel Format: 'MPG4' (compressed) Name: MPEG4 Encoded Stream $> v4l2-ctl -d0 --list-formats-out ioctl: VIDIOC_ENUM_FMT Index : 0 Type: Video Output Pixel Format: 'YU12' Name: YUV 4:2:0 Planar, YCbCr Index : 1 Type: Video Output Pixel Format: 'YV12' Name: YUV 4:2:0 Planar, YCrCb ==> First question, vid-cap should be related to the capture format, so YUV format in the encoder case, no ? $> v4l2-ctl -d0 --set-fmt-video-out=width=1280,height=720,pixelformat=YU12 $> v4l2-ctl -d0 --stream-mmap --stream-out-mmap --stream-to x.raw unsupported pixelformat VIDIOC_STREAMON: failed: Invalid argument And here is the dmesg : [ 444.470057] coda 204.vpu: s_ctrl: id = 9963796, val = 0 [ 444.470093] coda 204.vpu: s_ctrl: id = 9963797, val = 0 [ 444.470118] coda 204.vpu: s_ctrl: id = 10029519, val = 0 [ 444.470140] coda 204.vpu: s_ctrl: id = 10029515, val = 16 [ 444.470162] coda 204.vpu: s_ctrl: id = 10029662, val = 25 [ 444.470183] coda 204.vpu: s_ctrl: id = 10029663, val = 25 [ 444.470205] coda 204.vpu: s_ctrl: id = 10029666, val = 51 [ 444.470226] coda 204.vpu: s_ctrl: id = 10029672, val = 0 [ 444.470248] coda 204.vpu: s_ctrl: id = 10029673, val = 0 [ 444.470268] coda 204.vpu: s_ctrl: id = 10029674, val = 0 [ 444.470289] coda 204.vpu: s_ctrl: id = 10029712, val = 2 [ 444.470310] coda 204.vpu: s_ctrl: id = 10029713, val = 2 [ 444.470330] coda 204.vpu: s_ctrl: id = 10029533, val = 0 [ 444.470351] coda 204.vpu: s_ctrl: id = 10029532, val = 1 [ 444.470372] coda 204.vpu: s_ctrl: id = 10029531, val = 500 [ 444.470393] coda 204.vpu: s_ctrl: id = 10029528, val = 1 [ 444.470414] coda 204.vpu: s_ctrl: id = 10029526, val = 0 [ 444.484473] coda 204.vpu: Created instance 0 (bdade800) [ 444.484503] video0: open (0) [ 444.484586] video0: VIDIOC_QUERYCAP: driver=coda, card=CODA960, bus=platform:coda, version=0x00031200, capabilities=0x84208000, device_caps=0x04208000 [ 444.484685] video0: VIDIOC_QUERYCTRL: id=0x980001, type=6, name=User Controls, min/max=0/0, step=0, default=0, flags=0x0044 [ 444.484768] video0: VIDIOC_QUERYCTRL: id=0x980914, type=2, name=Horizontal Flip, min/max=0/1, step=1, default=0, flags=0x [ 444.487570] video0: VIDIOC_QUERYCTRL: id=0x980915, type=2, name=Vertical Flip, min/max=0/1, step=1, default=0, flags=0x [ 444.487741] video0: VIDIOC_QUERYCTRL: id=0x990001, type=6, name=Codec Controls, min/max=0/0, step=0, default=0, flags=0x0044 [ 444.487818] video0: VIDIOC_QUERYCTRL: id=0x9909cb, type=1, name=Video GOP Size, min/max=1/60, step=1, default=16, flags=0x [ 444.487954] video0: VIDIOC_QUERYCTRL: id=0x9909cf, type=1, name=Video Bitrate, min/max=0/32767000, step=1, default=0, flags=0x [ 444.488109] video0: VIDIOC_QUERYCTRL: id=0x9909d6, type=1, name=Number of Intra Refresh MBs, min/max=0/8160, step=1, default=0, flags=0x [ 444.488280] video0: VIDIOC_QUERYCTRL: id=0x9909d8, type=3, name=Sequence Header Mode, min/max=0/1, step=1, default=1, flags=0x [ 444.488434] video0: VIDIOC_QUERYCTRL: id=0x9909db, type=1, name=Maximum Bytes in a Slice, min/max=1/1073741823, step=1, default=500, flags=0x [ 444.488599] video0: VIDIOC_QUERYCTRL: id=0x9909dc, type=1, name=Number of MBs in a Slice, min/max=1/1073741823, step=1, default=1, flags=0x [ 444.488760] video0: VIDIOC_QUERYCTRL: id=0x9909dd, type=3, name=Slice Partitioning Method, min/max=0/2, step=1, default=0, flags=0x [ 444.488928] video0: VIDIOC_QUERYCTRL: id=0x990a5e, type=1, name=H264 I-Frame QP Value, min/max=0/51, step=1, default=25, flags=0x [ 444.489080] video0: VIDIOC_QUERYCTRL: id=0x990a5f, type=1, name=H264 P-Frame QP Value, min/max=0/51, step=1, default=25, flags=0x [ 444.489234] video0: VIDIOC_QUERYCTRL: id=0x990a62, type=1, name=H264 Maximum QP Value, min/max=0/51, step=1, default=51, flags=0x [ 444.489390] video0: VIDIOC_QUERYCTRL: id=0x990a68, type=1, name=H264 Loop Filter Alpha Offset, min/max=0/15, step=1, default=0, flags=0x [ 444.489565] video0: VIDIOC_QUERYCTRL: id=0x990a69, type=1, name=H264 Loop Filter Beta Offset, min/max=0/15, step=1, default=0, flags=0x [ 444.489737] video0: VIDIOC_QUERYCTRL: id=0x990a6a, type=3, name=H
Re: i.MX6 CODA960 encoder
Hi Philipp, Thanks for answering. 2014-11-26 17:55 GMT+01:00 Philipp Zabel : > Hi Jean-Michel, > > Am Mittwoch, den 26.11.2014, 14:33 +0100 schrieb Jean-Michel Hautbois: >> Hi, >> >> We are writing a gstreamer plugin to support CODA960 encoder on i.MX6, >> and it is not working so now trying to use v4l2-ctl for the moment. >> As I am asking about encoder, is there a way to make it support YUYV >> as input or is the firmware not able to do it ? I could not find a >> reference manual about that... > > The H.264 and MPEG-4 encoders support planar 4:2:0 subsampled formats > only: YU12, YV12, and chroma-interleaved NV12. > The JPEG encoder can also handle planar 4:2:2 subsampled frames, but > none of the interleaved (YUYV, UYVY, ...) variants. OK, just read this in TRM. This means that when the sensor is YUV 4:2:2 (say, a ADV76xx :)) it will have to be converted to NV12 in order to have it as input of the encoder... >> So back to the issue. >> $> cat /sys/class/video4linux/video0/name >> coda-encoder >> $> v4l2-ctl -d0 --list-formats >> ioctl: VIDIOC_ENUM_FMT >> Index : 0 >> Type: Video Capture >> Pixel Format: 'H264' (compressed) >> Name: H264 Encoded Stream >> >> Index : 1 >> Type: Video Capture >> Pixel Format: 'MPG4' (compressed) >> Name: MPEG4 Encoded Stream >> >> $> v4l2-ctl -d0 --list-formats-out >> ioctl: VIDIOC_ENUM_FMT >> Index : 0 >> Type: Video Output >> Pixel Format: 'YU12' >> Name: YUV 4:2:0 Planar, YCbCr >> >> Index : 1 >> Type: Video Output >> Pixel Format: 'YV12' >> Name: YUV 4:2:0 Planar, YCrCb > > Please apply all coda patches in the media-tree master branch first. > The output format list should include NV12 then. OK, applying right now. >> ==> First question, vid-cap should be related to the capture format, >> so YUV format in the encoder case, no ? >> >> $> v4l2-ctl -d0 --set-fmt-video-out=width=1280,height=720,pixelformat=YU12 >> $> v4l2-ctl -d0 --stream-mmap --stream-out-mmap --stream-to x.raw >> unsupported pixelformat >> VIDIOC_STREAMON: failed: Invalid argument > > On v3.18-rc6 with the coda patches currently in the pipeline applied, I > get this: > > $ v4l2-ctl -d0 --set-fmt-video-out=width=1280,height=720,pixelformat=YU12 > $ v4l2-ctl -d0 --stream-mmap --stream-out-mmap --stream-to x.raw > K>P>P>P>P>P>P>P>P>P>P>P>P>P>P>P>K>P>P>P>P>P>P>P>P>P>P>P>P>P>P>P>K>P>P>P>P>P>P > 38 fps >> 38 fps This seems really better, yes :). Well, I come with another question : it seems to be limited in framerate throughput ? I get the same thing with the video capture, I can go up to 33 fps but no more. When I use --stream-mmap=8 I have only two buffers used. Is this the case for you in the encoder too ? JM -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: i.MX6 CODA960 encoder
Hi Philipp, 2014-11-26 18:31 GMT+01:00 Jean-Michel Hautbois : > Hi Philipp, > > Thanks for answering. > > 2014-11-26 17:55 GMT+01:00 Philipp Zabel : >> Hi Jean-Michel, >> >> Am Mittwoch, den 26.11.2014, 14:33 +0100 schrieb Jean-Michel Hautbois: >>> Hi, >>> >>> We are writing a gstreamer plugin to support CODA960 encoder on i.MX6, >>> and it is not working so now trying to use v4l2-ctl for the moment. >>> As I am asking about encoder, is there a way to make it support YUYV >>> as input or is the firmware not able to do it ? I could not find a >>> reference manual about that... >> >> The H.264 and MPEG-4 encoders support planar 4:2:0 subsampled formats >> only: YU12, YV12, and chroma-interleaved NV12. >> The JPEG encoder can also handle planar 4:2:2 subsampled frames, but >> none of the interleaved (YUYV, UYVY, ...) variants. > > OK, just read this in TRM. This means that when the sensor is YUV > 4:2:2 (say, a ADV76xx :)) it will have to be converted to NV12 in > order to have it as input of the encoder... > >>> So back to the issue. >>> $> cat /sys/class/video4linux/video0/name >>> coda-encoder >>> $> v4l2-ctl -d0 --list-formats >>> ioctl: VIDIOC_ENUM_FMT >>> Index : 0 >>> Type: Video Capture >>> Pixel Format: 'H264' (compressed) >>> Name: H264 Encoded Stream >>> >>> Index : 1 >>> Type: Video Capture >>> Pixel Format: 'MPG4' (compressed) >>> Name: MPEG4 Encoded Stream >>> >>> $> v4l2-ctl -d0 --list-formats-out >>> ioctl: VIDIOC_ENUM_FMT >>> Index : 0 >>> Type: Video Output >>> Pixel Format: 'YU12' >>> Name: YUV 4:2:0 Planar, YCbCr >>> >>> Index : 1 >>> Type: Video Output >>> Pixel Format: 'YV12' >>> Name: YUV 4:2:0 Planar, YCrCb >> >> Please apply all coda patches in the media-tree master branch first. >> The output format list should include NV12 then. > > OK, applying right now. > >>> ==> First question, vid-cap should be related to the capture format, >>> so YUV format in the encoder case, no ? >>> >>> $> v4l2-ctl -d0 --set-fmt-video-out=width=1280,height=720,pixelformat=YU12 >>> $> v4l2-ctl -d0 --stream-mmap --stream-out-mmap --stream-to x.raw >>> unsupported pixelformat >>> VIDIOC_STREAMON: failed: Invalid argument >> >> On v3.18-rc6 with the coda patches currently in the pipeline applied, I >> get this: >> >> $ v4l2-ctl -d0 --set-fmt-video-out=width=1280,height=720,pixelformat=YU12 >> $ v4l2-ctl -d0 --stream-mmap --stream-out-mmap --stream-to x.raw >> K>P>P>P>P>P>P>P>P>P>P>P>P>P>P>P>K>P>P>P>P>P>P>P>P>P>P>P>P>P>P>P>K>P>P>P>P>P>P >> 38 fps >>> 38 fps I don't have the same behaviour, but I may have missed a patch. I have taken linux-next and rebased my work on it. I have some issues, but nothing to be worried about, no link with coda. I get the following : $> v4l2-ctl -d0 --set-fmt-video-out=width=1280,height=720,pixelfor $> v4l2-ctl -d0 --stream-mmap --stream-out-mmap --stream-to x.raw [ 173.705701] coda 204.vpu: CODA PIC_RUN timeout JM -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: i.MX6 CODA960 encoder
Hi Philipp,
2014-11-28 16:23 GMT+01:00 Philipp Zabel :
> Am Donnerstag, den 27.11.2014, 16:10 -0200 schrieb Fabio Estevam:
>> On Thu, Nov 27, 2014 at 3:54 PM, Jean-Michel Hautbois
>> wrote:
>>
>> > I don't have the same behaviour, but I may have missed a patch.
>> > I have taken linux-next and rebased my work on it. I have some issues,
>> > but nothing to be worried about, no link with coda.
>> > I get the following :
>> > $> v4l2-ctl -d0 --set-fmt-video-out=width=1280,height=720,pixelfor
>> > $> v4l2-ctl -d0 --stream-mmap --stream-out-mmap --stream-to x.raw
>> > [ 173.705701] coda 204.vpu: CODA PIC_RUN timeout
>>
>> I have this same error with linux-next when I try to decode a file.
>>
>> Philipp,
>>
>> Do you know if linux-next contains all required coda patches?
>>
>> Could this be caused by the fact that we are using an unsupported VPU
>> firmware version?
>
> I missed that the commit a04a0b6fed4f ("ARM: dts: imx6qdl: Enable
> CODA960 VPU") lost the switching of the interrupts between
> http://www.spinics.net/lists/arm-kernel/msg338645.html
> and
> http://www.spinics.net/lists/arm-kernel/msg376571.html .
>
> Of course the JPEG interrupt will never fire when encoding H.264, which
> causes the timeout. Patch in another mail.
OK, I applied the patch you mentionned, and it works ! :)
Now, I will try to make it working with gstreamer...
JM
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
i.MX6 Video combiner
Hi all, I read in the i.MX6 TRM that it can do combining or deinterlacing with VDIC. Has it been tested by anyone ? Could it be a driver, which would allow to do some simple compositing of souces ? Thanks, JM -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: i.MX6 Video combiner
Hi Steve, 2015-02-25 18:54 GMT+01:00 Steve Longerbeam : > On 02/25/2015 09:37 AM, Steve Longerbeam wrote: >> On 02/25/2015 02:57 AM, Jean-Michel Hautbois wrote: >>> Hi all, >>> >>> I read in the i.MX6 TRM that it can do combining or deinterlacing with VDIC. >>> Has it been tested by anyone ? >>> Could it be a driver, which would allow to do some simple compositing >>> of souces ? >>> >>> Thanks, >>> JM >> I've added VDIC support (deinterlace with motion compensation) to the >> capture driver, it's in the my media tree clone: >> >> g...@github.com:slongerbeam/mediatree.git, mx6-media-staging > > it is activated if user sets the motion compensation control to > 1 (low motion), 2 (medium motion), or 3 (high motion), for > example: > > # v4l2-ctl --set-ctrl=motion_compensation=2 Thx for the tip :). And in fact, it is "only" deinterlacing, not combining two planes with background as specified in the TRM (or did I miss something ?). JM -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 0001-media-vb2-Fill-vb2_buffer-with-bytesused-from-user.patch
Hi Sudip, 2015-02-25 19:23 GMT+01:00 Jeremiah Mahler : > Sudip, > > On Wed, Feb 25, 2015 at 03:29:22PM +0800, Sudip JAIN wrote: >> Dear Maintainer, >> >> PFA attached patch that prevents user from being returned garbage bytesused >> value from vb2 framework. >> >> Regards, >> Sudip Jain >> > > Patches should never be submitted as attachments, they should be inline. > > See Documentation/SubmittingPatches for more info. You also can have a look here : http://linuxtv.org/wiki/index.php/Development:_How_to_submit_patches In fact, is the patch on top of master tree ? According to line numbers, I would say no. Thx, JM -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: i.MX6 Video combiner
2015-02-25 22:44 GMT+01:00 Steve Longerbeam : > On 02/25/2015 11:40 AM, Jean-Michel Hautbois wrote: >> Hi Steve, >> >> 2015-02-25 18:54 GMT+01:00 Steve Longerbeam : >>> On 02/25/2015 09:37 AM, Steve Longerbeam wrote: >>>> On 02/25/2015 02:57 AM, Jean-Michel Hautbois wrote: >>>>> Hi all, >>>>> >>>>> I read in the i.MX6 TRM that it can do combining or deinterlacing with >>>>> VDIC. >>>>> Has it been tested by anyone ? >>>>> Could it be a driver, which would allow to do some simple compositing >>>>> of souces ? >>>>> >>>>> Thanks, >>>>> JM >>>> I've added VDIC support (deinterlace with motion compensation) to the >>>> capture driver, it's in the my media tree clone: >>>> >>>> g...@github.com:slongerbeam/mediatree.git, mx6-media-staging >>> it is activated if user sets the motion compensation control to >>> 1 (low motion), 2 (medium motion), or 3 (high motion), for >>> example: >>> >>> # v4l2-ctl --set-ctrl=motion_compensation=2 >> Thx for the tip :). >> And in fact, it is "only" deinterlacing, not combining two planes with >> background as specified in the TRM (or did I miss something ?). > > Hi JM, yes it is deinterlace only, the combiner in the VDIC is not > being used. Well, I don't really know if it would be possible to have it too, and how difficult it is. Maybe as a m2m device, as it could be driven by gstreamer for instance and would replace pure software composition element... I may need to take some time and look further into this, but if anyone has tested it, or can give me advices on how it should be done, it can help (a lot)... :). Thanks, JM -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/12] [media] coda: fail to start streaming if userspace set invalid formats
Hi Philipp,
2015-02-23 16:20 GMT+01:00 Philipp Zabel :
> Signed-off-by: Philipp Zabel
> ---
> drivers/media/platform/coda/coda-common.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/coda/coda-common.c
> b/drivers/media/platform/coda/coda-common.c
> index b42ccfc..4441179 100644
> --- a/drivers/media/platform/coda/coda-common.c
> +++ b/drivers/media/platform/coda/coda-common.c
> @@ -1282,12 +1282,23 @@ static int coda_start_streaming(struct vb2_queue *q,
> unsigned int count)
> if (!(ctx->streamon_out & ctx->streamon_cap))
> return 0;
>
> + q_data_dst = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_CAPTURE);
> + if ((q_data_src->width != q_data_dst->width &&
> +round_up(q_data_src->width, 16) != q_data_dst->width) ||
> + (q_data_src->height != q_data_dst->height &&
> +round_up(q_data_src->height, 16) != q_data_dst->height)) {
> + v4l2_err(v4l2_dev, "can't convert %dx%d to %dx%d\n",
> +q_data_src->width, q_data_src->height,
> +q_data_dst->width, q_data_dst->height);
> + ret = -EINVAL;
> + goto err;
> + }
> +
Shouldn't the driver check on queues related to encoding or decoding only ?
We don't need to set correct width/height from userspace if we are
encoding, or it should be done by s_fmt itself.
Thanks,
JM
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH] v4l2-subdev: allow subdev to send an event to the v4l2_device notify function
All drivers use custom notifications, in particular when source changes.
The bridge only has to map the subdev that sends it to whatever video node it
is connected to.
Signed-off-by: Jean-Michel Hautbois
---
Documentation/video4linux/v4l2-framework.txt | 4
include/media/v4l2-subdev.h | 2 ++
2 files changed, 6 insertions(+)
diff --git a/Documentation/video4linux/v4l2-framework.txt
b/Documentation/video4linux/v4l2-framework.txt
index f586e29..b01068e 100644
--- a/Documentation/video4linux/v4l2-framework.txt
+++ b/Documentation/video4linux/v4l2-framework.txt
@@ -1129,6 +1129,10 @@ available event type is 'class base + 1'.
An example on how the V4L2 events may be used can be found in the OMAP
3 ISP driver (drivers/media/platform/omap3isp).
+A subdev can directly send an event to the v4l2_device notify function with
+V4L2_DEVICE_NOTIFY_EVENT. This allows the bridge to map the subdev that sends
+the event to the video node(s) associated with the subdev that need to be
+informed about such an event.
V4L2 clocks
---
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 5beeb87..1798360 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -40,6 +40,8 @@
#define V4L2_SUBDEV_IR_TX_NOTIFY _IOW('v', 1, u32)
#define V4L2_SUBDEV_IR_TX_FIFO_SERVICE_REQ 0x0001
+#defineV4L2_DEVICE_NOTIFY_EVENT_IOW('v', 2, struct
v4l2_event)
+
struct v4l2_device;
struct v4l2_ctrl_handler;
struct v4l2_event_subscription;
--
2.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [media-workshop] [ANN] Media Mini-Summit Draft Agenda for March 26th
2015-03-21 13:36 GMT+01:00 Laurent Pinchart : > > Hi Hans, > > On Monday 16 March 2015 12:25:28 Hans Verkuil wrote: > > This is the draft agenda for the media mini-summit in San Jose on March > > 26th. > > > > Time: 9 AM to 5 PM (approximately) > > Room: TBC (Mauro, do you know this?) > > > > Attendees: > > > > Mauro Carvalho Chehab - mche...@osg.samsung.com - Samsung > > Laurent Pinchart - laurent.pinch...@ideasonboard.com - Ideas on > > board > > Hans Verkuil - hverk...@xs4all.nl- Cisco > > > > Mauro, do you have a better overview of who else will attend? > > > > Agenda: > > > > Times are approximate and will likely change. > > > > 9:00-9:15 Get everyone installed, laptops hooked up, etc. > > 9:15-9:30 Introduction > > 9:30-10:30 Media Controller support for DVB (Mauro): > > 1) dynamic creation/removal of pipelines > > 2) change media_entity_pipeline_start to also define > > the final entity > > 3) how to setup pipelines that also envolve audio and DRM > > 4) how to lock the media controller pipeline between enabling > > a > > pipeline and starting it, in order to avoid race conditions > > > > See this post for more detailed information: > > > > https://www.mail-archive.com/linux-media@vger.kernel.org/msg85910.html > > > > 10:30-10:45 Break > > 10:45-12:00 Continue discussion > > 12:00-13:00 Lunch (Mauro, do you have any idea whether there is a lunch > > organized, or if we are on our own?) > > 13:00-14:40 Continue discussion > > 14:40-15:00 Break > > 15:00-16:00 Subdev hotplug in the context of both FPGA dynamic > > reconfiguration and project Ara (http://www.projectara.com/) (Laurent). > > To be precise, this will be both hot plug and hot unplug. > > > 16:00-17:00 Update on ongoing projects (Hans): > > - proposal for Android Camera v3-type requests (aka > > configuration > > stores) > > I'm interested in this as well. > > > - work on colorspace improvements > > - vivid & v4l2-compliance improvements > > - removing duplicate subdev video ops and use pad ops instead > > - others? > > There's also the topic of the media device controller registry that we > discussed during the FOSDEM, but as far as I know there has been no progress > in that area. > Unfortunately I can't be there, but am interested by a report on this particular question :). Thanks, JM -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Gefen Toolbox HD pattern signal generator serial control
Hi ! As we are using this pattern generator for our tests and needed to control it with an automated system, we wrote a little library and a tool to control it : https://github.com/Vodalys/gtbhdsiggen Please, feel free to comment, fork, modify :) ! JM -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] media: adv7604: Fix masks used for querying timings in ADV7611
All masks for timings are different between ADV7604 and ADV7611.
Most of the values have 1 precision bit more in the latter.
Fix this by adding new fields to the chip_info structure.
Signed-off-by: Jean-Michel Hautbois
---
drivers/media/i2c/adv7604.c | 69 -
1 file changed, 56 insertions(+), 13 deletions(-)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 60ffcf0..c1be0f7 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -124,6 +124,20 @@ struct adv76xx_chip_info {
unsigned int num_recommended_settings[2];
unsigned long page_mask;
+
+ /* Masks for timings */
+ unsigned int linewidth_mask;
+ unsigned int field0_height_mask;
+ unsigned int field1_height_mask;
+ unsigned int hfrontporch_mask;
+ unsigned int hsync_mask;
+ unsigned int hbackporch_mask;
+ unsigned int field0_vfrontporch_mask;
+ unsigned int field1_vfrontporch_mask;
+ unsigned int field0_vsync_mask;
+ unsigned int field1_vsync_mask;
+ unsigned int field0_vbackporch_mask;
+ unsigned int field1_vbackporch_mask;
};
/*
@@ -1504,23 +1518,28 @@ static int adv76xx_query_dv_timings(struct v4l2_subdev
*sd,
if (is_digital_input(sd)) {
timings->type = V4L2_DV_BT_656_1120;
- /* FIXME: All masks are incorrect for ADV7611 */
- bt->width = hdmi_read16(sd, 0x07, 0xfff);
- bt->height = hdmi_read16(sd, 0x09, 0xfff);
+ bt->width = hdmi_read16(sd, 0x07, info->linewidth_mask);
+ bt->height = hdmi_read16(sd, 0x09, info->field0_height_mask);
bt->pixelclock = info->read_hdmi_pixelclock(sd);
- bt->hfrontporch = hdmi_read16(sd, 0x20, 0x3ff);
- bt->hsync = hdmi_read16(sd, 0x22, 0x3ff);
- bt->hbackporch = hdmi_read16(sd, 0x24, 0x3ff);
- bt->vfrontporch = hdmi_read16(sd, 0x2a, 0x1fff) / 2;
- bt->vsync = hdmi_read16(sd, 0x2e, 0x1fff) / 2;
- bt->vbackporch = hdmi_read16(sd, 0x32, 0x1fff) / 2;
+ bt->hfrontporch = hdmi_read16(sd, 0x20, info->hfrontporch_mask);
+ bt->hsync = hdmi_read16(sd, 0x22, info->hsync_mask);
+ bt->hbackporch = hdmi_read16(sd, 0x24, info->hbackporch_mask);
+ bt->vfrontporch = hdmi_read16(sd, 0x2a,
+ info->field0_vfrontporch_mask) / 2;
+ bt->vsync = hdmi_read16(sd, 0x2e, info->field0_vsync_mask) / 2;
+ bt->vbackporch = hdmi_read16(sd, 0x32,
+ info->field0_vbackporch_mask) / 2;
bt->polarities = ((hdmi_read(sd, 0x05) & 0x10) ?
V4L2_DV_VSYNC_POS_POL : 0) |
((hdmi_read(sd, 0x05) & 0x20) ? V4L2_DV_HSYNC_POS_POL :
0);
if (bt->interlaced == V4L2_DV_INTERLACED) {
- bt->height += hdmi_read16(sd, 0x0b, 0xfff);
- bt->il_vfrontporch = hdmi_read16(sd, 0x2c, 0x1fff) / 2;
- bt->il_vsync = hdmi_read16(sd, 0x30, 0x1fff) / 2;
- bt->il_vbackporch = hdmi_read16(sd, 0x34, 0x1fff) / 2;
+ bt->height += hdmi_read16(sd, 0x0b,
+ info->field1_height_mask);
+ bt->il_vfrontporch = hdmi_read16(sd, 0x2c,
+ info->field1_vfrontporch_mask) / 2;
+ bt->il_vsync = hdmi_read16(sd, 0x30,
+ info->field1_vsync_mask) / 2;
+ bt->il_vbackporch = hdmi_read16(sd, 0x34,
+ info->field1_vbackporch_mask) / 2;
}
adv76xx_fill_optional_dv_timings_fields(sd, timings);
} else {
@@ -2567,6 +2586,18 @@ static const struct adv76xx_chip_info
adv76xx_chip_info[] = {
BIT(ADV76XX_PAGE_EDID) | BIT(ADV76XX_PAGE_HDMI) |
BIT(ADV76XX_PAGE_TEST) | BIT(ADV76XX_PAGE_CP) |
BIT(ADV7604_PAGE_VDP),
+ .linewidth_mask = 0xfff,
+ .field0_height_mask = 0xfff,
+ .field1_height_mask = 0xfff,
+ .hfrontporch_mask = 0x3ff,
+ .hsync_mask = 0x3ff,
+ .hbackporch_mask = 0x3ff,
+ .field0_vfrontporch_mask = 0x1fff,
+ .field0_vsync_mask = 0x1fff,
+ .field0_vbackporch_mask = 0x1fff,
+ .field1_vfrontporch_mask = 0x1fff,
+ .field1_vsync_mask = 0x1fff,
+ .field1_vbackporch_mask = 0x1fff,
},
[ADV7611] = {
.type = ADV7611,
@@ -2596,6 +2627,18 @@ static const struct adv76xx_chip_info
adv76xx_chip_info[] = {
i.MX6 status for IPU/VPU/GPU
Hi there ! We have a custom board, based on i.MX6 SoC. We are currently using Freescale's release of Linux, but this is a 3.10.17 kernel, and several drivers are lacking (adv7611 for instance) or badly written (all the MXC part). As we want to have nice things :) we would like to use a mainline kernel, or at least a tree which can be mainlined. It seems (#v4l told me so) that some people (Steeve :) ?) are working on a rewriting of the IPU and all DRM part for i.MX6. What is the current status (compared to Freescale's release maybe) ? And what can we expect in a near future ? Maybe, how can we help too ? Thanks, JM -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Add support for LMH0395
From: Jean-Michel Hautbois
This device is a SPI based device from TI.
It is a 3 Gbps HD/SD SDI Dual Output Low Power
Extended Reach Adaptive Cable Equalizer.
Add routing support in order to select output
LMH0395 enables the use of up to two outputs.
Signed-off-by: Jean-Michel Hautbois
---
.../devicetree/bindings/media/spi/lmh0395.txt | 24 ++
drivers/media/Kconfig | 1 +
drivers/media/Makefile | 2 +-
drivers/media/spi/Kconfig | 14 ++
drivers/media/spi/Makefile | 1 +
drivers/media/spi/lmh0395.c| 256 +
6 files changed, 297 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/media/spi/lmh0395.txt
create mode 100644 drivers/media/spi/Kconfig
create mode 100644 drivers/media/spi/Makefile
create mode 100644 drivers/media/spi/lmh0395.c
diff --git a/Documentation/devicetree/bindings/media/spi/lmh0395.txt
b/Documentation/devicetree/bindings/media/spi/lmh0395.txt
new file mode 100644
index 000..d55c4eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/spi/lmh0395.txt
@@ -0,0 +1,24 @@
+* Texas Instruments lmh0395 3G HD/SD SDI equalizer
+
+The LMH0395 3 Gbps HD/SD SDI Dual Output Low Power Extended Reach Adaptive
+Cable Equalizer is designed to equalize data transmitted over cable (or any
+media with similar dispersive loss characteristics).
+The equalizer operates over a wide range of data rates from 125 Mbps to 2.97
Gbps
+and supports SMPTE 424M, SMPTE 292M, SMPTE344M, SMPTE 259M, and DVB-ASI
standards.
+
+Required Properties :
+- compatible: Must be "ti,lmh0395"
+
+Example:
+
+ecspi@0201 {
+ ...
+ ...
+
+ lmh0395@1 {
+ compatible = "ti,lmh0395";
+ reg = <1>;
+ spi-max-frequency = <2000>;
+ };
+ ...
+};
diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
index 1d0758a..ce193b0 100644
--- a/drivers/media/Kconfig
+++ b/drivers/media/Kconfig
@@ -199,6 +199,7 @@ config MEDIA_ATTACH
default MODULES
source "drivers/media/i2c/Kconfig"
+source "drivers/media/spi/Kconfig"
source "drivers/media/tuners/Kconfig"
source "drivers/media/dvb-frontends/Kconfig"
diff --git a/drivers/media/Makefile b/drivers/media/Makefile
index 620f275..7578bcd 100644
--- a/drivers/media/Makefile
+++ b/drivers/media/Makefile
@@ -28,6 +28,6 @@ obj-y += rc/
# Finally, merge the drivers that require the core
#
-obj-y += common/ platform/ pci/ usb/ mmc/ firewire/ parport/
+obj-y += common/ platform/ pci/ usb/ mmc/ firewire/ parport/ spi/
obj-$(CONFIG_VIDEO_DEV) += radio/
diff --git a/drivers/media/spi/Kconfig b/drivers/media/spi/Kconfig
new file mode 100644
index 000..291e7ea
--- /dev/null
+++ b/drivers/media/spi/Kconfig
@@ -0,0 +1,14 @@
+if VIDEO_V4L2
+
+config VIDEO_LMH0395
+ tristate "LMH0395 equalizer"
+ depends on VIDEO_V4L2 && SPI && MEDIA_CONTROLLER
+ ---help---
+ Support for TI LMH0395 3G HD/SD SDI Dual Output Low Power
+ Extended Reach Adaptive Cable Equalizer.
+
+ To compile this driver as a module, choose M here: the
+ module will be called lmh0395.
+
+
+endif
diff --git a/drivers/media/spi/Makefile b/drivers/media/spi/Makefile
new file mode 100644
index 000..6c587e5
--- /dev/null
+++ b/drivers/media/spi/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_LMH0395)+= lmh0395.o
diff --git a/drivers/media/spi/lmh0395.c b/drivers/media/spi/lmh0395.c
new file mode 100644
index 000..e287725
--- /dev/null
+++ b/drivers/media/spi/lmh0395.c
@@ -0,0 +1,256 @@
+/*
+ * LMH0395 SPI driver.
+ * Copyright (C) 2014 Jean-Michel Hautbois
+ *
+ * 3G HD/SD SDI Dual Output Low Power Extended Reach Adaptive Cable Equalizer
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int debug;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, "debug level (0-1)");
+
+#defineLMH0395_SPI_CMD_WRITE 0x00
+#defineLMH0395_SPI_CMD_READ0x80
+
+/* Registers of LMH0395 */
+#define LMH0395_GENERAL_CTRL 0x00
+#define LMH0395_OUTPUT_DRIVER 0x01
+#define LMH0395_LAUNCH_AMP_CTRL0x02
+#define LMH0395_MUTE_REF 0x03
+#define LMH0395_DEVICE_ID
Re: i.MX6 status for IPU/VPU/GPU
2014-08-04 13:54 GMT+02:00 Philipp Zabel : > Hi Tim, > > Am Sonntag, den 03.08.2014, 23:14 -0700 schrieb Tim Harvey: >> Philipp, >> >> It is unfortunate that the lack of the media device framework is >> holding back acceptance of Steve's patches. Is this something that can >> be added later? Does your patchset which you posted for reference >> resolve this issue and perhaps is something that everyone could agree >> on for a starting point? > > We should take this step by step. First I'd like to get Steve's ipu-v3 > series in, those don't have any major issues and are a prerequisite for > the media patches anyway. > > The capture patches had a few more issues than just missing media device > support. But this is indeed the biggest one, especially where it > involves a userspace interface that we don't want to have to support in > the future. > My RFC series wasn't without problems either. I'll work on the IPU this > week and then post another RFC. Are the capture patches using v4l2_async_notifier_register() ? I can help integrating/testing all these patches, if you want... JM -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Multiple devices with same SMBus address
Hi,
I have a custom board which has two LMH0303 SDI drivers on the same
i2c bus. They are connected in some daisy chain form, like on the
schematics in the datasheet on page 9 :
http://www.ti.com/lit/ds/symlink/lmh0303.pdf
My problem is how to declare these devices in the DT in order to set
the new adress of the first one when probed.
I thought that something like that could do the trick but it seems crappy :
lmh0303@17 {
new-addr = <0x16>;
rsti_n = <&gpio1_17>; /* GPIO signal connected to the RSTI signal
of the first LMH0303 */
};
lmh0303@17 {
/* Nothing to do right now */
};
This is a draft thought :).
Maybe would it also be possible do define a "super device" like this :
lmh0303@17 {
lmh0303_1 {
new-addr = <0x16>;
rsti_n = <&gpio1_17>; /* GPIO signal connected to the RSTI
signal of the first LMH0303 */
};
lmh0303_2 {
};
};
This would be something like the gpio-leds binding...
But there is probably already a nice way to do that :-) ?
Thanks for your advices !
JM
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: i.MX6 status for IPU/VPU/GPU
Hi Phillip, 2014-08-04 13:54 GMT+02:00 Philipp Zabel : > We should take this step by step. First I'd like to get Steve's ipu-v3 > series in, those don't have any major issues and are a prerequisite for > the media patches anyway. > > The capture patches had a few more issues than just missing media device > support. But this is indeed the biggest one, especially where it > involves a userspace interface that we don't want to have to support in > the future. > My RFC series wasn't without problems either. I'll work on the IPU this > week and then post another RFC. Any news about this ? I saw your patchset from june 12th. What is the current status of this RFC and is there a way to help integrating/testing it ? Do you have a public git repository I can fetch and merge in order to test ? Thanks, JM -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Add support for definition of register maps in DT in ADV7604
From: Jean-Michel Hautbois This patch adds support for DT parsing of register maps adresses. This allows multiple adv76xx devices on the same bus. Signed-off-by: Jean-Michel Hautbois --- .../devicetree/bindings/media/i2c/adv7604.txt | 12 drivers/media/i2c/adv7604.c| 71 ++ 2 files changed, 71 insertions(+), 12 deletions(-) diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt b/Documentation/devicetree/bindings/media/i2c/adv7604.txt index c27cede..33881fb 100644 --- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt +++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt @@ -32,6 +32,18 @@ The digital output port node must contain at least one endpoint. Optional Properties: - reset-gpios: Reference to the GPIO connected to the device's reset pin. + - adv7604-page-avlink: Programmed address for avlink register map + - adv7604-page-cec: Programmed address for cec register map + - adv7604-page-infoframe: Programmed address for infoframe register map + - adv7604-page-esdp: Programmed address for esdp register map + - adv7604-page-dpp: Programmed address for dpp register map + - adv7604-page-afe: Programmed address for afe register map + - adv7604-page-rep: Programmed address for rep register map + - adv7604-page-edid: Programmed address for edid register map + - adv7604-page-hdmi: Programmed address for hdmi register map + - adv7604-page-test: Programmed address for test register map + - adv7604-page-cp: Programmed address for cp register map + - adv7604-page-vdp: Programmed address for vdp register map Optional Endpoint Properties: diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c index d4fa213..89a7034 100644 --- a/drivers/media/i2c/adv7604.c +++ b/drivers/media/i2c/adv7604.c @@ -2718,18 +2718,65 @@ static int adv7604_parse_dt(struct adv7604_state *state) state->pdata.int1_config = ADV7604_INT1_CONFIG_DISABLED; /* Use the default I2C addresses. */ - state->pdata.i2c_addresses[ADV7604_PAGE_AVLINK] = 0x42; - state->pdata.i2c_addresses[ADV7604_PAGE_CEC] = 0x40; - state->pdata.i2c_addresses[ADV7604_PAGE_INFOFRAME] = 0x3e; - state->pdata.i2c_addresses[ADV7604_PAGE_ESDP] = 0x38; - state->pdata.i2c_addresses[ADV7604_PAGE_DPP] = 0x3c; - state->pdata.i2c_addresses[ADV7604_PAGE_AFE] = 0x26; - state->pdata.i2c_addresses[ADV7604_PAGE_REP] = 0x32; - state->pdata.i2c_addresses[ADV7604_PAGE_EDID] = 0x36; - state->pdata.i2c_addresses[ADV7604_PAGE_HDMI] = 0x34; - state->pdata.i2c_addresses[ADV7604_PAGE_TEST] = 0x30; - state->pdata.i2c_addresses[ADV7604_PAGE_CP] = 0x22; - state->pdata.i2c_addresses[ADV7604_PAGE_VDP] = 0x24; + of_property_read_u32(np, "adv7604-page-avlink", + &state->pdata.i2c_addresses[ADV7604_PAGE_AVLINK]); + if (!state->pdata.i2c_addresses[ADV7604_PAGE_AVLINK]) + state->pdata.i2c_addresses[ADV7604_PAGE_AVLINK] = 0x42; + + of_property_read_u32(np, "adv7604-page-cec", + &state->pdata.i2c_addresses[ADV7604_PAGE_CEC]); + if (!state->pdata.i2c_addresses[ADV7604_PAGE_CEC]) + state->pdata.i2c_addresses[ADV7604_PAGE_CEC] = 0x40; + + of_property_read_u32(np, "adv7604-page-infoframe", + &state->pdata.i2c_addresses[ADV7604_PAGE_INFOFRAME]); + if (!state->pdata.i2c_addresses[ADV7604_PAGE_INFOFRAME]) + state->pdata.i2c_addresses[ADV7604_PAGE_INFOFRAME] = 0x3e; + + of_property_read_u32(np, "adv7604-page-esdp", + &state->pdata.i2c_addresses[ADV7604_PAGE_ESDP]); + if (!state->pdata.i2c_addresses[ADV7604_PAGE_ESDP]) + state->pdata.i2c_addresses[ADV7604_PAGE_ESDP] = 0x38; + + of_property_read_u32(np, "adv7604-page-dpp", + &state->pdata.i2c_addresses[ADV7604_PAGE_DPP]); + if (!state->pdata.i2c_addresses[ADV7604_PAGE_DPP]) + state->pdata.i2c_addresses[ADV7604_PAGE_DPP] = 0x3c; + + of_property_read_u32(np, "adv7604-page-afe", + &state->pdata.i2c_addresses[ADV7604_PAGE_AFE]); + if (!state->pdata.i2c_addresses[ADV7604_PAGE_AFE]) + state->pdata.i2c_addresses[ADV7604_PAGE_AFE] = 0x26; + + of_property_read_u32(np, "adv7604-page-rep", + &state->pdata.i2c_addresses[ADV7604_PAGE_REP]); + if (!state->pdata.i2c_addresses[ADV7604_PAGE_REP]) + state->pdata.i2c_addresses[ADV7604_PAGE_REP] = 0x32; + + of_property_read_u32(np, "adv7604-page-edid", + &state->pdata.i2c_addresses[ADV7604_PAGE_EDID]); + if (!state->pdata.i2c_addresses[ADV7
Re: [PATCH] Add support for definition of register maps in DT in ADV7604
2014-08-27 15:03 GMT+02:00 Hans Verkuil : > On 08/27/14 14:53, jean-michel.hautb...@vodalys.com wrote: >> From: Jean-Michel Hautbois >> >> This patch adds support for DT parsing of register maps adresses. >> This allows multiple adv76xx devices on the same bus. >> >> Signed-off-by: Jean-Michel Hautbois >> --- >> .../devicetree/bindings/media/i2c/adv7604.txt | 12 >> drivers/media/i2c/adv7604.c| 71 >> ++ >> 2 files changed, 71 insertions(+), 12 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt >> b/Documentation/devicetree/bindings/media/i2c/adv7604.txt >> index c27cede..33881fb 100644 >> --- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt >> +++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt >> @@ -32,6 +32,18 @@ The digital output port node must contain at least one >> endpoint. >> Optional Properties: >> >>- reset-gpios: Reference to the GPIO connected to the device's reset pin. >> + - adv7604-page-avlink: Programmed address for avlink register map >> + - adv7604-page-cec: Programmed address for cec register map >> + - adv7604-page-infoframe: Programmed address for infoframe register map >> + - adv7604-page-esdp: Programmed address for esdp register map >> + - adv7604-page-dpp: Programmed address for dpp register map >> + - adv7604-page-afe: Programmed address for afe register map >> + - adv7604-page-rep: Programmed address for rep register map >> + - adv7604-page-edid: Programmed address for edid register map >> + - adv7604-page-hdmi: Programmed address for hdmi register map >> + - adv7604-page-test: Programmed address for test register map >> + - adv7604-page-cp: Programmed address for cp register map >> + - adv7604-page-vdp: Programmed address for vdp register map > > Might adv7604-addr-avlink be a better name? Other than that it looks good > to me. > > Hans > I can replace all -page- by -addr- if it seems better... I used page as this is also the name defined in the source code but you are probably right, it is an address, not a page... :) JM -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] Add support for definition of register maps in DT in ADV7604
This patch adds support for DT parsing of register maps adresses. This allows multiple adv76xx devices on the same bus. Signed-off-by: Jean-Michel Hautbois --- .../devicetree/bindings/media/i2c/adv7604.txt | 12 drivers/media/i2c/adv7604.c| 71 ++ 2 files changed, 71 insertions(+), 12 deletions(-) diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt b/Documentation/devicetree/bindings/media/i2c/adv7604.txt index c27cede..21146cb 100644 --- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt +++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt @@ -32,6 +32,18 @@ The digital output port node must contain at least one endpoint. Optional Properties: - reset-gpios: Reference to the GPIO connected to the device's reset pin. + - adv7604-addr-avlink: Programmed address for avlink register map + - adv7604-addr-cec: Programmed address for cec register map + - adv7604-addr-infoframe: Programmed address for infoframe register map + - adv7604-addr-esdp: Programmed address for esdp register map + - adv7604-addr-dpp: Programmed address for dpp register map + - adv7604-addr-afe: Programmed address for afe register map + - adv7604-addr-rep: Programmed address for rep register map + - adv7604-addr-edid: Programmed address for edid register map + - adv7604-addr-hdmi: Programmed address for hdmi register map + - adv7604-addr-test: Programmed address for test register map + - adv7604-addr-cp: Programmed address for cp register map + - adv7604-addr-vdp: Programmed address for vdp register map Optional Endpoint Properties: diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c index d4fa213..d15a05f 100644 --- a/drivers/media/i2c/adv7604.c +++ b/drivers/media/i2c/adv7604.c @@ -2718,18 +2718,65 @@ static int adv7604_parse_dt(struct adv7604_state *state) state->pdata.int1_config = ADV7604_INT1_CONFIG_DISABLED; /* Use the default I2C addresses. */ - state->pdata.i2c_addresses[ADV7604_PAGE_AVLINK] = 0x42; - state->pdata.i2c_addresses[ADV7604_PAGE_CEC] = 0x40; - state->pdata.i2c_addresses[ADV7604_PAGE_INFOFRAME] = 0x3e; - state->pdata.i2c_addresses[ADV7604_PAGE_ESDP] = 0x38; - state->pdata.i2c_addresses[ADV7604_PAGE_DPP] = 0x3c; - state->pdata.i2c_addresses[ADV7604_PAGE_AFE] = 0x26; - state->pdata.i2c_addresses[ADV7604_PAGE_REP] = 0x32; - state->pdata.i2c_addresses[ADV7604_PAGE_EDID] = 0x36; - state->pdata.i2c_addresses[ADV7604_PAGE_HDMI] = 0x34; - state->pdata.i2c_addresses[ADV7604_PAGE_TEST] = 0x30; - state->pdata.i2c_addresses[ADV7604_PAGE_CP] = 0x22; - state->pdata.i2c_addresses[ADV7604_PAGE_VDP] = 0x24; + of_property_read_u32(np, "adv7604-addr-avlink", + &state->pdata.i2c_addresses[ADV7604_PAGE_AVLINK]); + if (!state->pdata.i2c_addresses[ADV7604_PAGE_AVLINK]) + state->pdata.i2c_addresses[ADV7604_PAGE_AVLINK] = 0x42; + + of_property_read_u32(np, "adv7604-addr-cec", + &state->pdata.i2c_addresses[ADV7604_PAGE_CEC]); + if (!state->pdata.i2c_addresses[ADV7604_PAGE_CEC]) + state->pdata.i2c_addresses[ADV7604_PAGE_CEC] = 0x40; + + of_property_read_u32(np, "adv7604-addr-infoframe", + &state->pdata.i2c_addresses[ADV7604_PAGE_INFOFRAME]); + if (!state->pdata.i2c_addresses[ADV7604_PAGE_INFOFRAME]) + state->pdata.i2c_addresses[ADV7604_PAGE_INFOFRAME] = 0x3e; + + of_property_read_u32(np, "adv7604-addr-esdp", + &state->pdata.i2c_addresses[ADV7604_PAGE_ESDP]); + if (!state->pdata.i2c_addresses[ADV7604_PAGE_ESDP]) + state->pdata.i2c_addresses[ADV7604_PAGE_ESDP] = 0x38; + + of_property_read_u32(np, "adv7604-addr-dpp", + &state->pdata.i2c_addresses[ADV7604_PAGE_DPP]); + if (!state->pdata.i2c_addresses[ADV7604_PAGE_DPP]) + state->pdata.i2c_addresses[ADV7604_PAGE_DPP] = 0x3c; + + of_property_read_u32(np, "adv7604-addr-afe", + &state->pdata.i2c_addresses[ADV7604_PAGE_AFE]); + if (!state->pdata.i2c_addresses[ADV7604_PAGE_AFE]) + state->pdata.i2c_addresses[ADV7604_PAGE_AFE] = 0x26; + + of_property_read_u32(np, "adv7604-addr-rep", + &state->pdata.i2c_addresses[ADV7604_PAGE_REP]); + if (!state->pdata.i2c_addresses[ADV7604_PAGE_REP]) + state->pdata.i2c_addresses[ADV7604_PAGE_REP] = 0x32; + + of_property_read_u32(np, "adv7604-addr-edid", + &state->pdata.i2c_addresses[ADV7604_PAGE_EDID]); + if (!state->pdata.i2c_addresses[ADV7604_PAGE_EDID]) +
[PATCH 1/2] Allow DT parsing of secondary devices
This is based on reg and reg-names in DT.
Example:
reg = <0x10 0x20 0x30>;
reg-names = "main", "io", "test";
This function will create dummy devices io and test
with addresses 0x20 and 0x30 respectively.
Signed-off-by: Jean-Michel Hautbois
---
drivers/i2c/i2c-core.c | 20
include/linux/i2c.h| 6 ++
2 files changed, 26 insertions(+)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 632057a..5eb414d 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -798,6 +798,26 @@ struct i2c_client *i2c_new_dummy(struct i2c_adapter
*adapter, u16 address)
}
EXPORT_SYMBOL_GPL(i2c_new_dummy);
+struct i2c_client *i2c_new_secondary_device(struct i2c_client *client,
+ const char *name,
+ u32 default_addr)
+{
+ int i, addr;
+ struct device_node *np;
+
+ np = client->dev.of_node;
+ i = of_property_match_string(np, "reg-names", name);
+ if (i >= 0)
+ of_property_read_u32_index(np, "reg", i, &addr);
+ else
+ addr = default_addr;
+
+ dev_dbg(&client->adapter->dev, "Address for %s : 0x%x\n", name, addr);
+ return i2c_new_dummy(client->adapter, addr);
+}
+EXPORT_SYMBOL_GPL(i2c_new_secondary_device);
+
+
/* - */
/* I2C bus adapters -- one roots each I2C or SMBUS segment */
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index a95efeb..2d143d7 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -322,6 +322,12 @@ extern int i2c_probe_func_quick_read(struct i2c_adapter *,
unsigned short addr);
extern struct i2c_client *
i2c_new_dummy(struct i2c_adapter *adap, u16 address);
+/* Use reg/reg-names in DT in order to get extra addresses */
+extern struct i2c_client *
+i2c_new_secondary_device(struct i2c_client *client,
+ const char *name,
+ u32 default_addr);
+
extern void i2c_unregister_device(struct i2c_client *);
#endif /* I2C */
--
2.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] adv7604: Use DT parsing in dummy creation
This patch uses DT in order to parse addresses for dummy devices of adv7604.
If nothing is defined, it uses default addresses.
The main prupose is using two adv76xx on the same i2c bus.
Signed-off-by: Jean-Michel Hautbois
---
.../devicetree/bindings/media/i2c/adv7604.txt | 7 ++-
drivers/media/i2c/adv7604.c| 56 ++
2 files changed, 42 insertions(+), 21 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
index c27cede..221b75c 100644
--- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
+++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
@@ -10,6 +10,7 @@ Required Properties:
- compatible: Must contain one of the following
- "adi,adv7611" for the ADV7611
+- "adi,adv7604" for the ADV7604
- reg: I2C slave address
@@ -32,6 +33,8 @@ The digital output port node must contain at least one
endpoint.
Optional Properties:
- reset-gpios: Reference to the GPIO connected to the device's reset pin.
+ - reg-names : Names of registers to be reprogrammed.
+ Refer to source code for possible values.
Optional Endpoint Properties:
@@ -50,7 +53,9 @@ Example:
hdmi_receiver@4c {
compatible = "adi,adv7611";
- reg = <0x4c>;
+ /* edid page will be accessible @ 0x66 on i2c bus*/
+ reg = <0x4c 0x66>;
+ reg-names = "main", "edid";
reset-gpios = <&ioexp 0 GPIO_ACTIVE_LOW>;
hpd-gpios = <&ioexp 2 GPIO_ACTIVE_HIGH>;
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index d4fa213..4e660a2 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -326,6 +326,22 @@ static const struct adv7604_video_standards
adv7604_prim_mode_hdmi_gr[] = {
{ },
};
+static const char const *adv7604_secondary_names[] = {
+ "main", /* ADV7604_PAGE_IO */
+ "avlink", /* ADV7604_PAGE_AVLINK */
+ "cec", /* ADV7604_PAGE_CEC */
+ "infoframe", /* ADV7604_PAGE_INFOFRAME */
+ "esdp", /* ADV7604_PAGE_ESDP */
+ "dpp", /* ADV7604_PAGE_DPP */
+ "afe", /* ADV7604_PAGE_AFE */
+ "rep", /* ADV7604_PAGE_REP */
+ "edid", /* ADV7604_PAGE_EDID */
+ "hdmi", /* ADV7604_PAGE_HDMI */
+ "test", /* ADV7604_PAGE_TEST */
+ "cp", /* ADV7604_PAGE_CP */
+ "vdp" /* ADV7604_PAGE_VDP */
+};
+
/* --- */
static inline struct adv7604_state *to_state(struct v4l2_subdev *sd)
@@ -2528,13 +2544,27 @@ static void adv7604_unregister_clients(struct
adv7604_state *state)
}
static struct i2c_client *adv7604_dummy_client(struct v4l2_subdev *sd,
- u8 addr, u8 io_reg)
+ unsigned int i)
{
struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct adv7604_platform_data *pdata = client->dev.platform_data;
+ unsigned int io_reg = 0xf2 + i;
+ struct i2c_client *new_client;
+
+ /* Try to find it in DT */
+ new_client = i2c_new_secondary_device(client,
+ adv7604_secondary_names[i], io_read(sd, io_reg) >> 1);
- if (addr)
- io_write(sd, io_reg, addr << 1);
- return i2c_new_dummy(client->adapter, io_read(sd, io_reg) >> 1);
+ if (!new_client)
+ /* if not defined in DT, use default if available */
+ if (pdata && pdata->i2c_addresses[i])
+ new_client = i2c_new_dummy(client->adapter,
+ pdata->i2c_addresses[i]);
+
+ if (new_client)
+ io_write(sd, io_reg, new_client->addr << 1);
+
+ return new_client;
}
static const struct adv7604_reg_seq adv7604_recommended_settings_afe[] = {
@@ -2677,6 +2707,7 @@ MODULE_DEVICE_TABLE(i2c, adv7604_i2c_id);
static struct of_device_id adv7604_of_id[] __maybe_unused = {
{ .compatible = "adi,adv7611", .data = &adv7604_chip_info[ADV7611] },
+ { .compatible = "adi,adv7604", .data = &adv7604_chip_info[ADV7604] },
{ }
};
MODULE_DEVICE_TABLE(of, adv7604_of_id);
@@ -2717,20 +2748,6 @@ static int adv7604_parse_dt(struct adv7604_state *state)
/* Disable the interrupt for now as no DT-based board uses it. */
state->pdata.int1_config = ADV7604_INT1_CONFIG_DISABLED;
- /* Use the default I2C addresses. */
- state->pdata.i2c_addresses[ADV7604_PAGE_AVLINK] = 0x42;
- state->pdata.i2c_addresses[ADV7604
[PATCH v2 2/2] adv7604: Use DT parsing in dummy creation
This patch uses DT in order to parse addresses for dummy devices of adv7604.
The ADV7604 has thirteen 256-byte maps that can be accessed via the main
I²C ports. Each map has it own I²C address and acts
as a standard slave device on the I²C bus.
If nothing is defined, it uses default addresses.
The main prupose is using two adv76xx on the same i2c bus.
Signed-off-by: Jean-Michel Hautbois
---
.../devicetree/bindings/media/i2c/adv7604.txt | 17 +-
drivers/media/i2c/adv7604.c| 60 ++
2 files changed, 55 insertions(+), 22 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
index c27cede..8486b5c 100644
--- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
+++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
@@ -10,8 +10,12 @@ Required Properties:
- compatible: Must contain one of the following
- "adi,adv7611" for the ADV7611
+- "adi,adv7604" for the ADV7604
- - reg: I2C slave address
+ - reg: I2C slave addresses
+The ADV7604 has thirteen 256-byte maps that can be accessed via the main
+I²C ports. Each map has it own I²C address and acts
+as a standard slave device on the I²C bus.
- hpd-gpios: References to the GPIOs that control the HDMI hot-plug
detection pins, one per HDMI input. The active flag indicates the GPIO
@@ -32,6 +36,12 @@ The digital output port node must contain at least one
endpoint.
Optional Properties:
- reset-gpios: Reference to the GPIO connected to the device's reset pin.
+ - reg-names : Names of maps with programmable addresses.
+ It can contain any map needing another address than default one.
+ Possible maps names are :
+ADV7604 : "main", "avlink", "cec", "infoframe", "esdp", "dpp", "afe", "rep",
+ "edid", "hdmi", "test", "cp", "vdp"
+ADV7611 : "main", "cec", "infoframe", "afe", "rep", "edid", "hdmi", "cp"
Optional Endpoint Properties:
@@ -50,7 +60,10 @@ Example:
hdmi_receiver@4c {
compatible = "adi,adv7611";
- reg = <0x4c>;
+ /* edid page will be accessible @ 0x66 on i2c bus */
+ /* other maps keep their default addresses */
+ reg = <0x4c 0x66>;
+ reg-names = "main", "edid";
reset-gpios = <&ioexp 0 GPIO_ACTIVE_LOW>;
hpd-gpios = <&ioexp 2 GPIO_ACTIVE_HIGH>;
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index d4fa213..56037dd 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -326,6 +326,22 @@ static const struct adv7604_video_standards
adv7604_prim_mode_hdmi_gr[] = {
{ },
};
+static const char const *adv7604_secondary_names[] = {
+ "main", /* ADV7604_PAGE_IO */
+ "avlink", /* ADV7604_PAGE_AVLINK */
+ "cec", /* ADV7604_PAGE_CEC */
+ "infoframe", /* ADV7604_PAGE_INFOFRAME */
+ "esdp", /* ADV7604_PAGE_ESDP */
+ "dpp", /* ADV7604_PAGE_DPP */
+ "afe", /* ADV7604_PAGE_AFE */
+ "rep", /* ADV7604_PAGE_REP */
+ "edid", /* ADV7604_PAGE_EDID */
+ "hdmi", /* ADV7604_PAGE_HDMI */
+ "test", /* ADV7604_PAGE_TEST */
+ "cp", /* ADV7604_PAGE_CP */
+ "vdp" /* ADV7604_PAGE_VDP */
+};
+
/* --- */
static inline struct adv7604_state *to_state(struct v4l2_subdev *sd)
@@ -2528,13 +2544,31 @@ static void adv7604_unregister_clients(struct
adv7604_state *state)
}
static struct i2c_client *adv7604_dummy_client(struct v4l2_subdev *sd,
- u8 addr, u8 io_reg)
+ unsigned int i)
{
struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct adv7604_platform_data *pdata = client->dev.platform_data;
+ unsigned int io_reg = 0xf2 + i;
+ unsigned int default_addr = io_read(sd, io_reg) >> 1;
+ struct i2c_client *new_client;
+
+ if (IS_ENABLED(CONFIG_OF)) {
+ /* Try to find it in DT */
+ new_client = i2c_new_secondary_device(client,
+ adv7604_secondary_names[i], default_addr);
+ } else if (pdata) {
+ if (pdata->i2c_addresses[i])
+ new_client = i2c_new_dummy(client->adapter,
+ pdata->i2c_addresses[i]);
+
[PATCH v2 1/2] Allow DT parsing of secondary devices
This is based on reg and reg-names in DT.
Example:
reg = <0x10 0x20 0x30>;
reg-names = "main", "io", "test";
This function will create dummy devices io and test
with addresses 0x20 and 0x30 respectively.
Signed-off-by: Jean-Michel Hautbois
---
drivers/i2c/i2c-core.c | 20
include/linux/i2c.h| 6 ++
2 files changed, 26 insertions(+)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 632057a..5eb414d 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -798,6 +798,26 @@ struct i2c_client *i2c_new_dummy(struct i2c_adapter
*adapter, u16 address)
}
EXPORT_SYMBOL_GPL(i2c_new_dummy);
+struct i2c_client *i2c_new_secondary_device(struct i2c_client *client,
+ const char *name,
+ u32 default_addr)
+{
+ int i, addr;
+ struct device_node *np;
+
+ np = client->dev.of_node;
+ i = of_property_match_string(np, "reg-names", name);
+ if (i >= 0)
+ of_property_read_u32_index(np, "reg", i, &addr);
+ else
+ addr = default_addr;
+
+ dev_dbg(&client->adapter->dev, "Address for %s : 0x%x\n", name, addr);
+ return i2c_new_dummy(client->adapter, addr);
+}
+EXPORT_SYMBOL_GPL(i2c_new_secondary_device);
+
+
/* - */
/* I2C bus adapters -- one roots each I2C or SMBUS segment */
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index a95efeb..2d143d7 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -322,6 +322,12 @@ extern int i2c_probe_func_quick_read(struct i2c_adapter *,
unsigned short addr);
extern struct i2c_client *
i2c_new_dummy(struct i2c_adapter *adap, u16 address);
+/* Use reg/reg-names in DT in order to get extra addresses */
+extern struct i2c_client *
+i2c_new_secondary_device(struct i2c_client *client,
+ const char *name,
+ u32 default_addr);
+
extern void i2c_unregister_device(struct i2c_client *);
#endif /* I2C */
--
2.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] adv7604: Use DT parsing in dummy creation
2014-08-31 19:18 GMT+02:00 Laurent Pinchart :
> Hi Jean-Michel,
>
> Thank you for the patch.
>
> On Friday 29 August 2014 17:15:03 Jean-Michel Hautbois wrote:
>> This patch uses DT in order to parse addresses for dummy devices of adv7604.
>> The ADV7604 has thirteen 256-byte maps that can be accessed via the main
>> I²C ports. Each map has it own I²C address and acts
>> as a standard slave device on the I²C bus.
>>
>> If nothing is defined, it uses default addresses.
>> The main prupose is using two adv76xx on the same i2c bus.
>>
>> Signed-off-by: Jean-Michel Hautbois
>> ---
>> .../devicetree/bindings/media/i2c/adv7604.txt | 17 +-
>> drivers/media/i2c/adv7604.c| 60 ---
>> 2 files changed, 55 insertions(+), 22 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
>> b/Documentation/devicetree/bindings/media/i2c/adv7604.txt index
>> c27cede..8486b5c 100644
>> --- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
>> +++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
>> @@ -10,8 +10,12 @@ Required Properties:
>>
>>- compatible: Must contain one of the following
>> - "adi,adv7611" for the ADV7611
>> +- "adi,adv7604" for the ADV7604
>
> Addition of ADV7604 support is unrelated to the subject and needs to be split
> into a separate patch.
OK, I will do that.
>> - - reg: I2C slave address
>> + - reg: I2C slave addresses
>> +The ADV7604 has thirteen 256-byte maps that can be accessed via the
>> main
>> +I²C ports. Each map has it own I²C address and acts
>> +as a standard slave device on the I²C bus.
>>
>>- hpd-gpios: References to the GPIOs that control the HDMI hot-plug
>> detection pins, one per HDMI input. The active flag indicates the GPIO
>> @@ -32,6 +36,12 @@ The digital output port node must contain at least one
>> endpoint. Optional Properties:
>>
>>- reset-gpios: Reference to the GPIO connected to the device's reset pin.
>> + - reg-names : Names of maps with programmable addresses.
>> + It can contain any map needing another address than default
>> one.
>> + Possible maps names are :
>> +ADV7604 : "main", "avlink", "cec", "infoframe", "esdp", "dpp", "afe",
>> "rep",
>> + "edid", "hdmi", "test", "cp", "vdp"
>> +ADV7611 : "main", "cec", "infoframe", "afe", "rep", "edid", "hdmi", "cp"
>>
>> Optional Endpoint Properties:
>>
>> @@ -50,7 +60,10 @@ Example:
>>
>> hdmi_receiver@4c {
>> compatible = "adi,adv7611";
>> - reg = <0x4c>;
>> + /* edid page will be accessible @ 0x66 on i2c bus */
>> + /* other maps keep their default addresses */
>> + reg = <0x4c 0x66>;
>> + reg-names = "main", "edid";
>>
>> reset-gpios = <&ioexp 0 GPIO_ACTIVE_LOW>;
>> hpd-gpios = <&ioexp 2 GPIO_ACTIVE_HIGH>;
>> diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
>> index d4fa213..56037dd 100644
>> --- a/drivers/media/i2c/adv7604.c
>> +++ b/drivers/media/i2c/adv7604.c
>> @@ -326,6 +326,22 @@ static const struct adv7604_video_standards
>> adv7604_prim_mode_hdmi_gr[] = { { },
>> };
>>
>> +static const char const *adv7604_secondary_names[] = {
>> + "main", /* ADV7604_PAGE_IO */
>> + "avlink", /* ADV7604_PAGE_AVLINK */
>> + "cec", /* ADV7604_PAGE_CEC */
>> + "infoframe", /* ADV7604_PAGE_INFOFRAME */
>> + "esdp", /* ADV7604_PAGE_ESDP */
>> + "dpp", /* ADV7604_PAGE_DPP */
>> + "afe", /* ADV7604_PAGE_AFE */
>> + "rep", /* ADV7604_PAGE_REP */
>> + "edid", /* ADV7604_PAGE_EDID */
>> + "hdmi", /* ADV7604_PAGE_HDMI */
>> + "test", /* ADV7604_PAGE_TEST */
>> + "cp", /* ADV7604_PAGE_CP */
>> + "vdp" /* ADV7604_PAGE_VDP */
>> +};
>> +
>> /* ---
>> */
>>
>> static inline struct adv7604_state *to_state(struct v4l2_subdev *sd)
>> @@ -2528,13 +2544,31 @@ sta
ADV76xx : Endpoint parsing
Hi, I am trying to understand how endpoint parsing is done in adv7604/11 and the main objective is to get adv7604 endpoint parsing from DT for all its ports (4 HDMI and one VGA as input, one output). I am stuck on the function adv7604_parse_dt(). Tell me if I am wrong, but this function takes the first endpoint from DT, puts the node, and that's all... At least for ADV7611, there is two endpoints : one HDMI as input, one output. I am not even sure that this function gets both... And last but not least, how can we get support for all endpoints in the ADV7604 case ? Thanks, JM -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] adv7604: Add DT parsing support
This allows specifying I²C secodnary addresses different from default ones.
Signed-off-by: Jean-Michel Hautbois
---
drivers/media/i2c/adv7604.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 8336c02..75613a4 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -2705,6 +2705,7 @@ MODULE_DEVICE_TABLE(i2c, adv7604_i2c_id);
static struct of_device_id adv7604_of_id[] __maybe_unused = {
{ .compatible = "adi,adv7611", .data = &adv7604_chip_info[ADV7611] },
+ { .compatible = "adi,adv7604", .data = &adv7604_chip_info[ADV7604] },
{ }
};
MODULE_DEVICE_TABLE(of, adv7604_of_id);
--
2.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] adv7604: Add support for i2c_new_secondary_device
The ADV7604 has thirteen 256-byte maps that can be accessed via the main
I²C ports. Each map has it own I²C address and acts
as a standard slave device on the I²C bus.
If nothing is defined, it uses default addresses.
The main purpose is using two adv76xx on the same i2c bus.
Signed-off-by: Jean-Michel Hautbois
---
.../devicetree/bindings/media/i2c/adv7604.txt | 17 ++-
drivers/media/i2c/adv7604.c| 53 ++
2 files changed, 48 insertions(+), 22 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
index c27cede..8486b5c 100644
--- a/Documentation/devicetree/bindings/media/i2c/adv7604.txt
+++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
@@ -10,8 +10,12 @@ Required Properties:
- compatible: Must contain one of the following
- "adi,adv7611" for the ADV7611
+- "adi,adv7604" for the ADV7604
- - reg: I2C slave address
+ - reg: I2C slave addresses
+The ADV7604 has thirteen 256-byte maps that can be accessed via the main
+I²C ports. Each map has it own I²C address and acts
+as a standard slave device on the I²C bus.
- hpd-gpios: References to the GPIOs that control the HDMI hot-plug
detection pins, one per HDMI input. The active flag indicates the GPIO
@@ -32,6 +36,12 @@ The digital output port node must contain at least one
endpoint.
Optional Properties:
- reset-gpios: Reference to the GPIO connected to the device's reset pin.
+ - reg-names : Names of maps with programmable addresses.
+ It can contain any map needing another address than default one.
+ Possible maps names are :
+ADV7604 : "main", "avlink", "cec", "infoframe", "esdp", "dpp", "afe", "rep",
+ "edid", "hdmi", "test", "cp", "vdp"
+ADV7611 : "main", "cec", "infoframe", "afe", "rep", "edid", "hdmi", "cp"
Optional Endpoint Properties:
@@ -50,7 +60,10 @@ Example:
hdmi_receiver@4c {
compatible = "adi,adv7611";
- reg = <0x4c>;
+ /* edid page will be accessible @ 0x66 on i2c bus */
+ /* other maps keep their default addresses */
+ reg = <0x4c 0x66>;
+ reg-names = "main", "edid";
reset-gpios = <&ioexp 0 GPIO_ACTIVE_LOW>;
hpd-gpios = <&ioexp 2 GPIO_ACTIVE_HIGH>;
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index d4fa213..8336c02 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -326,6 +326,22 @@ static const struct adv7604_video_standards
adv7604_prim_mode_hdmi_gr[] = {
{ },
};
+static const char const *adv7604_secondary_names[] = {
+ [ADV7604_PAGE_IO] = "main",
+ [ADV7604_PAGE_AVLINK] = "avlink",
+ [ADV7604_PAGE_CEC] = "cec",
+ [ADV7604_PAGE_INFOFRAME] = "infoframe",
+ [ADV7604_PAGE_ESDP] = "esdp",
+ [ADV7604_PAGE_DPP] = "dpp",
+ [ADV7604_PAGE_AFE] = "afe",
+ [ADV7604_PAGE_REP] = "rep",
+ [ADV7604_PAGE_EDID] = "edid",
+ [ADV7604_PAGE_HDMI] = "hdmi",
+ [ADV7604_PAGE_TEST] = "test",
+ [ADV7604_PAGE_CP] = "cp",
+ [ADV7604_PAGE_VDP] = "vdp"
+};
+
/* --- */
static inline struct adv7604_state *to_state(struct v4l2_subdev *sd)
@@ -2528,13 +2544,25 @@ static void adv7604_unregister_clients(struct
adv7604_state *state)
}
static struct i2c_client *adv7604_dummy_client(struct v4l2_subdev *sd,
- u8 addr, u8 io_reg)
+ unsigned int i)
{
struct i2c_client *client = v4l2_get_subdevdata(sd);
+ struct adv7604_platform_data *pdata = client->dev.platform_data;
+ unsigned int io_reg = 0xf2 + i;
+ unsigned int default_addr = io_read(sd, io_reg) >> 1;
+ struct i2c_client *new_client;
+
+ if (pdata && pdata->i2c_addresses[i])
+ new_client = i2c_new_dummy(client->adapter,
+ pdata->i2c_addresses[i]);
+ else
+ new_client = i2c_new_secondary_device(client,
+ adv7604_secondary_names[i], default_addr);
- if (addr)
- io_write(sd, io_reg, addr << 1);
- return i2c_new_dummy(client->adapter, io_read(sd, io_reg) >> 1);
+ if (new_client)
+ io_write(sd, io
Re: i.MX6 status for IPU/VPU/GPU
2014-08-27 16:23 GMT+02:00 Steve Longerbeam : > Hi Jean-Michel, Phillip, Hi Steve, > I've done some work on Philipp's June 12 patchset, converting > the CSI driver to a CSI subdev entity, and fixing some issues here > and there. This June 12 patchset doesn't appear to be a fully working > driver, Phillip correct me if I am wrong. I can post this work as it > exists, it is incomplete but compiles. Dos it compile against a 3.17-rc3 kernel :) ? > I've also worked out what I think is a workable video pipeline graph for i.MX, > suitable for defining the entities, pads, and links. Unfortunately I haven't > been able to spend as much time as I'd like on it. This is very interesting, do you have written this somewhere ? > The complete driver I posted to the list does have some minor issues > mostly suggested by Hans Verkuil (switch to new selection API instead > of cropping API for example). It is a full featured driver but it does not > implement the media device framework, i.e. user does not have direct > control of the video pipeline, rather the driver chooses the pipeline based > on the traditional inputs from user (video format and controls). > > If there is interest I can submit another version of the traditional driver > to resolve the issues. But media device is a major rework, so I don't > know whether it would make sense to start from the traditional driver > and then implement media device on top later, since media device > is almost a complete rewrite. I, at least, am interested by this driver, even in its "traditionnal" form :). If you don't want to submit it directly because this is not using media controller, this is ok, you can provide me a git repo in order to get it, or send a patchset. JM -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] media: spi: Add support for LMH0395
This device is a SPI based device from TI.
It is a 3 Gbps HD/SD SDI Dual Output Low Power
Extended Reach Adaptive Cable Equalizer.
LMH0395 enables the use of up to two outputs.
These can be configured using DT.
Controls should be accessible from userspace too...
Signed-off-by: Jean-Michel Hautbois
---
.../devicetree/bindings/media/spi/lmh0395.txt | 44 +++
MAINTAINERS| 6 +
drivers/media/spi/Kconfig | 14 +
drivers/media/spi/Makefile | 1 +
drivers/media/spi/lmh0395.c| 355 +
5 files changed, 420 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/spi/lmh0395.txt
create mode 100644 drivers/media/spi/Kconfig
create mode 100644 drivers/media/spi/Makefile
create mode 100644 drivers/media/spi/lmh0395.c
diff --git a/Documentation/devicetree/bindings/media/spi/lmh0395.txt
b/Documentation/devicetree/bindings/media/spi/lmh0395.txt
new file mode 100644
index 000..0a640a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/spi/lmh0395.txt
@@ -0,0 +1,44 @@
+* Texas Instruments lmh0395 3G HD/SD SDI equalizer
+
+The LMH0395 3 Gbps HD/SD SDI Dual Output Low Power Extended Reach Adaptive
+Cable Equalizer is designed to equalize data transmitted over cable (or any
+media with similar dispersive loss characteristics).
+The equalizer operates over a wide range of data rates from 125 Mbps to 2.97
Gbps
+and supports SMPTE 424M, SMPTE 292M, SMPTE344M, SMPTE 259M, and DVB-ASI
standards.
+
+Required Properties :
+- compatible: Must be "ti,lmh0395"
+
+The device node must contain one 'port' child node per device input and output
+port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt. The port nodes
+are numbered as follows.
+
+ Port LMH0395
+
+ SDI input0
+ SDI output 1,2
+
+Example:
+
+ecspi@0201 {
+ ...
+ ...
+
+ lmh0395@1 {
+ compatible = "ti,lmh0395";
+ reg = <1>;
+ spi-max-frequency = <2000>;
+ ports {
+ port@0 {
+ reg = <0>;
+ sdi0_in: endpoint {};
+ };
+ port@1 {
+ reg=<1>;
+ sdi0_out0: endpoint {};
+ };
+ };
+ };
+ ...
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index cf24bb5..ca42b9e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9141,6 +9141,12 @@ S: Maintained
F: sound/soc/codecs/lm49453*
F: sound/soc/codecs/isabelle*
+TI LMH0395 DRIVER
+M: Jean-Michel Hautbois
+L: linux-media@vger.kernel.org
+S: Maintained
+F: drivers/media/spi/lmh0395*
+
TI LP855x BACKLIGHT DRIVER
M: Milo Kim
S: Maintained
diff --git a/drivers/media/spi/Kconfig b/drivers/media/spi/Kconfig
new file mode 100644
index 000..291e7ea
--- /dev/null
+++ b/drivers/media/spi/Kconfig
@@ -0,0 +1,14 @@
+if VIDEO_V4L2
+
+config VIDEO_LMH0395
+ tristate "LMH0395 equalizer"
+ depends on VIDEO_V4L2 && SPI && MEDIA_CONTROLLER
+ ---help---
+ Support for TI LMH0395 3G HD/SD SDI Dual Output Low Power
+ Extended Reach Adaptive Cable Equalizer.
+
+ To compile this driver as a module, choose M here: the
+ module will be called lmh0395.
+
+
+endif
diff --git a/drivers/media/spi/Makefile b/drivers/media/spi/Makefile
new file mode 100644
index 000..6c587e5
--- /dev/null
+++ b/drivers/media/spi/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_LMH0395)+= lmh0395.o
diff --git a/drivers/media/spi/lmh0395.c b/drivers/media/spi/lmh0395.c
new file mode 100644
index 000..ecf8f83
--- /dev/null
+++ b/drivers/media/spi/lmh0395.c
@@ -0,0 +1,355 @@
+/*
+ * LMH0395 SPI driver.
+ * Copyright (C) 2014 Jean-Michel Hautbois
+ *
+ * 3G HD/SD SDI Dual Output Low Power Extended Reach Adaptive Cable Equalizer
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int debug;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, "debug level (0-1)");
+
[PATCH v3] media: spi: Add support for LMH0395
This device is a SPI based device from TI.
It is a 3 Gbps HD/SD SDI Dual Output Low Power
Extended Reach Adaptive Cable Equalizer.
LMH0395 enables the use of up to two outputs.
These can be configured using DT.
Controls should be accessible from userspace too.
This will have to be done later.
Signed-off-by: Jean-Michel Hautbois
---
.../devicetree/bindings/media/spi/lmh0395.txt | 44 +++
MAINTAINERS| 6 +
drivers/media/spi/Kconfig | 14 +
drivers/media/spi/Makefile | 1 +
drivers/media/spi/lmh0395.c| 360 +
5 files changed, 425 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/spi/lmh0395.txt
create mode 100644 drivers/media/spi/Kconfig
create mode 100644 drivers/media/spi/Makefile
create mode 100644 drivers/media/spi/lmh0395.c
diff --git a/Documentation/devicetree/bindings/media/spi/lmh0395.txt
b/Documentation/devicetree/bindings/media/spi/lmh0395.txt
new file mode 100644
index 000..0a640a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/spi/lmh0395.txt
@@ -0,0 +1,44 @@
+* Texas Instruments lmh0395 3G HD/SD SDI equalizer
+
+The LMH0395 3 Gbps HD/SD SDI Dual Output Low Power Extended Reach Adaptive
+Cable Equalizer is designed to equalize data transmitted over cable (or any
+media with similar dispersive loss characteristics).
+The equalizer operates over a wide range of data rates from 125 Mbps to 2.97
Gbps
+and supports SMPTE 424M, SMPTE 292M, SMPTE344M, SMPTE 259M, and DVB-ASI
standards.
+
+Required Properties :
+- compatible: Must be "ti,lmh0395"
+
+The device node must contain one 'port' child node per device input and output
+port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt. The port nodes
+are numbered as follows.
+
+ Port LMH0395
+
+ SDI input0
+ SDI output 1,2
+
+Example:
+
+ecspi@0201 {
+ ...
+ ...
+
+ lmh0395@1 {
+ compatible = "ti,lmh0395";
+ reg = <1>;
+ spi-max-frequency = <2000>;
+ ports {
+ port@0 {
+ reg = <0>;
+ sdi0_in: endpoint {};
+ };
+ port@1 {
+ reg=<1>;
+ sdi0_out0: endpoint {};
+ };
+ };
+ };
+ ...
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index cf24bb5..ca42b9e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9141,6 +9141,12 @@ S: Maintained
F: sound/soc/codecs/lm49453*
F: sound/soc/codecs/isabelle*
+TI LMH0395 DRIVER
+M: Jean-Michel Hautbois
+L: linux-media@vger.kernel.org
+S: Maintained
+F: drivers/media/spi/lmh0395*
+
TI LP855x BACKLIGHT DRIVER
M: Milo Kim
S: Maintained
diff --git a/drivers/media/spi/Kconfig b/drivers/media/spi/Kconfig
new file mode 100644
index 000..291e7ea
--- /dev/null
+++ b/drivers/media/spi/Kconfig
@@ -0,0 +1,14 @@
+if VIDEO_V4L2
+
+config VIDEO_LMH0395
+ tristate "LMH0395 equalizer"
+ depends on VIDEO_V4L2 && SPI && MEDIA_CONTROLLER
+ ---help---
+ Support for TI LMH0395 3G HD/SD SDI Dual Output Low Power
+ Extended Reach Adaptive Cable Equalizer.
+
+ To compile this driver as a module, choose M here: the
+ module will be called lmh0395.
+
+
+endif
diff --git a/drivers/media/spi/Makefile b/drivers/media/spi/Makefile
new file mode 100644
index 000..6c587e5
--- /dev/null
+++ b/drivers/media/spi/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_LMH0395)+= lmh0395.o
diff --git a/drivers/media/spi/lmh0395.c b/drivers/media/spi/lmh0395.c
new file mode 100644
index 000..fe5c5f8
--- /dev/null
+++ b/drivers/media/spi/lmh0395.c
@@ -0,0 +1,360 @@
+/*
+ * LMH0395 SPI driver.
+ * Copyright (C) 2014 Jean-Michel Hautbois
+ *
+ * 3G HD/SD SDI Dual Output Low Power Extended Reach Adaptive Cable Equalizer
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int debug;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debu
[PATCH v4] media: spi: Add support for LMH0395
This device is a SPI based device from TI.
It is a 3 Gbps HD/SD SDI Dual Output Low Power
Extended Reach Adaptive Cable Equalizer.
LMH0395 enables the use of up to two outputs.
These can be configured using DT.
Controls should be accessible from userspace too.
This will have to be done later.
v2: Add DT support
v3: Change the bit set/clear in output_type as disabled means 'set the bit'
v4: Clearer description of endpoints usage in Doc, and some init changes.
Add a dependency on OF and don't test CONFIG_OF anymore.
Signed-off-by: Jean-Michel Hautbois
---
.../devicetree/bindings/media/spi/lmh0395.txt | 48 +++
MAINTAINERS| 6 +
drivers/media/spi/Kconfig | 14 +
drivers/media/spi/Makefile | 1 +
drivers/media/spi/lmh0395.c| 354 +
5 files changed, 423 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/spi/lmh0395.txt
create mode 100644 drivers/media/spi/Kconfig
create mode 100644 drivers/media/spi/Makefile
create mode 100644 drivers/media/spi/lmh0395.c
diff --git a/Documentation/devicetree/bindings/media/spi/lmh0395.txt
b/Documentation/devicetree/bindings/media/spi/lmh0395.txt
new file mode 100644
index 000..7cc0026
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/spi/lmh0395.txt
@@ -0,0 +1,48 @@
+* Texas Instruments lmh0395 3G HD/SD SDI equalizer
+
+The LMH0395 3 Gbps HD/SD SDI Dual Output Low Power Extended Reach Adaptive
+Cable Equalizer is designed to equalize data transmitted over cable (or any
+media with similar dispersive loss characteristics).
+The equalizer operates over a wide range of data rates from 125 Mbps to 2.97
Gbps
+and supports SMPTE 424M, SMPTE 292M, SMPTE344M, SMPTE 259M, and DVB-ASI
standards.
+
+Required Properties :
+- compatible: Must be "ti,lmh0395"
+
+The device node must contain one 'port' child node per device input and output
+port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt. The port nodes
+are numbered as follows.
+
+ Port LMH0395
+
+ SDI input0
+ SDI output 1,2
+
+Example:
+
+ecspi@0201 {
+ ...
+ ...
+
+ lmh0395@1 {
+ compatible = "ti,lmh0395";
+ reg = <1>;
+ spi-max-frequency = <2000>;
+ ports {
+ port@0 {
+ reg = <0>;
+ sdi0_in: endpoint {};
+ };
+ port@1 {
+ reg = <1>;
+ sdi0_out0: endpoint {};
+ };
+ port@2 {
+ reg = <2>;
+ /* endpoint not specified, disable output */
+ };
+ };
+ };
+ ...
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index cf24bb5..ca42b9e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9141,6 +9141,12 @@ S: Maintained
F: sound/soc/codecs/lm49453*
F: sound/soc/codecs/isabelle*
+TI LMH0395 DRIVER
+M: Jean-Michel Hautbois
+L: linux-media@vger.kernel.org
+S: Maintained
+F: drivers/media/spi/lmh0395*
+
TI LP855x BACKLIGHT DRIVER
M: Milo Kim
S: Maintained
diff --git a/drivers/media/spi/Kconfig b/drivers/media/spi/Kconfig
new file mode 100644
index 000..bcb1ab1
--- /dev/null
+++ b/drivers/media/spi/Kconfig
@@ -0,0 +1,14 @@
+if VIDEO_V4L2
+
+config VIDEO_LMH0395
+ tristate "LMH0395 equalizer"
+ depends on VIDEO_V4L2 && SPI && MEDIA_CONTROLLER && OF
+ ---help---
+ Support for TI LMH0395 3G HD/SD SDI Dual Output Low Power
+ Extended Reach Adaptive Cable Equalizer.
+
+ To compile this driver as a module, choose M here: the
+ module will be called lmh0395.
+
+
+endif
diff --git a/drivers/media/spi/Makefile b/drivers/media/spi/Makefile
new file mode 100644
index 000..6c587e5
--- /dev/null
+++ b/drivers/media/spi/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_LMH0395)+= lmh0395.o
diff --git a/drivers/media/spi/lmh0395.c b/drivers/media/spi/lmh0395.c
new file mode 100644
index 000..3eca0df
--- /dev/null
+++ b/drivers/media/spi/lmh0395.c
@@ -0,0 +1,354 @@
+/*
+ * LMH0395 SPI driver.
+ * Copyright (C) 2014 Jean-Michel Hautbois
+ *
+ * 3G HD/SD SDI Dual Output Low Power Extended Reach Adaptive Cable Equalizer
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * T
