Re: pwc over musb: 100% frame drop (lost) on high resolution stream
2016-07-20 0:34 GMT+03:00 Bin Liu :
> Hi,
>
> On Wed, Jul 20, 2016 at 12:25:44AM +0300, Matwey V. Kornilov wrote:
>> 2016-07-19 23:56 GMT+03:00 Bin Liu :
>> > Hi,
>> >
>> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, mat...@sai.msu.ru wrote:
>> >> Hello,
>> >>
>> >> I have Philips SPC 900 camera (0471:0329) connected to my AM335x based
>> >> BeagleBoneBlack SBC.
>> >> I am sure that both of them are fine and work properly.
>> >> I am running Linux 4.6.4 (my kernel config is available at
>> >> https://clck.ru/A2kQs ) and I've just discovered, that there is an issue
>> >> with frame transfer when high resolution formats are used.
>> >>
>> >> The issue is the following. I use simple v4l2 example tool (taken from
>> >> API docs), which source code is available at http://pastebin.com/grcNXxfe
>> >>
>> >> When I use (see line 488) 640x480 frames
>> >>
>> >> fmt.fmt.pix.width = 640;
>> >> fmt.fmt.pix.height = 480;
>> >>
>> >> then I get "select timeout" and don't get any frames.
>> >>
>> >> When I use 320x240 frames
>> >>
>> >> fmt.fmt.pix.width = 320;
>> >> fmt.fmt.pix.height = 240;
>> >>
>> >> then about 60% frames are missed. An example outpout of ./a.out -f is
>> >> available at https://yadi.sk/d/aRka8xWPtSc4y
>> >> It looks like there are pauses between bulks of frames (frame counter and
>> >> timestamp as returned from v4l2 API):
>> >>
>> >> 3 3705.142553
>> >> 8 3705.342533
>> >> 13 3705.542517
>> >> 110 3708.776208
>> >> 115 3708.976190
>> >> 120 3709.176169
>> >> 125 3709.376152
>> >> 130 3709.576144
>> >> 226 3712.807848
>> >>
>> >> When I use tiny 160x120 frames
>> >>
>> >> fmt.fmt.pix.width = 160;
>> >> fmt.fmt.pix.height = 120;
>> >>
>> >> then more frames are received. See output example at
>> >> https://yadi.sk/d/DedBmH6ftSc9t
>> >> That is why I thought that everything was fine in May when used tiny
>> >> xawtv window to check kernel OOPS presence (see
>> >> http://www.spinics.net/lists/linux-usb/msg141188.html for reference)
>> >>
>> >> Even more. When I introduce USB hub between the host and the webcam, I
>> >> can not receive even any 320x240 frames.
>> >>
>> >> I've managed to use ftrace to see what is going on when no frames are
>> >> received.
>> >> I've found that pwc_isoc_handler is called frequently as the following:
>> >>
>> >> 0) | pwc_isoc_handler [pwc]() {
>> >> 0) |usb_submit_urb [usbcore]() {
>> >> 0) | usb_submit_urb.part.3 [usbcore]() {
>> >> 0) |usb_hcd_submit_urb [usbcore]() {
>> >> 0) 0.834 us| usb_get_urb [usbcore]();
>> >> 0) | musb_map_urb_for_dma [musb_hdrc]() {
>> >> 0) 0.792 us|usb_hcd_map_urb_for_dma [usbcore]();
>> >> 0) 5.750 us| }
>> >> 0) | musb_urb_enqueue [musb_hdrc]() {
>> >> 0) 0.750 us|_raw_spin_lock_irqsave();
>> >> 0) |usb_hcd_link_urb_to_ep [usbcore]() {
>> >> 0) 0.792 us| _raw_spin_lock();
>> >> 0) 0.791 us| _raw_spin_unlock();
>> >> 0) + 10.500 us |}
>> >> 0) 0.791 us|_raw_spin_unlock_irqrestore();
>> >> 0) + 25.375 us | }
>> >> 0) + 45.208 us |}
>> >> 0) + 51.042 us | }
>> >> 0) + 56.084 us |}
>> >> 0) + 61.292 us | }
>> >>
>> >> However, pwc_isoc_handler never calls vb2_buffer_done() that is why I get
>> >> "select timeout" in userspace.
>> >> Unfortunately, my kernel is not compiled with CONFIG_USB_PWC_DEBUG=y but
>> >> I can recompile it, if you think that it could provide more information.
>> >> I am also ready to perform additional tests (use usbmon maybe?).
>> >>
>> >> How could this issue be resolved?
>> >>
>> >> Thank you.
>> >
>> > Do you have CPPI DMA enabled? If so I think you might hit on a known
>> > issue in CPPI Isoch transfer, in which the MUSB controller only sends IN
>> > tokens in every other SOF, so only half of the bus bandwidth is
>> > utilized, which causes video frame drops in higher resolution.
>> >
>>
>> Yes, I do use DMA:
>>
>> CONFIG_USB_TI_CPPI41_DMA=y
>
> Okay.
>
>>
>> > To confirm this, use a bus analyzer to capture a bus trace, you would
>> > see no IN tokens in every other SOF while transfering Isoch packets.
>> >
>>
>> I am sorry, I am new to USB debugging. Do you mean I need to use
>> usbmon or some external hardware device?
>
> I barely use usbmon, and not sure if it gives the information I am
> looking for. But I meant the external test equipment - USB bus protocol
> analyzer - a bus packet sniffer.
>
Now I see. I've googled it, they start from $1000, I don't know
when/whether/where I can get one to try.
Until that, could I check something else? For instance, disable
CONFIG_USB_TI_CPPI41_DMA.
I've found that after hours of transmit, the camera sto
Re: [PATCH 00/18] Complete moving media documentation to ReST format
Am 20.07.2016 um 02:00 schrieb Mauro Carvalho Chehab : > Em Tue, 19 Jul 2016 16:49:16 -0600 > Jonathan Corbet escreveu: > >> On Tue, 19 Jul 2016 11:53:19 -0300 >> Mauro Carvalho Chehab wrote: >> >>> So, I guess we should set the minimal requirement to 1.2.x. >> >> *sigh*. >> >> I hate to do that; things are happening quickly enough with Sphinx that >> it would be nice to be able to count on a newer version. That said, one >> of my goals in this whole thing was to make it *easier* for developers to >> generate the docs; the DocBook toolchain has always been notoriously >> difficult in that regard. Forcing people to install a newer sphinx by >> hand is not the way to get there. >> >> So I guess we need to make sure things work with 1.2 for now. I'd hope >> we could push that to at least 1.3 before too long, though, once the >> community distributions are there. I think we can be a *bit* more >> aggressive with the docs than with the kernel as a whole. > > Yeah, that seems to be the right strategy, IMHO. With the patch I sent, > the media books will again build fine with 1.2. It is a difficult situation, whatever we do, we will get in trouble. To handle this, (IMHO) at first we need a reference documentation. > What we miss is the documentation for Sphinx 1.2 and 1.3 versions. The > site only has documentation for the very latest version, making harder > to ensure that we're using only the tags supported by a certain version. We could build the documentation of the (e.g.) 1.2 tag https://github.com/sphinx-doc/sphinx/tree/1.2 by checkout the tag, cd to "./doc" and run "make html". I haven't tested yet, but it should work this way. Jon, what do you think ... could we serve this 1.2 doc on https://www.kernel.org/doc/ as reference? And whats about those who have 1.3 (or any version >1.2) as default in the linux distro? Should they install a virtualenv? ... it is a dilemma. Sorry that I have not identified this earlier ... I'am using python a long time and for me it is common to set up build processes with a version decoupled from the OS version, mostly the up to date version .. thats why I have neglected any version problems :( -- Markus -- > > Thanks, > Mauro -- 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: Troubles with kernel-doc and RST files
Am 20.07.2016 um 02:09 schrieb Mauro Carvalho Chehab : > Em Tue, 19 Jul 2016 17:16:35 -0600 > Jonathan Corbet escreveu: > >> On Sun, 17 Jul 2016 10:01:54 -0300 >> Mauro Carvalho Chehab wrote: >> >>> 3) When there's an asterisk inside the source code, for example, to >>> document a pointer, or when something else fails when parsing a >>> header file, kernel-doc handler just outputs: >>> /devel/v4l/patchwork/Documentation/media/kapi/mc-core.rst:137: WARNING: >>> Inline emphasis start-string without end-string. >>> /devel/v4l/patchwork/Documentation/media/kapi/mc-core.rst:470: WARNING: >>> Explicit markup ends without a blank line; unexpected unindent. >>> >>> pointing to a fake line at the rst file, instead of pointing to the >>> line inside the parsed header where the issue was detected, making >>> really hard to identify what's the error. >>> >>> In this specific case, mc-core.rst has only 260 lines at the time I got >>> such error. >> >> This sounds like the same warning issue that Daniel was dealing with. >> Hopefully his config change will at least make these easier to deal with. >> >> I wonder, though, if we could make kernel-doc a little smarter about >> these things so that the Right Thing happens for this sort of inadvertent >> markup? If we could just recognize and escape a singleton *, that would >> make a lot of things work. > > Yeah, that would be the best, but still, if some error happens, we need > the real line were it occurred, as it doesn't make sense to point to > a line that doesn't exist. I'am not sure, but this might be due to the ".. kernel-doc::" directive. Give me some time to dig. -- Markus -- > > > Thanks, > Mauro -- 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: Troubles with kernel-doc and RST files
Am 20.07.2016 um 00:58 schrieb Jonathan Corbet : > On Tue, 19 Jul 2016 12:00:24 +0200 > Markus Heiser wrote: > >> I recommend to consider to switch to the python version of the parser. >> I know, that there is a natural shyness about a reimplementation in python >> and thats why I offer to support it for a long time period .. it would >> be a joy for me ;-) >> >> If you interested in, I could send a RFC patch for this, if not please >> give the reasons why not. > > We've had this discussion already... Hi Jon, for me -- and may be I'am forgetful -- it was not really clear in the past discussion .. anyway I would say; thanks for clarifying your POV .. > The problem is not with "python", > it's with "reimplementation". We have enough moving parts in this > transition already; tossing in a wholesale replacement of a tool that, > for all of its many faults, embodies a couple decades worth of experience > just doesn't seem like the right thing to do at this time. > > I will be happy to entertain the idea of a new kernel-doc in the future; > trust me, I have no emotional attachment to the current one. But please > let's solidify what we have now first. There's enough stuff to deal with > as it is. OK, now I will accept to stay with the perl one and for this I will send my next patches ... Thanks -- Markus -- -- 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
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Wed Jul 20 04:00:18 CEST 2016 git branch: test git hash: 009a620848218d521f008141c62f56bf19294dd9 gcc version:i686-linux-gcc (GCC) 5.3.0 sparse version: v0.5.0-56-g7647c77 smatch version: v0.5.0-3428-gdfe27cf host hardware: x86_64 host os:4.6.0-164 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: OK linux-git-blackfin-bf561: OK linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: WARNINGS linux-3.11.1-i686: WARNINGS linux-3.12.23-i686: WARNINGS linux-3.13.11-i686: WARNINGS linux-3.14.9-i686: WARNINGS linux-3.15.2-i686: WARNINGS linux-3.16.7-i686: WARNINGS linux-3.17.8-i686: WARNINGS linux-3.18.7-i686: WARNINGS linux-3.19-i686: WARNINGS linux-4.0-i686: WARNINGS linux-4.1.1-i686: WARNINGS linux-4.2-i686: WARNINGS linux-4.3-i686: WARNINGS linux-4.4-i686: WARNINGS linux-4.5-i686: WARNINGS linux-4.6-i686: WARNINGS linux-4.7-rc1-i686: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: WARNINGS linux-3.11.1-x86_64: WARNINGS linux-3.12.23-x86_64: WARNINGS linux-3.13.11-x86_64: WARNINGS linux-3.14.9-x86_64: WARNINGS linux-3.15.2-x86_64: WARNINGS linux-3.16.7-x86_64: WARNINGS linux-3.17.8-x86_64: WARNINGS linux-3.18.7-x86_64: WARNINGS linux-3.19-x86_64: WARNINGS linux-4.0-x86_64: WARNINGS linux-4.1.1-x86_64: WARNINGS linux-4.2-x86_64: WARNINGS linux-4.3-x86_64: WARNINGS linux-4.4-x86_64: WARNINGS linux-4.5-x86_64: WARNINGS linux-4.6-x86_64: WARNINGS linux-4.7-rc1-x86_64: WARNINGS apps: OK spec-git: OK sparse: WARNINGS smatch: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.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: Troubles with kernel-doc and RST files
Em Tue, 19 Jul 2016 17:30:24 -0600 Jonathan Corbet escreveu: > On Sun, 17 Jul 2016 10:01:54 -0300 > Mauro Carvalho Chehab wrote: > > > 4) There are now several errors when parsing functions. Those seems to > > happen when an argument is a function pointer, like: > > > > /devel/v4l/patchwork/Documentation/media/kapi/v4l2-core.rst:757: WARNING: > > Error when parsing function declaration. > > If the function has no return type: > > Error in declarator or parameters and qualifiers > > Invalid definition: Expected identifier in nested name, got keyword: int > > [error at 3] > > int v4l2_ctrl_add_handler (struct v4l2_ctrl_handler * hdl, struct > > v4l2_ctrl_handler * add, bool (*filter) (const struct v4l2_ctrl *ctrl) > > ---^ > > So I've been trying to reproduce this one, without success; it seems to > work for me. As it should; the parsing code really should not have > changed at all. Is there some particular context in which this happens > for you? You could pull from my tree and see it yourself: git://linuxtv.org/media_tree.git docs-next What I'm noticing is a series of problems when parsing some function declarations. The number of warnings varies, depending on the Sphinx version. Basically, on all versions, it doesn't recognize arguments like: bool (*filter) (const struct v4l2_ctrl *ctrl) (this comes from kernel-doc) Sphinx itself doesn't even recognize arguments with "enum" on versions 1.3.x or older. With enums, it will still add it to the book. Just the cross-reference at the index won't appear. Thanks, Mauro -- 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: Troubles with kernel-doc and RST files
Em Tue, 19 Jul 2016 17:16:35 -0600 Jonathan Corbet escreveu: > On Sun, 17 Jul 2016 10:01:54 -0300 > Mauro Carvalho Chehab wrote: > > > 3) When there's an asterisk inside the source code, for example, to > > document a pointer, or when something else fails when parsing a > > header file, kernel-doc handler just outputs: > > /devel/v4l/patchwork/Documentation/media/kapi/mc-core.rst:137: WARNING: > > Inline emphasis start-string without end-string. > > /devel/v4l/patchwork/Documentation/media/kapi/mc-core.rst:470: WARNING: > > Explicit markup ends without a blank line; unexpected unindent. > > > > pointing to a fake line at the rst file, instead of pointing to the > > line inside the parsed header where the issue was detected, making > > really hard to identify what's the error. > > > > In this specific case, mc-core.rst has only 260 lines at the time I got > > such error. > > This sounds like the same warning issue that Daniel was dealing with. > Hopefully his config change will at least make these easier to deal with. > > I wonder, though, if we could make kernel-doc a little smarter about > these things so that the Right Thing happens for this sort of inadvertent > markup? If we could just recognize and escape a singleton *, that would > make a lot of things work. Yeah, that would be the best, but still, if some error happens, we need the real line were it occurred, as it doesn't make sense to point to a line that doesn't exist. Thanks, Mauro -- 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: Troubles with kernel-doc and RST files
Em Tue, 19 Jul 2016 17:01:33 -0600 Jonathan Corbet escreveu: > On Sun, 17 Jul 2016 10:01:54 -0300 > Mauro Carvalho Chehab wrote: > > > 2) For functions, kernel-doc is now an all or nothing. If not all > > functions are declared, it outputs this warning: > > > > ./include/media/media-devnode.h:1: warning: no structured comments > > > > And give up. No functions are exported, nor it points where it bailed. > > So, we need to manually look into all exported symbols to identify > > what's missing > > So could you describe this one in a bit more detail? An example of a > file with the problem and associated kernel-doc directive would be most > helpful here. This sounds like something we definitely want to fix. I actually noticed it when I was checking for the documentation generated by the RC header file. There, I had to add documentation for several functions: https://git.linuxtv.org/media_tree.git/commit/?h=docs-next&id=5b6137dc84f627e8497e554890ae02378c54f9f0 Without that, I had an error like the above, and no functions were documented. I didn't further tried to investigate the root cause. One thing I noticed is that Sphinx is very poor on detecting some types of changes, and we need to wipe out the Sphinx docs after some changes, as otherwise the document won't be ok. Maybe that's the case. Another possibility is that the all or nothing behavior happens when the :export: attribute is used. Thanks, Mauro -- 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 06/10] media: adv7180: implement g_parm
Implement g_parm to return the current standard's frame period.
Signed-off-by: Steve Longerbeam
Tested-by: Tim Harvey
Acked-by: Tim Harvey
---
drivers/media/i2c/adv7180.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
index 8612d21..8259549 100644
--- a/drivers/media/i2c/adv7180.c
+++ b/drivers/media/i2c/adv7180.c
@@ -766,6 +766,27 @@ static int adv7180_g_mbus_config(struct v4l2_subdev *sd,
return 0;
}
+static int adv7180_g_parm(struct v4l2_subdev *sd, struct v4l2_streamparm *a)
+{
+ struct adv7180_state *state = to_state(sd);
+ struct v4l2_captureparm *cparm = &a->parm.capture;
+
+ if (a->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ return -EINVAL;
+
+ memset(a, 0, sizeof(*a));
+ a->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+ if (state->curr_norm & V4L2_STD_525_60) {
+ cparm->timeperframe.numerator = 1001;
+ cparm->timeperframe.denominator = 3;
+ } else {
+ cparm->timeperframe.numerator = 1;
+ cparm->timeperframe.denominator = 25;
+ }
+
+ return 0;
+}
+
static int adv7180_cropcap(struct v4l2_subdev *sd, struct v4l2_cropcap
*cropcap)
{
struct adv7180_state *state = to_state(sd);
@@ -824,6 +845,7 @@ static int adv7180_subscribe_event(struct v4l2_subdev *sd,
static const struct v4l2_subdev_video_ops adv7180_video_ops = {
.s_std = adv7180_s_std,
.g_std = adv7180_g_std,
+ .g_parm = adv7180_g_parm,
.querystd = adv7180_querystd,
.g_input_status = adv7180_g_input_status,
.s_routing = adv7180_s_routing,
--
1.9.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
[PATCH v2 02/10] media: adv7180: Fix broken interrupt register access
Access to the interrupt page registers has been broken since at least
commit 3999e5d01da7 ("[media] adv7180: Do implicit register paging").
That commit forgot to add the interrupt page number to the register
defines.
Signed-off-by: Steve Longerbeam
Tested-by: Tim Harvey
Acked-by: Tim Harvey
Acked-by: Lars-Peter Clausen
---
drivers/media/i2c/adv7180.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
index b77b0a4..95cbc85 100644
--- a/drivers/media/i2c/adv7180.c
+++ b/drivers/media/i2c/adv7180.c
@@ -100,7 +100,7 @@
#define ADV7180_REG_IDENT 0x0011
#define ADV7180_ID_7180 0x18
-#define ADV7180_REG_ICONF1 0x0040
+#define ADV7180_REG_ICONF1 0x2040
#define ADV7180_ICONF1_ACTIVE_LOW 0x01
#define ADV7180_ICONF1_PSYNC_ONLY 0x10
#define ADV7180_ICONF1_ACTIVE_TO_CLR 0xC0
@@ -113,15 +113,15 @@
#define ADV7180_IRQ1_LOCK 0x01
#define ADV7180_IRQ1_UNLOCK0x02
-#define ADV7180_REG_ISR1 0x0042
-#define ADV7180_REG_ICR1 0x0043
-#define ADV7180_REG_IMR1 0x0044
-#define ADV7180_REG_IMR2 0x0048
+#define ADV7180_REG_ISR1 0x2042
+#define ADV7180_REG_ICR1 0x2043
+#define ADV7180_REG_IMR1 0x2044
+#define ADV7180_REG_IMR2 0x2048
#define ADV7180_IRQ3_AD_CHANGE 0x08
-#define ADV7180_REG_ISR3 0x004A
-#define ADV7180_REG_ICR3 0x004B
-#define ADV7180_REG_IMR3 0x004C
-#define ADV7180_REG_IMR4 0x50
+#define ADV7180_REG_ISR3 0x204A
+#define ADV7180_REG_ICR3 0x204B
+#define ADV7180_REG_IMR3 0x204C
+#define ADV7180_REG_IMR4 0x2050
#define ADV7180_REG_NTSC_V_BIT_END 0x00E6
#define ADV7180_NTSC_V_BIT_END_MANUAL_NVEND0x4F
--
1.9.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
[PATCH v2 05/10] media: adv7180: add power pin control
Some targets control the ADV7180 power pin via a gpio, so add
optional support for "powerdown" pin control.
Signed-off-by: Steve Longerbeam
Tested-by: Tim Harvey
Acked-by: Tim Harvey
Cc: Lars-Peter Clausen
---
v2:
- placed call to gpiod_get inline in adv7180_probe().
- rename gpio pin to "powerdown".
- document optional powerdown-gpios property in
Documentation/devicetree/bindings/media/i2c/adv7180.txt.
- include error number in error message on gpiod_get failure.
---
.../devicetree/bindings/media/i2c/adv7180.txt | 5
drivers/media/i2c/Kconfig | 2 +-
drivers/media/i2c/adv7180.c| 27 ++
3 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/media/i2c/adv7180.txt
b/Documentation/devicetree/bindings/media/i2c/adv7180.txt
index 0d50115..4da486f 100644
--- a/Documentation/devicetree/bindings/media/i2c/adv7180.txt
+++ b/Documentation/devicetree/bindings/media/i2c/adv7180.txt
@@ -15,6 +15,11 @@ Required Properties :
"adi,adv7282"
"adi,adv7282-m"
+Optional Properties :
+- powerdown-gpios: reference to the GPIO connected to the powerdown pin,
+ if any.
+
+
Example:
i2c0@1c22000 {
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index ce9006e..6769898 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -187,7 +187,7 @@ comment "Video decoders"
config VIDEO_ADV7180
tristate "Analog Devices ADV7180 decoder"
- depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+ depends on GPIOLIB && VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
---help---
Support for the Analog Devices ADV7180 video decoder.
diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
index 667931e9..8612d21 100644
--- a/drivers/media/i2c/adv7180.c
+++ b/drivers/media/i2c/adv7180.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -215,6 +216,7 @@ struct adv7180_state {
struct media_padpad;
struct mutexmutex; /* mutual excl. when accessing chip */
int irq;
+ struct gpio_desc*pwdn_gpio;
v4l2_std_id curr_norm;
boolnewavmode;
boolpowered;
@@ -466,6 +468,19 @@ static int adv7180_g_std(struct v4l2_subdev *sd,
v4l2_std_id *norm)
return 0;
}
+static void adv7180_set_power_pin(struct adv7180_state *state, bool on)
+{
+ if (!state->pwdn_gpio)
+ return;
+
+ if (on) {
+ gpiod_set_value_cansleep(state->pwdn_gpio, 0);
+ usleep_range(5000, 1);
+ } else {
+ gpiod_set_value_cansleep(state->pwdn_gpio, 1);
+ }
+}
+
static int adv7180_set_power(struct adv7180_state *state, bool on)
{
u8 val;
@@ -1221,6 +1236,8 @@ static int init_device(struct adv7180_state *state)
mutex_lock(&state->mutex);
+ adv7180_set_power_pin(state, true);
+
adv7180_write(state, ADV7180_REG_PWR_MAN, ADV7180_PWR_MAN_RES);
usleep_range(5000, 1);
@@ -1320,6 +1337,14 @@ static int adv7180_probe(struct i2c_client *client,
adv7180_of_parse(state);
+ state->pwdn_gpio = devm_gpiod_get_optional(&client->dev, "powerdown",
+ GPIOD_OUT_HIGH);
+ if (IS_ERR(state->pwdn_gpio)) {
+ ret = PTR_ERR(state->pwdn_gpio);
+ v4l_err(client, "request for power pin failed: %d\n", ret);
+ return ret;
+ }
+
if (state->chip_info->flags & ADV7180_FLAG_MIPI_CSI2) {
state->csi_client = i2c_new_dummy(client->adapter,
ADV7180_DEFAULT_CSI_I2C_ADDR);
@@ -1411,6 +1436,8 @@ static int adv7180_remove(struct i2c_client *client)
if (state->chip_info->flags & ADV7180_FLAG_MIPI_CSI2)
i2c_unregister_device(state->csi_client);
+ adv7180_set_power_pin(state, false);
+
mutex_destroy(&state->mutex);
return 0;
--
1.9.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
[PATCH v2 08/10] v4l: Add signal lock status to source change events
Add a signal lock status change to the source changes bitmask.
This indicates there was a signal lock or unlock event detected
at the input of a video decoder.
Signed-off-by: Steve Longerbeam
Cc: Mauro Carvalho Chehab
---
Documentation/DocBook/media/v4l/vidioc-dqevent.xml | 12 ++--
include/uapi/linux/videodev2.h | 1 +
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
index c9c3c77..7758ad7 100644
--- a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
@@ -233,8 +233,9 @@
This event is triggered when a source parameter change is
detected during runtime by the video device. It can be a
- runtime resolution change triggered by a video decoder or the
- format change happening on an input connector.
+ runtime resolution change or signal lock status change
+ triggered by a video decoder, or the format change happening
+ on an input connector.
This event requires that the id
matches the input index (when used with a video device node)
or the pad index (when used with a subdevice node) from which
@@ -461,6 +462,13 @@
from a video decoder.
+
+ V4L2_EVENT_SRC_CH_LOCK_STATUS
+ 0x0002
+ This event gets triggered when there is a signal lock or
+ unlock detected at the input of a video decoder.
+
+
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 724f43e..08a153f 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -2078,6 +2078,7 @@ struct v4l2_event_frame_sync {
};
#define V4L2_EVENT_SRC_CH_RESOLUTION (1 << 0)
+#define V4L2_EVENT_SRC_CH_LOCK_STATUS (1 << 1)
struct v4l2_event_src_change {
__u32 changes;
--
1.9.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
[PATCH v2 07/10] media: adv7180: change mbus format to UYVY
Change the media bus format from YUYV8_2X8 to UYVY8_2X8. Colors
now look correct when capturing with the i.mx6 backend.
Signed-off-by: Steve Longerbeam
Tested-by: Tim Harvey
Acked-by: Tim Harvey
Acked-by: Lars-Peter Clausen
Acked-by: Niklas Söderlund
---
drivers/media/i2c/adv7180.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
index 8259549..0f0568c 100644
--- a/drivers/media/i2c/adv7180.c
+++ b/drivers/media/i2c/adv7180.c
@@ -636,7 +636,7 @@ static int adv7180_enum_mbus_code(struct v4l2_subdev *sd,
if (code->index != 0)
return -EINVAL;
- code->code = MEDIA_BUS_FMT_YUYV8_2X8;
+ code->code = MEDIA_BUS_FMT_UYVY8_2X8;
return 0;
}
@@ -646,7 +646,7 @@ static int adv7180_mbus_fmt(struct v4l2_subdev *sd,
{
struct adv7180_state *state = to_state(sd);
- fmt->code = MEDIA_BUS_FMT_YUYV8_2X8;
+ fmt->code = MEDIA_BUS_FMT_UYVY8_2X8;
fmt->colorspace = V4L2_COLORSPACE_SMPTE170M;
fmt->width = 720;
fmt->height = state->curr_norm & V4L2_STD_525_60 ? 480 : 576;
--
1.9.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
[PATCH v2 03/10] media: adv7180: define more registers
Replace hard-coded addresses with new register macro defines. No
functional changes.
Signed-off-by: Steve Longerbeam
---
drivers/media/i2c/adv7180.c | 73 ++---
1 file changed, 49 insertions(+), 24 deletions(-)
diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
index 95cbc85..cb83ebb 100644
--- a/drivers/media/i2c/adv7180.c
+++ b/drivers/media/i2c/adv7180.c
@@ -56,10 +56,11 @@
#define ADV7182_REG_INPUT_VIDSEL 0x0002
+#define ADV7180_REG_OUTPUT_CONTROL 0x0003
#define ADV7180_REG_EXTENDED_OUTPUT_CONTROL0x0004
#define ADV7180_EXTENDED_OUTPUT_CONTROL_NTSCDIS0xC5
-#define ADV7180_REG_AUTODETECT_ENABLE 0x07
+#define ADV7180_REG_AUTODETECT_ENABLE 0x0007
#define ADV7180_AUTODETECT_DEFAULT 0x7f
/* Contrast */
#define ADV7180_REG_CON0x0008 /*Unsigned */
@@ -100,6 +101,20 @@
#define ADV7180_REG_IDENT 0x0011
#define ADV7180_ID_7180 0x18
+#define ADV7180_REG_STATUS30x0013
+#define ADV7180_REG_ANALOG_CLAMP_CTL 0x0014
+#define ADV7180_REG_SHAP_FILTER_CTL_1 0x0017
+#define ADV7180_REG_CTRL_2 0x001d
+#define ADV7180_REG_VSYNC_FIELD_CTL_1 0x0031
+#define ADV7180_REG_MANUAL_WIN_CTL_1 0x003d
+#define ADV7180_REG_MANUAL_WIN_CTL_2 0x003e
+#define ADV7180_REG_MANUAL_WIN_CTL_3 0x003f
+#define ADV7180_REG_LOCK_CNT 0x0051
+#define ADV7180_REG_CVBS_TRIM 0x0052
+#define ADV7180_REG_CLAMP_ADJ 0x005a
+#define ADV7180_REG_RES_CIR0x005f
+#define ADV7180_REG_DIFF_MODE 0x0060
+
#define ADV7180_REG_ICONF1 0x2040
#define ADV7180_ICONF1_ACTIVE_LOW 0x01
#define ADV7180_ICONF1_PSYNC_ONLY 0x10
@@ -129,9 +144,15 @@
#define ADV7180_REG_VPP_SLAVE_ADDR 0xFD
#define ADV7180_REG_CSI_SLAVE_ADDR 0xFE
-#define ADV7180_REG_FLCONTROL 0x40e0
+#define ADV7180_REG_ACE_CTRL1 0x4080
+#define ADV7180_REG_ACE_CTRL5 0x4084
+#define ADV7180_REG_FLCONTROL 0x40e0
#define ADV7180_FLCONTROL_FL_ENABLE 0x1
+#define ADV7180_REG_RST_CLAMP 0x809c
+#define ADV7180_REG_AGC_ADJ1 0x80b6
+#define ADV7180_REG_AGC_ADJ2 0x80c0
+
#define ADV7180_CSI_REG_PWRDN 0x00
#define ADV7180_CSI_PWRDN 0x80
@@ -886,16 +907,20 @@ static int adv7182_init(struct adv7180_state *state)
/* ADI required writes */
if (state->chip_info->flags & ADV7180_FLAG_MIPI_CSI2) {
- adv7180_write(state, 0x0003, 0x4e);
- adv7180_write(state, 0x0004, 0x57);
- adv7180_write(state, 0x001d, 0xc0);
+ adv7180_write(state, ADV7180_REG_OUTPUT_CONTROL, 0x4e);
+ adv7180_write(state, ADV7180_REG_EXTENDED_OUTPUT_CONTROL, 0x57);
+ adv7180_write(state, ADV7180_REG_CTRL_2, 0xc0);
} else {
if (state->chip_info->flags & ADV7180_FLAG_V2)
- adv7180_write(state, 0x0004, 0x17);
+ adv7180_write(state,
+ ADV7180_REG_EXTENDED_OUTPUT_CONTROL,
+ 0x17);
else
- adv7180_write(state, 0x0004, 0x07);
- adv7180_write(state, 0x0003, 0x0c);
- adv7180_write(state, 0x001d, 0x40);
+ adv7180_write(state,
+ ADV7180_REG_EXTENDED_OUTPUT_CONTROL,
+ 0x07);
+ adv7180_write(state, ADV7180_REG_OUTPUT_CONTROL, 0x0c);
+ adv7180_write(state, ADV7180_REG_CTRL_2, 0x40);
}
adv7180_write(state, 0x0013, 0x00);
@@ -972,8 +997,8 @@ static int adv7182_select_input(struct adv7180_state
*state, unsigned int input)
return ret;
/* Reset clamp circuitry - ADI recommended writes */
- adv7180_write(state, 0x809c, 0x00);
- adv7180_write(state, 0x809c, 0xff);
+ adv7180_write(state, ADV7180_REG_RST_CLAMP, 0x00);
+ adv7180_write(state, ADV7180_REG_RST_CLAMP, 0xff);
input_type = adv7182_get_input_type(input);
@@ -981,10 +1006,10 @@ static int adv7182_select_input(struct adv7180_state
*state, unsigned int input)
case ADV7182_INPUT_TYPE_CVBS:
case ADV7182_INPUT_TYPE_DIFF_CVBS:
/* ADI recommends to use the SH1 filter */
- adv7180_write(state, 0x0017, 0x41);
+ adv7180_write(state, ADV7180_REG_SHAP_FILTER_CTL_1, 0x41);
break;
default:
- adv7180_write(state, 0x0017, 0x01);
+ adv7180_write(state, ADV7180_REG_SHAP_FILTER_CTL_1, 0x01);
break;
}
@@ -994,21 +1019,21 @@ static int adv7182_select_input(struct adv7180_state
*state, unsigned int input)
lbias = adv7182_lbias_settings[input_type];
for (i = 0; i < ARRAY_SIZE(adv7182_lbias_settings[0]); i++)
-
[PATCH v2 04/10] media: adv7180: add support for NEWAVMODE
Parse the optional v4l2 endpoint DT node. If the V4L2_MBUS_NEWAVMODE
parallel bus flag is set, configure the BT.656 bus in NEWAVMODE.
Signed-off-by: Steve Longerbeam
---
drivers/media/i2c/adv7180.c | 47 ++---
1 file changed, 44 insertions(+), 3 deletions(-)
diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
index cb83ebb..667931e9 100644
--- a/drivers/media/i2c/adv7180.c
+++ b/drivers/media/i2c/adv7180.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
@@ -106,6 +107,7 @@
#define ADV7180_REG_SHAP_FILTER_CTL_1 0x0017
#define ADV7180_REG_CTRL_2 0x001d
#define ADV7180_REG_VSYNC_FIELD_CTL_1 0x0031
+#define ADV7180_VSYNC_FIELD_CTL_1_NEWAVMODE 0x02
#define ADV7180_REG_MANUAL_WIN_CTL_1 0x003d
#define ADV7180_REG_MANUAL_WIN_CTL_2 0x003e
#define ADV7180_REG_MANUAL_WIN_CTL_3 0x003f
@@ -214,6 +216,7 @@ struct adv7180_state {
struct mutexmutex; /* mutual excl. when accessing chip */
int irq;
v4l2_std_id curr_norm;
+ boolnewavmode;
boolpowered;
boolstreaming;
u8 input;
@@ -740,6 +743,8 @@ static int adv7180_g_mbus_config(struct v4l2_subdev *sd,
*/
cfg->flags = V4L2_MBUS_MASTER | V4L2_MBUS_PCLK_SAMPLE_RISING |
V4L2_MBUS_DATA_ACTIVE_HIGH;
+ if (state->newavmode)
+ cfg->flags |= V4L2_MBUS_NEWAVMODE;
cfg->type = V4L2_MBUS_BT656;
}
@@ -864,9 +869,15 @@ static int adv7180_init(struct adv7180_state *state)
if (ret < 0)
return ret;
- /* Manually set V bit end position in NTSC mode */
- return adv7180_write(state, ADV7180_REG_NTSC_V_BIT_END,
- ADV7180_NTSC_V_BIT_END_MANUAL_NVEND);
+ if (!state->newavmode) {
+ /* Manually set V bit end position in NTSC mode */
+ ret = adv7180_write(state, ADV7180_REG_NTSC_V_BIT_END,
+ ADV7180_NTSC_V_BIT_END_MANUAL_NVEND);
+ if (ret < 0)
+ return ret;
+ }
+
+ return 0;
}
static int adv7180_set_std(struct adv7180_state *state, unsigned int std)
@@ -1217,6 +1228,13 @@ static int init_device(struct adv7180_state *state)
if (ret)
goto out_unlock;
+ if (state->newavmode) {
+ ret = adv7180_write(state, ADV7180_REG_VSYNC_FIELD_CTL_1,
+ ADV7180_VSYNC_FIELD_CTL_1_NEWAVMODE);
+ if (ret < 0)
+ goto out_unlock;
+ }
+
ret = adv7180_program_std(state);
if (ret)
goto out_unlock;
@@ -1257,6 +1275,27 @@ out_unlock:
return ret;
}
+static void adv7180_of_parse(struct adv7180_state *state)
+{
+ struct i2c_client *client = state->client;
+ struct device_node *np = client->dev.of_node;
+ struct device_node *endpoint;
+ struct v4l2_of_endpoint ep;
+
+ endpoint = of_graph_get_next_endpoint(np, NULL);
+ if (!endpoint) {
+ v4l_warn(client, "endpoint node not found\n");
+ return;
+ }
+
+ v4l2_of_parse_endpoint(endpoint, &ep);
+ of_node_put(endpoint);
+
+ if (ep.bus_type == V4L2_MBUS_BT656 &&
+ ep.bus.parallel.flags & V4L2_MBUS_NEWAVMODE)
+ state->newavmode = true;
+}
+
static int adv7180_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
@@ -1279,6 +1318,8 @@ static int adv7180_probe(struct i2c_client *client,
state->field = V4L2_FIELD_INTERLACED;
state->chip_info = (struct adv7180_chip_info *)id->driver_data;
+ adv7180_of_parse(state);
+
if (state->chip_info->flags & ADV7180_FLAG_MIPI_CSI2) {
state->csi_client = i2c_new_dummy(client->adapter,
ADV7180_DEFAULT_CSI_I2C_ADDR);
--
1.9.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
[PATCH v2 09/10] media: adv7180: enable lock/unlock interrupts
Enable the SD lock/unlock interrupts and send V4L2_EVENT_SRC_CH_LOCK_STATUS
in the interrupt handler on a detected lock/unlock.
Signed-off-by: Steve Longerbeam
---
v2:
- last version of this patch was based on the old reverted autodetect
code. This version now only enables the interrupt and sends the
event in the interrupt handler.
---
drivers/media/i2c/adv7180.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
index 0f0568c..61f2140 100644
--- a/drivers/media/i2c/adv7180.c
+++ b/drivers/media/i2c/adv7180.c
@@ -876,19 +876,29 @@ static const struct v4l2_subdev_ops adv7180_ops = {
static irqreturn_t adv7180_irq(int irq, void *devid)
{
struct adv7180_state *state = devid;
- u8 isr3;
+ u8 isr1, isr3;
mutex_lock(&state->mutex);
+ isr1 = adv7180_read(state, ADV7180_REG_ISR1);
isr3 = adv7180_read(state, ADV7180_REG_ISR3);
/* clear */
+ adv7180_write(state, ADV7180_REG_ICR1, isr1);
adv7180_write(state, ADV7180_REG_ICR3, isr3);
- if (isr3 & ADV7180_IRQ3_AD_CHANGE) {
- static const struct v4l2_event src_ch = {
+ if ((isr3 & ADV7180_IRQ3_AD_CHANGE) ||
+ (isr1 & (ADV7180_IRQ1_LOCK | ADV7180_IRQ1_UNLOCK))) {
+ static struct v4l2_event src_ch = {
.type = V4L2_EVENT_SOURCE_CHANGE,
- .u.src_change.changes = V4L2_EVENT_SRC_CH_RESOLUTION,
};
+ if (isr3 & ADV7180_IRQ3_AD_CHANGE)
+ src_ch.u.src_change.changes |=
+ V4L2_EVENT_SRC_CH_RESOLUTION;
+
+ if (isr1 & (ADV7180_IRQ1_LOCK | ADV7180_IRQ1_UNLOCK))
+ src_ch.u.src_change.changes |=
+ V4L2_EVENT_SRC_CH_LOCK_STATUS;
+
v4l2_subdev_notify_event(&state->sd, &src_ch);
}
mutex_unlock(&state->mutex);
@@ -1289,7 +1299,9 @@ static int init_device(struct adv7180_state *state)
if (ret < 0)
goto out_unlock;
- ret = adv7180_write(state, ADV7180_REG_IMR1, 0);
+ /* enable lock/unlock interrupts */
+ ret = adv7180_write(state, ADV7180_REG_IMR1,
+ ADV7180_IRQ1_LOCK | ADV7180_IRQ1_UNLOCK);
if (ret < 0)
goto out_unlock;
--
1.9.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
[PATCH v2 10/10] media: adv7180: fix field type
The ADV7180 and ADV7182 transmit whole fields, bottom field followed
by top (or vice-versa, depending on detected video standard). So
for chips that do not have support for explicitly setting the field
mode, set the field mode to SEQ_BT for PAL, and SEQ_TB for NTSC (there
seems to be conflicting info on field order of PAL vs NTSC, so follow
what is in adv7183.c).
Signed-off-by: Steve Longerbeam
---
v2:
- the init of state->curr_norm in probe needs to be moved up, ahead
of the init of state->field.
---
drivers/media/i2c/adv7180.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/media/i2c/adv7180.c b/drivers/media/i2c/adv7180.c
index 61f2140..58e1f53 100644
--- a/drivers/media/i2c/adv7180.c
+++ b/drivers/media/i2c/adv7180.c
@@ -718,10 +718,17 @@ static int adv7180_set_pad_format(struct v4l2_subdev *sd,
switch (format->format.field) {
case V4L2_FIELD_NONE:
if (!(state->chip_info->flags & ADV7180_FLAG_I2P))
- format->format.field = V4L2_FIELD_INTERLACED;
+ format->format.field =
+ (state->curr_norm & V4L2_STD_525_60) ?
+ V4L2_FIELD_SEQ_TB : V4L2_FIELD_SEQ_BT;
break;
default:
- format->format.field = V4L2_FIELD_INTERLACED;
+ if (state->chip_info->flags & ADV7180_FLAG_I2P)
+ format->format.field = V4L2_FIELD_INTERLACED;
+ else
+ format->format.field =
+ (state->curr_norm & V4L2_STD_525_60) ?
+ V4L2_FIELD_SEQ_TB : V4L2_FIELD_SEQ_BT;
break;
}
@@ -1366,8 +1373,14 @@ static int adv7180_probe(struct i2c_client *client,
return -ENOMEM;
state->client = client;
- state->field = V4L2_FIELD_INTERLACED;
state->chip_info = (struct adv7180_chip_info *)id->driver_data;
+ state->curr_norm = V4L2_STD_NTSC;
+
+ if (state->chip_info->flags & ADV7180_FLAG_I2P)
+ state->field = V4L2_FIELD_INTERLACED;
+ else
+ state->field = (state->curr_norm & V4L2_STD_525_60) ?
+ V4L2_FIELD_SEQ_TB : V4L2_FIELD_SEQ_BT;
adv7180_of_parse(state);
@@ -1397,7 +1410,6 @@ static int adv7180_probe(struct i2c_client *client,
state->irq = client->irq;
mutex_init(&state->mutex);
- state->curr_norm = V4L2_STD_NTSC;
if (state->chip_info->flags & ADV7180_FLAG_RESET_POWERED)
state->powered = true;
else
--
1.9.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
[PATCH v2 01/10] v4l: of: add "newavmode" property for Analog Devices codecs
This patch adds a "newavmode" boolean property as part of the v4l2 endpoint properties. This indicates an Analog Devices decoder is generating EAV/SAV codes to suit Analog Devices encoders. Signed-off-by: Steve Longerbeam Cc: Mauro Carvalho Chehab Cc: Javier Martinez Canillas Cc: Laurent Pinchart Cc: Sakari Ailus --- Documentation/devicetree/bindings/media/video-interfaces.txt | 2 ++ drivers/media/v4l2-core/v4l2-of.c| 4 include/media/v4l2-mediabus.h| 5 + 3 files changed, 11 insertions(+) diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt index 9cd2a36..6f2df51 100644 --- a/Documentation/devicetree/bindings/media/video-interfaces.txt +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt @@ -88,6 +88,8 @@ Optional endpoint properties - field-even-active: field signal level during the even field data transmission. - pclk-sample: sample data on rising (1) or falling (0) edge of the pixel clock signal. +- newavmode: a boolean property to indicate an Analog Devices decoder is + operating in NEWAVMODE. Valid for BT.656 busses only. - sync-on-green-active: active state of Sync-on-green (SoG) signal, 0/1 for LOW/HIGH respectively. - data-lanes: an array of physical data lane indexes. Position of an entry diff --git a/drivers/media/v4l2-core/v4l2-of.c b/drivers/media/v4l2-core/v4l2-of.c index 93b3368..719a7d1 100644 --- a/drivers/media/v4l2-core/v4l2-of.c +++ b/drivers/media/v4l2-core/v4l2-of.c @@ -109,6 +109,10 @@ static void v4l2_of_parse_parallel_bus(const struct device_node *node, flags |= v ? V4L2_MBUS_DATA_ACTIVE_HIGH : V4L2_MBUS_DATA_ACTIVE_LOW; + if (endpoint->bus_type == V4L2_MBUS_BT656 && + of_get_property(node, "newavmode", &v)) + flags |= V4L2_MBUS_NEWAVMODE; + if (of_get_property(node, "slave-mode", &v)) flags |= V4L2_MBUS_SLAVE; else diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h index 34cc99e..0bd5f0e 100644 --- a/include/media/v4l2-mediabus.h +++ b/include/media/v4l2-mediabus.h @@ -43,6 +43,11 @@ /* Active state of Sync-on-green (SoG) signal, 0/1 for LOW/HIGH respectively. */ #define V4L2_MBUS_VIDEO_SOG_ACTIVE_HIGH(1 << 12) #define V4L2_MBUS_VIDEO_SOG_ACTIVE_LOW (1 << 13) +/* + * BT.656 specific flags + */ +/* Analog Device's NEWAVMODE */ +#define V4L2_MBUS_NEWAVMODE(1 << 14) /* Serial flags */ /* How many lanes the client can use */ -- 1.9.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
[PATCH v2 00/10] adv7180 subdev fixes, v2
This version adds a new v4l2 endpoint property and BT.656 bus flag for the "NEWAVMODE" setting of Analog Devices decoders. The i.MX6 capture backend is not able to sync on the bt.656 stream from the ADV7180 when the latter is in manual video standard setting mode, unless NEWWAVMODE is used in conjunction. The backend needs to be aware of NEWAVMODE so that it can make adjustments to the AV code detection. That's the biggest addition in this version, besides the requested feedback changes from last version. Steve Longerbeam (10): v4l: of: add "newavmode" property for Analog Devices codecs media: adv7180: Fix broken interrupt register access media: adv7180: define more registers media: adv7180: add support for NEWAVMODE media: adv7180: add power pin control media: adv7180: implement g_parm media: adv7180: change mbus format to UYVY v4l: Add signal lock status to source change events media: adv7180: enable lock/unlock interrupts media: adv7180: fix field type Documentation/DocBook/media/v4l/vidioc-dqevent.xml | 12 +- .../devicetree/bindings/media/i2c/adv7180.txt | 5 + .../devicetree/bindings/media/video-interfaces.txt | 2 + drivers/media/i2c/Kconfig | 2 +- drivers/media/i2c/adv7180.c| 233 - drivers/media/v4l2-core/v4l2-of.c | 4 + include/media/v4l2-mediabus.h | 5 + include/uapi/linux/videodev2.h | 1 + 8 files changed, 214 insertions(+), 50 deletions(-) -- 1.9.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: [PATCH 00/18] Complete moving media documentation to ReST format
Em Tue, 19 Jul 2016 16:49:16 -0600 Jonathan Corbet escreveu: > On Tue, 19 Jul 2016 11:53:19 -0300 > Mauro Carvalho Chehab wrote: > > > So, I guess we should set the minimal requirement to 1.2.x. > > *sigh*. > > I hate to do that; things are happening quickly enough with Sphinx that > it would be nice to be able to count on a newer version. That said, one > of my goals in this whole thing was to make it *easier* for developers to > generate the docs; the DocBook toolchain has always been notoriously > difficult in that regard. Forcing people to install a newer sphinx by > hand is not the way to get there. > > So I guess we need to make sure things work with 1.2 for now. I'd hope > we could push that to at least 1.3 before too long, though, once the > community distributions are there. I think we can be a *bit* more > aggressive with the docs than with the kernel as a whole. Yeah, that seems to be the right strategy, IMHO. With the patch I sent, the media books will again build fine with 1.2. Thanks, Mauro -- 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: Troubles with kernel-doc and RST files
On Sun, 17 Jul 2016 10:01:54 -0300 Mauro Carvalho Chehab wrote: > 4) There are now several errors when parsing functions. Those seems to > happen when an argument is a function pointer, like: > > /devel/v4l/patchwork/Documentation/media/kapi/v4l2-core.rst:757: WARNING: > Error when parsing function declaration. > If the function has no return type: > Error in declarator or parameters and qualifiers > Invalid definition: Expected identifier in nested name, got keyword: int > [error at 3] > int v4l2_ctrl_add_handler (struct v4l2_ctrl_handler * hdl, struct > v4l2_ctrl_handler * add, bool (*filter) (const struct v4l2_ctrl *ctrl) > ---^ So I've been trying to reproduce this one, without success; it seems to work for me. As it should; the parsing code really should not have changed at all. Is there some particular context in which this happens for you? Thanks, jon -- 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: Troubles with kernel-doc and RST files
On Sun, 17 Jul 2016 10:01:54 -0300 Mauro Carvalho Chehab wrote: > 3) When there's an asterisk inside the source code, for example, to > document a pointer, or when something else fails when parsing a > header file, kernel-doc handler just outputs: > /devel/v4l/patchwork/Documentation/media/kapi/mc-core.rst:137: WARNING: > Inline emphasis start-string without end-string. > /devel/v4l/patchwork/Documentation/media/kapi/mc-core.rst:470: WARNING: > Explicit markup ends without a blank line; unexpected unindent. > > pointing to a fake line at the rst file, instead of pointing to the > line inside the parsed header where the issue was detected, making > really hard to identify what's the error. > > In this specific case, mc-core.rst has only 260 lines at the time I got > such error. This sounds like the same warning issue that Daniel was dealing with. Hopefully his config change will at least make these easier to deal with. I wonder, though, if we could make kernel-doc a little smarter about these things so that the Right Thing happens for this sort of inadvertent markup? If we could just recognize and escape a singleton *, that would make a lot of things work. jon -- 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 7/7] [media] rc: add support for IR LEDs driven through SPI
On Wed, Jul 20, 2016 at 12:56:58AM +0900, Andi Shyti wrote:
> The ir-spi is a simple device driver which supports the
> connection between an IR LED and the MOSI line of an SPI device.
>
> The driver, indeed, uses the SPI framework to stream the raw data
> provided by userspace through a character device. The chardev is
> handled by the LIRC framework and its functionality basically
> provides:
>
> - raw write: data to be sent to the SPI and then streamed to the
>MOSI line;
> - set frequency: sets the frequency whith which the data should
>be sent;
>
> The character device is created under /dev/lircX name, where X is
> and ID assigned by the LIRC framework.
>
> Example of usage:
>
> fd = open("/dev/lirc0", O_RDWR);
> if (fd < 0)
> return -1;
>
> val = 608000;
> ret = ioctl(fd, LIRC_SET_SEND_CARRIER, &val);
> if (ret < 0)
> return -1;
>
> n = write(fd, buffer, BUF_LEN);
> if (n < 0 || n != BUF_LEN)
> ret = -1;
>
> close(fd);
>
> Signed-off-by: Andi Shyti
> ---
> drivers/media/rc/Kconfig | 9
> drivers/media/rc/Makefile | 1 +
> drivers/media/rc/ir-spi.c | 133
> ++
> 3 files changed, 143 insertions(+)
> create mode 100644 drivers/media/rc/ir-spi.c
>
> diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
> index bd4d685..dacaa29 100644
> --- a/drivers/media/rc/Kconfig
> +++ b/drivers/media/rc/Kconfig
> @@ -261,6 +261,15 @@ config IR_REDRAT3
> To compile this driver as a module, choose M here: the
> module will be called redrat3.
>
> +config IR_SPI
> + tristate "SPI connected IR LED"
> + depends on SPI && LIRC
> + ---help---
> + Say Y if you want to use an IR LED connected through SPI bus.
> +
> + To compile this driver as a module, choose M here: the module will be
> + called ir-spi.
> +
> config IR_STREAMZAP
> tristate "Streamzap PC Remote IR Receiver"
> depends on USB_ARCH_HAS_HCD
> diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
> index 379a5c0..1417c8d 100644
> --- a/drivers/media/rc/Makefile
> +++ b/drivers/media/rc/Makefile
> @@ -27,6 +27,7 @@ obj-$(CONFIG_IR_NUVOTON) += nuvoton-cir.o
> obj-$(CONFIG_IR_ENE) += ene_ir.o
> obj-$(CONFIG_IR_REDRAT3) += redrat3.o
> obj-$(CONFIG_IR_RX51) += ir-rx51.o
> +obj-$(CONFIG_IR_SPI) += ir-spi.o
> obj-$(CONFIG_IR_STREAMZAP) += streamzap.o
> obj-$(CONFIG_IR_WINBOND_CIR) += winbond-cir.o
> obj-$(CONFIG_RC_LOOPBACK) += rc-loopback.o
> diff --git a/drivers/media/rc/ir-spi.c b/drivers/media/rc/ir-spi.c
> new file mode 100644
> index 000..7b6f344
> --- /dev/null
> +++ b/drivers/media/rc/ir-spi.c
> @@ -0,0 +1,133 @@
> +/*
> + * Copyright (c) 2016 Samsung Electronics Co., Ltd.
> + * Author: Andi Shyti
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * SPI driven IR LED device driver
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define IR_SPI_DRIVER_NAME "ir-spi"
> +
> +#define IR_SPI_DEFAULT_FREQUENCY 38000
> +#define IR_SPI_BIT_PER_WORD 8
> +
> +struct ir_spi_data {
> + struct rc_dev *rc;
> + struct spi_device *spi;
> + struct spi_transfer xfer;
> + struct mutex mutex;
> + struct regulator *regulator;
> +};
> +
> +static int ir_spi_tx(struct rc_dev *dev, unsigned *buffer, unsigned n)
> +{
> + int ret;
> + struct ir_spi_data *idata = (struct ir_spi_data *) dev->priv;
No cast needed.
> +
> + ret = regulator_enable(idata->regulator);
> + if (ret)
> + return ret;
> +
> + mutex_lock(&idata->mutex);
> + idata->xfer.len = n;
> + idata->xfer.tx_buf = buffer;
> + mutex_unlock(&idata->mutex);
I'm not convinced the locking works here. You want to guard against
someone modifying xfer while you are sending (so in spi_sync_transfer),
which this locking is not doing. You could declare a
local "struct spi_transfer xfer" and avoid the mutex altogether.
As discussed here you should be converting from pulse-space also.
> +
> + ret = spi_sync_transfer(idata->spi, &idata->xfer, 1);
> + if (ret)
> + dev_err(&idata->spi->dev, "unable to deliver the signal\n");
> +
> + regulator_disable(idata->regulator);
> +
> + return ret;
> +}
> +
> +static int ir_spi_set_tx_carrier(struct rc_dev *dev, u32 carrier)
> +{
> + struct ir_spi_data *idata = (struct ir_spi_data *) dev->priv;
No cast needed here.
> +
> + if (!carrier)
> + return -EINVAL;
> +
> + mutex_lock(&idata->mutex);
> + idata->xfer.speed_hz = carrier;
> + mutex_unlock(&idata->mutex);
> +
> + return 0;
> +}
> +
> +static int ir_spi_probe(struct spi_device *spi)
> +{
> +
Re: Troubles with kernel-doc and RST files
On Sun, 17 Jul 2016 10:01:54 -0300 Mauro Carvalho Chehab wrote: > 2) For functions, kernel-doc is now an all or nothing. If not all > functions are declared, it outputs this warning: > > ./include/media/media-devnode.h:1: warning: no structured comments > > And give up. No functions are exported, nor it points where it bailed. > So, we need to manually look into all exported symbols to identify > what's missing So could you describe this one in a bit more detail? An example of a file with the problem and associated kernel-doc directive would be most helpful here. This sounds like something we definitely want to fix. Thanks, jon -- 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: Troubles with kernel-doc and RST files
On Tue, 19 Jul 2016 12:00:24 +0200 Markus Heiser wrote: > I recommend to consider to switch to the python version of the parser. > I know, that there is a natural shyness about a reimplementation in python > and thats why I offer to support it for a long time period .. it would > be a joy for me ;-) > > If you interested in, I could send a RFC patch for this, if not please > give the reasons why not. We've had this discussion already... The problem is not with "python", it's with "reimplementation". We have enough moving parts in this transition already; tossing in a wholesale replacement of a tool that, for all of its many faults, embodies a couple decades worth of experience just doesn't seem like the right thing to do at this time. I will be happy to entertain the idea of a new kernel-doc in the future; trust me, I have no emotional attachment to the current one. But please let's solidify what we have now first. There's enough stuff to deal with as it is. Thanks, jon -- 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 00/18] Complete moving media documentation to ReST format
On Tue, 19 Jul 2016 11:53:19 -0300 Mauro Carvalho Chehab wrote: > So, I guess we should set the minimal requirement to 1.2.x. *sigh*. I hate to do that; things are happening quickly enough with Sphinx that it would be nice to be able to count on a newer version. That said, one of my goals in this whole thing was to make it *easier* for developers to generate the docs; the DocBook toolchain has always been notoriously difficult in that regard. Forcing people to install a newer sphinx by hand is not the way to get there. So I guess we need to make sure things work with 1.2 for now. I'd hope we could push that to at least 1.3 before too long, though, once the community distributions are there. I think we can be a *bit* more aggressive with the docs than with the kernel as a whole. jon -- 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 5/7] [media] ir-lirc-codec: do not handle any buffer for raw transmitters
On Wed, Jul 20, 2016 at 12:56:56AM +0900, Andi Shyti wrote:
> Raw transmitters receive the data which need to be sent to
> receivers from userspace as stream of bits, they don't require
> any handling from the lirc framework.
No drivers of type RC_DRIVER_IR_RAW_TX should handle tx just like any
other device, so data should be provided as an array of u32 alternating
pulse-space. If your device does not handle input like that then convert
it into that format in the driver. Every other driver has to do some
sort of conversion of that kind.
Thanks
Sean
>
> Signed-off-by: Andi Shyti
> ---
> drivers/media/rc/ir-lirc-codec.c | 30 +++---
> 1 file changed, 19 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/media/rc/ir-lirc-codec.c
> b/drivers/media/rc/ir-lirc-codec.c
> index 5effc65..80e94b6 100644
> --- a/drivers/media/rc/ir-lirc-codec.c
> +++ b/drivers/media/rc/ir-lirc-codec.c
> @@ -121,17 +121,6 @@ static ssize_t ir_lirc_transmit_ir(struct file *file,
> const char __user *buf,
> if (!lirc)
> return -EFAULT;
>
> - if (n < sizeof(unsigned) || n % sizeof(unsigned))
> - return -EINVAL;
> -
> - count = n / sizeof(unsigned);
> - if (count > LIRCBUF_SIZE || count % 2 == 0)
> - return -EINVAL;
> -
> - txbuf = memdup_user(buf, n);
> - if (IS_ERR(txbuf))
> - return PTR_ERR(txbuf);
> -
> dev = lirc->dev;
> if (!dev) {
> ret = -EFAULT;
> @@ -143,6 +132,25 @@ static ssize_t ir_lirc_transmit_ir(struct file *file,
> const char __user *buf,
> goto out;
> }
>
> + if (dev->driver_type == RC_DRIVER_IR_RAW_TX) {
> + txbuf = memdup_user(buf, n);
> + if (IS_ERR(txbuf))
> + return PTR_ERR(txbuf);
> +
> + return dev->tx_ir(dev, txbuf, n);
> + }
> +
> + if (n < sizeof(unsigned) || n % sizeof(unsigned))
> + return -EINVAL;
> +
> + count = n / sizeof(unsigned);
> + if (count > LIRCBUF_SIZE || count % 2 == 0)
> + return -EINVAL;
> +
> + txbuf = memdup_user(buf, n);
> + if (IS_ERR(txbuf))
> + return PTR_ERR(txbuf);
> +
> for (i = 0; i < count; i++) {
> if (txbuf[i] > IR_MAX_DURATION / 1000 - duration || !txbuf[i]) {
> ret = -EINVAL;
> --
> 2.8.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
--
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 3/7] [media] rc-core: add support for IR raw transmitters
On Wed, Jul 20, 2016 at 12:56:54AM +0900, Andi Shyti wrote:
> IR raw transmitter driver type is specified in the enum
> rc_driver_type as RC_DRIVER_IR_RAW_TX which includes all those
> devices that transmit raw stream of bit to a receiver.
>
> The data are provided by userspace applications, therefore they
> don't need any input device allocation, but still they need to be
> registered as raw devices.
>
> Suggested-by: Sean Young
> Signed-off-by: Andi Shyti
> ---
> drivers/media/rc/rc-main.c | 35 +++
> include/media/rc-core.h| 1 +
> 2 files changed, 24 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
> index ac91157..f555f38 100644
> --- a/drivers/media/rc/rc-main.c
> +++ b/drivers/media/rc/rc-main.c
> @@ -1354,20 +1354,24 @@ struct rc_dev *rc_allocate_device(enum rc_driver_type
> type)
> if (!dev)
> return NULL;
>
> - dev->input_dev = input_allocate_device();
> - if (!dev->input_dev) {
> - kfree(dev);
> - return NULL;
> - }
> + if (type != RC_DRIVER_IR_RAW_TX) {
> + dev->input_dev = input_allocate_device();
> + if (!dev->input_dev) {
> + kfree(dev);
> + return NULL;
> + }
>
> - dev->input_dev->getkeycode = ir_getkeycode;
> - dev->input_dev->setkeycode = ir_setkeycode;
> - input_set_drvdata(dev->input_dev, dev);
> + dev->input_dev->getkeycode = ir_getkeycode;
> + dev->input_dev->setkeycode = ir_setkeycode;
> + input_set_drvdata(dev->input_dev, dev);
>
> - spin_lock_init(&dev->rc_map.lock);
> - spin_lock_init(&dev->keylock);
> + setup_timer(&dev->timer_keyup, ir_timer_keyup,
> + (unsigned long)dev);
> +
> + spin_lock_init(&dev->rc_map.lock);
> + spin_lock_init(&dev->keylock);
> + }
> mutex_init(&dev->lock);
> - setup_timer(&dev->timer_keyup, ir_timer_keyup, (unsigned long)dev);
>
> dev->dev.type = &rc_dev_type;
> dev->dev.class = &rc_class;
> @@ -1515,7 +1519,14 @@ int rc_register_device(struct rc_dev *dev)
> dev->input_name ?: "Unspecified device", path ?: "N/A");
> kfree(path);
>
> - if (dev->driver_type == RC_DRIVER_IR_RAW) {
> + if (dev->driver_type != RC_DRIVER_IR_RAW_TX) {
> + rc = rc_setup_rx_device(dev);
> + if (rc)
> + goto out_dev;
> + }
> +
> + if (dev->driver_type == RC_DRIVER_IR_RAW ||
> + dev->driver_type == RC_DRIVER_IR_RAW_TX) {
Here the if is wrong. It should be
"if (dev->driver_type != RC_DRIVER_IR_RAW_TX)". Note that as result
the decoder thread is not started, so patch 4 won't be needed either.
> if (!raw_init) {
> request_module_nowait("ir-lirc-codec");
> raw_init = true;
> diff --git a/include/media/rc-core.h b/include/media/rc-core.h
> index c6bf1ef..77b0893 100644
> --- a/include/media/rc-core.h
> +++ b/include/media/rc-core.h
> @@ -32,6 +32,7 @@ do {
> \
> enum rc_driver_type {
> RC_DRIVER_SCANCODE = 0, /* Driver or hardware generates a scancode */
> RC_DRIVER_IR_RAW, /* Needs a Infra-Red pulse/space decoder */
> + RC_DRIVER_IR_RAW_TX,/* Device is transmitter, driver handles raw */
The comment should really mention the lack of receiver.
--
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 1/7] [media] rc-main: assign driver type during allocation
On Wed, Jul 20, 2016 at 12:56:52AM +0900, Andi Shyti wrote:
> The driver type can be assigned immediately when an RC device
> requests to the framework to allocate the device.
>
> This is an 'enum rc_driver_type' data type and specifies whether
> the device is a raw receiver or scancode receiver. The type will
> be given as parameter to the rc_allocate_device device.
This patch is good, but it does unfortunately break all the other
rc-core drivers, as now rc_allocate_device() needs argument. All
drivers will need a simple change in this patch.
Also note that there lots of issues that checkpatch.pl would pick
in these series.
>
> Suggested-by: Sean Young
> Signed-off-by: Andi Shyti
> ---
> drivers/media/rc/rc-main.c | 4 +++-
> include/media/rc-core.h| 2 +-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
> index 7dfc7c2..6403674 100644
> --- a/drivers/media/rc/rc-main.c
> +++ b/drivers/media/rc/rc-main.c
> @@ -1346,7 +1346,7 @@ static struct device_type rc_dev_type = {
> .uevent = rc_dev_uevent,
> };
>
> -struct rc_dev *rc_allocate_device(void)
> +struct rc_dev *rc_allocate_device(enum rc_driver_type type)
> {
> struct rc_dev *dev;
>
> @@ -1373,6 +1373,8 @@ struct rc_dev *rc_allocate_device(void)
> dev->dev.class = &rc_class;
> device_initialize(&dev->dev);
>
> + dev->driver_type = type;
> +
> __module_get(THIS_MODULE);
> return dev;
> }
> diff --git a/include/media/rc-core.h b/include/media/rc-core.h
> index b6586a9..c6bf1ef 100644
> --- a/include/media/rc-core.h
> +++ b/include/media/rc-core.h
> @@ -185,7 +185,7 @@ struct rc_dev {
> * Remote Controller, at sys/class/rc.
> */
>
> -struct rc_dev *rc_allocate_device(void);
> +struct rc_dev *rc_allocate_device(enum rc_driver_type);
> void rc_free_device(struct rc_dev *dev);
> int rc_register_device(struct rc_dev *dev);
> void rc_unregister_device(struct rc_dev *dev);
> --
> 2.8.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
--
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: pwc over musb: 100% frame drop (lost) on high resolution stream
Hi,
On Wed, Jul 20, 2016 at 12:25:44AM +0300, Matwey V. Kornilov wrote:
> 2016-07-19 23:56 GMT+03:00 Bin Liu :
> > Hi,
> >
> > On Tue, Jul 19, 2016 at 11:21:17PM +0300, mat...@sai.msu.ru wrote:
> >> Hello,
> >>
> >> I have Philips SPC 900 camera (0471:0329) connected to my AM335x based
> >> BeagleBoneBlack SBC.
> >> I am sure that both of them are fine and work properly.
> >> I am running Linux 4.6.4 (my kernel config is available at
> >> https://clck.ru/A2kQs ) and I've just discovered, that there is an issue
> >> with frame transfer when high resolution formats are used.
> >>
> >> The issue is the following. I use simple v4l2 example tool (taken from API
> >> docs), which source code is available at http://pastebin.com/grcNXxfe
> >>
> >> When I use (see line 488) 640x480 frames
> >>
> >> fmt.fmt.pix.width = 640;
> >> fmt.fmt.pix.height = 480;
> >>
> >> then I get "select timeout" and don't get any frames.
> >>
> >> When I use 320x240 frames
> >>
> >> fmt.fmt.pix.width = 320;
> >> fmt.fmt.pix.height = 240;
> >>
> >> then about 60% frames are missed. An example outpout of ./a.out -f is
> >> available at https://yadi.sk/d/aRka8xWPtSc4y
> >> It looks like there are pauses between bulks of frames (frame counter and
> >> timestamp as returned from v4l2 API):
> >>
> >> 3 3705.142553
> >> 8 3705.342533
> >> 13 3705.542517
> >> 110 3708.776208
> >> 115 3708.976190
> >> 120 3709.176169
> >> 125 3709.376152
> >> 130 3709.576144
> >> 226 3712.807848
> >>
> >> When I use tiny 160x120 frames
> >>
> >> fmt.fmt.pix.width = 160;
> >> fmt.fmt.pix.height = 120;
> >>
> >> then more frames are received. See output example at
> >> https://yadi.sk/d/DedBmH6ftSc9t
> >> That is why I thought that everything was fine in May when used tiny xawtv
> >> window to check kernel OOPS presence (see
> >> http://www.spinics.net/lists/linux-usb/msg141188.html for reference)
> >>
> >> Even more. When I introduce USB hub between the host and the webcam, I can
> >> not receive even any 320x240 frames.
> >>
> >> I've managed to use ftrace to see what is going on when no frames are
> >> received.
> >> I've found that pwc_isoc_handler is called frequently as the following:
> >>
> >> 0) | pwc_isoc_handler [pwc]() {
> >> 0) |usb_submit_urb [usbcore]() {
> >> 0) | usb_submit_urb.part.3 [usbcore]() {
> >> 0) |usb_hcd_submit_urb [usbcore]() {
> >> 0) 0.834 us| usb_get_urb [usbcore]();
> >> 0) | musb_map_urb_for_dma [musb_hdrc]() {
> >> 0) 0.792 us|usb_hcd_map_urb_for_dma [usbcore]();
> >> 0) 5.750 us| }
> >> 0) | musb_urb_enqueue [musb_hdrc]() {
> >> 0) 0.750 us|_raw_spin_lock_irqsave();
> >> 0) |usb_hcd_link_urb_to_ep [usbcore]() {
> >> 0) 0.792 us| _raw_spin_lock();
> >> 0) 0.791 us| _raw_spin_unlock();
> >> 0) + 10.500 us |}
> >> 0) 0.791 us|_raw_spin_unlock_irqrestore();
> >> 0) + 25.375 us | }
> >> 0) + 45.208 us |}
> >> 0) + 51.042 us | }
> >> 0) + 56.084 us |}
> >> 0) + 61.292 us | }
> >>
> >> However, pwc_isoc_handler never calls vb2_buffer_done() that is why I get
> >> "select timeout" in userspace.
> >> Unfortunately, my kernel is not compiled with CONFIG_USB_PWC_DEBUG=y but I
> >> can recompile it, if you think that it could provide more information. I
> >> am also ready to perform additional tests (use usbmon maybe?).
> >>
> >> How could this issue be resolved?
> >>
> >> Thank you.
> >
> > Do you have CPPI DMA enabled? If so I think you might hit on a known
> > issue in CPPI Isoch transfer, in which the MUSB controller only sends IN
> > tokens in every other SOF, so only half of the bus bandwidth is
> > utilized, which causes video frame drops in higher resolution.
> >
>
> Yes, I do use DMA:
>
> CONFIG_USB_TI_CPPI41_DMA=y
Okay.
>
> > To confirm this, use a bus analyzer to capture a bus trace, you would
> > see no IN tokens in every other SOF while transfering Isoch packets.
> >
>
> I am sorry, I am new to USB debugging. Do you mean I need to use
> usbmon or some external hardware device?
I barely use usbmon, and not sure if it gives the information I am
looking for. But I meant the external test equipment - USB bus protocol
analyzer - a bus packet sniffer.
Regards,
-Bin,
>
> > Regards,
> > -Bin.
> >
>
>
>
> --
> With best regards,
> Matwey V. Kornilov.
> Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
> 119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
--
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.kern
Re: pwc over musb: 100% frame drop (lost) on high resolution stream
2016-07-19 23:56 GMT+03:00 Bin Liu :
> Hi,
>
> On Tue, Jul 19, 2016 at 11:21:17PM +0300, mat...@sai.msu.ru wrote:
>> Hello,
>>
>> I have Philips SPC 900 camera (0471:0329) connected to my AM335x based
>> BeagleBoneBlack SBC.
>> I am sure that both of them are fine and work properly.
>> I am running Linux 4.6.4 (my kernel config is available at
>> https://clck.ru/A2kQs ) and I've just discovered, that there is an issue
>> with frame transfer when high resolution formats are used.
>>
>> The issue is the following. I use simple v4l2 example tool (taken from API
>> docs), which source code is available at http://pastebin.com/grcNXxfe
>>
>> When I use (see line 488) 640x480 frames
>>
>> fmt.fmt.pix.width = 640;
>> fmt.fmt.pix.height = 480;
>>
>> then I get "select timeout" and don't get any frames.
>>
>> When I use 320x240 frames
>>
>> fmt.fmt.pix.width = 320;
>> fmt.fmt.pix.height = 240;
>>
>> then about 60% frames are missed. An example outpout of ./a.out -f is
>> available at https://yadi.sk/d/aRka8xWPtSc4y
>> It looks like there are pauses between bulks of frames (frame counter and
>> timestamp as returned from v4l2 API):
>>
>> 3 3705.142553
>> 8 3705.342533
>> 13 3705.542517
>> 110 3708.776208
>> 115 3708.976190
>> 120 3709.176169
>> 125 3709.376152
>> 130 3709.576144
>> 226 3712.807848
>>
>> When I use tiny 160x120 frames
>>
>> fmt.fmt.pix.width = 160;
>> fmt.fmt.pix.height = 120;
>>
>> then more frames are received. See output example at
>> https://yadi.sk/d/DedBmH6ftSc9t
>> That is why I thought that everything was fine in May when used tiny xawtv
>> window to check kernel OOPS presence (see
>> http://www.spinics.net/lists/linux-usb/msg141188.html for reference)
>>
>> Even more. When I introduce USB hub between the host and the webcam, I can
>> not receive even any 320x240 frames.
>>
>> I've managed to use ftrace to see what is going on when no frames are
>> received.
>> I've found that pwc_isoc_handler is called frequently as the following:
>>
>> 0) | pwc_isoc_handler [pwc]() {
>> 0) |usb_submit_urb [usbcore]() {
>> 0) | usb_submit_urb.part.3 [usbcore]() {
>> 0) |usb_hcd_submit_urb [usbcore]() {
>> 0) 0.834 us| usb_get_urb [usbcore]();
>> 0) | musb_map_urb_for_dma [musb_hdrc]() {
>> 0) 0.792 us|usb_hcd_map_urb_for_dma [usbcore]();
>> 0) 5.750 us| }
>> 0) | musb_urb_enqueue [musb_hdrc]() {
>> 0) 0.750 us|_raw_spin_lock_irqsave();
>> 0) |usb_hcd_link_urb_to_ep [usbcore]() {
>> 0) 0.792 us| _raw_spin_lock();
>> 0) 0.791 us| _raw_spin_unlock();
>> 0) + 10.500 us |}
>> 0) 0.791 us|_raw_spin_unlock_irqrestore();
>> 0) + 25.375 us | }
>> 0) + 45.208 us |}
>> 0) + 51.042 us | }
>> 0) + 56.084 us |}
>> 0) + 61.292 us | }
>>
>> However, pwc_isoc_handler never calls vb2_buffer_done() that is why I get
>> "select timeout" in userspace.
>> Unfortunately, my kernel is not compiled with CONFIG_USB_PWC_DEBUG=y but I
>> can recompile it, if you think that it could provide more information. I am
>> also ready to perform additional tests (use usbmon maybe?).
>>
>> How could this issue be resolved?
>>
>> Thank you.
>
> Do you have CPPI DMA enabled? If so I think you might hit on a known
> issue in CPPI Isoch transfer, in which the MUSB controller only sends IN
> tokens in every other SOF, so only half of the bus bandwidth is
> utilized, which causes video frame drops in higher resolution.
>
Yes, I do use DMA:
CONFIG_USB_TI_CPPI41_DMA=y
> To confirm this, use a bus analyzer to capture a bus trace, you would
> see no IN tokens in every other SOF while transfering Isoch packets.
>
I am sorry, I am new to USB debugging. Do you mean I need to use
usbmon or some external hardware device?
> Regards,
> -Bin.
>
--
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382
--
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: pwc over musb: 100% frame drop (lost) on high resolution stream
Hi,
On Tue, Jul 19, 2016 at 11:21:17PM +0300, mat...@sai.msu.ru wrote:
> Hello,
>
> I have Philips SPC 900 camera (0471:0329) connected to my AM335x based
> BeagleBoneBlack SBC.
> I am sure that both of them are fine and work properly.
> I am running Linux 4.6.4 (my kernel config is available at
> https://clck.ru/A2kQs ) and I've just discovered, that there is an issue with
> frame transfer when high resolution formats are used.
>
> The issue is the following. I use simple v4l2 example tool (taken from API
> docs), which source code is available at http://pastebin.com/grcNXxfe
>
> When I use (see line 488) 640x480 frames
>
> fmt.fmt.pix.width = 640;
> fmt.fmt.pix.height = 480;
>
> then I get "select timeout" and don't get any frames.
>
> When I use 320x240 frames
>
> fmt.fmt.pix.width = 320;
> fmt.fmt.pix.height = 240;
>
> then about 60% frames are missed. An example outpout of ./a.out -f is
> available at https://yadi.sk/d/aRka8xWPtSc4y
> It looks like there are pauses between bulks of frames (frame counter and
> timestamp as returned from v4l2 API):
>
> 3 3705.142553
> 8 3705.342533
> 13 3705.542517
> 110 3708.776208
> 115 3708.976190
> 120 3709.176169
> 125 3709.376152
> 130 3709.576144
> 226 3712.807848
>
> When I use tiny 160x120 frames
>
> fmt.fmt.pix.width = 160;
> fmt.fmt.pix.height = 120;
>
> then more frames are received. See output example at
> https://yadi.sk/d/DedBmH6ftSc9t
> That is why I thought that everything was fine in May when used tiny xawtv
> window to check kernel OOPS presence (see
> http://www.spinics.net/lists/linux-usb/msg141188.html for reference)
>
> Even more. When I introduce USB hub between the host and the webcam, I can
> not receive even any 320x240 frames.
>
> I've managed to use ftrace to see what is going on when no frames are
> received.
> I've found that pwc_isoc_handler is called frequently as the following:
>
> 0) | pwc_isoc_handler [pwc]() {
> 0) |usb_submit_urb [usbcore]() {
> 0) | usb_submit_urb.part.3 [usbcore]() {
> 0) |usb_hcd_submit_urb [usbcore]() {
> 0) 0.834 us| usb_get_urb [usbcore]();
> 0) | musb_map_urb_for_dma [musb_hdrc]() {
> 0) 0.792 us|usb_hcd_map_urb_for_dma [usbcore]();
> 0) 5.750 us| }
> 0) | musb_urb_enqueue [musb_hdrc]() {
> 0) 0.750 us|_raw_spin_lock_irqsave();
> 0) |usb_hcd_link_urb_to_ep [usbcore]() {
> 0) 0.792 us| _raw_spin_lock();
> 0) 0.791 us| _raw_spin_unlock();
> 0) + 10.500 us |}
> 0) 0.791 us|_raw_spin_unlock_irqrestore();
> 0) + 25.375 us | }
> 0) + 45.208 us |}
> 0) + 51.042 us | }
> 0) + 56.084 us |}
> 0) + 61.292 us | }
>
> However, pwc_isoc_handler never calls vb2_buffer_done() that is why I get
> "select timeout" in userspace.
> Unfortunately, my kernel is not compiled with CONFIG_USB_PWC_DEBUG=y but I
> can recompile it, if you think that it could provide more information. I am
> also ready to perform additional tests (use usbmon maybe?).
>
> How could this issue be resolved?
>
> Thank you.
Do you have CPPI DMA enabled? If so I think you might hit on a known
issue in CPPI Isoch transfer, in which the MUSB controller only sends IN
tokens in every other SOF, so only half of the bus bandwidth is
utilized, which causes video frame drops in higher resolution.
To confirm this, use a bus analyzer to capture a bus trace, you would
see no IN tokens in every other SOF while transfering Isoch packets.
Regards,
-Bin.
--
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
pwc over musb: 100% frame drop (lost) on high resolution stream
Hello,
I have Philips SPC 900 camera (0471:0329) connected to my AM335x based
BeagleBoneBlack SBC.
I am sure that both of them are fine and work properly.
I am running Linux 4.6.4 (my kernel config is available at
https://clck.ru/A2kQs ) and I've just discovered, that there is an issue with
frame transfer when high resolution formats are used.
The issue is the following. I use simple v4l2 example tool (taken from API
docs), which source code is available at http://pastebin.com/grcNXxfe
When I use (see line 488) 640x480 frames
fmt.fmt.pix.width = 640;
fmt.fmt.pix.height = 480;
then I get "select timeout" and don't get any frames.
When I use 320x240 frames
fmt.fmt.pix.width = 320;
fmt.fmt.pix.height = 240;
then about 60% frames are missed. An example outpout of ./a.out -f is available
at https://yadi.sk/d/aRka8xWPtSc4y
It looks like there are pauses between bulks of frames (frame counter and
timestamp as returned from v4l2 API):
3 3705.142553
8 3705.342533
13 3705.542517
110 3708.776208
115 3708.976190
120 3709.176169
125 3709.376152
130 3709.576144
226 3712.807848
When I use tiny 160x120 frames
fmt.fmt.pix.width = 160;
fmt.fmt.pix.height = 120;
then more frames are received. See output example at
https://yadi.sk/d/DedBmH6ftSc9t
That is why I thought that everything was fine in May when used tiny xawtv
window to check kernel OOPS presence (see
http://www.spinics.net/lists/linux-usb/msg141188.html for reference)
Even more. When I introduce USB hub between the host and the webcam, I can not
receive even any 320x240 frames.
I've managed to use ftrace to see what is going on when no frames are received.
I've found that pwc_isoc_handler is called frequently as the following:
0) | pwc_isoc_handler [pwc]() {
0) |usb_submit_urb [usbcore]() {
0) | usb_submit_urb.part.3 [usbcore]() {
0) |usb_hcd_submit_urb [usbcore]() {
0) 0.834 us| usb_get_urb [usbcore]();
0) | musb_map_urb_for_dma [musb_hdrc]() {
0) 0.792 us|usb_hcd_map_urb_for_dma [usbcore]();
0) 5.750 us| }
0) | musb_urb_enqueue [musb_hdrc]() {
0) 0.750 us|_raw_spin_lock_irqsave();
0) |usb_hcd_link_urb_to_ep [usbcore]() {
0) 0.792 us| _raw_spin_lock();
0) 0.791 us| _raw_spin_unlock();
0) + 10.500 us |}
0) 0.791 us|_raw_spin_unlock_irqrestore();
0) + 25.375 us | }
0) + 45.208 us |}
0) + 51.042 us | }
0) + 56.084 us |}
0) + 61.292 us | }
However, pwc_isoc_handler never calls vb2_buffer_done() that is why I get
"select timeout" in userspace.
Unfortunately, my kernel is not compiled with CONFIG_USB_PWC_DEBUG=y but I can
recompile it, if you think that it could provide more information. I am also
ready to perform additional tests (use usbmon maybe?).
How could this issue be resolved?
Thank you.
--
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
System freeze when going into suspend after "modprobe -r cx23885 cx25840"
When my system (with last upstream kernel) goes into suspend (hybrid-sleep with systemd), I get sometimes (around every third to fifth time) a system freeze, when systemd removes the modules cx23885 cx25840 for my DVB-C/T card DVBSky T982. The modules are not used at the moment (e.g. by tvheadend). Kernel version from /proc/version: Linux version 4.7.0-040700rc7-generic (kernel@gloin) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1) ) #201607110032 SMP Mon Jul 11 04:34:25 UTC 2016 Command to remove DVB modules in a systemd/systemctl script: modprobe -r cx23885 cx25840 Whole conf for systemd/systemctl in /etc/systemd/system/dvb.service: [Unit] Description=Restart DVB services Before=sleep.target StopWhenUnneeded=yes [Service] Type=oneshot RemainAfterExit=yes ExecStart=/sbin/modprobe -r cx23885 cx25840 ExecStop=/sbin/modprobe cx25840 ; /sbin/modprobe cx23885 [Install] WantedBy=sleep.target Syslog output with error during crash/freeze: Jul 13 14:20:22 HomeServer NetworkManager[783]: [1468412422.2305] manager: sleep requested (sleeping: no enabled: yes) Jul 13 14:20:22 HomeServer NetworkManager[783]: [1468412422.2306] manager: sleeping... Jul 13 14:20:22 HomeServer NetworkManager[783]: [1468412422.2307] manager: NetworkManager state is now ASLEEP Jul 13 14:20:22 HomeServer whoopsie[814]: [14:20:22] offline Jul 13 14:20:22 HomeServer com.canonical.indicator.application[1275]: (process:1466): indicator-application-service-WARNING **: Application already exists, re-requesting properties. Jul 13 14:20:22 HomeServer systemd[1]: Starting Restart DVB services... Jul 13 14:20:22 HomeServer kernel: [ 261.815215] BUG: unable to handle kernel NULL pointer dereference at 0200 Jul 13 14:20:22 HomeServer kernel: [ 261.815291] IP: [] dvb_frontend_stop+0x34/0xd0 [dvb_core] Jul 13 14:20:22 HomeServer kernel: [ 261.815356] PGD 0 Jul 13 14:20:22 HomeServer kernel: [ 261.815377] Oops: [#1] SMP Jul 13 14:20:22 HomeServer kernel: [ 261.815403] Modules linked in: cx23885(-) altera_ci tda18271 altera_stapl m88ds3103 tveeprom cx2341x videobuf2_dvb dvb_core rc_core videobuf2_dma_sg videobuf2_memops videobuf2_v4l2 videobuf2_core cx25840 v4l2_common videodev fuse si2157 si2168 nls_utf8 nls_cp437 vfat fat snd_hda_codec_hdmi snd_hda_intel snd_hda_codec snd_hda_core i2c_mux snd_hwdep snd_pcm intel_rapl x86_pkg_temp_thermal intel_powerclamp snd_seq_midi coretemp snd_seq_midi_event snd_rawmidi kvm_intel kvm irqbypass intel_cstate intel_rapl_perf snd_seq efi_pstore snd_seq_device snd_timer joydev media serio_raw efivars lpc_ich sg snd mfd_core soundcore mei_me mei shpchp battery evdev tpm_tis tpm parport_pc ppdev lp parport efivarfs autofs4 ext4 crc16 jbd2 mbcache xts gf128mul algif_skcipher af_alg dm_crypt dm_mod raid10 raid1 raid0 multipath linear raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c crc32c_generic md_mod sd_mod hid_logitech_hidpp hid_logitech_dj usbhid hid crct10dif_pclmul crc32_pclmul ahci libahci crc32c_intel libata ghash_clmulni_intel cryptd scsi_mod psmouse fan thermal xhci_pci ehci_pci xhci_hcd ehci_hcd e1000e fjes ptp i915 pps_core usbcore video button i2c_algo_bit usb_common drm_kms_helper drm [last unloaded: videodev] Jul 13 14:20:22 HomeServer kernel: [ 261.816495] CPU: 0 PID: 2789 Comm: modprobe Not tainted 4.7.0-040700rc7-generic #201607110032 Jul 13 14:20:22 HomeServer kernel: [ 261.816555] Hardware name: /DH87RL, BIOS RLH8710H.86A.0330.2015.0720.1750 07/20/2015 Jul 13 14:20:22 HomeServer kernel: [ 261.816620] task: 8800d11ef1c0 ti: 8800d6be task.ti: 8800d6be Jul 13 14:20:22 HomeServer kernel: [ 261.816673] RIP: 0010:[] [] dvb_frontend_stop+0x34/0xd0 [dvb_core] Jul 13 14:20:22 HomeServer kernel: [ 261.816749] RSP: 0018:8800d6be3d78 EFLAGS: 00010293 Jul 13 14:20:22 HomeServer kernel: [ 261.816789] RAX: 8800d11ef1c0 RBX: RCX: ea00035bd51f Jul 13 14:20:22 HomeServer kernel: [ 261.816839] RDX: 8000 RSI: 8800b725b400 RDI: 8800590e1830 Jul 13 14:20:22 HomeServer kernel: [ 261.816889] RBP: 8800590e1830 R08: ea0001459b60 R09: 0002 Jul 13 14:20:22 HomeServer kernel: [ 261.816940] R10: 81b09300 R11: 81b092c0 R12: 8800d1a3f280 Jul 13 14:20:22 HomeServer kernel: [ 261.820361] R13: 880112889768 R14: 880112889778 R15: 7ffd78781738 Jul 13 14:20:22 HomeServer kernel: [ 261.823746] FS: 7efd7e7d8700() GS:88011fa0() knlGS: Jul 13 14:20:22 HomeServer kernel: [ 261.827151] CS: 0010 DS: ES: CR0: 80050033 Jul 13 14:20:22 HomeServer kernel: [ 261.830458] CR2: 0200 CR3: 343db000 CR4: 000406f0 Jul 13 14:20:22 HomeServer kernel: [ 261.833570] Stack: Jul 13 14:20:22 HomeServer kernel: [ 261.836658] 8800590e1830 c086f236 c06e1281 Jul 13 14:20:22 HomeServer kernel: [ 261.839813] 880112889768 8801128897
[PATCH] [media] tw686x: Delete an unnecessary check before the function call "video_unregister_device"
From: Markus Elfring
Date: Tue, 19 Jul 2016 21:24:26 +0200
The video_unregister_device() function tests whether its argument is NULL
and then returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/media/pci/tw686x/tw686x-video.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/media/pci/tw686x/tw686x-video.c
b/drivers/media/pci/tw686x/tw686x-video.c
index cdb16de..4475a9d9 100644
--- a/drivers/media/pci/tw686x/tw686x-video.c
+++ b/drivers/media/pci/tw686x/tw686x-video.c
@@ -1093,8 +1093,7 @@ void tw686x_video_free(struct tw686x_dev *dev)
for (ch = 0; ch < max_channels(dev); ch++) {
struct tw686x_video_channel *vc = &dev->video_channels[ch];
- if (vc->device)
- video_unregister_device(vc->device);
+ video_unregister_device(vc->device);
if (dev->dma_ops->free)
for (pb = 0; pb < 2; pb++)
--
2.9.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] [media] v4l2-common: Delete an unnecessary check before the function call "spi_unregister_device"
Am 19.07.2016 20:02, schrieb SF Markus Elfring: > From: Markus Elfring > Date: Tue, 19 Jul 2016 19:54:16 +0200 > > The spi_unregister_device() function tests whether its argument is NULL > and then returns immediately. Thus the test around the call is not needed. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring > --- > drivers/media/v4l2-core/v4l2-common.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/media/v4l2-core/v4l2-common.c > b/drivers/media/v4l2-core/v4l2-common.c > index 5b80850..57cfe26a 100644 > --- a/drivers/media/v4l2-core/v4l2-common.c > +++ b/drivers/media/v4l2-core/v4l2-common.c > @@ -291,7 +291,7 @@ struct v4l2_subdev *v4l2_spi_new_subdev(struct > v4l2_device *v4l2_dev, > error: > /* If we have a client but no subdev, then something went wrong and > we must unregister the client. */ > - if (spi && sd == NULL) > + if (!sd) > spi_unregister_device(spi); > > return sd; if i read the code correct sd is always NULL at this point. so this was wrong in the first place and you must remove sd also. re, wh -- 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] v4l2-common: Delete an unnecessary check before the function call "spi_unregister_device"
From: Markus Elfring Date: Tue, 19 Jul 2016 19:54:16 +0200 The spi_unregister_device() function tests whether its argument is NULL and then returns immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/media/v4l2-core/v4l2-common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c index 5b80850..57cfe26a 100644 --- a/drivers/media/v4l2-core/v4l2-common.c +++ b/drivers/media/v4l2-core/v4l2-common.c @@ -291,7 +291,7 @@ struct v4l2_subdev *v4l2_spi_new_subdev(struct v4l2_device *v4l2_dev, error: /* If we have a client but no subdev, then something went wrong and we must unregister the client. */ - if (spi && sd == NULL) + if (!sd) spi_unregister_device(spi); return sd; -- 2.9.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 00/18] Complete moving media documentation to ReST format
Em Tue, 19 Jul 2016 18:42:50 +0200 Markus Heiser escreveu: > > What we miss is the documentation for Sphinx 1.2 and 1.3 versions. The > > site only has documentation for the very latest version, making harder > > to ensure that we're using only the tags supported by a certain version. > > We could build the documentation of the (e.g.) 1.2 tag > > https://github.com/sphinx-doc/sphinx/tree/1.2 > > by checkout the tag, cd to "./doc" and run "make html". > I haven't tested yet, but it should work this way. Yep, but this should be placed somewhere and IMHO linked at the kernel-documentation book as the reference to be used by Kernel documentation developers. > > Sphinx is very evil with that regards: it keeps generating the > > files, except that the contents of the tags that contain unrecognized > > fields will be empty (with is very bad for :toctree:) and a few > > additional warnings will be generated. Very hard for a script to detect > > if the doc was OK or got mangled by the toolchain, because of a version > > incompatibility. > > On your build host, you could turn warnings into errors (Daniel posted > the -W option) > > $ make SPHINXOPTS=-W htmldocs > > But this will only be helpfull when the build is free of warnings > (and this will be more and more harder as more content is placed > into). We're very far away for getting it free of warnings, as I didn't find a way yet to get rid of some of them. Also, as you said, it is harder as more content is placed, specially when it comes from other books that we don't maintain. > > >> IMHO the main problem is, that we have not yet documented on which > >> Sphinx version we agree and how to get a build environment which > >> fullfills these requirements. > > > > Yes, the Sphinx minimal version should be documented at > > Documentation/Changes. > > > > I'd say that the minimal version should be the Sphinx version > > found on the latest version of the main distributions, e .g. > > at least Fedora, openSuse, Debian, Ubuntu. > > (I guess distros like ArchLinux and Gentoo won't be a problem, > > as they tend to use the newer versions of the sources). > > > > On a quick check: > > > > - Fedora 24 comes with 1.3.x > > - openSuse 13.2 with 1.2.x > > - Debian 8.5 with 1.2.x. > > - Ubuntu 16.04 with 1.3.x > > - Ubuntu 14.04 with 1.2.x > > - Mageia 5 with 1.2.x > > > > So, I guess we should set the minimal requirement to 1.2.x. > > > > Btw, usually, on Kernel, we're very conservative to increment the > > minimal version of a toolchain. So, for example, while GCC current > > version is 6.1, the minimal requirement is gcc 3.2 (with was released > > in 2003). > > OK, I understand, but I have a differentiated meaning about *pure-kernel* > and toolchains to build kernel documentation. I know, that there is a > unclear boundary, but IMHO: while the key aspects of *pure-kernel* are > stability, > backward compatibility etc. they key aspects of building documentation > are more on accessibility in multiple and modern output formats. E.g. there > was a discussion if javascript should be needed in HTML, or think about > output formats like ePub etc. ... when we want to get in use of all > this various, we need to follow up to date developments. > > E.g. if we use Sphinx 1.2, we have to test how well it works with the RTD > theme > we have to cover all the bugs and drawbacks of the old version and we will > get problems if we want to use modern builders. We have to write and test > our extensions with backward compatibility in mind etc. IMHO building a > toolchain with backward compatibility and fixed errors will take > much more time. IMHO we should not try to do what sphinx-doc & Co. > wan't do. > > Will should also take in mind, that Sphinx-doc is (compared to gcc > or DocBook) a upcoming development, it first 1.0 release is from 2010. > > Note: > > Previous is my opinion, I'am not a *pure kernel* developer, please > correct if I oversee some of kernel developers needs or problems > raised with kernel development. I guess you missed the point. From my PoV, what I expect by using a markup language is that a lot more developers will be able to write patches improving the media documentation, as it is easier to write a markup text than to write docs for DocBook. However, this will only happen if the developers would be able to test if their documentation changes will be recognized by the toolchain. If we raise the bar and require that every developer working on documentation to be a Python expert and install their own virtualenv, this will never happen, and even the current contributors won't do it, as very few Kernel developers are also Python developers. > >> For build environments I recommend to set up a python virtualenv > >> > >> * https://virtualenv.pypa.io/en/stable/ > > > > We can't assume that every Kernel developer would install a > > python virtualenv. Instead, they'll just use whatever Sphinx > > version is provided on the
Re: [PATCHv2 04/16] [media] rcar-vin: return correct error from platform_get_irq
Hello. On 07/19/2016 05:20 PM, Niklas Söderlund wrote: Fix a error from the original driver where the wrong error code is returned if the driver fails to get a IRQ number from platform_get_irq(). Signed-off-by: Niklas Söderlund --- drivers/media/platform/rcar-vin/rcar-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/rcar-vin/rcar-core.c b/drivers/media/platform/rcar-vin/rcar-core.c index 481d82a..ff27d75 100644 --- a/drivers/media/platform/rcar-vin/rcar-core.c +++ b/drivers/media/platform/rcar-vin/rcar-core.c @@ -318,7 +318,7 @@ static int rcar_vin_probe(struct platform_device *pdev) irq = platform_get_irq(pdev, 0); if (irq <= 0) - return ret; + return irq; This is still wrong, i.e. it'll return 0 from the probe() method if 'irq' is 0 (and you consider that an error). [...] MBR, Sergei -- 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/3] [media] hva: multi-format video encoder V4L2 driver
On 07/19/2016 05:55 PM, Jean Christophe TROTIN wrote:
> Hi Hans,
>
> Thank you for your comments.
> I've started to take them into account.
> I've got a question about V4L2_FIELD_ANY in buf_prepare (please see below).
>
> [snip]
>
> >> +static int hva_buf_prepare(struct vb2_buffer *vb)
> >> +{
> >> + struct hva_ctx *ctx = vb2_get_drv_priv(vb->vb2_queue);
> >> + struct device *dev = ctx_to_dev(ctx);
> >> + struct vb2_v4l2_buffer *vbuf = to_vb2_v4l2_buffer(vb);
> >> +
> >> + if (vb->vb2_queue->type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
> >> + struct hva_frame *frame = to_hva_frame(vbuf);
> >> +
> >> + if (vbuf->field == V4L2_FIELD_ANY)
> >> + vbuf->field = V4L2_FIELD_NONE;
> >
> > Anything other than FIELD_NONE should result in an error since no
> interlaced
> is supported.
> > FIELD_ANY is an incorrect value as well.
> >
>
> In videodev2.h, V4L2_FIELD_ANY is commented as "driver can choose from none,
> top, bottom, interlaced depending on whatever it thinks is approximate ...":
> I
> understand this comment as if vbuf->field is equal to V4L2_FIELD_ANY, then
> the
> driver can choose to force it to V4L2_FIELD_NONE. Furthermore, it's coded in
> the
> same way in vim2m.c (vim2m_buf_prepare).
> Finally, if I remove these 2 lines, I've got the following error with the
> v4l2-compliance:
> Streaming ioctls:
> VIDIOC_G_INPUT returned -1 (Inappropriate ioctl for device)
> VIDIOC_ENUMINPUT returned -1 (Inappropriate ioctl for device)
> test read/write: OK (Not Supported)
> VIDIOC_QUERYCAP returned 0 (Success)
> [snip]
> VIDIOC_QUERYBUF returned 0 (Success)
> VIDIOC_QBUF returned -1 (Invalid argument)
> fail:
> /local/home/frq08988/views/opensdk-2.1.4.1/sources/v4l-utils/utils/v4l2-compliance/v4l2-test-buffers.cpp(773):
>
> buf.qbuf(node)
> fail:
> /local/home/frq08988/views/opensdk-2.1.4.1/sources/v4l-utils/utils/v4l2-compliance/v4l2-test-buffers.cpp(971):
>
> setupM2M(node, m2m_q)
> test MMAP: FAIL
>
> Don't you think that I could keep these two lines?
Keep it for now, I dug into this a bit further and it is really a workaround for
poorly written applications that can't be bothered to set the field value to a
proper value. I think the documentation needs to be updated for this.
I might change my mind, though :-)
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
Re: [PATCH] vcodec: mediatek: Add g/s_selection support for V4L2 Encoder
Hi Hans,
On Mon, 2016-07-18 at 14:44 +0200, Hans Verkuil wrote:
> On 07/18/2016 02:28 PM, tiffany lin wrote:
> > Understood now.
> >
> > Now I am trying to figure out how to make this function right.
> > Our encoder only support crop range from (0, 0) to (width, height), so
> > if s->r.top and s->r.left not 0, I will return -EINVAL.
> >
> >
> > Another thing is that in v4l2-compliance test, it has testLegacyCrop.
> > It looks like we still need to support
> > V4L2_SEL_TGT_COMPOSE_DEFAULT:
> > V4L2_SEL_TGT_COMPOSE_BOUNDS:
> > V4L2_SEL_TGT_COMPOSE:
> > to pass v4l2 compliance test, Or it will fail in
> > fail: v4l2-test-formats.cpp(1318): !doioctl(node, VIDIOC_G_SELECTION,
> > &sel)
> > fail: v4l2-test-formats.cpp(1336): testLegacyCrop(node)
> > test Cropping: FAIL
>
> Against which kernel are you testing? In the current media_tree master
> there is a bug in drivers/media/v4l2-core/v4l2-ioctl.c, v4l_cropcap():
>
> This code:
>
> if (WARN_ON(!ops->vidioc_cropcap && !ops->vidioc_cropcap))
>
> should be:
>
> if (WARN_ON(!ops->vidioc_cropcap && !ops->vidioc_g_selection))
>
> The fix is waiting for a pull from Linus.
>
> Also update to the latest v4l2-compliance: I've made some changes that
> might affect this. And I added additional checks to verify if all the
> colorspace-related format fields are properly propagated from the
> output format to the capture format.
>
Sorry, I miss this part.
After update to latest version include this fix, it can pass crop test
without supporting COMPOSE in output queue.
Appreciated for your help
best regards,
Tiffany
> Regards,
>
> Hans
>
> >
> > I don't understand the following testing code.
> >
> > /*
> > * If either CROPCAP or G_CROP works, then G_SELECTION should
> > * work as well.
> > * If neither CROPCAP nor G_CROP work, then G_SELECTION
> > shouldn't
> > * work either.
> > */
> > if (!doioctl(node, VIDIOC_CROPCAP, &cap)) {
> > fail_on_test(doioctl(node, VIDIOC_G_SELECTION, &sel));
> >
> > // Checks for invalid types
> > if (cap.type == V4L2_BUF_TYPE_VIDEO_CAPTURE)
> > cap.type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
> > else
> > cap.type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE;
> > fail_on_test(doioctl(node, VIDIOC_CROPCAP, &cap) !=
> > EINVAL);
> > cap.type = 0xff;
> > fail_on_test(doioctl(node, VIDIOC_CROPCAP, &cap) !=
> > EINVAL);
> > } else {
> > fail_on_test(!doioctl(node, VIDIOC_G_SELECTION, &sel));
> > -> fail here
> > }
> >
> > When test OUTPUT queue, it fail because v4l_cropcap will fail when
> > s.target = V4L2_SEL_TGT_COMPOSE_BOUNDS.
> > If VIDIOC_CROPCAP ioctl fail, VIDIOC_G_SELECTION should fail.
> > But VIDIOC_G_SELECTION target on CROP not COMPOSE and it success.
> >
> >
> > best regards,
> > Tiffany
> >
> >
> >
> >> Regards,
> >>
> >>Hans
> >>
> >>>
> >>>
> >>> static int v4l_g_crop(const struct v4l2_ioctl_ops *ops,
> >>> struct file *file, void *fh, void *arg)
> >>> {
> >>> struct v4l2_crop *p = arg;
> >>> struct v4l2_selection s = {
> >>> .type = p->type,
> >>> };
> >>> int ret;
> >>>
> >>> if (ops->vidioc_g_crop)
> >>> return ops->vidioc_g_crop(file, fh, p);
> >>> /* simulate capture crop using selection api */
> >>>
> >>> /* crop means compose for output devices */
> >>> if (V4L2_TYPE_IS_OUTPUT(p->type))
> >>> s.target = V4L2_SEL_TGT_COMPOSE_ACTIVE;
> >>> else
> >>> s.target = V4L2_SEL_TGT_CROP_ACTIVE;
> >>>
> >>> ret = ops->vidioc_g_selection(file, fh, &s);
> >>>
> >>> /* copying results to old structure on success */
> >>> if (!ret)
> >>> p->c = s.r;
> >>> return ret;
> >>> }
> >>>
> >>> static int v4l_s_crop(const struct v4l2_ioctl_ops *ops,
> >>> struct file *file, void *fh, void *arg)
> >>> {
> >>> struct v4l2_crop *p = arg;
> >>> struct v4l2_selection s = {
> >>> .type = p->type,
> >>> .r = p->c,
> >>> };
> >>>
> >>> if (ops->vidioc_s_crop)
> >>> return ops->vidioc_s_crop(file, fh, p);
> >>> /* simulate capture crop using selection api */
> >>>
> >>> /* crop means compose for output devices */
> >>> if (V4L2_TYPE_IS_OUTPUT(p->type))
> >>> s.target = V4L2_SEL_TGT_COMPOSE_ACTIVE;
> >>> else
> >>> s.target = V4L2_SEL_TGT_CROP_ACTIVE;
> >>>
> >>> return ops->vidioc_s_selection(file, fh, &s);
> >>> }
> >>>
> >>>
> >>> best regards,
> >>> Tiffany
> >>>
> >>>
> >>>
> >>>
> Regards,
>
> Hans
>
> > +
> > + return 0;
> > +}
> > +
> > static int vidioc_venc_qbuf(struct file *file, void *priv,
> > struct v4l2_buffer *buf)
> > {
> > @@ -688,6 +759,9 @@ const struct v4l2_ioctl_ops mtk_venc_ioct
Re: [PATCH 00/18] Complete moving media documentation to ReST format
Am 19.07.2016 um 16:53 schrieb Mauro Carvalho Chehab : > Em Tue, 19 Jul 2016 14:31:18 +0200 > Markus Heiser escreveu: > > >>> I really hate stupid toolchains that require everybody to upgrade to >>> the very latest version of it every time. >> >> Hi Mauro, >> >> It might be annoying how sphinx handles errors, but normally a build >> process should report errors to monitor. > > The documents are automatically built at linuxtv.org once a day. While > Sphinx doesn't build them without warnings, I won't enable any sort > of feedback from the server, as I don't want to be bothered all > days about the same warnings. > > Also, for safety reasons, we only install packages on the server > that are shipped with the distribution. OK, I understand .. but with this you have to run software with known bugs or other drawbacks .. If I'am sloppy I would say: this is your decision, other will find other decisions .. ;-) / sorry >>> Maybe someone at linux-doc >>> may have an idea about how to add new markup attributes to the >>> documents without breaking for the ones using older versions of Sphinx. >> >> see below >> >>> The problem we're facing is due to a change meant to add a title before >>> each media's table of contents (provided via :toctree: markup). >> >> I think this is only ONE drawback, others see the changelog .. > > I had to remove captions from tables on a past patch, because of the > same reason: Sphinx 1.2.x doesn't support it. > >> * http://www.sphinx-doc.org/en/stable/changes.html > > What we miss is the documentation for Sphinx 1.2 and 1.3 versions. The > site only has documentation for the very latest version, making harder > to ensure that we're using only the tags supported by a certain version. We could build the documentation of the (e.g.) 1.2 tag https://github.com/sphinx-doc/sphinx/tree/1.2 by checkout the tag, cd to "./doc" and run "make html". I haven't tested yet, but it should work this way. >>> All it needs is something that will be translated to HTML as: >>> Table of contents, without the need of creating any cross >>> reference, nor being added to the main TOC at Documentation/index.rst. >>> >>> We can't simply use the normal way to generate tags: >>> >>> --- a/Documentation/media/dvb-drivers/index.rst >>> +++ b/Documentation/media/dvb-drivers/index.rst >>> @@ -15,6 +15,10 @@ the license is included in the chapter entitled "GNU >>> Free Documentation >>> License". >>> >>> >>> +# >>> +FOO Table of contents >>> +# >>> + >>> .. toctree:: >>> :maxdepth: 5 >>> :numbered: >>> >>> The page itself would look OK, but this would produce a new entry at the >>> output/html/index.html: >>> >>> * Linux Digital TV driver-specific documentation >>> * FOO Table of contents >>> >>> 1. Introdution >>> >>> With is not what we want. >>> >>> With Sphinx 1.4.5, the way of doing that is to add a :caption: tag >>> to the toctree, but this tag doesn't exist on 1.2.x. Also, as it >>> also convert captions on references, and all books are linked >>> together at Documentation/index.rst, it also needs a :name: tag, >>> in order to avoid warnings about duplicated tags when building the >>> main index.rst. >>> >>> I have no idea about how to do that in a backward-compatible way. >>> >>> Maybe Markus, Jani or someone else at linux-doc may have some >>> glue. >> >> IMHO: A backward-compatible way for all linux distros and versions >> out there is not the way. >> >> If we use options or features of a new version, we have to >> install the new version (independent which xml we used in the past >> or python tool we want to use). > > With DocBook this is clear: the document itself is bound against > an specific version of the spec. So, *all* versions of the DocBook > toolchains support the very same document, or, when it doesn't, the > toolchain aborts with an error and doesn't produce anything. Very > easy for a script to identify if the build succeeds or not. OK, you are right ... for this, I suggested (below) to test the requirements (e.g. sphinx 1.2, RTD-theme) ... > Sphinx is very evil with that regards: it keeps generating the > files, except that the contents of the tags that contain unrecognized > fields will be empty (with is very bad for :toctree:) and a few > additional warnings will be generated. Very hard for a script to detect > if the doc was OK or got mangled by the toolchain, because of a version > incompatibility. On your build host, you could turn warnings into errors (Daniel posted the -W option) $ make SPHINXOPTS=-W htmldocs But this will only be helpfull when the build is free of warnings (and this will be more and more harder as more content is placed into). >> IMHO the main problem is, that we have not yet documented on which >> Sphinx version we agree and how to get a build environment which >> fullfills these requirements. > > Yes, the Sphinx minimal version should be documented at
[RFC 5/7] [media] ir-lirc-codec: do not handle any buffer for raw transmitters
Raw transmitters receive the data which need to be sent to
receivers from userspace as stream of bits, they don't require
any handling from the lirc framework.
Signed-off-by: Andi Shyti
---
drivers/media/rc/ir-lirc-codec.c | 30 +++---
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/drivers/media/rc/ir-lirc-codec.c b/drivers/media/rc/ir-lirc-codec.c
index 5effc65..80e94b6 100644
--- a/drivers/media/rc/ir-lirc-codec.c
+++ b/drivers/media/rc/ir-lirc-codec.c
@@ -121,17 +121,6 @@ static ssize_t ir_lirc_transmit_ir(struct file *file,
const char __user *buf,
if (!lirc)
return -EFAULT;
- if (n < sizeof(unsigned) || n % sizeof(unsigned))
- return -EINVAL;
-
- count = n / sizeof(unsigned);
- if (count > LIRCBUF_SIZE || count % 2 == 0)
- return -EINVAL;
-
- txbuf = memdup_user(buf, n);
- if (IS_ERR(txbuf))
- return PTR_ERR(txbuf);
-
dev = lirc->dev;
if (!dev) {
ret = -EFAULT;
@@ -143,6 +132,25 @@ static ssize_t ir_lirc_transmit_ir(struct file *file,
const char __user *buf,
goto out;
}
+ if (dev->driver_type == RC_DRIVER_IR_RAW_TX) {
+ txbuf = memdup_user(buf, n);
+ if (IS_ERR(txbuf))
+ return PTR_ERR(txbuf);
+
+ return dev->tx_ir(dev, txbuf, n);
+ }
+
+ if (n < sizeof(unsigned) || n % sizeof(unsigned))
+ return -EINVAL;
+
+ count = n / sizeof(unsigned);
+ if (count > LIRCBUF_SIZE || count % 2 == 0)
+ return -EINVAL;
+
+ txbuf = memdup_user(buf, n);
+ if (IS_ERR(txbuf))
+ return PTR_ERR(txbuf);
+
for (i = 0; i < count; i++) {
if (txbuf[i] > IR_MAX_DURATION / 1000 - duration || !txbuf[i]) {
ret = -EINVAL;
--
2.8.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
[RFC 1/7] [media] rc-main: assign driver type during allocation
The driver type can be assigned immediately when an RC device
requests to the framework to allocate the device.
This is an 'enum rc_driver_type' data type and specifies whether
the device is a raw receiver or scancode receiver. The type will
be given as parameter to the rc_allocate_device device.
Suggested-by: Sean Young
Signed-off-by: Andi Shyti
---
drivers/media/rc/rc-main.c | 4 +++-
include/media/rc-core.h| 2 +-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index 7dfc7c2..6403674 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -1346,7 +1346,7 @@ static struct device_type rc_dev_type = {
.uevent = rc_dev_uevent,
};
-struct rc_dev *rc_allocate_device(void)
+struct rc_dev *rc_allocate_device(enum rc_driver_type type)
{
struct rc_dev *dev;
@@ -1373,6 +1373,8 @@ struct rc_dev *rc_allocate_device(void)
dev->dev.class = &rc_class;
device_initialize(&dev->dev);
+ dev->driver_type = type;
+
__module_get(THIS_MODULE);
return dev;
}
diff --git a/include/media/rc-core.h b/include/media/rc-core.h
index b6586a9..c6bf1ef 100644
--- a/include/media/rc-core.h
+++ b/include/media/rc-core.h
@@ -185,7 +185,7 @@ struct rc_dev {
* Remote Controller, at sys/class/rc.
*/
-struct rc_dev *rc_allocate_device(void);
+struct rc_dev *rc_allocate_device(enum rc_driver_type);
void rc_free_device(struct rc_dev *dev);
int rc_register_device(struct rc_dev *dev);
void rc_unregister_device(struct rc_dev *dev);
--
2.8.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
[RFC 2/7] [media] rc-main: split setup and unregister functions
Move the input device allocation, map and protocol handling to
different functions.
Signed-off-by: Andi Shyti
---
drivers/media/rc/rc-main.c | 140 +
1 file changed, 77 insertions(+), 63 deletions(-)
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index 6403674..ac91157 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -1396,16 +1396,12 @@ void rc_free_device(struct rc_dev *dev)
}
EXPORT_SYMBOL_GPL(rc_free_device);
-int rc_register_device(struct rc_dev *dev)
+static int rc_setup_rx_device(struct rc_dev *dev)
{
- static bool raw_init = false; /* raw decoders loaded? */
- struct rc_map *rc_map;
- const char *path;
- int attr = 0;
- int minor;
int rc;
+ struct rc_map *rc_map;
- if (!dev || !dev->map_name)
+ if (!dev->map_name)
return -EINVAL;
rc_map = rc_map_get(dev->map_name);
@@ -1414,6 +1410,19 @@ int rc_register_device(struct rc_dev *dev)
if (!rc_map || !rc_map->scan || rc_map->size == 0)
return -EINVAL;
+ rc = ir_setkeytable(dev, rc_map);
+ if (rc)
+ return rc;
+
+ if (dev->change_protocol) {
+ u64 rc_type = (1ll << rc_map->rc_type);
+
+ rc = dev->change_protocol(dev, &rc_type);
+ if (rc < 0)
+ goto out_table;
+ dev->enabled_protocols = rc_type;
+ }
+
set_bit(EV_KEY, dev->input_dev->evbit);
set_bit(EV_REP, dev->input_dev->evbit);
set_bit(EV_MSC, dev->input_dev->evbit);
@@ -1423,6 +1432,61 @@ int rc_register_device(struct rc_dev *dev)
if (dev->close)
dev->input_dev->close = ir_close;
+ /*
+* Default delay of 250ms is too short for some protocols, especially
+* since the timeout is currently set to 250ms. Increase it to 500ms,
+* to avoid wrong repetition of the keycodes. Note that this must be
+* set after the call to input_register_device().
+*/
+ dev->input_dev->rep[REP_DELAY] = 500;
+
+ /*
+* As a repeat event on protocols like RC-5 and NEC take as long as
+* 110/114ms, using 33ms as a repeat period is not the right thing
+* to do.
+*/
+ dev->input_dev->rep[REP_PERIOD] = 125;
+
+ /* rc_open will be called here */
+ rc = input_register_device(dev->input_dev);
+ if (rc)
+ goto out_table;
+
+ dev->input_dev->dev.parent = &dev->dev;
+ memcpy(&dev->input_dev->id, &dev->input_id, sizeof(dev->input_id));
+ dev->input_dev->phys = dev->input_phys;
+ dev->input_dev->name = dev->input_name;
+
+ return 0;
+
+out_table:
+ ir_free_table(&dev->rc_map);
+
+ return rc;
+}
+
+static void rc_free_rx_device(struct rc_dev *dev)
+{
+ if (!dev || dev->driver_type == RC_DRIVER_IR_RAW_TX)
+ return;
+
+ ir_free_table(&dev->rc_map);
+
+ input_unregister_device(dev->input_dev);
+ dev->input_dev = NULL;
+}
+
+int rc_register_device(struct rc_dev *dev)
+{
+ static bool raw_init = false; /* raw decoders loaded? */
+ const char *path;
+ int attr = 0;
+ int minor;
+ int rc;
+
+ if (!dev)
+ return -EINVAL;
+
minor = ida_simple_get(&rc_ida, 0, RC_DEV_MAX, GFP_KERNEL);
if (minor < 0)
return minor;
@@ -1446,35 +1510,6 @@ int rc_register_device(struct rc_dev *dev)
if (rc)
goto out_unlock;
- rc = ir_setkeytable(dev, rc_map);
- if (rc)
- goto out_dev;
-
- dev->input_dev->dev.parent = &dev->dev;
- memcpy(&dev->input_dev->id, &dev->input_id, sizeof(dev->input_id));
- dev->input_dev->phys = dev->input_phys;
- dev->input_dev->name = dev->input_name;
-
- /*
-* Default delay of 250ms is too short for some protocols, especially
-* since the timeout is currently set to 250ms. Increase it to 500ms,
-* to avoid wrong repetition of the keycodes. Note that this must be
-* set after the call to input_register_device().
-*/
- dev->input_dev->rep[REP_DELAY] = 500;
-
- /*
-* As a repeat event on protocols like RC-5 and NEC take as long as
-* 110/114ms, using 33ms as a repeat period is not the right thing
-* to do.
-*/
- dev->input_dev->rep[REP_PERIOD] = 125;
-
- /* rc_open will be called here */
- rc = input_register_device(dev->input_dev);
- if (rc)
- goto out_table;
-
path = kobject_get_path(&dev->dev.kobj, GFP_KERNEL);
dev_info(&dev->dev, "%s as %s\n",
dev->input_name ?: "Unspecified device", path ?: "N/A");
@@ -1487,36 +1522,20 @@ int rc_register_device(struct rc_dev *dev)
}
rc = ir_raw_event_register(dev);
if (rc < 0)
-
[RFC 7/7] [media] rc: add support for IR LEDs driven through SPI
The ir-spi is a simple device driver which supports the
connection between an IR LED and the MOSI line of an SPI device.
The driver, indeed, uses the SPI framework to stream the raw data
provided by userspace through a character device. The chardev is
handled by the LIRC framework and its functionality basically
provides:
- raw write: data to be sent to the SPI and then streamed to the
MOSI line;
- set frequency: sets the frequency whith which the data should
be sent;
The character device is created under /dev/lircX name, where X is
and ID assigned by the LIRC framework.
Example of usage:
fd = open("/dev/lirc0", O_RDWR);
if (fd < 0)
return -1;
val = 608000;
ret = ioctl(fd, LIRC_SET_SEND_CARRIER, &val);
if (ret < 0)
return -1;
n = write(fd, buffer, BUF_LEN);
if (n < 0 || n != BUF_LEN)
ret = -1;
close(fd);
Signed-off-by: Andi Shyti
---
drivers/media/rc/Kconfig | 9
drivers/media/rc/Makefile | 1 +
drivers/media/rc/ir-spi.c | 133 ++
3 files changed, 143 insertions(+)
create mode 100644 drivers/media/rc/ir-spi.c
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index bd4d685..dacaa29 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -261,6 +261,15 @@ config IR_REDRAT3
To compile this driver as a module, choose M here: the
module will be called redrat3.
+config IR_SPI
+ tristate "SPI connected IR LED"
+ depends on SPI && LIRC
+ ---help---
+ Say Y if you want to use an IR LED connected through SPI bus.
+
+ To compile this driver as a module, choose M here: the module will be
+ called ir-spi.
+
config IR_STREAMZAP
tristate "Streamzap PC Remote IR Receiver"
depends on USB_ARCH_HAS_HCD
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index 379a5c0..1417c8d 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_IR_NUVOTON) += nuvoton-cir.o
obj-$(CONFIG_IR_ENE) += ene_ir.o
obj-$(CONFIG_IR_REDRAT3) += redrat3.o
obj-$(CONFIG_IR_RX51) += ir-rx51.o
+obj-$(CONFIG_IR_SPI) += ir-spi.o
obj-$(CONFIG_IR_STREAMZAP) += streamzap.o
obj-$(CONFIG_IR_WINBOND_CIR) += winbond-cir.o
obj-$(CONFIG_RC_LOOPBACK) += rc-loopback.o
diff --git a/drivers/media/rc/ir-spi.c b/drivers/media/rc/ir-spi.c
new file mode 100644
index 000..7b6f344
--- /dev/null
+++ b/drivers/media/rc/ir-spi.c
@@ -0,0 +1,133 @@
+/*
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ * Author: Andi Shyti
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * SPI driven IR LED device driver
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define IR_SPI_DRIVER_NAME "ir-spi"
+
+#define IR_SPI_DEFAULT_FREQUENCY 38000
+#define IR_SPI_BIT_PER_WORD8
+
+struct ir_spi_data {
+ struct rc_dev *rc;
+ struct spi_device *spi;
+ struct spi_transfer xfer;
+ struct mutex mutex;
+ struct regulator *regulator;
+};
+
+static int ir_spi_tx(struct rc_dev *dev, unsigned *buffer, unsigned n)
+{
+ int ret;
+ struct ir_spi_data *idata = (struct ir_spi_data *) dev->priv;
+
+ ret = regulator_enable(idata->regulator);
+ if (ret)
+ return ret;
+
+ mutex_lock(&idata->mutex);
+ idata->xfer.len = n;
+ idata->xfer.tx_buf = buffer;
+ mutex_unlock(&idata->mutex);
+
+ ret = spi_sync_transfer(idata->spi, &idata->xfer, 1);
+ if (ret)
+ dev_err(&idata->spi->dev, "unable to deliver the signal\n");
+
+ regulator_disable(idata->regulator);
+
+ return ret;
+}
+
+static int ir_spi_set_tx_carrier(struct rc_dev *dev, u32 carrier)
+{
+ struct ir_spi_data *idata = (struct ir_spi_data *) dev->priv;
+
+ if (!carrier)
+ return -EINVAL;
+
+ mutex_lock(&idata->mutex);
+ idata->xfer.speed_hz = carrier;
+ mutex_unlock(&idata->mutex);
+
+ return 0;
+}
+
+static int ir_spi_probe(struct spi_device *spi)
+{
+ int ret;
+ struct ir_spi_data *idata;
+
+ idata = devm_kzalloc(&spi->dev, sizeof(*idata), GFP_KERNEL);
+ if (!idata)
+ return -ENOMEM;
+
+ idata->regulator = devm_regulator_get(&spi->dev, "irda_regulator");
+ if (IS_ERR(idata->regulator))
+ return PTR_ERR(idata->regulator);
+
+ idata->rc = rc_allocate_device(RC_DRIVER_IR_RAW_TX);
+ if (!idata->rc)
+ return -ENOMEM;
+
+ idata->rc->s_tx_carrier = ir_spi_set_tx_carrier;
+ idata->rc->tx_ir = ir_spi_tx;
+ idata->rc->driver_name = IR_SPI_DRIVER_NAME;
+ idata->rc->priv = idata;
+
+ret = rc_r
[RFC 6/7] Documentation: bindings: add documentation for ir-spi device driver
Document the ir-spi driver's binding which is a IR led driven
through the SPI line.
Signed-off-by: Andi Shyti
---
Documentation/devicetree/bindings/media/spi-ir.txt | 20
1 file changed, 20 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/spi-ir.txt
diff --git a/Documentation/devicetree/bindings/media/spi-ir.txt
b/Documentation/devicetree/bindings/media/spi-ir.txt
new file mode 100644
index 000..532da68
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/spi-ir.txt
@@ -0,0 +1,20 @@
+Device tree bindings for IR LED connected through SPI bus which is used as
+remote controller.
+
+The IR LED switch is connected to the MOSI line of the SPI device and the data
+are delivered thourgh that.
+
+Required properties:
+ - compatible: should be "ir-spi"
+
+Optional properties:
+ - irled,switch: specifies the gpio switch which enables the irled
+
+Example:
+
+irled@0 {
+compatible = "ir-spi";
+reg = <0x0>;
+spi-max-frequency = <500>;
+irled,switch = <&gpr3 3 0>;
+};
--
2.8.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
[RFC 3/7] [media] rc-core: add support for IR raw transmitters
IR raw transmitter driver type is specified in the enum
rc_driver_type as RC_DRIVER_IR_RAW_TX which includes all those
devices that transmit raw stream of bit to a receiver.
The data are provided by userspace applications, therefore they
don't need any input device allocation, but still they need to be
registered as raw devices.
Suggested-by: Sean Young
Signed-off-by: Andi Shyti
---
drivers/media/rc/rc-main.c | 35 +++
include/media/rc-core.h| 1 +
2 files changed, 24 insertions(+), 12 deletions(-)
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index ac91157..f555f38 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -1354,20 +1354,24 @@ struct rc_dev *rc_allocate_device(enum rc_driver_type
type)
if (!dev)
return NULL;
- dev->input_dev = input_allocate_device();
- if (!dev->input_dev) {
- kfree(dev);
- return NULL;
- }
+ if (type != RC_DRIVER_IR_RAW_TX) {
+ dev->input_dev = input_allocate_device();
+ if (!dev->input_dev) {
+ kfree(dev);
+ return NULL;
+ }
- dev->input_dev->getkeycode = ir_getkeycode;
- dev->input_dev->setkeycode = ir_setkeycode;
- input_set_drvdata(dev->input_dev, dev);
+ dev->input_dev->getkeycode = ir_getkeycode;
+ dev->input_dev->setkeycode = ir_setkeycode;
+ input_set_drvdata(dev->input_dev, dev);
- spin_lock_init(&dev->rc_map.lock);
- spin_lock_init(&dev->keylock);
+ setup_timer(&dev->timer_keyup, ir_timer_keyup,
+ (unsigned long)dev);
+
+ spin_lock_init(&dev->rc_map.lock);
+ spin_lock_init(&dev->keylock);
+ }
mutex_init(&dev->lock);
- setup_timer(&dev->timer_keyup, ir_timer_keyup, (unsigned long)dev);
dev->dev.type = &rc_dev_type;
dev->dev.class = &rc_class;
@@ -1515,7 +1519,14 @@ int rc_register_device(struct rc_dev *dev)
dev->input_name ?: "Unspecified device", path ?: "N/A");
kfree(path);
- if (dev->driver_type == RC_DRIVER_IR_RAW) {
+ if (dev->driver_type != RC_DRIVER_IR_RAW_TX) {
+ rc = rc_setup_rx_device(dev);
+ if (rc)
+ goto out_dev;
+ }
+
+ if (dev->driver_type == RC_DRIVER_IR_RAW ||
+ dev->driver_type == RC_DRIVER_IR_RAW_TX) {
if (!raw_init) {
request_module_nowait("ir-lirc-codec");
raw_init = true;
diff --git a/include/media/rc-core.h b/include/media/rc-core.h
index c6bf1ef..77b0893 100644
--- a/include/media/rc-core.h
+++ b/include/media/rc-core.h
@@ -32,6 +32,7 @@ do {
\
enum rc_driver_type {
RC_DRIVER_SCANCODE = 0, /* Driver or hardware generates a scancode */
RC_DRIVER_IR_RAW, /* Needs a Infra-Red pulse/space decoder */
+ RC_DRIVER_IR_RAW_TX,/* Device is transmitter, driver handles raw */
};
/**
--
2.8.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
[RFC 4/7] [media] rc-ir-raw: do not generate any receiving thread for raw transmitters
Raw IR transmitters do not need any thread listening for
occurring events. Check the driver type before running the
thread.
Signed-off-by: Andi Shyti
---
drivers/media/rc/rc-ir-raw.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/media/rc/rc-ir-raw.c b/drivers/media/rc/rc-ir-raw.c
index 144304c..64ddc3d 100644
--- a/drivers/media/rc/rc-ir-raw.c
+++ b/drivers/media/rc/rc-ir-raw.c
@@ -274,12 +274,19 @@ int ir_raw_event_register(struct rc_dev *dev)
INIT_KFIFO(dev->raw->kfifo);
spin_lock_init(&dev->raw->lock);
- dev->raw->thread = kthread_run(ir_raw_event_thread, dev->raw,
- "rc%u", dev->minor);
- if (IS_ERR(dev->raw->thread)) {
- rc = PTR_ERR(dev->raw->thread);
- goto out;
+ /*
+* raw transmitters do not need any event registration
+* because the event is coming from userspace
+*/
+ if (dev->driver_type != RC_DRIVER_IR_RAW_TX) {
+ dev->raw->thread = kthread_run(ir_raw_event_thread, dev->raw,
+ "rc%u", dev->minor);
+
+ if (IS_ERR(dev->raw->thread)) {
+ rc = PTR_ERR(dev->raw->thread);
+ goto out;
+ }
}
mutex_lock(&ir_raw_handler_lock);
--
2.8.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
[RFC 0/7] Add support for IR transmitters
Hi, this is an RFCset that follows this patch: http://marc.info/?l=linux-kernel&m=146736225606125&w=2 and after Sean's review and recommendations: http://marc.info/?l=linux-kernel&m=146737935611128&w=2 The main goal is to add support in the rc framework for IR transmitters, which currently is only supported by lirc but that is not the preferred way. with this RFCset I'm trying to gather some opinions as I'm not really aware of other use cases other than the simple ir transmitter in the last patch. As it is, the code to me looks quite forced in order to achieve "my" goal by abusing on the driver type check. The last rfc-patch adds support for an IR transmitter driven by the MOSI line of an SPI controller, it's the case of the Samsung TM2(e) board which support is going to come soon. Please let me know if there is anything to improve. Thanks, Andi Andi Shyti (7): [media] rc-main: assign driver type during allocation [media] rc-main: split setup and unregister functions [media] rc-core: add support for IR raw transmitters [media] rc-ir-raw: do not generate any receiving thread for raw transmitters [media] ir-lirc-codec: do not handle any buffer for raw transmitters Documentation: bindings: add documentation for ir-spi device driver [media] rc: add support for IR LEDs driven through SPI Documentation/devicetree/bindings/media/spi-ir.txt | 20 +++ drivers/media/rc/Kconfig | 9 ++ drivers/media/rc/Makefile | 1 + drivers/media/rc/ir-lirc-codec.c | 30 ++-- drivers/media/rc/ir-spi.c | 133 +++ drivers/media/rc/rc-ir-raw.c | 17 +- drivers/media/rc/rc-main.c | 179 - include/media/rc-core.h| 3 +- 8 files changed, 299 insertions(+), 93 deletions(-) create mode 100644 Documentation/devicetree/bindings/media/spi-ir.txt create mode 100644 drivers/media/rc/ir-spi.c -- 2.8.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: [PATCH v2 2/3] [media] hva: multi-format video encoder V4L2 driver
Hi Hans,
Thank you for your comments.
I've started to take them into account.
I've got a question about V4L2_FIELD_ANY in buf_prepare (please see below).
[snip]
>> +static int hva_buf_prepare(struct vb2_buffer *vb)
>> +{
>> + struct hva_ctx *ctx = vb2_get_drv_priv(vb->vb2_queue);
>> + struct device *dev = ctx_to_dev(ctx);
>> + struct vb2_v4l2_buffer *vbuf = to_vb2_v4l2_buffer(vb);
>> +
>> + if (vb->vb2_queue->type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
>> + struct hva_frame *frame = to_hva_frame(vbuf);
>> +
>> + if (vbuf->field == V4L2_FIELD_ANY)
>> + vbuf->field = V4L2_FIELD_NONE;
>
> Anything other than FIELD_NONE should result in an error since no interlaced
is supported.
> FIELD_ANY is an incorrect value as well.
>
In videodev2.h, V4L2_FIELD_ANY is commented as "driver can choose from none,
top, bottom, interlaced depending on whatever it thinks is approximate ...": I
understand this comment as if vbuf->field is equal to V4L2_FIELD_ANY, then the
driver can choose to force it to V4L2_FIELD_NONE. Furthermore, it's coded in
the
same way in vim2m.c (vim2m_buf_prepare).
Finally, if I remove these 2 lines, I've got the following error with the
v4l2-compliance:
Streaming ioctls:
VIDIOC_G_INPUT returned -1 (Inappropriate ioctl for device)
VIDIOC_ENUMINPUT returned -1 (Inappropriate ioctl for device)
test read/write: OK (Not Supported)
VIDIOC_QUERYCAP returned 0 (Success)
[snip]
VIDIOC_QUERYBUF returned 0 (Success)
VIDIOC_QBUF returned -1 (Invalid argument)
fail:
/local/home/frq08988/views/opensdk-2.1.4.1/sources/v4l-utils/utils/v4l2-compliance/v4l2-test-buffers.cpp(773):
buf.qbuf(node)
fail:
/local/home/frq08988/views/opensdk-2.1.4.1/sources/v4l-utils/utils/v4l2-compliance/v4l2-test-buffers.cpp(971):
setupM2M(node, m2m_q)
test MMAP: FAIL
Don't you think that I could keep these two lines?
>> + if (vbuf->field != V4L2_FIELD_NONE) {
>> + dev_dbg(dev,
>> + "%s frame[%d] prepare: %d field not
>> supported\n",
>> + ctx->name, vb->index, vbuf->field);
>> + return -EINVAL;
>> + }
>> +
>> + if (!frame->prepared) {
>> + /* get memory addresses */
>> + frame->vaddr = vb2_plane_vaddr(&vbuf->vb2_buf, 0);
>> + frame->paddr = vb2_dma_contig_plane_dma_addr(
>> + &vbuf->vb2_buf, 0);
>> + frame->info = ctx->frameinfo;
>> + frame->prepared = true;
>> +
>> + dev_dbg(dev,
>> + "%s frame[%d] prepared; virt=%p, phy=%pad\n",
>> + ctx->name, vb->index,
>> + frame->vaddr, &frame->paddr);
>> + }
>> + } else {
>> + struct hva_stream *stream = to_hva_stream(vbuf);
>> +
>> + if (!stream->prepared) {
>> + /* get memory addresses */
>> + stream->vaddr = vb2_plane_vaddr(&vbuf->vb2_buf, 0);
>> + stream->paddr = vb2_dma_contig_plane_dma_addr(
>> + &vbuf->vb2_buf, 0);
>> + stream->size = vb2_plane_size(&vbuf->vb2_buf, 0);
>> + stream->prepared = true;
>> +
>> + dev_dbg(dev,
>> + "%s stream[%d] prepared; virt=%p, phy=%pad\n",
>> + ctx->name, vb->index,
>> + stream->vaddr, &stream->paddr);
>> + }
>> + }
>> +
>> + return 0;
>> +}
>> +
[snip]
Regards,
Jean-Christophe.
--
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 00/18] Complete moving media documentation to ReST format
Em Tue, 19 Jul 2016 11:53:19 -0300
Mauro Carvalho Chehab escreveu:
> Yet, this doesn't solve the specific issue for the TOC index
> name. How this could be done in a way that would be backward
> compatible to 1.2.x?
Answering myself, the following patch should trick Sphinx to
allow the media books to be built against older versions of
the toolchain.
Regards,
Mauro
[PATCH] [media] doc-rst: backward compatibility with older Sphinx
versions
Sphinx is really evil when an older version finds an extra
attribute for the :toctree: tag: it simply ignores everything
and produce documents without any chapter inside!
As we're now using tags available only on Sphinx 1.4.x, we
need to use some creative ways to add a title before the
table of contents. Do that by using a css class.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/Documentation/media/dvb-drivers/index.rst
b/Documentation/media/dvb-drivers/index.rst
index e1d4d87f2a47..e4c2e74db9dc 100644
--- a/Documentation/media/dvb-drivers/index.rst
+++ b/Documentation/media/dvb-drivers/index.rst
@@ -14,12 +14,13 @@ any later version published by the Free Software
Foundation. A copy of
the license is included in the chapter entitled "GNU Free Documentation
License".
+.. class:: toc-title
+
+ Table of Contents
.. toctree::
:maxdepth: 5
:numbered:
- :caption: Table of Contents
- :name: dvb_mastertoc
intro
avermedia
diff --git a/Documentation/media/media_kapi.rst
b/Documentation/media/media_kapi.rst
index 0af80e90b7b5..5414d2a7dfb8 100644
--- a/Documentation/media/media_kapi.rst
+++ b/Documentation/media/media_kapi.rst
@@ -14,11 +14,13 @@ any later version published by the Free Software
Foundation. A copy of
the license is included in the chapter entitled "GNU Free Documentation
License".
+.. class:: toc-title
+
+Table of Contents
+
.. toctree::
:maxdepth: 5
:numbered:
-:caption: Table of Contents
-:name: kapi_mastertoc
kapi/v4l2-framework
kapi/v4l2-controls
diff --git a/Documentation/media/media_uapi.rst
b/Documentation/media/media_uapi.rst
index debe4531040b..aaa9a0e387c4 100644
--- a/Documentation/media/media_uapi.rst
+++ b/Documentation/media/media_uapi.rst
@@ -14,11 +14,12 @@ any later version published by the Free Software
Foundation. A copy of
the license is included in the chapter entitled "GNU Free Documentation
License".
+.. class:: toc-title
+
+Table of Contents
.. toctree::
:maxdepth: 5
-:caption: Table of Contents
-:name: uapi_mastertoc
intro
uapi/v4l/v4l2
diff --git a/Documentation/media/v4l-drivers/index.rst
b/Documentation/media/v4l-drivers/index.rst
index 8d1710234e5a..2aab653905ce 100644
--- a/Documentation/media/v4l-drivers/index.rst
+++ b/Documentation/media/v4l-drivers/index.rst
@@ -14,12 +14,13 @@ any later version published by the Free Software
Foundation. A copy of
the license is included in the chapter entitled "GNU Free Documentation
License".
+.. class:: toc-title
+
+Table of Contents
.. toctree::
:maxdepth: 5
:numbered:
- :caption: Table of Contents
- :name: v4l_mastertoc
fourcc
v4l-with-ir
diff --git a/Documentation/sphinx-static/theme_overrides.css
b/Documentation/sphinx-static/theme_overrides.css
index c97d8428302d..3a2ac4bcfd78 100644
--- a/Documentation/sphinx-static/theme_overrides.css
+++ b/Documentation/sphinx-static/theme_overrides.css
@@ -31,6 +31,11 @@
* - hide the permalink symbol as long as link is not hovered
*/
+.toc-title {
+font-size: 150%;
+ font-weight: bold;
+}
+
caption, .wy-table caption, .rst-content table.field-list caption {
font-size: 100%;
}
--
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] cxd2841er: BER and SNR reading for ISDB-T
Added function to read BER for ISDB-T
Also SNR values fixed for ISDB-T
Signed-off-by: Abylay Ospan
---
drivers/media/dvb-frontends/cxd2841er.c | 48 ++---
1 file changed, 45 insertions(+), 3 deletions(-)
diff --git a/drivers/media/dvb-frontends/cxd2841er.c
b/drivers/media/dvb-frontends/cxd2841er.c
index d2e28ea..3df0604 100644
--- a/drivers/media/dvb-frontends/cxd2841er.c
+++ b/drivers/media/dvb-frontends/cxd2841er.c
@@ -206,6 +206,9 @@ static const struct cxd2841er_cnr_data s2_cn_data[] = {
(u32)(((iffreq)/48.0)*16777216.0 + 0.5) : \
(u32)(((iffreq)/41.0)*16777216.0 + 0.5))
+static int cxd2841er_freeze_regs(struct cxd2841er_priv *priv);
+static int cxd2841er_unfreeze_regs(struct cxd2841er_priv *priv);
+
static void cxd2841er_i2c_debug(struct cxd2841er_priv *priv,
u8 addr, u8 reg, u8 write,
const u8 *data, u32 len)
@@ -1401,6 +1404,41 @@ static int cxd2841er_read_ber_c(struct cxd2841er_priv
*priv,
return 0;
}
+static int cxd2841er_read_ber_i(struct cxd2841er_priv *priv,
+ u32 *bit_error, u32 *bit_count)
+{
+ u8 data[3];
+ u8 pktnum[2];
+
+ dev_dbg(&priv->i2c->dev, "%s()\n", __func__);
+ if (priv->state != STATE_ACTIVE_TC) {
+ dev_dbg(&priv->i2c->dev, "%s(): invalid state %d\n",
+ __func__, priv->state);
+ return -EINVAL;
+ }
+
+ cxd2841er_freeze_regs(priv);
+ cxd2841er_write_reg(priv, I2C_SLVT, 0x00, 0x60);
+ cxd2841er_read_regs(priv, I2C_SLVT, 0x5B, pktnum, sizeof(pktnum));
+ cxd2841er_read_regs(priv, I2C_SLVT, 0x16, data, sizeof(data));
+
+ if (!pktnum[0] && !pktnum[1]) {
+ dev_dbg(&priv->i2c->dev,
+ "%s(): no valid BER data\n", __func__);
+ cxd2841er_unfreeze_regs(priv);
+ return -EINVAL;
+ }
+
+ *bit_error = ((u32)(data[0] & 0x7F) << 16) |
+ ((u32)data[1] << 8) | data[2];
+ *bit_count = u32)pktnum[0] << 8) | pktnum[1]) * 204 * 8);
+ dev_dbg(&priv->i2c->dev, "%s(): bit_error=%u bit_count=%u\n",
+ __func__, *bit_error, *bit_count);
+
+ cxd2841er_unfreeze_regs(priv);
+ return 0;
+}
+
static int cxd2841er_mon_read_ber_s(struct cxd2841er_priv *priv,
u32 *bit_error, u32 *bit_count)
{
@@ -1798,9 +1836,7 @@ static int cxd2841er_read_snr_i(struct cxd2841er_priv
*priv, u32 *snr)
cxd2841er_unfreeze_regs(priv);
return 0;
}
- if (reg > 4996)
- reg = 4996;
- *snr = 100 * intlog10(reg) - 9031;
+ *snr = 1 * (intlog10(reg) >> 24) - 9031;
cxd2841er_unfreeze_regs(priv);
return 0;
}
@@ -1879,6 +1915,9 @@ static void cxd2841er_read_ber(struct dvb_frontend *fe)
case SYS_DVBC_ANNEX_C:
ret = cxd2841er_read_ber_c(priv, &bit_error, &bit_count);
break;
+ case SYS_ISDBT:
+ ret = cxd2841er_read_ber_i(priv, &bit_error, &bit_count);
+ break;
case SYS_DVBS:
ret = cxd2841er_mon_read_ber_s(priv, &bit_error, &bit_count);
break;
@@ -1992,6 +2031,9 @@ static void cxd2841er_read_snr(struct dvb_frontend *fe)
return;
}
+ dev_dbg(&priv->i2c->dev, "%s(): snr=%d\n",
+ __func__, (int32_t)tmp);
+
if (!ret) {
p->cnr.stat[0].scale = FE_SCALE_DECIBEL;
p->cnr.stat[0].svalue = tmp;
--
2.7.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] [media] dvb-usb: avoid link error with dib3000m{b,c|
Tha ARM randconfig builds came up with another rare build failure
for the dib3000mc driver, when dvb-usb-dibusb-mb is built-in and
dib3000mc is a loadable module:
ERROR: "dibusb_dib3000mc_frontend_attach"
[drivers/media/usb/dvb-usb/dvb-usb-nova-t-usb2.ko] undefined!
ERROR: "dibusb_dib3000mc_tuner_attach"
[drivers/media/usb/dvb-usb/dvb-usb-nova-t-usb2.ko] undefined!
Apparently this used to be a valid configuration (build-time, not
run-time), but broke as part of a cleanup.
I tried reverting the cleanup, but saw that the code was still wrong
then. This version adds a dependency for dib3000mb, to ensure that
dib3000mb does not force the dibusb_dib3000mc_frontend_attach function
to be built-in when dib3000mc is a loadable module.
I have also checked the two other files that were changed in the original
cleanup, and found them to be correct in either version, so I do not
touch that part.
As this is a rather obscure bug, there is no need for backports.
Signed-off-by: Arnd Bergmann
Fixes: 028c70ff42783 ("[media] dvb-usb/dvb-usb-v2: use IS_ENABLED")
---
This is one of two different ways to avoid the link error, please
pick one of them. Adding a dependency is simpler but slighly
more limiting.
---
drivers/media/usb/dvb-usb/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/usb/dvb-usb/Kconfig
b/drivers/media/usb/dvb-usb/Kconfig
index 8c99faa6..959fa09dfd92 100644
--- a/drivers/media/usb/dvb-usb/Kconfig
+++ b/drivers/media/usb/dvb-usb/Kconfig
@@ -44,6 +44,7 @@ config DVB_USB_DIBUSB_MB
depends on DVB_USB
select DVB_PLL if MEDIA_SUBDRV_AUTOSELECT
select DVB_DIB3000MB
+ depends on DVB_DIB3000MC || !DVB_DIB3000MC
select MEDIA_TUNER_MT2060 if MEDIA_SUBDRV_AUTOSELECT
help
Support for USB 1.1 and 2.0 DVB-T receivers based on reference
designs made by
--
2.9.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
[PATCH variant 1/2] [media] dvb-usb: split out common parts of dibusb
Tha ARM randconfig builds came up with another rare build failure
for the dib3000mc driver, when dvb-usb-dibusb-mb is built-in and
dib3000mc is a loadable module:
ERROR: "dibusb_dib3000mc_frontend_attach"
[drivers/media/usb/dvb-usb/dvb-usb-nova-t-usb2.ko] undefined!
ERROR: "dibusb_dib3000mc_tuner_attach"
[drivers/media/usb/dvb-usb/dvb-usb-nova-t-usb2.ko] undefined!
Apparently this used to be a valid configuration (build-time, not
run-time), but broke as part of a cleanup.
I tried reverting the cleanup, but saw that the code was still wrong
then. This tries to fix the code properly, by moving the problematic
functions into a new file that now is built as a loadable module or
built-in, whichever is correct for a particular configuration. It fixes
the regression as well as the runtime problem that already existed.
The new module dependency chain is now:
dvb-usb-{dibusb_mc,a800,dib0700,umt-010,gp8psk} dvb-usb-dibusb-mb
|| | |
dvb-usb-dibusb-mc-common |___| |
| ||| |
dib3000mc (frontend) ||| dib3000mb (frontend)
|||
|||
dvb-usb-dibusb-common
I have also checked the two other files that were changed in the original
cleanup, and found them to be correct in either version, so I do not
touch that part.
As this is a rather obscure bug, there is no need for backports.
Signed-off-by: Arnd Bergmann
Fixes: 028c70ff42783 ("[media] dvb-usb/dvb-usb-v2: use IS_ENABLED")
---
I think I sent this before, but couldn't find a reference to it any more.
It is certainly still needed. I'm now sending an alternative simpler
patch as well, please pick one of the two
drivers/media/usb/dvb-usb/Kconfig| 20 +++-
drivers/media/usb/dvb-usb/Makefile | 11 +-
drivers/media/usb/dvb-usb/dibusb-common.c| 158 -
drivers/media/usb/dvb-usb/dibusb-mc-common.c | 168 +++
4 files changed, 190 insertions(+), 167 deletions(-)
create mode 100644 drivers/media/usb/dvb-usb/dibusb-mc-common.c
diff --git a/drivers/media/usb/dvb-usb/Kconfig
b/drivers/media/usb/dvb-usb/Kconfig
index f03b0b70c901..8c99faa6 100644
--- a/drivers/media/usb/dvb-usb/Kconfig
+++ b/drivers/media/usb/dvb-usb/Kconfig
@@ -20,10 +20,20 @@ config DVB_USB_DEBUG
Say Y if you want to enable debugging. See modinfo dvb-usb (and the
appropriate drivers) for debug levels.
+config DVB_USB_DIB3000MC
+ tristate
+ depends on DVB_USB
+ select DVB_DIB3000MC
+ help
+ This is a module with helper functions for accessing the
+ DIB3000MC from USB DVB devices. It must be a separate module
+ in case DVB_USB is built-in and DVB_DIB3000MC is a module,
+ and gets selected automatically when needed.
+
config DVB_USB_A800
tristate "AVerMedia AverTV DVB-T USB 2.0 (A800)"
depends on DVB_USB
- select DVB_DIB3000MC
+ select DVB_USB_DIB3000MC
select DVB_PLL if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_MT2060 if MEDIA_SUBDRV_AUTOSELECT
help
@@ -54,7 +64,7 @@ config DVB_USB_DIBUSB_MB_FAULTY
config DVB_USB_DIBUSB_MC
tristate "DiBcom USB DVB-T devices (based on the DiB3000M-C/P) (see
help for device list)"
depends on DVB_USB
- select DVB_DIB3000MC
+ select DVB_USB_DIB3000MC
select MEDIA_TUNER_MT2060 if MEDIA_SUBDRV_AUTOSELECT
help
Support for USB2.0 DVB-T receivers based on reference designs made by
@@ -72,7 +82,7 @@ config DVB_USB_DIB0700
select DVB_DIB7000P if MEDIA_SUBDRV_AUTOSELECT
select DVB_DIB7000M if MEDIA_SUBDRV_AUTOSELECT
select DVB_DIB8000 if MEDIA_SUBDRV_AUTOSELECT
- select DVB_DIB3000MC if MEDIA_SUBDRV_AUTOSELECT
+ select DVB_USB_DIB3000MC if MEDIA_SUBDRV_AUTOSELECT
select DVB_S5H1411 if MEDIA_SUBDRV_AUTOSELECT
select DVB_LGDT3305 if MEDIA_SUBDRV_AUTOSELECT
select DVB_TUNER_DIB0070 if MEDIA_SUBDRV_AUTOSELECT
@@ -99,7 +109,7 @@ config DVB_USB_UMT_010
tristate "HanfTek UMT-010 DVB-T USB2.0 support"
depends on DVB_USB
select DVB_PLL if MEDIA_SUBDRV_AUTOSELECT
- select DVB_DIB3000MC
+ select DVB_USB_DIB3000MC
select MEDIA_TUNER_MT2060 if MEDIA_SUBDRV_AUTOSELECT
select DVB_MT352 if MEDIA_SUBDRV_AUTOSELECT
help
@@ -192,7 +202,7 @@ config DVB_USB_GP8PSK
config DVB_USB_NOVA_T_USB2
tristate "Hauppauge WinTV-NOVA-T usb2 DVB-T USB2.0 support"
depends on DVB_USB
- select DVB_DIB3000MC
+ select DVB_USB_DIB3000MC
select DVB_PLL if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_MT2060 if MEDIA_SUBDRV_AUTOSELECT
help
diff --git a/drivers/media/usb/dvb-usb/Makefile
b/drivers/media/usb/dvb-usb/
Re: [PATCH 00/18] Complete moving media documentation to ReST format
Em Tue, 19 Jul 2016 14:31:18 +0200 Markus Heiser escreveu: > > I really hate stupid toolchains that require everybody to upgrade to > > the very latest version of it every time. > > Hi Mauro, > > It might be annoying how sphinx handles errors, but normally a build > process should report errors to monitor. The documents are automatically built at linuxtv.org once a day. While Sphinx doesn't build them without warnings, I won't enable any sort of feedback from the server, as I don't want to be bothered all days about the same warnings. Also, for safety reasons, we only install packages on the server that are shipped with the distribution. > > Maybe someone at linux-doc > > may have an idea about how to add new markup attributes to the > > documents without breaking for the ones using older versions of Sphinx. > > see below > > > The problem we're facing is due to a change meant to add a title before > > each media's table of contents (provided via :toctree: markup). > > I think this is only ONE drawback, others see the changelog .. I had to remove captions from tables on a past patch, because of the same reason: Sphinx 1.2.x doesn't support it. > * http://www.sphinx-doc.org/en/stable/changes.html What we miss is the documentation for Sphinx 1.2 and 1.3 versions. The site only has documentation for the very latest version, making harder to ensure that we're using only the tags supported by a certain version. > > All it needs is something that will be translated to HTML as: > > Table of contents, without the need of creating any cross > > reference, nor being added to the main TOC at Documentation/index.rst. > > > > We can't simply use the normal way to generate tags: > > > > --- a/Documentation/media/dvb-drivers/index.rst > > +++ b/Documentation/media/dvb-drivers/index.rst > > @@ -15,6 +15,10 @@ the license is included in the chapter entitled "GNU > > Free Documentation > > License". > > > > > > +# > > +FOO Table of contents > > +# > > + > > .. toctree:: > > :maxdepth: 5 > > :numbered: > > > > The page itself would look OK, but this would produce a new entry at the > > output/html/index.html: > > > > * Linux Digital TV driver-specific documentation > > * FOO Table of contents > > > > 1. Introdution > > > > With is not what we want. > > > > With Sphinx 1.4.5, the way of doing that is to add a :caption: tag > > to the toctree, but this tag doesn't exist on 1.2.x. Also, as it > > also convert captions on references, and all books are linked > > together at Documentation/index.rst, it also needs a :name: tag, > > in order to avoid warnings about duplicated tags when building the > > main index.rst. > > > > I have no idea about how to do that in a backward-compatible way. > > > > Maybe Markus, Jani or someone else at linux-doc may have some > > glue. > > IMHO: A backward-compatible way for all linux distros and versions > out there is not the way. > > If we use options or features of a new version, we have to > install the new version (independent which xml we used in the past > or python tool we want to use). With DocBook this is clear: the document itself is bound against an specific version of the spec. So, *all* versions of the DocBook toolchains support the very same document, or, when it doesn't, the toolchain aborts with an error and doesn't produce anything. Very easy for a script to identify if the build succeeds or not. Sphinx is very evil with that regards: it keeps generating the files, except that the contents of the tags that contain unrecognized fields will be empty (with is very bad for :toctree:) and a few additional warnings will be generated. Very hard for a script to detect if the doc was OK or got mangled by the toolchain, because of a version incompatibility. > IMHO the main problem is, that we have not yet documented on which > Sphinx version we agree and how to get a build environment which > fullfills these requirements. Yes, the Sphinx minimal version should be documented at Documentation/Changes. I'd say that the minimal version should be the Sphinx version found on the latest version of the main distributions, e .g. at least Fedora, openSuse, Debian, Ubuntu. (I guess distros like ArchLinux and Gentoo won't be a problem, as they tend to use the newer versions of the sources). On a quick check: - Fedora 24 comes with 1.3.x - openSuse 13.2 with 1.2.x - Debian 8.5 with 1.2.x. - Ubuntu 16.04 with 1.3.x - Ubuntu 14.04 with 1.2.x - Mageia 5 with 1.2.x So, I guess we should set the minimal requirement to 1.2.x. Btw, usually, on Kernel, we're very conservative to increment the minimal version of a toolchain. So, for example, while GCC current version is 6.1, the minimal requirement is gcc 3.2 (with was released in 2003). > For build environments I recommend to set up a python virtualenv > > * https://virtualenv.pypa.io/en/stable/ We can't assume that every Kernel developer woul
[PATCHv2 09/16] [media] rcar-vin: rework how subdeivce is found and bound
The original drivers code to find a subdevice by looking in the DT graph
and how the callbacks to the v4l2 async bind framework where poorly
written. The most obvious example of badness was the duplication of data
in the struct rvin_graph_entity.
This patch removes the data duplication, simplifies the parsing of the
DT graph and add checks to the v4l2 callbacks.
Signed-off-by: Niklas Söderlund
---
drivers/media/platform/rcar-vin/rcar-core.c | 232 +---
drivers/media/platform/rcar-vin/rcar-vin.h | 8 +-
2 files changed, 111 insertions(+), 129 deletions(-)
diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
b/drivers/media/platform/rcar-vin/rcar-core.c
index 6744325..6934940 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -31,16 +31,14 @@
#define notifier_to_vin(n) container_of(n, struct rvin_dev, notifier)
-static int rvin_mbus_supported(struct rvin_dev *vin)
+static bool rvin_mbus_supported(struct rvin_dev *vin)
{
- struct v4l2_subdev *sd;
+ struct v4l2_subdev *sd = vin->digital.subdev;
struct v4l2_subdev_mbus_code_enum code = {
.which = V4L2_SUBDEV_FORMAT_ACTIVE,
};
bool found;
- sd = vin_to_source(vin);
-
code.index = 0;
while (!v4l2_subdev_call(sd, pad, enum_mbus_code, NULL, &code)) {
code.index++;
@@ -50,8 +48,6 @@ static int rvin_mbus_supported(struct rvin_dev *vin)
case MEDIA_BUS_FMT_UYVY10_2X10:
case MEDIA_BUS_FMT_RGB888_1X24:
vin->source.code = code.code;
- vin_dbg(vin, "Found supported media bus format: %d\n",
- vin->source.code);
return true;
default:
break;
@@ -100,17 +96,22 @@ static int rvin_digital_notify_complete(struct
v4l2_async_notifier *notifier)
struct rvin_dev *vin = notifier_to_vin(notifier);
int ret;
+ /* Verify subdevices mbus format */
+ if (!rvin_mbus_supported(vin)) {
+ vin_err(vin, "Unsupported media bus format for %s\n",
+ vin->digital.subdev->name);
+ return -EINVAL;
+ }
+
+ vin_dbg(vin, "Found media bus format for %s: %d\n",
+ vin->digital.subdev->name, vin->source.code);
+
ret = v4l2_device_register_subdev_nodes(&vin->v4l2_dev);
if (ret < 0) {
vin_err(vin, "Failed to register subdev nodes\n");
return ret;
}
- if (!rvin_mbus_supported(vin)) {
- vin_err(vin, "No supported mediabus format found\n");
- return -EINVAL;
- }
-
return rvin_v4l2_probe(vin);
}
@@ -120,7 +121,14 @@ static void rvin_digital_notify_unbind(struct
v4l2_async_notifier *notifier,
{
struct rvin_dev *vin = notifier_to_vin(notifier);
- rvin_v4l2_remove(vin);
+ if (vin->digital.subdev == subdev) {
+ vin_dbg(vin, "unbind digital subdev %s\n", subdev->name);
+ rvin_v4l2_remove(vin);
+ vin->digital.subdev = NULL;
+ return;
+ }
+
+ vin_err(vin, "no entity for subdev %s to unbind\n", subdev->name);
}
static int rvin_digital_notify_bound(struct v4l2_async_notifier *notifier,
@@ -129,89 +137,111 @@ static int rvin_digital_notify_bound(struct
v4l2_async_notifier *notifier,
{
struct rvin_dev *vin = notifier_to_vin(notifier);
- vin_dbg(vin, "subdev %s bound\n", subdev->name);
+ v4l2_set_subdev_hostdata(subdev, vin);
- vin->digital.entity = &subdev->entity;
- vin->digital.subdev = subdev;
+ if (vin->digital.asd.match.of.node == subdev->dev->of_node) {
+ vin_dbg(vin, "bound digital subdev %s\n", subdev->name);
+ vin->digital.subdev = subdev;
+ return 0;
+ }
- return 0;
+ vin_err(vin, "no entity for subdev %s to bind\n", subdev->name);
+ return -EINVAL;
}
-static int rvin_digital_parse(struct rvin_dev *vin,
- struct device_node *node)
+static int rvin_digitial_parse_v4l2(struct rvin_dev *vin,
+ struct device_node *ep,
+ struct v4l2_mbus_config *mbus_cfg)
{
- struct device_node *remote;
- struct device_node *ep = NULL;
- struct device_node *next;
- int ret = 0;
-
- while (1) {
- next = of_graph_get_next_endpoint(node, ep);
- if (!next)
- break;
+ struct v4l2_of_endpoint v4l2_ep;
+ int ret;
- of_node_put(ep);
- ep = next;
+ ret = v4l2_of_parse_endpoint(ep, &v4l2_ep);
+ if (ret) {
+ vin_err(vin, "Could not parse v4l2 endpoint\n");
+ return -EINVAL;
+ }
- remote = of_grap
[PATCHv2 10/16] [media] rcar-vin: move media bus information to struct rvin_graph_entity
The primary reason for this change is to prepare for Gen3 support where
there will be more then one possible video source. Each source will have
its own media bus format and code, so it needs to be moved from the per
device structure to a structure used to represent an individual
connection to a video source.
Signed-off-by: Niklas Söderlund
---
drivers/media/platform/rcar-vin/rcar-core.c | 12 ++--
drivers/media/platform/rcar-vin/rcar-dma.c | 10 +-
drivers/media/platform/rcar-vin/rcar-v4l2.c | 2 +-
drivers/media/platform/rcar-vin/rcar-vin.h | 9 +
4 files changed, 17 insertions(+), 16 deletions(-)
diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
b/drivers/media/platform/rcar-vin/rcar-core.c
index 6934940..fa1fa53 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -31,9 +31,9 @@
#define notifier_to_vin(n) container_of(n, struct rvin_dev, notifier)
-static bool rvin_mbus_supported(struct rvin_dev *vin)
+static bool rvin_mbus_supported(struct rvin_graph_entity *entity)
{
- struct v4l2_subdev *sd = vin->digital.subdev;
+ struct v4l2_subdev *sd = entity->subdev;
struct v4l2_subdev_mbus_code_enum code = {
.which = V4L2_SUBDEV_FORMAT_ACTIVE,
};
@@ -47,7 +47,7 @@ static bool rvin_mbus_supported(struct rvin_dev *vin)
case MEDIA_BUS_FMT_UYVY8_2X8:
case MEDIA_BUS_FMT_UYVY10_2X10:
case MEDIA_BUS_FMT_RGB888_1X24:
- vin->source.code = code.code;
+ entity->code = code.code;
return true;
default:
break;
@@ -97,14 +97,14 @@ static int rvin_digital_notify_complete(struct
v4l2_async_notifier *notifier)
int ret;
/* Verify subdevices mbus format */
- if (!rvin_mbus_supported(vin)) {
+ if (!rvin_mbus_supported(&vin->digital)) {
vin_err(vin, "Unsupported media bus format for %s\n",
vin->digital.subdev->name);
return -EINVAL;
}
vin_dbg(vin, "Found media bus format for %s: %d\n",
- vin->digital.subdev->name, vin->source.code);
+ vin->digital.subdev->name, vin->digital.code);
ret = v4l2_device_register_subdev_nodes(&vin->v4l2_dev);
if (ret < 0) {
@@ -205,7 +205,7 @@ static int rvin_digital_graph_parse(struct rvin_dev *vin)
}
of_node_put(np);
- ret = rvin_digitial_parse_v4l2(vin, ep, &vin->mbus_cfg);
+ ret = rvin_digitial_parse_v4l2(vin, ep, &vin->digital.mbus_cfg);
of_node_put(ep);
if (ret)
return ret;
diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
b/drivers/media/platform/rcar-vin/rcar-dma.c
index 7249c4f..79e7963 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -163,7 +163,7 @@ static int rvin_setup(struct rvin_dev *vin)
/*
* Input interface
*/
- switch (vin->source.code) {
+ switch (vin->digital.code) {
case MEDIA_BUS_FMT_YUYV8_1X16:
/* BT.601/BT.1358 16bit YCbCr422 */
vnmc |= VNMC_INF_YUV16;
@@ -171,7 +171,7 @@ static int rvin_setup(struct rvin_dev *vin)
break;
case MEDIA_BUS_FMT_UYVY8_2X8:
/* BT.656 8bit YCbCr422 or BT.601 8bit YCbCr422 */
- vnmc |= vin->mbus_cfg.type == V4L2_MBUS_BT656 ?
+ vnmc |= vin->digital.mbus_cfg.type == V4L2_MBUS_BT656 ?
VNMC_INF_YUV8_BT656 : VNMC_INF_YUV8_BT601;
input_is_yuv = true;
break;
@@ -180,7 +180,7 @@ static int rvin_setup(struct rvin_dev *vin)
break;
case MEDIA_BUS_FMT_UYVY10_2X10:
/* BT.656 10bit YCbCr422 or BT.601 10bit YCbCr422 */
- vnmc |= vin->mbus_cfg.type == V4L2_MBUS_BT656 ?
+ vnmc |= vin->digital.mbus_cfg.type == V4L2_MBUS_BT656 ?
VNMC_INF_YUV10_BT656 : VNMC_INF_YUV10_BT601;
input_is_yuv = true;
break;
@@ -192,11 +192,11 @@ static int rvin_setup(struct rvin_dev *vin)
dmr2 = VNDMR2_FTEV | VNDMR2_VLV(1);
/* Hsync Signal Polarity Select */
- if (!(vin->mbus_cfg.flags & V4L2_MBUS_HSYNC_ACTIVE_LOW))
+ if (!(vin->digital.mbus_cfg.flags & V4L2_MBUS_HSYNC_ACTIVE_LOW))
dmr2 |= VNDMR2_HPS;
/* Vsync Signal Polarity Select */
- if (!(vin->mbus_cfg.flags & V4L2_MBUS_VSYNC_ACTIVE_LOW))
+ if (!(vin->digital.mbus_cfg.flags & V4L2_MBUS_VSYNC_ACTIVE_LOW))
dmr2 |= VNDMR2_VPS;
/*
diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index ef3464d..d0e9d65 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@
[PATCHv2 08/16] [media] rcar-vin: move chip check for pixelformat support
The check for if the specific pixelformat is supported on the current
chip should happen in VIDIOC_S_FMT and VIDIOC_TRY_FMT and not when we
try to setup the hardware for streaming.
Signed-off-by: Niklas Söderlund
---
drivers/media/platform/rcar-vin/rcar-dma.c | 8 +++-
drivers/media/platform/rcar-vin/rcar-v4l2.c | 5 +
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
b/drivers/media/platform/rcar-vin/rcar-dma.c
index 0836b15..7249c4f 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -225,11 +225,9 @@ static int rvin_setup(struct rvin_dev *vin)
dmr = 0;
break;
case V4L2_PIX_FMT_XBGR32:
- if (vin->chip == RCAR_GEN2 || vin->chip == RCAR_H1) {
- dmr = VNDMR_EXRGB;
- break;
- }
- /* fall through */
+ /* Note: not supported on M1 */
+ dmr = VNDMR_EXRGB;
+ break;
default:
vin_err(vin, "Invalid pixelformat (0x%x)\n",
vin->format.pixelformat);
diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 09df396..ef3464d 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -192,6 +192,11 @@ static int __rvin_try_format(struct rvin_dev *vin,
pix->sizeimage = max_t(u32, pix->sizeimage,
rvin_format_sizeimage(pix));
+ if (vin->chip == RCAR_M1 && pix->pixelformat == V4L2_PIX_FMT_XBGR32) {
+ vin_err(vin, "pixel format XBGR32 not supported on M1\n");
+ return -EINVAL;
+ }
+
vin_dbg(vin, "Requested %ux%u Got %ux%u bpl: %d size: %d\n",
rwidth, rheight, pix->width, pix->height,
pix->bytesperline, pix->sizeimage);
--
2.9.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
[PATCHv2 00/16] rcar-vin: Enable Gen3 support
Hi, This series enable Gen3 support for the rcar-vin driver. It is based on top of the media_tree. This is a rather large patch since unfortunately the subdevice and input selection on Gen3 are much more complex than on Gen2, see individual patches for a more detailed explanation. - Patch 1-2 picks up media entity additions from Laurent which the driver depends on. - Patch 3 picks up a fix for incorrect media bus formats. This patch is posted separately but to resolve the merge conflict it generated i included it in this series. - Patch 4-8 cleans up the driver fixing some logical, style and dependency errors that was not found before the driver was added to media_next. - Patch 9 simplifies how DT is parsed and how v4l2 async binding to subdevices are setup. A incorrect usage of of_node_put() is also fixed. - Patch 10 moves struct variables around to prepare for multiple input sources. - Patch 11-12 adds an abstraction layer between the code and which subdevices are currently used. This also fixes the problem where a subdevice could not be unbound and later rebound keeping the VIN driver working. - Patch 13 adds Gen3 Hw support. - Patch 14 is the big patch adding subdevice groups that can be shared between multiple rcar-vin instances. See commit message for much more details. - Patch 15-16 adds DT bindings for Gen3 and compatibility bindings for Gen2 and Gen3. The series is tested on Koelsch for Gen2 and it works as expected. If one wants to test the HDMI input the patch 'r8a7791-koelsch.dts: add HDMI input' from Hans Verkuil are needed to add it to DT. The driver passes a v4l2-compliance on Gen2 without errors or warnings. And there are no problems grabbing frames from the CVBS or HDMI input sources using qv4l2. For Gen3 there are more drivers needed to get working video input running. To be able to grab frames drivers are needed for the R-Car CSI-2 interface and the ADV7482 device which are not yet present in the kernel. A driver for the CSI-2 interface and a prototype for ADV7482 are posted on the media malinglist. Unfortunately the ADV7482 driver needs more support in the v4l2 framework to be able to provide two interdependent video pipelines (CVBS and HDMI). Until this is resolved the driver can be compiled for either CVBS or HDMI operation. If one have a DT that only contain CVBS configuration rcar-vin v4l2-compliance pass all test expect for controls since they are not added to the ADV7482 driver. For HDMI DT and ADV7482 compiled for HDMI instead of the default CVBS v4l2-compliance fails for controls and DV timings since some parts are missing in the ADV7482 driver. It is however possible to capture both CVBS and HDMI video using qv4l2. If one is interested to test on Gen3 without having to hunt patches look at the elinux wiki for a branch containing the latest status. http://elinux.org/R-Car/Tests:rcar-vin Changes since v1: - Address review comments from Laurent. - Split cleanup of driver to smaller chunks. - Remove initial work for v4l2 framework changes to support a pad aware s_stream operation. - Picked up patch for incorrect media bus format. - Removed Ulrich patches which now have been picked up in media_tree. Laurent Pinchart (2): media: entity: Add has_route entity operation media: entity: Add media_entity_has_route() function Niklas Söderlund (14): [media] rcar-vin: add legacy mode for wrong media bus formats [media] rcar-vin: return correct error from platform_get_irq [media] rcar-vin: do not use v4l2_device_call_until_err() [media] rcar-vin: cosmetic clean up in preparation for Gen3 [media] rcar-vin: add dependency on MEDIA_CONTROLLER [media] rcar-vin: move chip check for pixelformat support [media] rcar-vin: rework how subdeivce is found and bound [media] rcar-vin: move media bus information to struct rvin_graph_entity [media] rcar-vin: add abstraction layer to interact with subdevices [media] rcar-vin: allow subdevices to be bound late [media] rcar-vin: add Gen3 HW registers [media] rcar-vin: add shared subdevice groups [media] rcar-vin: enable Gen3 [media] rcar-vin: add Gen2 and Gen3 fallback compatibility strings .../devicetree/bindings/media/rcar_vin.txt | 218 +++- drivers/media/media-entity.c | 29 + drivers/media/platform/rcar-vin/Kconfig|4 +- drivers/media/platform/rcar-vin/Makefile |2 +- drivers/media/platform/rcar-vin/rcar-core.c| 461 +--- drivers/media/platform/rcar-vin/rcar-dma.c | 212 +++- drivers/media/platform/rcar-vin/rcar-group.c | 1250 drivers/media/platform/rcar-vin/rcar-group.h | 104 ++ drivers/media/platform/rcar-vin/rcar-v4l2.c| 466 drivers/media/platform/rcar-vin/rcar-vin.h | 73 +- include/media/media-entity.h |8 + 11 files changed, 2339 insertions(+), 488 deletions(-) creat
[PATCHv2 05/16] [media] rcar-vin: do not use v4l2_device_call_until_err()
Fix a error from the original driver where v4l2_device_call_until_err() where used for the pad specific v4l2 operation set_fmt. Also fix up the error path from this fix so if there is an error it will be propagated to the caller. The error path label have also been renamed as a result from a nitpicking review comment since we are fixing other issues here. Signed-off-by: Niklas Söderlund --- drivers/media/platform/rcar-vin/rcar-v4l2.c | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c b/drivers/media/platform/rcar-vin/rcar-v4l2.c index 10a5c10..5dceff8 100644 --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c @@ -114,10 +114,9 @@ static int __rvin_try_format_source(struct rvin_dev *vin, format.pad = vin->src_pad_idx; - ret = v4l2_device_call_until_err(sd->v4l2_dev, 0, pad, set_fmt, -pad_cfg, &format); - if (ret < 0) - goto cleanup; + ret = v4l2_subdev_call(sd, pad, set_fmt, pad_cfg, &format); + if (ret < 0 && ret != -ENOIOCTLCMD) + goto done; v4l2_fill_pix_format(pix, &format.format); @@ -127,9 +126,9 @@ static int __rvin_try_format_source(struct rvin_dev *vin, vin_dbg(vin, "Source resolution: %ux%u\n", source->width, source->height); -cleanup: +done: v4l2_subdev_free_pad_config(pad_cfg); - return 0; + return ret; } static int __rvin_try_format(struct rvin_dev *vin, -- 2.9.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
[PATCHv2 06/16] [media] rcar-vin: cosmetic clean up in preparation for Gen3
The main purpose of this commit is to make consecutive patches easier to
read. This is achieved with the following changes.
- Rename the variable 'entity' in struct rvin_dev to 'digital'. When we
add Gen3 support later this will only deal with the digital input
source.
- Rename all functions dealing with the v4l2 async framework and DT
parsing for the digital input from rvin_graph_* to rvin_digital_*.
- Reduce indentation in rvin_s_dv_timings() and use 'ret' instead of
'err' for return value variable as used in the rest of the driver.
- Order enum chip_id in chronological order.
- Fix indentation errors in rcar-v4l2.c which for some reason had bad
indentations at some locations.
Signed-off-by: Niklas Söderlund
---
drivers/media/platform/rcar-vin/rcar-core.c | 46 ++--
drivers/media/platform/rcar-vin/rcar-v4l2.c | 66 ++---
drivers/media/platform/rcar-vin/rcar-vin.h | 8 ++--
3 files changed, 59 insertions(+), 61 deletions(-)
diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
b/drivers/media/platform/rcar-vin/rcar-core.c
index ff27d75..6744325 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -95,7 +95,7 @@ static int rvin_mbus_supported(struct rvin_dev *vin)
return false;
}
-static int rvin_graph_notify_complete(struct v4l2_async_notifier *notifier)
+static int rvin_digital_notify_complete(struct v4l2_async_notifier *notifier)
{
struct rvin_dev *vin = notifier_to_vin(notifier);
int ret;
@@ -114,31 +114,31 @@ static int rvin_graph_notify_complete(struct
v4l2_async_notifier *notifier)
return rvin_v4l2_probe(vin);
}
-static void rvin_graph_notify_unbind(struct v4l2_async_notifier *notifier,
-struct v4l2_subdev *sd,
-struct v4l2_async_subdev *asd)
+static void rvin_digital_notify_unbind(struct v4l2_async_notifier *notifier,
+ struct v4l2_subdev *subdev,
+ struct v4l2_async_subdev *asd)
{
struct rvin_dev *vin = notifier_to_vin(notifier);
rvin_v4l2_remove(vin);
}
-static int rvin_graph_notify_bound(struct v4l2_async_notifier *notifier,
- struct v4l2_subdev *subdev,
- struct v4l2_async_subdev *asd)
+static int rvin_digital_notify_bound(struct v4l2_async_notifier *notifier,
+struct v4l2_subdev *subdev,
+struct v4l2_async_subdev *asd)
{
struct rvin_dev *vin = notifier_to_vin(notifier);
vin_dbg(vin, "subdev %s bound\n", subdev->name);
- vin->entity.entity = &subdev->entity;
- vin->entity.subdev = subdev;
+ vin->digital.entity = &subdev->entity;
+ vin->digital.subdev = subdev;
return 0;
}
-static int rvin_graph_parse(struct rvin_dev *vin,
- struct device_node *node)
+static int rvin_digital_parse(struct rvin_dev *vin,
+ struct device_node *node)
{
struct device_node *remote;
struct device_node *ep = NULL;
@@ -166,10 +166,10 @@ static int rvin_graph_parse(struct rvin_dev *vin,
}
/* Remote node to connect */
- if (!vin->entity.node) {
- vin->entity.node = remote;
- vin->entity.asd.match_type = V4L2_ASYNC_MATCH_OF;
- vin->entity.asd.match.of.node = remote;
+ if (!vin->digital.node) {
+ vin->digital.node = remote;
+ vin->digital.asd.match_type = V4L2_ASYNC_MATCH_OF;
+ vin->digital.asd.match.of.node = remote;
ret++;
}
}
@@ -179,13 +179,13 @@ static int rvin_graph_parse(struct rvin_dev *vin,
return ret;
}
-static int rvin_graph_init(struct rvin_dev *vin)
+static int rvin_digital_init(struct rvin_dev *vin)
{
struct v4l2_async_subdev **subdevs = NULL;
int ret;
/* Parse the graph to extract a list of subdevice DT nodes. */
- ret = rvin_graph_parse(vin, vin->dev->of_node);
+ ret = rvin_digital_parse(vin, vin->dev->of_node);
if (ret < 0) {
vin_err(vin, "Graph parsing failed\n");
goto done;
@@ -208,13 +208,13 @@ static int rvin_graph_init(struct rvin_dev *vin)
goto done;
}
- subdevs[0] = &vin->entity.asd;
+ subdevs[0] = &vin->digital.asd;
vin->notifier.subdevs = subdevs;
vin->notifier.num_subdevs = 1;
- vin->notifier.bound = rvin_graph_notify_bound;
- vin->notifier.unbind = rvin_graph_notify_unbind;
- vin->notifier.complete = rvin_graph_notify_complete;
+ vin->notifier.bound = rvin_digital_notify_bound;
+ vin->notifier.unbind =
[PATCHv2 15/16] [media] rcar-vin: enable Gen3
Signed-off-by: Niklas Söderlund
---
drivers/media/platform/rcar-vin/Kconfig | 2 +-
drivers/media/platform/rcar-vin/rcar-core.c | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/rcar-vin/Kconfig
b/drivers/media/platform/rcar-vin/Kconfig
index 111d2a1..e0e981c 100644
--- a/drivers/media/platform/rcar-vin/Kconfig
+++ b/drivers/media/platform/rcar-vin/Kconfig
@@ -5,7 +5,7 @@ config VIDEO_RCAR_VIN
select VIDEOBUF2_DMA_CONTIG
---help---
Support for Renesas R-Car Video Input (VIN) driver.
- Supports R-Car Gen2 SoCs.
+ Supports R-Car Gen2 and Gen3 SoCs.
To compile this driver as a module, choose M here: the
module will be called rcar-vin.
diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
b/drivers/media/platform/rcar-vin/rcar-core.c
index 8842777..eab3009 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -336,6 +336,7 @@ static int rvin_digital_graph_init(struct rvin_dev *vin)
*/
static const struct of_device_id rvin_of_id_table[] = {
+ { .compatible = "renesas,vin-r8a7795", .data = (void *)RCAR_GEN3 },
{ .compatible = "renesas,vin-r8a7794", .data = (void *)RCAR_GEN2 },
{ .compatible = "renesas,vin-r8a7793", .data = (void *)RCAR_GEN2 },
{ .compatible = "renesas,vin-r8a7791", .data = (void *)RCAR_GEN2 },
--
2.9.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
[PATCHv2 03/16] [media] rcar-vin: add legacy mode for wrong media bus formats
A recent bugfix to adv7180 brought to light that the rcar-vin driver are
looking for the wrong media bus format. It was looking for a YUVU format
but then expecting UYVY data. The bugfix for adv7180 will break the
usage of rcar-vin together with a adv7180 as found on Renesas R-Car2
Koelsch boards for example.
This patch fix the rcar-vin driver to look for the correct UYVU formats
and adds a legacy mode. The legacy mode is needed since I don't know if
other devices provide a incorrect media bus format and I don't want to
break any working configurations. Hopefully the legacy mode can be
removed sometime in the future.
Signed-off-by: Niklas Söderlund
---
drivers/media/platform/rcar-vin/rcar-core.c | 39 +++--
drivers/media/platform/rcar-vin/rcar-dma.c | 4 +--
2 files changed, 39 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
b/drivers/media/platform/rcar-vin/rcar-core.c
index 4b2007b..481d82a 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -37,6 +37,7 @@ static int rvin_mbus_supported(struct rvin_dev *vin)
struct v4l2_subdev_mbus_code_enum code = {
.which = V4L2_SUBDEV_FORMAT_ACTIVE,
};
+ bool found;
sd = vin_to_source(vin);
@@ -45,8 +46,8 @@ static int rvin_mbus_supported(struct rvin_dev *vin)
code.index++;
switch (code.code) {
case MEDIA_BUS_FMT_YUYV8_1X16:
- case MEDIA_BUS_FMT_YUYV8_2X8:
- case MEDIA_BUS_FMT_YUYV10_2X10:
+ case MEDIA_BUS_FMT_UYVY8_2X8:
+ case MEDIA_BUS_FMT_UYVY10_2X10:
case MEDIA_BUS_FMT_RGB888_1X24:
vin->source.code = code.code;
vin_dbg(vin, "Found supported media bus format: %d\n",
@@ -57,6 +58,40 @@ static int rvin_mbus_supported(struct rvin_dev *vin)
}
}
+ /*
+* Older versions where looking for the wrong media bus format.
+* It where looking for a YUVY format but then treated it as a
+* UYVY format. This was not noticed since atlest one subdevice
+* used for testing (adv7180) reported a YUVY media bus format
+* but provided UYVY data. There might be other unknown subdevices
+* which also do this, to not break compatibility try to use them
+* in legacy mode.
+*/
+ found = false;
+ code.index = 0;
+ while (!v4l2_subdev_call(sd, pad, enum_mbus_code, NULL, &code)) {
+ code.index++;
+ switch (code.code) {
+ case MEDIA_BUS_FMT_YUYV8_2X8:
+ vin->source.code = MEDIA_BUS_FMT_UYVY8_2X8;
+ found = true;
+ break;
+ case MEDIA_BUS_FMT_YUYV10_2X10:
+ vin->source.code = MEDIA_BUS_FMT_UYVY10_2X10;
+ found = true;
+ break;
+ default:
+ break;
+ }
+
+ if (found) {
+ vin_err(vin,
+ "media bus %d not supported, trying legacy mode
%d\n",
+ code.code, vin->source.code);
+ return true;
+ }
+ }
+
return false;
}
diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
b/drivers/media/platform/rcar-vin/rcar-dma.c
index dad3b03..0836b15 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -169,7 +169,7 @@ static int rvin_setup(struct rvin_dev *vin)
vnmc |= VNMC_INF_YUV16;
input_is_yuv = true;
break;
- case MEDIA_BUS_FMT_YUYV8_2X8:
+ case MEDIA_BUS_FMT_UYVY8_2X8:
/* BT.656 8bit YCbCr422 or BT.601 8bit YCbCr422 */
vnmc |= vin->mbus_cfg.type == V4L2_MBUS_BT656 ?
VNMC_INF_YUV8_BT656 : VNMC_INF_YUV8_BT601;
@@ -178,7 +178,7 @@ static int rvin_setup(struct rvin_dev *vin)
case MEDIA_BUS_FMT_RGB888_1X24:
vnmc |= VNMC_INF_RGB888;
break;
- case MEDIA_BUS_FMT_YUYV10_2X10:
+ case MEDIA_BUS_FMT_UYVY10_2X10:
/* BT.656 10bit YCbCr422 or BT.601 10bit YCbCr422 */
vnmc |= vin->mbus_cfg.type == V4L2_MBUS_BT656 ?
VNMC_INF_YUV10_BT656 : VNMC_INF_YUV10_BT601;
--
2.9.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
[PATCHv2 13/16] [media] rcar-vin: add Gen3 HW registers
Add the register needed to work with Gen3 hardware. This patch just adds
the logic for how to work with the Gen3 hardware. More work is required
to enable the subdevice structure needed to support capturing.
Signed-off-by: Niklas Söderlund
---
drivers/media/platform/rcar-vin/rcar-dma.c | 97 -
drivers/media/platform/rcar-vin/rcar-v4l2.c | 15 -
drivers/media/platform/rcar-vin/rcar-vin.h | 1 +
3 files changed, 79 insertions(+), 34 deletions(-)
diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
b/drivers/media/platform/rcar-vin/rcar-dma.c
index 7e571a8..d63b186 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -33,21 +33,23 @@
#define VNELPRC_REG0x10/* Video n End Line Pre-Clip Register */
#define VNSPPRC_REG0x14/* Video n Start Pixel Pre-Clip Register */
#define VNEPPRC_REG0x18/* Video n End Pixel Pre-Clip Register */
-#define VNSLPOC_REG0x1C/* Video n Start Line Post-Clip Register */
-#define VNELPOC_REG0x20/* Video n End Line Post-Clip Register */
-#define VNSPPOC_REG0x24/* Video n Start Pixel Post-Clip Register */
-#define VNEPPOC_REG0x28/* Video n End Pixel Post-Clip Register */
#define VNIS_REG 0x2C/* Video n Image Stride Register */
#define VNMB_REG(m)(0x30 + ((m) << 2)) /* Video n Memory Base m Register */
#define VNIE_REG 0x40/* Video n Interrupt Enable Register */
#define VNINTS_REG 0x44/* Video n Interrupt Status Register */
#define VNSI_REG 0x48/* Video n Scanline Interrupt Register */
#define VNMTC_REG 0x4C/* Video n Memory Transfer Control Register */
-#define VNYS_REG 0x50/* Video n Y Scale Register */
-#define VNXS_REG 0x54/* Video n X Scale Register */
#define VNDMR_REG 0x58/* Video n Data Mode Register */
#define VNDMR2_REG 0x5C/* Video n Data Mode Register 2 */
#define VNUVAOF_REG0x60/* Video n UV Address Offset Register */
+
+/* Register offsets specific for Gen2 */
+#define VNSLPOC_REG0x1C/* Video n Start Line Post-Clip Register */
+#define VNELPOC_REG0x20/* Video n End Line Post-Clip Register */
+#define VNSPPOC_REG0x24/* Video n Start Pixel Post-Clip Register */
+#define VNEPPOC_REG0x28/* Video n End Pixel Post-Clip Register */
+#define VNYS_REG 0x50/* Video n Y Scale Register */
+#define VNXS_REG 0x54/* Video n X Scale Register */
#define VNC1A_REG 0x80/* Video n Coefficient Set C1A Register */
#define VNC1B_REG 0x84/* Video n Coefficient Set C1B Register */
#define VNC1C_REG 0x88/* Video n Coefficient Set C1C Register */
@@ -73,9 +75,13 @@
#define VNC8B_REG 0xF4/* Video n Coefficient Set C8B Register */
#define VNC8C_REG 0xF8/* Video n Coefficient Set C8C Register */
+/* Register offsets specific for Gen3 */
+#define VNCSI_IFMD_REG 0x20 /* Video n CSI2 Interface Mode Register */
/* Register bit fields for R-Car VIN */
/* Video n Main Control Register bits */
+#define VNMC_DPINE (1 << 27) /* Gen3 specific */
+#define VNMC_SCLE (1 << 26) /* Gen3 specific */
#define VNMC_FOC (1 << 21)
#define VNMC_YCAL (1 << 19)
#define VNMC_INF_YUV8_BT656(0 << 16)
@@ -118,6 +124,12 @@
#define VNDMR2_FTEV(1 << 17)
#define VNDMR2_VLV(n) ((n & 0xf) << 12)
+/* Video n CSI2 Interface Mode Register (Gen3) */
+#define VNCSI_IFMD_DES2(1 << 27)
+#define VNCSI_IFMD_DES1(1 << 26)
+#define VNCSI_IFMD_DES0(1 << 25)
+#define VNCSI_IFMD_CSI_CHSEL(n) ((n & 0xf) << 0)
+
static void rvin_write(struct rvin_dev *vin, u32 value, u32 offset)
{
iowrite32(value, vin->base + offset);
@@ -196,7 +208,10 @@ static int rvin_setup(struct rvin_dev *vin)
}
/* Enable VSYNC Field Toogle mode after one VSYNC input */
- dmr2 = VNDMR2_FTEV | VNDMR2_VLV(1);
+ if (vin->chip == RCAR_GEN3)
+ dmr2 = VNDMR2_FTEV;
+ else
+ dmr2 = VNDMR2_FTEV | VNDMR2_VLV(1);
/* Hsync Signal Polarity Select */
if (!(mbus_cfg.flags & V4L2_MBUS_HSYNC_ACTIVE_LOW))
@@ -248,6 +263,14 @@ static int rvin_setup(struct rvin_dev *vin)
if (input_is_yuv == output_is_yuv)
vnmc |= VNMC_BPS;
+ if (vin->chip == RCAR_GEN3) {
+ /* Select between CSI-2 and Digital input */
+ if (mbus_cfg.type == V4L2_MBUS_CSI2)
+ vnmc &= ~VNMC_DPINE;
+ else
+ vnmc |= VNMC_DPINE;
+ }
+
/* Progressive or interlaced mode */
interrupts = progressive ? VNIE_FIE : VNIE_EFE;
@@ -738,28 +761,10 @@ static void rvin_set_coeff(struct rvin_dev *vin, unsigned
short xs)
rvin_write(vin, p_set->coeff_set[23], VNC8C_REG);
}
-void rvin_crop_scale_comp(struct rvin_dev *
[PATCHv2 11/16] [media] rcar-vin: add abstraction layer to interact with subdevices
In order to try and separate which v4l2 subdevice operation the driver
calls from which subdevice it currently have chosen as its current input
a abstraction is created. The abstraction is mostly straight forward:
- The v4l2_subdev_call() calls that only can act on the current active
subdevice are replaced with rvin_subdev_call(). The parameters
describing the v4l2 operation is kept the same but the first argument
is switch from a struct v4l2_subdev* to a struct rvin_dev*. The
abstraction then pass on the v4l2 operation to the correct subdevice.
- The v4l2_subdev_call() calls that can be used in enumerate input
properties are replaced with rvin_subdev_call_input() (g_input_status,
dv_timings_cap, g_tvnorms and enum_dv_timings). The parameters
describing the v4l2 operation is kept the same but the first two
arguments are switch from a struct v4l2_subdev* to a struct rvin_dev*
and a number for the input source. The abstraction then pass on the
v4l2 operation to the correct subdevice.
- Wrappers are added to get the media bus format and code from the
currently active input source.
- Wrapper are added to handle controls from the currently active input
source.
This patch just adds and replace the v4l2 calls with there abstraction
layer counter part, there are still only one possible input source. This
is done to prepare for Gen3 support where there are more then one
possible subdevices to chose from at runtime.
Signed-off-by: Niklas Söderlund
---
drivers/media/platform/rcar-vin/rcar-core.c | 37 +
drivers/media/platform/rcar-vin/rcar-dma.c | 29 ++-
drivers/media/platform/rcar-vin/rcar-v4l2.c | 81 ++---
drivers/media/platform/rcar-vin/rcar-vin.h | 15 ++
4 files changed, 107 insertions(+), 55 deletions(-)
diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
b/drivers/media/platform/rcar-vin/rcar-core.c
index fa1fa53..6fe9b6c 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -26,6 +26,43 @@
#include "rcar-vin.h"
/*
-
+ * Subdevice group helpers
+ */
+
+int rvin_subdev_get_code(struct rvin_dev *vin, u32 *code)
+{
+ *code = vin->digital.code;
+ return 0;
+}
+
+int rvin_subdev_get_mbus_cfg(struct rvin_dev *vin,
+struct v4l2_mbus_config *mbus_cfg)
+{
+ *mbus_cfg = vin->digital.mbus_cfg;
+ return 0;
+}
+
+struct v4l2_subdev_pad_config*
+rvin_subdev_alloc_pad_config(struct rvin_dev *vin)
+{
+ return v4l2_subdev_alloc_pad_config(vin->digital.subdev);
+}
+
+int rvin_subdev_ctrl_add_handler(struct rvin_dev *vin)
+{
+ int ret;
+
+ v4l2_ctrl_handler_free(&vin->ctrl_handler);
+
+ ret = v4l2_ctrl_handler_init(&vin->ctrl_handler, 16);
+ if (ret < 0)
+ return ret;
+
+ return v4l2_ctrl_add_handler(&vin->ctrl_handler,
+vin->digital.subdev->ctrl_handler, NULL);
+}
+
+/*
-
* Async notifier
*/
diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c
b/drivers/media/platform/rcar-vin/rcar-dma.c
index 79e7963..252adae 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -130,9 +130,16 @@ static u32 rvin_read(struct rvin_dev *vin, u32 offset)
static int rvin_setup(struct rvin_dev *vin)
{
- u32 vnmc, dmr, dmr2, interrupts;
+ u32 code, vnmc, dmr, dmr2, interrupts;
+ struct v4l2_mbus_config mbus_cfg;
bool progressive = false, output_is_yuv = false, input_is_yuv = false;
+ if (rvin_subdev_get_mbus_cfg(vin, &mbus_cfg))
+ return -EINVAL;
+
+ if (rvin_subdev_get_code(vin, &code))
+ return -EINVAL;
+
switch (vin->format.field) {
case V4L2_FIELD_TOP:
vnmc = VNMC_IM_ODD;
@@ -163,7 +170,7 @@ static int rvin_setup(struct rvin_dev *vin)
/*
* Input interface
*/
- switch (vin->digital.code) {
+ switch (code) {
case MEDIA_BUS_FMT_YUYV8_1X16:
/* BT.601/BT.1358 16bit YCbCr422 */
vnmc |= VNMC_INF_YUV16;
@@ -171,7 +178,7 @@ static int rvin_setup(struct rvin_dev *vin)
break;
case MEDIA_BUS_FMT_UYVY8_2X8:
/* BT.656 8bit YCbCr422 or BT.601 8bit YCbCr422 */
- vnmc |= vin->digital.mbus_cfg.type == V4L2_MBUS_BT656 ?
+ vnmc |= mbus_cfg.type == V4L2_MBUS_BT656 ?
VNMC_INF_YUV8_BT656 : VNMC_INF_YUV8_BT601;
input_is_yuv = true;
break;
@@ -180,7 +187,7 @@ static int rvin_setup(struct rvin_dev *vin)
break;
case MEDIA_BUS_FMT_UYVY10_2X10:
/* BT.656 10bit YCbCr422 or BT.601 10bit YCbCr422 */
- vnmc |= vin->digital.mbu
[PATCHv2 04/16] [media] rcar-vin: return correct error from platform_get_irq
Fix a error from the original driver where the wrong error code is returned if the driver fails to get a IRQ number from platform_get_irq(). Signed-off-by: Niklas Söderlund --- drivers/media/platform/rcar-vin/rcar-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/rcar-vin/rcar-core.c b/drivers/media/platform/rcar-vin/rcar-core.c index 481d82a..ff27d75 100644 --- a/drivers/media/platform/rcar-vin/rcar-core.c +++ b/drivers/media/platform/rcar-vin/rcar-core.c @@ -318,7 +318,7 @@ static int rcar_vin_probe(struct platform_device *pdev) irq = platform_get_irq(pdev, 0); if (irq <= 0) - return ret; + return irq; ret = rvin_dma_probe(vin, irq); if (ret) -- 2.9.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
[PATCHv2 16/16] [media] rcar-vin: add Gen2 and Gen3 fallback compatibility strings
These are present in the soc-camera version of this driver and it's time
to add them to this driver as well.
Signed-off-by: Niklas Söderlund
---
drivers/media/platform/rcar-vin/rcar-core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
b/drivers/media/platform/rcar-vin/rcar-core.c
index eab3009..e02ce48 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -343,6 +343,8 @@ static const struct of_device_id rvin_of_id_table[] = {
{ .compatible = "renesas,vin-r8a7790", .data = (void *)RCAR_GEN2 },
{ .compatible = "renesas,vin-r8a7779", .data = (void *)RCAR_H1 },
{ .compatible = "renesas,vin-r8a7778", .data = (void *)RCAR_M1 },
+ { .compatible = "renesas,rcar-gen3-vin", .data = (void *)RCAR_GEN3 },
+ { .compatible = "renesas,rcar-gen2-vin", .data = (void *)RCAR_GEN2 },
{ },
};
MODULE_DEVICE_TABLE(of, rvin_of_id_table);
--
2.9.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
[PATCHv2 12/16] [media] rcar-vin: allow subdevices to be bound late
This is done to prepare for Gen3 support where there are more than one
subdevice and the usage of them are complex. There is a need to be able
to change which subdevices are involved in capturing during runtime (but
not while streaming). Furthermore the subdevices can be shared by
more then one rcar-vin instance. To be able to facilitate this for Gen3
this patch adds support to select an input (set of subdevices) after the
struct video_device have been registered.
It makes the selection when the first open occurs on the video device,
concurrent opens of the device are stuck with the input which was set by
the first open. A exception to this is if there is only one user of the
video device it is possible to change the input selection using s_input.
If s_input is attempted while there are more then one user of the video
device it will be disallowed with a -EBUSY. If a user tries to open the
video device before it has found a valid input (bound its subdevices) it
will be denied to open the video device with a -EBUSY.
At this point this change is purely academic since the driver in its
current form only supports one subdevice so not much point in trying to
change it. It dose however solve the issue of bind/unbind of subdevices
and still remaining operational.
Signed-off-by: Niklas Söderlund
---
drivers/media/platform/rcar-vin/rcar-core.c | 106 --
drivers/media/platform/rcar-vin/rcar-dma.c | 7 -
drivers/media/platform/rcar-vin/rcar-v4l2.c | 310 +---
drivers/media/platform/rcar-vin/rcar-vin.h | 27 ++-
4 files changed, 254 insertions(+), 196 deletions(-)
diff --git a/drivers/media/platform/rcar-vin/rcar-core.c
b/drivers/media/platform/rcar-vin/rcar-core.c
index 6fe9b6c..5171953 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -29,6 +29,45 @@
* Subdevice group helpers
*/
+static unsigned int rvin_pad_idx(struct v4l2_subdev *sd, int direction)
+{
+ unsigned int pad_idx;
+
+ for (pad_idx = 0; pad_idx < sd->entity.num_pads; pad_idx++)
+ if (sd->entity.pads[pad_idx].flags == direction)
+ return pad_idx;
+
+ return 0;
+}
+
+int rvin_subdev_get(struct rvin_dev *vin)
+{
+ strncpy(vin->inputs[0].name, "Digital", RVIN_INPUT_NAME_SIZE);
+ vin->inputs[0].sink_idx =
+ rvin_pad_idx(vin->digital.subdev, MEDIA_PAD_FL_SINK);
+ vin->inputs[0].source_idx =
+ rvin_pad_idx(vin->digital.subdev, MEDIA_PAD_FL_SOURCE);
+
+ vin->current_input = 0;
+
+ return 0;
+}
+
+int rvin_subdev_put(struct rvin_dev *vin)
+{
+ vin->current_input = 0;
+
+ return 0;
+}
+
+int rvin_subdev_set_input(struct rvin_dev *vin, struct rvin_input_item *item)
+{
+ if (vin->digital.subdev)
+ return 0;
+
+ return -EBUSY;
+}
+
int rvin_subdev_get_code(struct rvin_dev *vin, u32 *code)
{
*code = vin->digital.code;
@@ -149,7 +188,7 @@ static int rvin_digital_notify_complete(struct
v4l2_async_notifier *notifier)
return ret;
}
- return rvin_v4l2_probe(vin);
+ return 0;
}
static void rvin_digital_notify_unbind(struct v4l2_async_notifier *notifier,
@@ -160,7 +199,6 @@ static void rvin_digital_notify_unbind(struct
v4l2_async_notifier *notifier,
if (vin->digital.subdev == subdev) {
vin_dbg(vin, "unbind digital subdev %s\n", subdev->name);
- rvin_v4l2_remove(vin);
vin->digital.subdev = NULL;
return;
}
@@ -307,24 +345,12 @@ static const struct of_device_id rvin_of_id_table[] = {
};
MODULE_DEVICE_TABLE(of, rvin_of_id_table);
-static int rcar_vin_probe(struct platform_device *pdev)
+static int rvin_probe_channel(struct platform_device *pdev,
+ struct rvin_dev *vin)
{
- const struct of_device_id *match;
- struct rvin_dev *vin;
struct resource *mem;
int irq, ret;
- vin = devm_kzalloc(&pdev->dev, sizeof(*vin), GFP_KERNEL);
- if (!vin)
- return -ENOMEM;
-
- match = of_match_device(of_match_ptr(rvin_of_id_table), &pdev->dev);
- if (!match)
- return -ENODEV;
-
- vin->dev = &pdev->dev;
- vin->chip = (enum chip_id)match->data;
-
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (mem == NULL)
return -EINVAL;
@@ -341,18 +367,54 @@ static int rcar_vin_probe(struct platform_device *pdev)
if (ret)
return ret;
+ return 0;
+}
+
+static int rcar_vin_probe(struct platform_device *pdev)
+{
+ const struct of_device_id *match;
+ struct rvin_dev *vin;
+ int ret;
+
+ vin = devm_kzalloc(&pdev->dev, sizeof(*vin), GFP_KERNEL);
+ if (!vin)
+ return -ENOMEM;
+
+ match = of_match_device(of_match_ptr(rvin_of_id_table), &pdev->dev);
+ if (!match)
+ return
[PATCHv2 07/16] [media] rcar-vin: add dependency on MEDIA_CONTROLLER
This is done in preparation for Gen3 support where media controller support will be mandatory for the driver. Signed-off-by: Niklas Söderlund --- drivers/media/platform/rcar-vin/Kconfig | 2 +- drivers/media/platform/rcar-vin/rcar-v4l2.c | 7 +-- 2 files changed, 2 insertions(+), 7 deletions(-) diff --git a/drivers/media/platform/rcar-vin/Kconfig b/drivers/media/platform/rcar-vin/Kconfig index b2ff2d4..111d2a1 100644 --- a/drivers/media/platform/rcar-vin/Kconfig +++ b/drivers/media/platform/rcar-vin/Kconfig @@ -1,6 +1,6 @@ config VIDEO_RCAR_VIN tristate "R-Car Video Input (VIN) Driver" - depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF && HAS_DMA + depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF && HAS_DMA && MEDIA_CONTROLLER depends on ARCH_RENESAS || COMPILE_TEST select VIDEOBUF2_DMA_CONTIG ---help--- diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c b/drivers/media/platform/rcar-vin/rcar-v4l2.c index 3f80a0b..09df396 100644 --- a/drivers/media/platform/rcar-vin/rcar-v4l2.c +++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c @@ -771,10 +771,7 @@ int rvin_v4l2_probe(struct rvin_dev *vin) struct v4l2_mbus_framefmt *mf = &fmt.format; struct video_device *vdev = &vin->vdev; struct v4l2_subdev *sd = vin_to_source(vin); -#if defined(CONFIG_MEDIA_CONTROLLER) - int pad_idx; -#endif - int ret; + int pad_idx, ret; v4l2_set_subdev_hostdata(sd, vin); @@ -821,7 +818,6 @@ int rvin_v4l2_probe(struct rvin_dev *vin) V4L2_CAP_READWRITE; vin->src_pad_idx = 0; -#if defined(CONFIG_MEDIA_CONTROLLER) for (pad_idx = 0; pad_idx < sd->entity.num_pads; pad_idx++) if (sd->entity.pads[pad_idx].flags == MEDIA_PAD_FL_SOURCE) break; @@ -829,7 +825,6 @@ int rvin_v4l2_probe(struct rvin_dev *vin) return -EINVAL; vin->src_pad_idx = pad_idx; -#endif fmt.pad = vin->src_pad_idx; /* Try to improve our guess of a reasonable window format */ -- 2.9.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
[PATCHv2 14/16] [media] rcar-vin: add shared subdevice groups
This is done to prepare for Gen3 support where there are more than one subdevice and the usage of them are complex and can be shared between multiple rcar-vin instances. There are a few trouble areas with Gen3 that needs to be solved in order to be able to capture video. 1. There can be up to 4 CSI-2 sources, CSI20, CSI21, CSI40 and CSI41. Each CSI-2 source can be used simultaneously by more then one VIN instance, as shown below. This requires that more then one rcar-vin instance be able to to use the same set of subdevices at the same time. 2. There can be up to 8 VIN instances, VIN0-VIN7. Each instance can capture video simultaneous as any other instance, but they are not fully independent of each other. There is one register which controls what input source is used that is only present in VIN0 and VIN4. The register in VIN0 controls input source for VIN0-VIN3 and the register in VIN4 input source for VIN4-7. To further complicate input selection it is not possible to independently select an input for a specific VIN instance, the whole group of VIN0-3 or VIN4-7 are needs to be set according to these predetermined selections. - VIN0-3 controlled by chsel bits in VnCSI_IFMD register in VIN0 chselVIN0VIN1VIN2VIN3 0CSI40/VC0 CSI20/VC0 CSI21/VC0 CSI40/VC1 1CSI20/VC0 CSI21/VC0 CSI40/VC0 CSI20/VC1 2CSI21/VC0 CSI40/VC0 CSI20/VC0 CSI21/VC1 3CSI40/VC0 CSI40/VC1 CSI40/VC2 CSI40/VC3 4CSI20/VC0 CSI20/VC1 CSI20/VC2 CSI20/VC3 5CSI21/VC0 CSI21/VC1 CSI21/VC2 CSI21/VC3 - VIN4-7 controlled by chsel bits in VnCSI_IFMD register in VIN4 chselVIN4VIN5VIN6VIN7 0CSI41/VC0 CSI20/VC0 CSI21/VC0 CSI41/VC1 1CSI20/VC0 CSI21/VC0 CSI41/VC0 CSI20/VC1 2CSI21/VC0 CSI41/VC0 CSI20/VC0 CSI21/VC1 3CSI41/VC0 CSI41/VC1 CSI41/VC2 CSI41/VC3 4CSI20/VC0 CSI20/VC1 CSI20/VC2 CSI20/VC3 5CSI21/VC0 CSI21/VC1 CSI21/VC2 CSI21/VC3 3. Some VIN instances (VIN4 and VIN5) can in addition the shared CSI-2 sources described above have access to a private digital input channel. This patch tries to solve this problem by adding a group concept to the rcar-vin driver. One VIN instance is in DT described to be the group master. It can be any VIN node but preferably it should be VIN0 or VIN4 since at lest one of those nodes are required to control the chsel bits. To allow CSI-2 input for VIN0-3 the VIN0 node must be present and the same is true for VIN4-7 and VIN4. One can even have two separate groups one for VIN0-3 and one for VIN4-7 provided the two groups don't want to share a CSI-2 input source. Each rcar-vin instance will register itself as a v4l2 subdevice in addition to a video device. This subdevice serves a few purposes: 1. Allow for the group master to find all rcar-vin members of its group and bind them. 2. Allow for the group master to control the chsel bits using the only operation implemented on the subdevice, s_gpio. This operation is only valid for VIN0 and VIN4 instances of rcar-vin. 3. Allow for the slave rcar-vin members to access the group API exposed by the master by use of the subdevice v4l2_dev pointer. The master rcar-vin instance will bind to all subdevices needed by the group. That is all the rcar-vin slave nodes, CSI-2 nodes and the video source subdevices which is connected to the other end of the CSI-2 nodes. It will expose an API to the slave nodes by setting the subdevice v4l2_dev pointer. The group API exposed by the master allows each slave rcar-vin instance to operate on the correct set of subdevices for the current chsel value simply by using the operation rvin_subdev_call() instead of v4l2_subdev_call(). There is one special case for the operations involved in input enumeration (g_input_status, g_tvnorms, dv_timings_cap and *enum_dv_timings), where an extension is made v4l2_subdev_call_input() which allows for the slave to specify which of its inputs it wish to operate on. Inside the group API there is refcounting keeping track of s_power and s_stream calls so they are not called multiple times for the same set of subdevices. This is needed since more then one rcar-vin slave can view the same input. The second instance will simply join an ongoing stream. Each rcar-vin slave can request for the input to be changed (chsel value) for its subgroup (VIN0-3 or VIN4-7). But there are a few restrictions on if the input changed is allowed. These restrictions exist to prevent one rcar-vin instance from pulling the rug from another. 1. It is only allowed to change input if the request is coming from a sole user of the subgroup. That is to say if there is exactly one open video device in the subgroup (the one requesting the input change). Multiple opens
[PATCHv2 01/16] media: entity: Add has_route entity operation
From: Laurent Pinchart
The optional operation can be used by entities to report whether two
pads are internally connected.
Signed-off-by: Laurent Pinchart
Signed-off-by: Michal Simek
Signed-off-by: Niklas Söderlund
---
include/media/media-entity.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index cbb266f..c4b2dca 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -179,6 +179,9 @@ struct media_pad {
* @link_validate: Return whether a link is valid from the entity point of
* view. The media_entity_pipeline_start() function
* validates all links by calling this operation. Optional.
+ * @has_route: Return whether a route exists inside the entity between
+ * two given pads. Optional. If the operation isn't
+ * implemented all pads will be considered as connected.
*
* Note: Those these callbacks are called with struct media_device.@graph_mutex
* mutex held.
@@ -188,6 +191,8 @@ struct media_entity_operations {
const struct media_pad *local,
const struct media_pad *remote, u32 flags);
int (*link_validate)(struct media_link *link);
+ bool (*has_route)(struct media_entity *entity, unsigned int pad0,
+ unsigned int pad1);
};
/**
--
2.9.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
[PATCHv2 02/16] media: entity: Add media_entity_has_route() function
From: Laurent Pinchart
This is a wrapper around the media entity has_route operation.
Signed-off-by: Laurent Pinchart
Signed-off-by: Michal Simek
Signed-off-by: Niklas Söderlund
---
drivers/media/media-entity.c | 29 +
include/media/media-entity.h | 3 +++
2 files changed, 32 insertions(+)
diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index d8a2299..8732579 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -240,6 +240,35 @@ EXPORT_SYMBOL_GPL(media_entity_pads_init);
* Graph traversal
*/
+/**
+ * media_entity_has_route - Check if two entity pads are connected internally
+ * @entity: The entity
+ * @pad0: The first pad index
+ * @pad1: The second pad index
+ *
+ * This function can be used to check whether two pads of an entity are
+ * connected internally in the entity.
+ *
+ * The caller must hold entity->source->parent->mutex.
+ *
+ * Return: true if the pads are connected internally and false otherwise.
+ */
+bool media_entity_has_route(struct media_entity *entity, unsigned int pad0,
+ unsigned int pad1)
+{
+ if (pad0 >= entity->num_pads || pad1 >= entity->num_pads)
+ return false;
+
+ if (pad0 == pad1)
+ return true;
+
+ if (!entity->ops || !entity->ops->has_route)
+ return true;
+
+ return entity->ops->has_route(entity, pad0, pad1);
+}
+EXPORT_SYMBOL_GPL(media_entity_has_route);
+
static struct media_entity *
media_entity_other(struct media_entity *entity, struct media_link *link)
{
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index c4b2dca..68af160 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -796,6 +796,9 @@ void media_entity_graph_walk_cleanup(struct
media_entity_graph *graph);
*/
void media_entity_put(struct media_entity *entity);
+bool media_entity_has_route(struct media_entity *entity, unsigned int sink,
+ unsigned int source);
+
/**
* media_entity_graph_walk_start - Start walking the media graph at a given
entity
* @graph: Media graph structure that will be used to walk the graph
--
2.9.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
[PATCHv2] [PATCH] [media] rcar-csi2: add Renesas R-Car MIPI CSI-2 driver
Hi all, This patch adds support for the R-Car MIPI CSI-2 interface. And is based on top of the media_tree. Changes since v1: - Drop dependency on a pad aware s_stream operation. - Use the DT bindings format "renesas,-", thanks Geert for pointing this out. Niklas Söderlund (1): [media] rcar-csi2: add Renesas R-Car MIPI CSI-2 driver .../devicetree/bindings/media/rcar-csi2.txt| 79 +++ drivers/media/platform/rcar-vin/Kconfig| 11 + drivers/media/platform/rcar-vin/Makefile | 2 + drivers/media/platform/rcar-vin/rcar-csi2.c| 544 + 4 files changed, 636 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/rcar-csi2.txt create mode 100644 drivers/media/platform/rcar-vin/rcar-csi2.c -- 2.9.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
[PATCHv2] [media] rcar-csi2: add Renesas R-Car MIPI CSI-2 driver
A V4L2 driver for Renesas R-Car MIPI CSI-2 interface. The driver
supports the rcar-vin driver on R-Car Gen3 SoCs where a separate driver
is needed to receive CSI-2.
Driver is based on a prototype by Koji Matsuoka in the Renesas BSP.
Signed-off-by: Niklas Söderlund
---
.../devicetree/bindings/media/rcar-csi2.txt| 79 +++
drivers/media/platform/rcar-vin/Kconfig| 11 +
drivers/media/platform/rcar-vin/Makefile | 2 +
drivers/media/platform/rcar-vin/rcar-csi2.c| 544 +
4 files changed, 636 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/rcar-csi2.txt
create mode 100644 drivers/media/platform/rcar-vin/rcar-csi2.c
diff --git a/Documentation/devicetree/bindings/media/rcar-csi2.txt
b/Documentation/devicetree/bindings/media/rcar-csi2.txt
new file mode 100644
index 000..0dc40c19
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/rcar-csi2.txt
@@ -0,0 +1,79 @@
+Renesas R-Car MIPI CSI-2 driver (rcar-csi2)
+---
+
+The rcar-csi2 device provides MIPI CSI-2 capabilities for the Renesas R-Car
+family of devices. It is to be used in conjunction with the rcar-vin driver
which
+provides the video input capabilities.
+
+ - compatible: Must be one or more of the following
+ - "renesas,r8a7795-csi2" for the R8A7795 device
+ - "renesas,rcar-gen3-csi2" for a generic R-Car Gen3 compatible device.
+
+ When compatible with the generic version nodes must list the
+ SoC-specific version corresponding to the platform first
+ followed by the generic version.
+
+ - reg: the register base and size for the device registers
+ - interrupts: the interrupt for the device
+ - clocks: Reference to the parent clock
+
+The device node should contain two 'port' child nodes with one child 'endpoint'
+node, according to the bindings defined in Documentation/devicetree/bindings/
+media/video-interfaces.txt. Port 0 should connect the device that is the CSI-2
+producer. Port 1 should connect the R-Car VIN device (rcar-vin) consumer.
+
+ - ports:
+ - port@0: sub-node describing a endpoint to the CSI-2 source
+ - port@1: sub-node describing a endpoint to the VIN consumer
+
+Additionally, an alias named csiX will need to be created to specify
+which CSI-2 device this is.
+
+Example:
+
+/* SoC properties */
+
+ aliases {
+ csi40 = &csi40;
+ };
+
+ csi40: csi2@feaa {
+ compatible = "renesas,r8a7795-csi2";
+ reg = <0 0xfeaa 0 0x1>;
+ interrupts = <0 246 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 716>;
+ power-domains = <&cpg>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+ csi40_out: endpoint@1 {
+ remote-endpoint = <&vin0csi40>;
+ };
+ };
+ };
+ };
+
+/* Board properties */
+
+ &csi40 {
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ csi40_in: endpoint@0 {
+ clock-lanes = <0>;
+ data-lanes = <1 2 3 4>;
+ remote-endpoint = <&adv7482_1_out>;
+ };
+ };
+ };
+ };
diff --git a/drivers/media/platform/rcar-vin/Kconfig
b/drivers/media/platform/rcar-vin/Kconfig
index b2ff2d4..e0774ee 100644
--- a/drivers/media/platform/rcar-vin/Kconfig
+++ b/drivers/media/platform/rcar-vin/Kconfig
@@ -9,3 +9,14 @@ config VIDEO_RCAR_VIN
To compile this driver as a module, choose M here: the
module will be called rcar-vin.
+
+config VIDEO_RCAR_CSI2
+ tristate "R-Car MIPI CSI-2 Interface driver"
+ depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF
+ depends on ARCH_RENESAS || COMPILE_TEST
+ ---help---
+ Support for Renesas R-Car MIPI CSI-2 interface driver.
+ Supports R-Car Gen3 SoCs.
+
+ To compile this driver as a module, choose M here: the
+ module will be called rcar-csi2.
diff --git a/drivers/media/platform/rcar-vin/Makefile
b/drivers/media/platform/rcar-vin/Makefile
index 48c5632..81a37f2 100644
--- a/drivers/media/platform/rcar-vin/Makefile
+++ b/drivers/media/platform/rcar-vin/Makefile
@@ -1,3 +1,5 @@
rcar-vin-objs = rcar-core.o rcar-dma.o rcar-v4l2.o
obj-$(CONFIG_VIDEO_RCAR_VIN) += rcar-vin.o
+
+obj-$(CONFIG_VIDEO_RCAR_CSI2) += rcar-csi2.o
diff --git a/drivers/media/platform/rcar-vin/rcar-csi2.c
b/drivers/
Re: [PATCH 00/18] Complete moving media documentation to ReST format
Am 19.07.2016 um 13:12 schrieb Mauro Carvalho Chehab : > Em Tue, 19 Jul 2016 11:19:11 +0200 > Hans Verkuil escreveu: > >>> All those documents are built automatically, once by day, at linuxtv.org: >>> >>> uAPI: >>> https://linuxtv.org/downloads/v4l-dvb-apis-new/media/media_uapi.html >> >> Erm, there is nothing there, only the top-level menu. > > Gah! The problem is due to the Sphinx version. I added a patch yesterday > adding a caption to each book's toctree. This doesn't work with the > Sphinx version at the server (1.2.3). Instead of ignoring the option, > Sphinx decided to just drop the entire tag, with actually means to > drop all media pages! > > I really hate stupid toolchains that require everybody to upgrade to > the very latest version of it every time. Hi Mauro, It might be annoying how sphinx handles errors, but normally a build process should report errors to monitor. > Maybe someone at linux-doc > may have an idea about how to add new markup attributes to the > documents without breaking for the ones using older versions of Sphinx. see below > The problem we're facing is due to a change meant to add a title before > each media's table of contents (provided via :toctree: markup). I think this is only ONE drawback, others see the changelog .. * http://www.sphinx-doc.org/en/stable/changes.html > All it needs is something that will be translated to HTML as: > Table of contents, without the need of creating any cross > reference, nor being added to the main TOC at Documentation/index.rst. > > We can't simply use the normal way to generate tags: > > --- a/Documentation/media/dvb-drivers/index.rst > +++ b/Documentation/media/dvb-drivers/index.rst > @@ -15,6 +15,10 @@ the license is included in the chapter entitled "GNU Free > Documentation > License". > > > +# > +FOO Table of contents > +# > + > .. toctree:: > :maxdepth: 5 > :numbered: > > The page itself would look OK, but this would produce a new entry at the > output/html/index.html: > > * Linux Digital TV driver-specific documentation > * FOO Table of contents > > 1. Introdution > > With is not what we want. > > With Sphinx 1.4.5, the way of doing that is to add a :caption: tag > to the toctree, but this tag doesn't exist on 1.2.x. Also, as it > also convert captions on references, and all books are linked > together at Documentation/index.rst, it also needs a :name: tag, > in order to avoid warnings about duplicated tags when building the > main index.rst. > > I have no idea about how to do that in a backward-compatible way. > > Maybe Markus, Jani or someone else at linux-doc may have some > glue. IMHO: A backward-compatible way for all linux distros and versions out there is not the way. If we use options or features of a new version, we have to install the new version (independent which xml we used in the past or python tool we want to use). IMHO the main problem is, that we have not yet documented on which Sphinx version we agree and how to get a build environment which fullfills these requirements. For build environments I recommend to set up a python virtualenv * https://virtualenv.pypa.io/en/stable/ Additional: At this time, the make file only checks if sphinx is installed. With a small addition to the make file, we could check if all requirements are fulfilled. If you are interested in how, I could send a patch. -- Markus -- > In the mean time, I attached a patch that the server applies before > building the documentation. > > > Thanks, > Mauro > > doc-rst: Don't use :caption: or :name: tags for media documents > > If Sphinx version is lower than 1.4.x (I tested with 1.4.5), this patch > is needed for it to build, as otherwise Sphinx will ignore the toctable > markups and won't build the media documentation, creating just an > empty page. > > Signed-off-by: Mauro Carvalho Chehab > > diff --git a/Documentation/media/dvb-drivers/index.rst > b/Documentation/media/dvb-drivers/index.rst > index e1d4d87f2a47..0e065533beb6 100644 > --- a/Documentation/media/dvb-drivers/index.rst > +++ b/Documentation/media/dvb-drivers/index.rst > @@ -18,8 +18,6 @@ License". > .. toctree:: > :maxdepth: 5 > :numbered: > - :caption: Table of Contents > - :name: dvb_mastertoc > > intro > avermedia > diff --git a/Documentation/media/media_kapi.rst > b/Documentation/media/media_kapi.rst > index 0af80e90b7b5..556c0eb55c85 100644 > --- a/Documentation/media/media_kapi.rst > +++ b/Documentation/media/media_kapi.rst > @@ -17,8 +17,6 @@ License". > .. toctree:: > :maxdepth: 5 > :numbered: > -:caption: Table of Contents > -:name: kapi_mastertoc > > kapi/v4l2-framework > kapi/v4l2-controls > diff --git a/Documentation/media/media_uapi.rst > b/Documentation/media/media_uapi.rst > index debe4531040b..aae8124defcc 100644 > --- a/Documentation/media/media_uapi.rst > +++ b/Documentation/me
Re: [PATCH] v4l: platform: Add Renesas R-Car FDP1 Driver
Hi Kieran, Hmm, I don't think I ever reviewed this one. So here is my quick review: General note: I need to see the v4l2-compliance output. Make sure you run with the latest version from v4l-utils. On 06/30/16 15:41, Kieran Bingham wrote: > The FDP1 driver performs advanced de-interlacing on a memory 2 memory > based video stream, and supports conversion from YCbCr/YUV > to RGB pixel formats > > Signed-off-by: Kieran Bingham > --- > MAINTAINERS|9 + > drivers/media/platform/Kconfig | 13 + > drivers/media/platform/Makefile|1 + > drivers/media/platform/rcar_fdp1.c | 2395 > > 4 files changed, 2418 insertions(+) > create mode 100644 drivers/media/platform/rcar_fdp1.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index eb5e3b673c1d..985d243ff066 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -7331,6 +7331,15 @@ F: > Documentation/devicetree/bindings/media/renesas,fcp.txt > F: drivers/media/platform/rcar-fcp.c > F: include/media/rcar-fcp.h > > +MEDIA DRIVERS FOR RENESAS - FDP1 > +M: Kieran Bingham > +L: linux-media@vger.kernel.org > +L: linux-renesas-...@vger.kernel.org > +T: git git://linuxtv.org/media_tree.git > +S: Supported > +F: Documentation/devicetree/bindings/media/renesas,fdp1.txt > +F: drivers/media/platform/rcar_fdp1.c > + > MEDIA DRIVERS FOR RENESAS - VSP1 > M: Laurent Pinchart > L: linux-media@vger.kernel.org > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig > index 0141af8cfdbc..80cdc3b6efa3 100644 > --- a/drivers/media/platform/Kconfig > +++ b/drivers/media/platform/Kconfig > @@ -235,6 +235,19 @@ config VIDEO_SH_VEU > Support for the Video Engine Unit (VEU) on SuperH and > SH-Mobile SoCs. > > +config VIDEO_RENESAS_FDP1 > + tristate "Renesas Fine Display Processor" > + depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA > + depends on ARCH_SHMOBILE || COMPILE_TEST > + select VIDEOBUF2_DMA_CONTIG > + select V4L2_MEM2MEM_DEV > + ---help--- > + This is a V4L2 driver for the Renesas Fine Display Processor > + providing colour space conversion, and de-interlacing features. > + > + To compile this driver as a module, choose M here: the module > + will be called rcar_fdp1. > + > config VIDEO_RENESAS_JPU > tristate "Renesas JPEG Processing Unit" > depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA > diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile > index befc4f97057c..0c8a3ae7b6cb 100644 > --- a/drivers/media/platform/Makefile > +++ b/drivers/media/platform/Makefile > @@ -47,6 +47,7 @@ obj-$(CONFIG_VIDEO_SH_VOU) += sh_vou.o > obj-$(CONFIG_SOC_CAMERA) += soc_camera/ > > obj-$(CONFIG_VIDEO_RENESAS_FCP) += rcar-fcp.o > +obj-$(CONFIG_VIDEO_RENESAS_FDP1) += rcar_fdp1.o > obj-$(CONFIG_VIDEO_RENESAS_JPU) += rcar_jpu.o > obj-$(CONFIG_VIDEO_RENESAS_VSP1) += vsp1/ > > diff --git a/drivers/media/platform/rcar_fdp1.c > b/drivers/media/platform/rcar_fdp1.c > new file mode 100644 > index ..c7280183262a > --- /dev/null > +++ b/drivers/media/platform/rcar_fdp1.c > @@ -0,0 +1,2395 @@ > +/* > + * Renesas RCar Fine Display Processor > + * > + * Video format converter and frame deinterlacer device. > + * > + * Author: Kieran Bingham, > + * Copyright (c) 2016 Renesas Electronics Corporation. > + * > + * This code is developed and inspired from the vim2m, rcar_jpu, > + * m2m-deinterlace, and vsp1 drivers. > + * > + * 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 > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +static unsigned int debug; > +module_param(debug, uint, 0644); > +MODULE_PARM_DESC(debug, "activate debug info"); > + > +/* Min Width/Height/Height-Field */ > +#define FDP1_MIN_W 80U > +#define FDP1_MIN_H 80U > + > +#define FDP1_MAX_W 3840U > +#define FDP1_MAX_H 2160U > + > +#define FDP1_MAX_PLANES 3U > + > +/* Flags that indicate a format can be used for capture/output */ > +#define FDP1_CAPTURE BIT(0) > +#define FDP1_OUTPUT BIT(1) > + > +#define DRIVER_NAME "rcar_fdp1" > + > +/* Number of Job's to have available on the processing queue */ > +#define FDP1_NUMBER_JOBS 8 > +#define FDP1_NUMBER_BUFFERS ((FDP1_NUMBER_JOBS*2)+1) > + > +#define dprintk(fdp1, fmt, arg...) \ > + v4l2_dbg(1, debug, &fdp1->v4l2_dev, "%s: " fmt, __func__, ## arg) > + > +/* > + * FDP1 registers and bits > + */ > + > +
Re: [PATCH] [media] fdp1: vb2_queue dev conversion
Thanks Geert,
That looks good to me.
I'll fold in to my existing patch.
--
Regards
Kieran
On 19/07/16 12:51, Geert Uytterhoeven wrote:
> drivers/media/platform/rcar_fdp1.c:1972:2: warning: initialization from
> incompatible pointer type
> .queue_setup = fdp1_queue_setup,
> ^
> drivers/media/platform/rcar_fdp1.c:1972:2: warning: (near initialization
> for 'fdp1_qops.queue_setup')
> drivers/media/platform/rcar_fdp1.c: In function 'fdp1_probe':
> drivers/media/platform/rcar_fdp1.c:2264:2: error: implicit declaration of
> function 'vb2_dma_contig_init_ctx' [-Werror=implicit-function-declaration]
> fdp1->alloc_ctx = vb2_dma_contig_init_ctx(&pdev->dev);
> ^
> drivers/media/platform/rcar_fdp1.c:2264:18: warning: assignment makes
> pointer from integer without a cast
> fdp1->alloc_ctx = vb2_dma_contig_init_ctx(&pdev->dev);
> ^
> drivers/media/platform/rcar_fdp1.c:2331:2: error: implicit declaration of
> function 'vb2_dma_contig_cleanup_ctx' [-Werror=implicit-function-declaration]
> vb2_dma_contig_cleanup_ctx(fdp1->alloc_ctx);
> ^
>
> Commit 36c0f8b32c4bd4f6 ("[media] vb2: replace void *alloc_ctxs by
> struct device *alloc_devs") removed the vb2_dma_contig_init_ctx() and
> vb2_dma_contig_cleanup_ctx() functions, and changed the prototype of
> vb2_ops.queue_setup().
>
> To fix this:
> - Update the signature of fdp1_queue_setup(),
> - Convert the FDP1 driver to use the new vb2_queue dev field, cfr.
> commit 53ddcc683faef8c7 ("[media] media/platform: convert drivers to
> use the new vb2_queue dev field").
>
> Signed-off-by: Geert Uytterhoeven
> ---
> To be folded into "[PATCH v2] v4l: platform: Add Renesas R-Car FDP1
> Driver".
> ---
> drivers/media/platform/rcar_fdp1.c | 26 ++
> 1 file changed, 6 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/media/platform/rcar_fdp1.c
> b/drivers/media/platform/rcar_fdp1.c
> index c7280183262a3046..a2587745ca68dedb 100644
> --- a/drivers/media/platform/rcar_fdp1.c
> +++ b/drivers/media/platform/rcar_fdp1.c
> @@ -570,7 +570,6 @@ struct fdp1_dev {
> void __iomem*regs;
> unsigned intirq;
> struct device *dev;
> - void*alloc_ctx;
>
> /* Job Queues */
> struct fdp1_job jobs[FDP1_NUMBER_JOBS];
> @@ -1788,7 +1787,8 @@ static const struct v4l2_ioctl_ops fdp1_ioctl_ops = {
>
> static int fdp1_queue_setup(struct vb2_queue *vq,
> unsigned int *nbuffers, unsigned int *nplanes,
> - unsigned int sizes[], void *alloc_ctxs[])
> + unsigned int sizes[],
> + struct device *alloc_ctxs[])
> {
> struct fdp1_ctx *ctx = vb2_get_drv_priv(vq);
> struct fdp1_q_data *q_data;
> @@ -1800,18 +1800,13 @@ static int fdp1_queue_setup(struct vb2_queue *vq,
> if (*nplanes > FDP1_MAX_PLANES)
> return -EINVAL;
>
> - for (i = 0; i < *nplanes; i++)
> - alloc_ctxs[i] = ctx->fdp1->alloc_ctx;
> -
> return 0;
> }
>
> *nplanes = q_data->format.num_planes;
>
> - for (i = 0; i < *nplanes; i++) {
> + for (i = 0; i < *nplanes; i++)
> sizes[i] = q_data->format.plane_fmt[i].sizeimage;
> - alloc_ctxs[i] = ctx->fdp1->alloc_ctx;
> - }
>
> return 0;
> }
> @@ -1992,6 +1987,7 @@ static int queue_init(void *priv, struct vb2_queue
> *src_vq,
> src_vq->mem_ops = &vb2_dma_contig_memops;
> src_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
> src_vq->lock = &ctx->fdp1->dev_mutex;
> + src_vq->dev = ctx->fdp1->dev;
>
> ret = vb2_queue_init(src_vq);
> if (ret)
> @@ -2005,6 +2001,7 @@ static int queue_init(void *priv, struct vb2_queue
> *src_vq,
> dst_vq->mem_ops = &vb2_dma_contig_memops;
> dst_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
> dst_vq->lock = &ctx->fdp1->dev_mutex;
> + dst_vq->dev = ctx->fdp1->dev;
>
> return vb2_queue_init(dst_vq);
> }
> @@ -2260,18 +2257,11 @@ static int fdp1_probe(struct platform_device *pdev)
> fdp1->clk_rate = clk_get_rate(clk);
> clk_put(clk);
>
> - /* Memory allocation contexts */
> - fdp1->alloc_ctx = vb2_dma_contig_init_ctx(&pdev->dev);
> - if (IS_ERR(fdp1->alloc_ctx)) {
> - v4l2_err(&fdp1->v4l2_dev, "Failed to init memory allocator\n");
> - return PTR_ERR(fdp1->alloc_ctx);
> - }
> -
> /* V4L2 device registration */
> ret = v4l2_device_register(&pdev->dev, &fdp1->v4l2_dev);
> if (ret) {
> v4l2_err(&fdp1->v4l2_dev, "Failed to register video device\n");
> - goto vb2_allocator_rollback;
> + return ret;
> }
>
> /* M2M registration */
> @@ -2327,9 +2317,6 @@ release_m2m:
> unreg_dev:
> v4l2_d
[PATCH] [media] fdp1: vb2_queue dev conversion
drivers/media/platform/rcar_fdp1.c:1972:2: warning: initialization from
incompatible pointer type
.queue_setup = fdp1_queue_setup,
^
drivers/media/platform/rcar_fdp1.c:1972:2: warning: (near initialization
for 'fdp1_qops.queue_setup')
drivers/media/platform/rcar_fdp1.c: In function 'fdp1_probe':
drivers/media/platform/rcar_fdp1.c:2264:2: error: implicit declaration of
function 'vb2_dma_contig_init_ctx' [-Werror=implicit-function-declaration]
fdp1->alloc_ctx = vb2_dma_contig_init_ctx(&pdev->dev);
^
drivers/media/platform/rcar_fdp1.c:2264:18: warning: assignment makes
pointer from integer without a cast
fdp1->alloc_ctx = vb2_dma_contig_init_ctx(&pdev->dev);
^
drivers/media/platform/rcar_fdp1.c:2331:2: error: implicit declaration of
function 'vb2_dma_contig_cleanup_ctx' [-Werror=implicit-function-declaration]
vb2_dma_contig_cleanup_ctx(fdp1->alloc_ctx);
^
Commit 36c0f8b32c4bd4f6 ("[media] vb2: replace void *alloc_ctxs by
struct device *alloc_devs") removed the vb2_dma_contig_init_ctx() and
vb2_dma_contig_cleanup_ctx() functions, and changed the prototype of
vb2_ops.queue_setup().
To fix this:
- Update the signature of fdp1_queue_setup(),
- Convert the FDP1 driver to use the new vb2_queue dev field, cfr.
commit 53ddcc683faef8c7 ("[media] media/platform: convert drivers to
use the new vb2_queue dev field").
Signed-off-by: Geert Uytterhoeven
---
To be folded into "[PATCH v2] v4l: platform: Add Renesas R-Car FDP1
Driver".
---
drivers/media/platform/rcar_fdp1.c | 26 ++
1 file changed, 6 insertions(+), 20 deletions(-)
diff --git a/drivers/media/platform/rcar_fdp1.c
b/drivers/media/platform/rcar_fdp1.c
index c7280183262a3046..a2587745ca68dedb 100644
--- a/drivers/media/platform/rcar_fdp1.c
+++ b/drivers/media/platform/rcar_fdp1.c
@@ -570,7 +570,6 @@ struct fdp1_dev {
void __iomem*regs;
unsigned intirq;
struct device *dev;
- void*alloc_ctx;
/* Job Queues */
struct fdp1_job jobs[FDP1_NUMBER_JOBS];
@@ -1788,7 +1787,8 @@ static const struct v4l2_ioctl_ops fdp1_ioctl_ops = {
static int fdp1_queue_setup(struct vb2_queue *vq,
unsigned int *nbuffers, unsigned int *nplanes,
- unsigned int sizes[], void *alloc_ctxs[])
+ unsigned int sizes[],
+ struct device *alloc_ctxs[])
{
struct fdp1_ctx *ctx = vb2_get_drv_priv(vq);
struct fdp1_q_data *q_data;
@@ -1800,18 +1800,13 @@ static int fdp1_queue_setup(struct vb2_queue *vq,
if (*nplanes > FDP1_MAX_PLANES)
return -EINVAL;
- for (i = 0; i < *nplanes; i++)
- alloc_ctxs[i] = ctx->fdp1->alloc_ctx;
-
return 0;
}
*nplanes = q_data->format.num_planes;
- for (i = 0; i < *nplanes; i++) {
+ for (i = 0; i < *nplanes; i++)
sizes[i] = q_data->format.plane_fmt[i].sizeimage;
- alloc_ctxs[i] = ctx->fdp1->alloc_ctx;
- }
return 0;
}
@@ -1992,6 +1987,7 @@ static int queue_init(void *priv, struct vb2_queue
*src_vq,
src_vq->mem_ops = &vb2_dma_contig_memops;
src_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
src_vq->lock = &ctx->fdp1->dev_mutex;
+ src_vq->dev = ctx->fdp1->dev;
ret = vb2_queue_init(src_vq);
if (ret)
@@ -2005,6 +2001,7 @@ static int queue_init(void *priv, struct vb2_queue
*src_vq,
dst_vq->mem_ops = &vb2_dma_contig_memops;
dst_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
dst_vq->lock = &ctx->fdp1->dev_mutex;
+ dst_vq->dev = ctx->fdp1->dev;
return vb2_queue_init(dst_vq);
}
@@ -2260,18 +2257,11 @@ static int fdp1_probe(struct platform_device *pdev)
fdp1->clk_rate = clk_get_rate(clk);
clk_put(clk);
- /* Memory allocation contexts */
- fdp1->alloc_ctx = vb2_dma_contig_init_ctx(&pdev->dev);
- if (IS_ERR(fdp1->alloc_ctx)) {
- v4l2_err(&fdp1->v4l2_dev, "Failed to init memory allocator\n");
- return PTR_ERR(fdp1->alloc_ctx);
- }
-
/* V4L2 device registration */
ret = v4l2_device_register(&pdev->dev, &fdp1->v4l2_dev);
if (ret) {
v4l2_err(&fdp1->v4l2_dev, "Failed to register video device\n");
- goto vb2_allocator_rollback;
+ return ret;
}
/* M2M registration */
@@ -2327,9 +2317,6 @@ release_m2m:
unreg_dev:
v4l2_device_unregister(&fdp1->v4l2_dev);
-vb2_allocator_rollback:
- vb2_dma_contig_cleanup_ctx(fdp1->alloc_ctx);
-
return ret;
}
@@ -2340,7 +2327,6 @@ static int fdp1_remove(struct platform_device *pdev)
v4l2_m2m_release(fdp1->m2m_dev);
video_unregi
Re: [RFC 00/16] Make use of kref in media device, grab references as needed
Em Tue, 19 Jul 2016 10:27:47 +0300 Sakari Ailus escreveu: > Hi Mauro, > > Thank you for your reply. > > Mauro Carvalho Chehab wrote: > > Em Fri, 15 Jul 2016 01:34:55 +0300 > > Sakari Ailus escreveu: > > > >> Hi folks, > >> > >> I've been working on this for some time now but only got the full patchset > >> working some moments ago. The patchset properly, I believe, fixes the > >> issue of removing a device whilst streaming. > >> > >> Media device is refcounted and its memory is only released once the last > >> reference is gone: unregistering is simply unregistering, it no longer > >> should release memory which could be further accessed. > >> > >> A video node or a sub-device node also gets a reference to the media > >> device, i.e. the release function of the video device node will release > >> its reference to the media device. The same goes for file handles to the > >> media device. > >> > >> As a side effect of refcounting the media device, it is allocate together > >> with the media devnode. The driver may also rely its own resources to the > >> media device. Alternatively there's also a priv field to hold drivers > >> private pointer (for container_of() is an option in this case). > >> > >> I've tested this by manually unbinding the omap3isp platform device while > >> streaming. Driver changes are required for this to work; by not using > >> dynamic allocation (i.e. media_device_alloc()) the old behaviour is still > >> supported. This is still unlikely to be a grave problem as there are not > >> that many device drivers that support physically removable devices. We've > >> had this problem for other devices for many years without paying much > >> notice --- that doesn't mean I don't think at least drivers for removable > >> devices shouldn't be changed as part of the set later on, I'd just like to > >> get review comments on the approach first. > >> > >> The three patches that originally partially resolved some of these issues > >> are reverted in the beginning of the set. I'm still posting this as an RFC > >> mainly since the testing is somewhat limited so far. > > > > > > I didn't look inside this patch series. Won't likely have time to > > look at core changes before the end of the merge window. However, > > I found several structural problems on this RFC: > > > > 1) Please do incremental changes, instead of reverting patches. It is > > really hard for reviewers to be sure that nothing breaks when someone > > simply reverts a previous approach and add its own. > > I believe people are more familiar with the state of the code with the > reverts than without them. What people are more familiar depends on what each person knows and when he lastly looked at the code. Kernel's policy is to not build patches based on what you think the others know, but, instead, we develop stuff incrementally. So, if you want such patch series to be reviewed and merged, you should apply incremental changes, not destroy everything before applying your stuff, because your work were based on a past version. Btw, one of the things I'm missing on this series is what's the problem you're still facing with the upstream version, as you didn't add any descripton and OOPSes that you're noticing upstream. Anyone reviewing this series would need to be able to reproduce such problem, and add to their existing test case scenarios, to be sure that the solution won't cause regressions to their own scenarios and will solve for yours. > The first two reverted patches I don't really > have a problem with, but they depend on the third reverted patch which > is more problematic and they'll no longer be needed afterwards. To > refresh our memory: > > http://www.spinics.net/lists/linux-media/msg100355.html> > http://www.spinics.net/lists/linux-media/msg100927.html> > http://www.spinics.net/lists/linux-media/msg100952.html> > > > > > 2) Each individual patch should not cause regressions to none of > > the existing drivers or to the core. The revert re-introduces bugs. > > We've had the problem for five years without even realising it. What's > merged now is a workaround that avoids *some* of the underlying problems. I don't doubt that there are still underlying problems. Making a race-free solution for the drivers bind/unbind scenario is not trivial. Yet, as I said before, we need not only the patches but the scenarios you're testing, for us to be able to reproduce your problem and verify that your solution solves it, without causing regressions to other test scenarios. > With the current media-master, the system still crashes if the device is > removed during video streaming. With this set (and appropriate driver > changes) it does not. Driver changes alone are not enough to fix this > either. The best way to test such scenario would be, IMHO, to add patches for some USB driver, like uvcvideo or au0828, as, there you can actually physically remove the hardware while streaming. One problem with OMAP3 driver is
[PATCH -next] [media] staging: media: lirc: add missing platform_device_del() on error in lirc_parallel_init()
From: Wei Yongjun
Add the missing platform_device_del() before return from
lirc_parallel_init() in the error handling case.
Signed-off-by: Wei Yongjun
---
drivers/staging/media/lirc/lirc_parallel.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/media/lirc/lirc_parallel.c
b/drivers/staging/media/lirc/lirc_parallel.c
index 3906ac6..878fdea 100644
--- a/drivers/staging/media/lirc/lirc_parallel.c
+++ b/drivers/staging/media/lirc/lirc_parallel.c
@@ -650,7 +650,7 @@ static int __init lirc_parallel_init(void)
if (!pport) {
pr_notice("no port at %x found\n", io);
result = -ENXIO;
- goto exit_device_put;
+ goto exit_device_del;
}
ppdevice = parport_register_device(pport, LIRC_DRIVER_NAME,
pf, kf, lirc_lirc_irq_handler, 0,
@@ -659,7 +659,7 @@ static int __init lirc_parallel_init(void)
if (!ppdevice) {
pr_notice("parport_register_device() failed\n");
result = -ENXIO;
- goto exit_device_put;
+ goto exit_device_del;
}
if (parport_claim(ppdevice) != 0)
goto skip_init;
@@ -678,7 +678,7 @@ static int __init lirc_parallel_init(void)
parport_release(pport);
parport_unregister_device(ppdevice);
result = -EIO;
- goto exit_device_put;
+ goto exit_device_del;
}
#endif
@@ -695,11 +695,13 @@ static int __init lirc_parallel_init(void)
pr_notice("register_chrdev() failed\n");
parport_unregister_device(ppdevice);
result = -EIO;
- goto exit_device_put;
+ goto exit_device_del;
}
pr_info("installed using port 0x%04x irq %d\n", io, irq);
return 0;
+exit_device_del:
+ platform_device_del(lirc_parallel_dev);
exit_device_put:
platform_device_put(lirc_parallel_dev);
exit_driver_unregister:
--
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 00/18] Complete moving media documentation to ReST format
Em Tue, 19 Jul 2016 11:19:11 +0200 Hans Verkuil escreveu: > > All those documents are built automatically, once by day, at linuxtv.org: > > > > uAPI: > > https://linuxtv.org/downloads/v4l-dvb-apis-new/media/media_uapi.html > > Erm, there is nothing there, only the top-level menu. Gah! The problem is due to the Sphinx version. I added a patch yesterday adding a caption to each book's toctree. This doesn't work with the Sphinx version at the server (1.2.3). Instead of ignoring the option, Sphinx decided to just drop the entire tag, with actually means to drop all media pages! I really hate stupid toolchains that require everybody to upgrade to the very latest version of it every time. Maybe someone at linux-doc may have an idea about how to add new markup attributes to the documents without breaking for the ones using older versions of Sphinx. The problem we're facing is due to a change meant to add a title before each media's table of contents (provided via :toctree: markup). All it needs is something that will be translated to HTML as: Table of contents, without the need of creating any cross reference, nor being added to the main TOC at Documentation/index.rst. We can't simply use the normal way to generate tags: --- a/Documentation/media/dvb-drivers/index.rst +++ b/Documentation/media/dvb-drivers/index.rst @@ -15,6 +15,10 @@ the license is included in the chapter entitled "GNU Free Documentation License". +# +FOO Table of contents +# + .. toctree:: :maxdepth: 5 :numbered: The page itself would look OK, but this would produce a new entry at the output/html/index.html: * Linux Digital TV driver-specific documentation * FOO Table of contents 1. Introdution With is not what we want. With Sphinx 1.4.5, the way of doing that is to add a :caption: tag to the toctree, but this tag doesn't exist on 1.2.x. Also, as it also convert captions on references, and all books are linked together at Documentation/index.rst, it also needs a :name: tag, in order to avoid warnings about duplicated tags when building the main index.rst. I have no idea about how to do that in a backward-compatible way. Maybe Markus, Jani or someone else at linux-doc may have some glue. In the mean time, I attached a patch that the server applies before building the documentation. Thanks, Mauro doc-rst: Don't use :caption: or :name: tags for media documents If Sphinx version is lower than 1.4.x (I tested with 1.4.5), this patch is needed for it to build, as otherwise Sphinx will ignore the toctable markups and won't build the media documentation, creating just an empty page. Signed-off-by: Mauro Carvalho Chehab diff --git a/Documentation/media/dvb-drivers/index.rst b/Documentation/media/dvb-drivers/index.rst index e1d4d87f2a47..0e065533beb6 100644 --- a/Documentation/media/dvb-drivers/index.rst +++ b/Documentation/media/dvb-drivers/index.rst @@ -18,8 +18,6 @@ License". .. toctree:: :maxdepth: 5 :numbered: - :caption: Table of Contents - :name: dvb_mastertoc intro avermedia diff --git a/Documentation/media/media_kapi.rst b/Documentation/media/media_kapi.rst index 0af80e90b7b5..556c0eb55c85 100644 --- a/Documentation/media/media_kapi.rst +++ b/Documentation/media/media_kapi.rst @@ -17,8 +17,6 @@ License". .. toctree:: :maxdepth: 5 :numbered: -:caption: Table of Contents -:name: kapi_mastertoc kapi/v4l2-framework kapi/v4l2-controls diff --git a/Documentation/media/media_uapi.rst b/Documentation/media/media_uapi.rst index debe4531040b..aae8124defcc 100644 --- a/Documentation/media/media_uapi.rst +++ b/Documentation/media/media_uapi.rst @@ -17,8 +17,6 @@ License". .. toctree:: :maxdepth: 5 -:caption: Table of Contents -:name: uapi_mastertoc intro uapi/v4l/v4l2 diff --git a/Documentation/media/v4l-drivers/index.rst b/Documentation/media/v4l-drivers/index.rst index 8d1710234e5a..b9c9c0911db9 100644 --- a/Documentation/media/v4l-drivers/index.rst +++ b/Documentation/media/v4l-drivers/index.rst @@ -18,8 +18,6 @@ License". .. toctree:: :maxdepth: 5 :numbered: - :caption: Table of Contents - :name: v4l_mastertoc fourcc v4l-with-ir -- 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: Troubles with kernel-doc and RST files
Am 18.07.2016 um 13:54 schrieb Mauro Carvalho Chehab : > Em Sun, 17 Jul 2016 20:37:19 -0600 > Jonathan Corbet escreveu: > >> [Back home and trying to get going on stuff for real. I'll look at the >> issues listed in this message one at a time.] >> >> On Sun, 17 Jul 2016 10:01:54 -0300 >> Mauro Carvalho Chehab wrote: >> >>> 1) We now need to include each header file with documentation twice, >>> one to get the enums, structs, typedefs, ... and another one for the >>> functions: >>> >>> .. kernel-doc:: include/media/media-device.h >>> >>> .. kernel-doc:: include/media/media-entity.h >>>:export: drivers/media/media-entity.c >> >> So I'm a little confused here; you're including from two different header >> files here. Did you want media-entity.h in both directives? > > Yeah, on my patch I was including every header twice. The first > one to get the structs: > > .. kernel-doc:: include/media/media-device.h > > .. kernel-doc:: include/media/media-devnode.h > > .. kernel-doc:: include/media/media-entity.h > > And the next one to get the functions: > > .. kernel-doc:: include/media/media-device.h > :export: drivers/media/media-device.c > > .. kernel-doc:: include/media/media-entity.h > :export: drivers/media/media-entity.c > > >> If I do a simple test with a single line: >> >> .. kernel-doc:: include/media/media-entity.h >> >> I get everything - structs, functions, etc. - as I would expect. Are you >> seeing something different? > > Weird, now it worked... I noticed this issue because some of the cross > references were broken if I didn't include everything twice, but it > seems that including just one time is enough. Not sure what happened > when I tested it. > >> It probably would be nice to have an option for "data structures, doc >> sections, and exported functions only" at some point. > > Yeah. Well, actually, I ended by moving the doc sections from the > headers, adding them as a separate rst file. This way, I don't have > to workaround on some parsing issues that might happen with kernel-doc > parsing. Also, IMHO, it makes easier to edit and keep it organized. To have an option for "data structures etc." would be nice, but first we should concentrate on the reST produced by kernel-doc and therefor it is recommended to elaborate what we need to build man pages. The man pages request will reveal what need e.g: * using the cpp domain to handle more then one e.g. "ioctl" declaration * structured markup with headers * quoting pointers * ... IMHO yet, the main drawback of the current kernel-doc parser is, that there are no header structures in the reST markup. E.g. the example from Mauro (see below) is one big HTML page with no chapters and sections, thats why there are no links generated in the left navigation bar. These -- and the other request we discussed -- could be done with the kernel-doc perl script, but we will see that it becomes harder and harder to force it through a pipe communication. I wrote a python version of the parser with an API which could cover all theses and future aspects less complicated and more straight forward. I tested this parser by building a complete source tree of documentation: http://return42.github.io/sphkerneldoc/linux_src_doc/index.html and all books (aka DocBooks) http://return42.github.io/sphkerneldoc/#references-to-books I recommend to consider to switch to the python version of the parser. I know, that there is a natural shyness about a reimplementation in python and thats why I offer to support it for a long time period .. it would be a joy for me ;-) If you interested in, I could send a RFC patch for this, if not please give the reasons why not. > Yet, still it could be interesting to be able of putting data structs > on a separate page than the functions. One of the (minor) issues. > What I'm noticing now is that some HTML pages are becoming too big, > as Sphinx is associating one output page per one input page. Yes, that is right. Changing this 1:1 associations could be done by feature the kernel-doc directive. But a can't recommend this, since this breaks some basic rules sphinx implementations expect. I recommend to split the kernel-doc directives into separate rst-files. Over all: IMHO "Explicit is better than implicit." ... its is better to name each function, struct etc. e.g: .. kernel-doc:: include/media/tuner.h :functions: tuner_mode Being explicit gives the parser the chance to log errors if a declaration not or no longer exists. Yes, I know there are use cases which will be covered better by being implicit ... the decision is left to the author. > It means that, for something like the V4L2 core: > > Video2Linux devices > --- > > .. kernel-doc:: include/media/tuner.h > > .. kernel-doc:: include/media/tuner-types.h > > .. kernel-doc:: include/media/tveeprom.h > > .. kernel-doc:: include/media/v4l2-async.h > > .. kernel-doc:: include/media/v4l2-ctrls.h > >
[PATCHv3] doc-rst: cec: update documentation
Update and expand the CEC documentation. Especially w.r.t. non-blocking mode. Signed-off-by: Hans Verkuil --- This depends on https://patchwork.linuxtv.org/patch/35614/. Changes since v2: better document the timestamp fields Changes since v1: update the documentation of the all_device_types and features fields due to changes in the CEC API (these were ignored for CEC 1.4, but after the pull request above they are no longer ignored). --- diff --git a/Documentation/media/uapi/cec/cec-func-open.rst b/Documentation/media/uapi/cec/cec-func-open.rst index cbf1176..38fd7e0 100644 --- a/Documentation/media/uapi/cec/cec-func-open.rst +++ b/Documentation/media/uapi/cec/cec-func-open.rst @@ -32,12 +32,12 @@ Arguments Open flags. Access mode must be ``O_RDWR``. When the ``O_NONBLOCK`` flag is given, the -:ref:`CEC_RECEIVE ` ioctl will return the EAGAIN -error code when no message is available, and ioctls -:ref:`CEC_TRANSMIT `, +:ref:`CEC_RECEIVE ` and :ref:`CEC_DQEVENT ` ioctls +will return the ``EAGAIN`` error code when no message or event is available, and +ioctls :ref:`CEC_TRANSMIT `, :ref:`CEC_ADAP_S_PHYS_ADDR ` and :ref:`CEC_ADAP_S_LOG_ADDRS ` -all act in non-blocking mode. +all return 0. Other flags have no effect. diff --git a/Documentation/media/uapi/cec/cec-ioc-adap-g-log-addrs.rst b/Documentation/media/uapi/cec/cec-ioc-adap-g-log-addrs.rst index eab734e..04ee900 100644 --- a/Documentation/media/uapi/cec/cec-ioc-adap-g-log-addrs.rst +++ b/Documentation/media/uapi/cec/cec-ioc-adap-g-log-addrs.rst @@ -45,10 +45,24 @@ To query the current CEC logical addresses, applications call To set new logical addresses, applications fill in :c:type:`struct cec_log_addrs` and call :ref:`ioctl CEC_ADAP_S_LOG_ADDRS ` with a pointer to this struct. The :ref:`ioctl CEC_ADAP_S_LOG_ADDRS ` -is only available if ``CEC_CAP_LOG_ADDRS`` is set (ENOTTY error code is -returned otherwise). This ioctl will block until all requested logical -addresses have been claimed. The :ref:`ioctl CEC_ADAP_S_LOG_ADDRS ` can only be called -by a file handle in initiator mode (see :ref:`CEC_S_MODE`). +is only available if ``CEC_CAP_LOG_ADDRS`` is set (the ``ENOTTY`` error code is +returned otherwise). The :ref:`ioctl CEC_ADAP_S_LOG_ADDRS ` +can only be called by a file descriptor in initiator mode (see :ref:`CEC_S_MODE`), if not +the ``EBUSY`` error code will be returned. + +To clear existing logical addresses set ``num_log_addrs`` to 0. All other fields +will be ignored in that case. The adapter will go to the unconfigured state. + +If the physical address is valid (see :ref:`ioctl CEC_ADAP_S_PHYS_ADDR `), +then this ioctl will block until all requested logical +addresses have been claimed. If the file descriptor is in non-blocking mode then it will +not wait for the logical addresses to be claimed, instead it just returns 0. + +A :ref:`CEC_EVENT_STATE_CHANGE ` event is sent when the +logical addresses are claimed or cleared. + +Attempting to call :ref:`ioctl CEC_ADAP_S_LOG_ADDRS ` when +logical address types are already defined will return with error ``EBUSY``. .. _cec-log-addrs: @@ -63,7 +77,7 @@ by a file handle in initiator mode (see :ref:`CEC_S_MODE`). - __u8 - - ``log_addr`` [CEC_MAX_LOG_ADDRS] + - ``log_addr[CEC_MAX_LOG_ADDRS]`` - The actual logical addresses that were claimed. This is set by the driver. If no logical address could be claimed, then it is set to @@ -136,7 +150,7 @@ by a file handle in initiator mode (see :ref:`CEC_S_MODE`). - char - - ``osd_name``\ [15] + - ``osd_name[15]`` - The On-Screen Display name as is returned by the ``CEC_MSG_SET_OSD_NAME`` message. @@ -145,7 +159,7 @@ by a file handle in initiator mode (see :ref:`CEC_S_MODE`). - __u8 - - ``primary_device_type`` [CEC_MAX_LOG_ADDRS] + - ``primary_device_type[CEC_MAX_LOG_ADDRS]`` - Primary device type for each logical address. See :ref:`cec-prim-dev-types` for possible types. @@ -154,7 +168,7 @@ by a file handle in initiator mode (see :ref:`CEC_S_MODE`). - __u8 - - ``log_addr_type`` [CEC_MAX_LOG_ADDRS] + - ``log_addr_type[CEC_MAX_LOG_ADDRS]`` - Logical address types. See :ref:`cec-log-addr-types` for possible types. The driver will update this with the actual @@ -165,25 +179,27 @@ by a file handle in initiator mode (see :ref:`CEC_S_MODE`). - __u8 - - ``all_device_types`` [CEC_MAX_LOG_ADDRS] + - ``all_device_types[CEC_MAX_LOG_ADDRS]`` - - CEC 2.0 specific: all device types. See - :ref:`cec-all-dev-types-flags`. Used to implement the - ``CEC_MSG_REPORT_FEATURES`` message. This field is ignored if - ``cec_version`` < :ref:`CEC_OP_CEC_VERSION_2_0 `. + - CEC 2.0 specific: the bit mask of all device types. See + :ref:`cec-all-dev-types-flags`. It i
Re: [PATCH 00/18] Complete moving media documentation to ReST format
On 07/18/16 20:30, Mauro Carvalho Chehab wrote:
> This patch series finally ends the conversion of the media documents to ReST
> format.
>
> After this series, *all* media documentation will be inside a ReST book.
>
> They'll be:
>
> - Linux Media Infrastructure userspace API
> - With 5 parts:
> - Video for Linux API
> - Digital TV API
> - Remote Controller API
> - Media Controller API
> - CEC API
> - Media subsystem kernel internal API
> - Linux Digital TV driver-specific documentation
> - Video4Linux (V4L) driver-specific documentation
>
> All those documents are built automatically, once by day, at linuxtv.org:
>
> uAPI:
> https://linuxtv.org/downloads/v4l-dvb-apis-new/media/media_uapi.html
Erm, there is nothing there, only the top-level menu.
Regards,
Hans
>
> kAPI:
> https://linuxtv.org/downloads/v4l-dvb-apis-new/media/media_kapi.html
>
> DVB drivers:
>
> https://linuxtv.org/downloads/v4l-dvb-apis-new/media/dvb-drivers/index.html
>
> V4L drivers:
>
> https://linuxtv.org/downloads/v4l-dvb-apis-new/media/v4l-drivers/index.html
>
> That's said, there are lots of old/deprecated information there. Also, as the
> books
> are actually an aggregation of stuff written on different times, by different
> people,
> they don't look all the same.
>
> I tried to fix some things while doing the documentation patch series, but
> there are
> still lots of things to be done, specially at the DVB and V4L drivers
> documentation.
>
> There are also several V4L2 core functions not documented at the kAPI book,
> and
> the V4L framework document there is not properly cross referenced.
>
> Anyway, now that everything can be seen on 4 books via html, maybe it will now
> be easier to identify and fix the gaps. I intend do do it for Kernel 4.9.
>
> I'm merging all stuff on my main development tree:
> https://git.linuxtv.org//mchehab/experimental.git/log/?h=docs-next
>
> I should be merge soon today what we currently have at media mainstream tree.
>
> Regards,
> Mauro
>
> Mauro Carvalho Chehab (18):
> [media] doc-rst: move bttv documentation to bttv.rst file
> [media] doc-rst: add documentation for bttv driver
> [media] doc-rst: add documentation for tuners
> [media] doc-rst: start adding documentation for cx2341x
> [media] cx2341x.rst: add fw-decoder-registers.txt content
> [media] cx2341x.rst: Add the contents of fw-encoder-api.txt
> [media] cx2341x.rst: add the contents of fw-calling.txt
> [media] cx2341x.rst: add contents of fw-dma.txt
> [media] cx2341x.rst: add contents of fw-memory.txt
> [media] cx2341x.rst: add the contents of fw-upload.txt
> [media] cx2341x.rst: add contents of fw-osd-api.txt
> [media] cx2341x: add contents of README.hm12
> [media] cx2341x.rst: add contents of README.vbi
> [media] cx88.rst: add contents from not-in-cx2388x-datasheet.txt
> [media] cx88.rst: add contents of hauppauge-wintv-cx88-ir.txt
> [media] get rid of Documentation/video4linux/lifeview.txt
> [media] doc-rst: fix media kAPI documentation
> [media] doc-rst: better name the media books
>
> Documentation/index.rst|2 +-
> Documentation/media/dvb-drivers/index.rst |9 +-
> Documentation/media/kapi/dtv-core.rst |4 -
> Documentation/media/kapi/mc-core.rst |8 -
> Documentation/media/kapi/rc-core.rst |3 +-
> Documentation/media/kapi/v4l2-core.rst | 21 -
> .../media/{media_drivers.rst => media_kapi.rst}|9 +-
> Documentation/media/media_uapi.rst | 10 +-
> Documentation/media/v4l-drivers/bttv.rst | 1923 ++
> Documentation/media/v4l-drivers/cx2341x.rst| 3858
>
> Documentation/media/v4l-drivers/cx88.rst | 104 +
> Documentation/media/v4l-drivers/index.rst | 11 +-
> Documentation/media/v4l-drivers/saa7134.rst| 36 +
> Documentation/media/v4l-drivers/tuners.rst | 131 +
> Documentation/video4linux/bttv/CONTRIBUTORS| 25 -
> Documentation/video4linux/bttv/Cards | 960 -
> Documentation/video4linux/bttv/ICs | 37 -
> Documentation/video4linux/bttv/Insmod-options | 172 -
> Documentation/video4linux/bttv/MAKEDEV | 27 -
> Documentation/video4linux/bttv/Modprobe.conf | 11 -
> Documentation/video4linux/bttv/Modules.conf| 14 -
> Documentation/video4linux/bttv/PROBLEMS| 62 -
> Documentation/video4linux/bttv/README | 90 -
> Documentation/video4linux/bttv/README.WINVIEW | 33 -
> Documentation/video4linux/bttv/README.freeze | 74 -
> Documentation/video4linux/bttv/README.quirks | 83 -
> Documentation/video4linux/bttv/Sound-FAQ | 148 -
> Documentation/video4linux/bttv/Specs |3 -
> Documentation/video4linux/bttv/THANKS |
Re: [PATCH next] [media] vb2: Fix allocation size of dma_parms
Hi
On 2016-07-18 19:54, Vincent Stehlé wrote:
When allocating memory to hold the device dma parameters in
vb2_dma_contig_set_max_seg_size(), the requested size is by mistake only
the size of a pointer. Request the correct size instead.
Fixes: 3f0339691896 ("media: vb2-dma-contig: add helper for setting dma max seg
size")
Signed-off-by: Vincent Stehlé
Cc: Marek Szyprowski
Cc: Sylwester Nawrocki
I'm really sorry for such silly mistake. Thanks for spotting this issue.
Acked-by: Marek Szyprowski
---
Hi,
I saw that in linux next-20160718.
Best regards,
Vincent.
drivers/media/v4l2-core/videobuf2-dma-contig.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index b09b2c9..59fa204 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -743,7 +743,7 @@ EXPORT_SYMBOL_GPL(vb2_dma_contig_memops);
int vb2_dma_contig_set_max_seg_size(struct device *dev, unsigned int size)
{
if (!dev->dma_parms) {
- dev->dma_parms = kzalloc(sizeof(dev->dma_parms), GFP_KERNEL);
+ dev->dma_parms = kzalloc(sizeof(*dev->dma_parms), GFP_KERNEL);
if (!dev->dma_parms)
return -ENOMEM;
}
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
--
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] [media] cec: add RC_CORE dependency
On Tuesday, July 19, 2016 10:30:22 AM CEST Hans Verkuil wrote:
> On 07/19/16 10:10, Arnd Bergmann wrote:
> > We cannot build the cec driver when the RC core is a module
> > and cec is built-in:
> >
> > drivers/staging/built-in.o: In function `cec_allocate_adapter':
> > :(.text+0x134): undefined reference to `rc_allocate_device'
> > drivers/staging/built-in.o: In function `cec_register_adapter':
> > :(.text+0x304): undefined reference to `rc_register_device'
> >
> > This adds an explicit dependency to avoid this case. We still
> > allow building when CONFIG_RC_CORE is disabled completely,
> > as the driver has checks for this case itself.
>
> This makes no sense: the rc_allocate_device and rc_register_device
> are under:
>
> #if IS_REACHABLE(CONFIG_RC_CORE)
>
> So it shouldn't be enabled at all, should it?
My mistake, I forgot to remove my patch from the backlog after
you added 5bb2399a4fe4 ("[media] cec: fix Kconfig dependency
problems"), and I saw that it's still marked as "new" in
patchwork with no reply.
I'll drop the patch from my local series and won't submit it again,
sorry for the mixup.
Arnd
--
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] [media] cec: add RC_CORE dependency
On 07/19/16 10:10, Arnd Bergmann wrote: > We cannot build the cec driver when the RC core is a module > and cec is built-in: > > drivers/staging/built-in.o: In function `cec_allocate_adapter': > :(.text+0x134): undefined reference to `rc_allocate_device' > drivers/staging/built-in.o: In function `cec_register_adapter': > :(.text+0x304): undefined reference to `rc_register_device' > > This adds an explicit dependency to avoid this case. We still > allow building when CONFIG_RC_CORE is disabled completely, > as the driver has checks for this case itself. This makes no sense: the rc_allocate_device and rc_register_device are under: #if IS_REACHABLE(CONFIG_RC_CORE) So it shouldn't be enabled at all, should it? Regards, Hans > > Signed-off-by: Arnd Bergmann > --- > I originally submitted this on June 29, but it may have gotten > lost as out of the three patch series, one patch got replaced > and another patch got applied, but nothing happened on this one. > --- > drivers/staging/media/cec/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/staging/media/cec/Kconfig > b/drivers/staging/media/cec/Kconfig > index 21457a1f6c9f..c623bd32a5b8 100644 > --- a/drivers/staging/media/cec/Kconfig > +++ b/drivers/staging/media/cec/Kconfig > @@ -1,6 +1,7 @@ > config MEDIA_CEC > bool "CEC API (EXPERIMENTAL)" > depends on MEDIA_SUPPORT > + depends on RC_CORE || !RC_CORE > select MEDIA_CEC_EDID > ---help--- > Enable the CEC API. > -- 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] [media] cec: add RC_CORE dependency
We cannot build the cec driver when the RC core is a module and cec is built-in: drivers/staging/built-in.o: In function `cec_allocate_adapter': :(.text+0x134): undefined reference to `rc_allocate_device' drivers/staging/built-in.o: In function `cec_register_adapter': :(.text+0x304): undefined reference to `rc_register_device' This adds an explicit dependency to avoid this case. We still allow building when CONFIG_RC_CORE is disabled completely, as the driver has checks for this case itself. Signed-off-by: Arnd Bergmann --- I originally submitted this on June 29, but it may have gotten lost as out of the three patch series, one patch got replaced and another patch got applied, but nothing happened on this one. --- drivers/staging/media/cec/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/staging/media/cec/Kconfig b/drivers/staging/media/cec/Kconfig index 21457a1f6c9f..c623bd32a5b8 100644 --- a/drivers/staging/media/cec/Kconfig +++ b/drivers/staging/media/cec/Kconfig @@ -1,6 +1,7 @@ config MEDIA_CEC bool "CEC API (EXPERIMENTAL)" depends on MEDIA_SUPPORT + depends on RC_CORE || !RC_CORE select MEDIA_CEC_EDID ---help--- Enable the CEC API. -- 2.9.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
[PATCH 1/2] [media] staging: add MEDIA_SUPPORT dependency
staging media drivers tend to have a build time dependency on the
media support. In particular, the newly added pulse8 cec driver can
only be a loadable module if MEDIA_SUPPORT=m, but its build dependency
is on a 'bool' symbol (MEDIA_CEC), so a randconfig build can fail
with pulse8_cec built-in:
drivers/staging/built-in.o: In function `pulse8_disconnect':
dgnc_utils.c:(.text+0x114): undefined reference to `cec_unregister_adapter'
drivers/staging/built-in.o: In function `pulse8_irq_work_handler':
dgnc_utils.c:(.text+0x1bc): undefined reference to `cec_transmit_done'
dgnc_utils.c:(.text+0x1d8): undefined reference to `cec_received_msg'
dgnc_utils.c:(.text+0x1f4): undefined reference to `cec_transmit_done'
dgnc_utils.c:(.text+0x218): undefined reference to `cec_transmit_done'
dgnc_utils.c:(.text+0x23c): undefined reference to `cec_transmit_done'
drivers/staging/built-in.o: In function `pulse8_connect':
dgnc_utils.c:(.text+0x844): undefined reference to `cec_allocate_adapter'
dgnc_utils.c:(.text+0x8a4): undefined reference to `cec_delete_adapter'
dgnc_utils.c:(.text+0xa10): undefined reference to `cec_register_adapter'
Originally, MEDIA_CEC itself was a tristate symbol, which would have
prevented this, but since 5bb2399a4fe4 ("[media] cec: fix Kconfig
dependency problems"), it doesn't work like that any more.
This encloses all of the staging media drivers in a CONFIG_MEDIA_SUPPORT
dependency in Kconfig, which solves the problem by enforcing that none
of the drivers can be built-in if the media core is a module.
Signed-off-by: Arnd Bergmann
---
drivers/staging/media/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/media/Kconfig b/drivers/staging/media/Kconfig
index cae42e56f270..7292f23954df 100644
--- a/drivers/staging/media/Kconfig
+++ b/drivers/staging/media/Kconfig
@@ -16,7 +16,7 @@ menuconfig STAGING_MEDIA
If in doubt, say N here.
-if STAGING_MEDIA
+if STAGING_MEDIA && MEDIA_SUPPORT
# Please keep them in alphabetic order
source "drivers/staging/media/bcm2048/Kconfig"
--
2.9.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: [RFC 00/16] Make use of kref in media device, grab references as needed
Sakari Ailus wrote: > I believe people are more familiar with the state of the code with the > reverts than without them. The first two reverted patches I don't really > have a problem with, but they depend on the third reverted patch which > is more problematic and they'll no longer be needed afterwards. To > refresh our memory: "media: fix media devnode ioctl/syscall and unregister race" is actually a part of the workaround as well: http://www.spinics.net/lists/linux-media/msg101295.html> http://www.spinics.net/lists/linux-media/msg101327.html> -- Sakari Ailus sakari.ai...@linux.intel.com -- 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
[PATCHv2] doc-rst: cec: update documentation
Update and expand the CEC documentation. Especially w.r.t. non-blocking mode. Signed-off-by: Hans Verkuil --- This depends on https://patchwork.linuxtv.org/patch/35614/. Changes since v2: update the documentation of the all_device_types and features fields due to changes in the CEC API (these were ignored for CEC 1.4, but after the pull request above they are no longer ignored). --- diff --git a/Documentation/media/uapi/cec/cec-func-open.rst b/Documentation/media/uapi/cec/cec-func-open.rst index cbf1176..38fd7e0 100644 --- a/Documentation/media/uapi/cec/cec-func-open.rst +++ b/Documentation/media/uapi/cec/cec-func-open.rst @@ -32,12 +32,12 @@ Arguments Open flags. Access mode must be ``O_RDWR``. When the ``O_NONBLOCK`` flag is given, the -:ref:`CEC_RECEIVE ` ioctl will return the EAGAIN -error code when no message is available, and ioctls -:ref:`CEC_TRANSMIT `, +:ref:`CEC_RECEIVE ` and :ref:`CEC_DQEVENT ` ioctls +will return the ``EAGAIN`` error code when no message or event is available, and +ioctls :ref:`CEC_TRANSMIT `, :ref:`CEC_ADAP_S_PHYS_ADDR ` and :ref:`CEC_ADAP_S_LOG_ADDRS ` -all act in non-blocking mode. +all return 0. Other flags have no effect. diff --git a/Documentation/media/uapi/cec/cec-ioc-adap-g-log-addrs.rst b/Documentation/media/uapi/cec/cec-ioc-adap-g-log-addrs.rst index eab734e..04ee900 100644 --- a/Documentation/media/uapi/cec/cec-ioc-adap-g-log-addrs.rst +++ b/Documentation/media/uapi/cec/cec-ioc-adap-g-log-addrs.rst @@ -45,10 +45,24 @@ To query the current CEC logical addresses, applications call To set new logical addresses, applications fill in :c:type:`struct cec_log_addrs` and call :ref:`ioctl CEC_ADAP_S_LOG_ADDRS ` with a pointer to this struct. The :ref:`ioctl CEC_ADAP_S_LOG_ADDRS ` -is only available if ``CEC_CAP_LOG_ADDRS`` is set (ENOTTY error code is -returned otherwise). This ioctl will block until all requested logical -addresses have been claimed. The :ref:`ioctl CEC_ADAP_S_LOG_ADDRS ` can only be called -by a file handle in initiator mode (see :ref:`CEC_S_MODE`). +is only available if ``CEC_CAP_LOG_ADDRS`` is set (the ``ENOTTY`` error code is +returned otherwise). The :ref:`ioctl CEC_ADAP_S_LOG_ADDRS ` +can only be called by a file descriptor in initiator mode (see :ref:`CEC_S_MODE`), if not +the ``EBUSY`` error code will be returned. + +To clear existing logical addresses set ``num_log_addrs`` to 0. All other fields +will be ignored in that case. The adapter will go to the unconfigured state. + +If the physical address is valid (see :ref:`ioctl CEC_ADAP_S_PHYS_ADDR `), +then this ioctl will block until all requested logical +addresses have been claimed. If the file descriptor is in non-blocking mode then it will +not wait for the logical addresses to be claimed, instead it just returns 0. + +A :ref:`CEC_EVENT_STATE_CHANGE ` event is sent when the +logical addresses are claimed or cleared. + +Attempting to call :ref:`ioctl CEC_ADAP_S_LOG_ADDRS ` when +logical address types are already defined will return with error ``EBUSY``. .. _cec-log-addrs: @@ -63,7 +77,7 @@ by a file handle in initiator mode (see :ref:`CEC_S_MODE`). - __u8 - - ``log_addr`` [CEC_MAX_LOG_ADDRS] + - ``log_addr[CEC_MAX_LOG_ADDRS]`` - The actual logical addresses that were claimed. This is set by the driver. If no logical address could be claimed, then it is set to @@ -136,7 +150,7 @@ by a file handle in initiator mode (see :ref:`CEC_S_MODE`). - char - - ``osd_name``\ [15] + - ``osd_name[15]`` - The On-Screen Display name as is returned by the ``CEC_MSG_SET_OSD_NAME`` message. @@ -145,7 +159,7 @@ by a file handle in initiator mode (see :ref:`CEC_S_MODE`). - __u8 - - ``primary_device_type`` [CEC_MAX_LOG_ADDRS] + - ``primary_device_type[CEC_MAX_LOG_ADDRS]`` - Primary device type for each logical address. See :ref:`cec-prim-dev-types` for possible types. @@ -154,7 +168,7 @@ by a file handle in initiator mode (see :ref:`CEC_S_MODE`). - __u8 - - ``log_addr_type`` [CEC_MAX_LOG_ADDRS] + - ``log_addr_type[CEC_MAX_LOG_ADDRS]`` - Logical address types. See :ref:`cec-log-addr-types` for possible types. The driver will update this with the actual @@ -165,25 +179,27 @@ by a file handle in initiator mode (see :ref:`CEC_S_MODE`). - __u8 - - ``all_device_types`` [CEC_MAX_LOG_ADDRS] + - ``all_device_types[CEC_MAX_LOG_ADDRS]`` - - CEC 2.0 specific: all device types. See - :ref:`cec-all-dev-types-flags`. Used to implement the - ``CEC_MSG_REPORT_FEATURES`` message. This field is ignored if - ``cec_version`` < :ref:`CEC_OP_CEC_VERSION_2_0 `. + - CEC 2.0 specific: the bit mask of all device types. See + :ref:`cec-all-dev-types-flags`. It is used in the CEC 2.0 + ``CEC_MSG_REPORT_FEATURE
[GIT PULL FOR v4.8] (v3) CEC fixes, vivid CEC enhancement
These patches fix a number of bugs in the CEC framework. These were discovered while extending and improving the compliance tests for the CEC API. The vivid patch adds MONITOR_ALL support. The latest compliance tests are here: https://git.linuxtv.org/hverkuil/v4l-utils.git/log/?h=cec-johan The docrst needs an update as well, I'll make a separate patch for that. Regards, Hans (v3 adds patch "cec: always check all_device_types and features") (v2 adds patch "cec: poll should check if there is room in the tx queue") The following changes since commit e05b1872f29a85532c2b34e3a4974a27158f1463: [media] cxd2841er: Reading SNR for DVB-C added (2016-07-16 07:01:31 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v4.8l for you to fetch changes up to a513478569811ad69f012d294fe2a0f74dbf9fc1: cec: always check all_device_types and features (2016-07-19 09:28:08 +0200) Hans Verkuil (9): cec: CEC_RECEIVE overwrote the timeout field cec: clear all status fields before transmit and always fill in sequence cec: don't set fh to NULL in CEC_TRANSMIT cec: zero unused msg part after msg->len cec: limit the size of the transmit queue cec: fix test for unconfigured adapter in main message loop vivid: support monitor all mode cec: poll should check if there is room in the tx queue cec: always check all_device_types and features drivers/media/platform/vivid/vivid-cec.c | 44 +++--- drivers/staging/media/cec/cec-adap.c | 87 +--- drivers/staging/media/cec/cec-api.c | 15 ++- include/media/cec.h | 19 + 4 files changed, 91 insertions(+), 74 deletions(-) -- 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 00/16] Make use of kref in media device, grab references as needed
Hi Mauro, Thank you for your reply. Mauro Carvalho Chehab wrote: > Em Fri, 15 Jul 2016 01:34:55 +0300 > Sakari Ailus escreveu: > >> Hi folks, >> >> I've been working on this for some time now but only got the full patchset >> working some moments ago. The patchset properly, I believe, fixes the >> issue of removing a device whilst streaming. >> >> Media device is refcounted and its memory is only released once the last >> reference is gone: unregistering is simply unregistering, it no longer >> should release memory which could be further accessed. >> >> A video node or a sub-device node also gets a reference to the media >> device, i.e. the release function of the video device node will release >> its reference to the media device. The same goes for file handles to the >> media device. >> >> As a side effect of refcounting the media device, it is allocate together >> with the media devnode. The driver may also rely its own resources to the >> media device. Alternatively there's also a priv field to hold drivers >> private pointer (for container_of() is an option in this case). >> >> I've tested this by manually unbinding the omap3isp platform device while >> streaming. Driver changes are required for this to work; by not using >> dynamic allocation (i.e. media_device_alloc()) the old behaviour is still >> supported. This is still unlikely to be a grave problem as there are not >> that many device drivers that support physically removable devices. We've >> had this problem for other devices for many years without paying much >> notice --- that doesn't mean I don't think at least drivers for removable >> devices shouldn't be changed as part of the set later on, I'd just like to >> get review comments on the approach first. >> >> The three patches that originally partially resolved some of these issues >> are reverted in the beginning of the set. I'm still posting this as an RFC >> mainly since the testing is somewhat limited so far. > > > I didn't look inside this patch series. Won't likely have time to > look at core changes before the end of the merge window. However, > I found several structural problems on this RFC: > > 1) Please do incremental changes, instead of reverting patches. It is > really hard for reviewers to be sure that nothing breaks when someone > simply reverts a previous approach and add its own. I believe people are more familiar with the state of the code with the reverts than without them. The first two reverted patches I don't really have a problem with, but they depend on the third reverted patch which is more problematic and they'll no longer be needed afterwards. To refresh our memory: http://www.spinics.net/lists/linux-media/msg100355.html> http://www.spinics.net/lists/linux-media/msg100927.html> http://www.spinics.net/lists/linux-media/msg100952.html> > > 2) Each individual patch should not cause regressions to none of > the existing drivers or to the core. The revert re-introduces bugs. We've had the problem for five years without even realising it. What's merged now is a workaround that avoids *some* of the underlying problems. With the current media-master, the system still crashes if the device is removed during video streaming. With this set (and appropriate driver changes) it does not. Driver changes alone are not enough to fix this either. > > 3) Each patch should not break compilation. Patch 06/16, for example, > changes the structure used by the release method: > > -static void media_device_release(struct media_devnode *mdev) > +static void media_device_release(struct media_devnode *devnode) > > Without touching a single driver. That means compilation breakages. > This is not acceptable upstream. > > It should be touching *all* drivers that use the function altogether. This change you're referring to in patch 06/16 changes the name of the argument of a function to devnode. This change was missing from patch "[media] media-devnode: fix namespace mess". What comes to media_device_alloc() and media_device_get()/put(), their use is optional. Driver changes are needed at least for drivers that can be removed physically from the system. Once all drivers are converted, we can remove the old API. > > 4) From a very quick look at the series, without trying to compile the > series (with would very likely break), it seems that all drivers that > uses the media controller should be migrated to the new way. > > It means that you'll need to patch all drivers altogether as you're > changing the kAPI at the same patch you change it. I want to first get the review comments on the API itself and then move the removable drivers to use it. Individual drivers may still have issues with removing devices while they're in use. -- Kind regards, Sakari Ailus sakari.ai...@linux.intel.com -- 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-
