Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression)

[Krzysztof Hałasa]

Andrey Utkin  writes:

>> Does (only) adding the
>> 
>>  pci_read_config_word(solo_dev->pdev, PCI_STATUS, );
>> 
>> in solo_reg_write() help?
>
> Yes.
> I have posted a patch with this change few days ago, I thought you have
> noticed it.

Well, I think you haven't sent me a copy. Anyway, it would be great to
determine where exactly writes need a flush. Adding it everywhere is a
bit suboptimal, one would think.

Can you share some details about the machine you are experiencing the
problems on? CPU, chipset? I'd try to see if I can recreate the problem.

Alternatively, you could investigate yourself - at first you could put
pci_read_config_word() at the end of subroutines (including return
statements) using solo_reg_write(). And in that solo_p2m_dma_desc(),
before wait_for_completion_timeout(). Then eliminate them using some
sort of binary search to see which ones are required.
-- 
Krzysztof Halasa

Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, 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

media: rockchip-vpu: I should place the huffman table at kernel or userspace ?

[Randy Li]

Hello:
  I have just done a JPEG HW encoder for the RK3288. I have been told 
that I can't use the standard way to generate huffman table, the VPU 
supports only 10 levels with a different huffman table.
  If I send the huffman table through the v4l2 extra control, the 
memory copy is requested, although the data is not very large(2 x 64 
bytes) but still a overhead. The other way is to place them in the 
kernel driver, and just define the quality every time it encode a 
picture. But storing in kernel would make the driver a little bigger(2 x 
11 x 64 bytes) and beyond the FIFO job.

  So where Should I place the huffman table?
--
Randy Li
The third produce department
===
This email message, including any attachments, is for the sole
use of the intended recipient(s) and may contain confidential and
privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message. [Fuzhou Rockchip Electronics, INC. China mainland]
===

--
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: [v4l-utils PATCH 1/1] Fix static linking of v4l2-compliance and v4l2-ctl

[Sakari Ailus]

Hi Mauro,

On Mon, Sep 26, 2016 at 01:59:45PM -0300, Mauro Carvalho Chehab wrote:
> Em Mon, 26 Sep 2016 18:46:40 +0300
> Sakari Ailus  escreveu:
> 
> > Hi Mauro,
> > 
> > On Mon, Sep 19, 2016 at 11:19:12AM -0300, Mauro Carvalho Chehab wrote:
> > > Em Mon, 19 Sep 2016 16:21:30 +0300
> > > Sakari Ailus  escreveu:
> > >   
> > > > Hi Mauro,
> > > > 
> > > > On 09/19/16 14:22, Mauro Carvalho Chehab wrote:  
> > > > > Em Mon, 19 Sep 2016 13:50:25 +0300
> > > > > Sakari Ailus  escreveu:
> > > > > 
> > > > >> v4l2-compliance and v4l2-ctl depend on librt and libpthread. The 
> > > > >> symbols
> > > > >> are found by the linker only if these libraries are specified after 
> > > > >> the
> > > > >> objects that depend on them.
> > > > >>
> > > > >> As LDFLAGS variable end up expanded on libtool command line before 
> > > > >> LDADD,
> > > > >> move the libraries to LDADD after local objects. -lpthread is added 
> > > > >> as on
> > > > >> some systems librt depends on libpthread. This is the case on Ubuntu 
> > > > >> 16.04
> > > > >> for instance.
> > > > >>
> > > > >> After this patch, creating a static build using the command
> > > > >>
> > > > >> LDFLAGS="--static -static" ./configure --disable-shared 
> > > > >> --enable-static
> > > > > 
> > > > > It sounds weird to use LDFLAGS="--static -static" here, as the
> > > > > configure options are already asking for static.
> > > > > 
> > > > > IMHO, the right way would be to change configure.ac to add those 
> > > > > LDFLAGS
> > > > > when --disable-shared is used.
> > > > 
> > > > That's one option, but then shared libraries won't be built at all.  
> > > 
> > > Well, my understanding is that  --disable-shared is meant to disable
> > > building the shared library build :)
> > >   
> > > > I'm
> > > > not sure what would be the use cases for that, though: static linking
> > > > isn't very commonly needed except when you need to run the binaries
> > > > elsewhere (for whatever reason) where you don't have the libraries you
> > > > linked against available.  
> > > 
> > > Yeah, that's the common usage. It is also interesting if someone
> > > wants to build 2 versions of the same utility, each using a
> > > different library, for testing purposes.
> > > 
> > > The usecase I can't see is to use --disable-shared but keeping
> > > using the dynamic library for the exec files.  
> > 
> > There are three primary options here,
> > 
> > 1. build an entirely static binary,
> > 2. build a binary that relies on dynamic libraries as well and
> > 3. build a binary that relies on dynamic libraries outside v4l-utils package
> >but that links v4l-utils originating libraries statically.
> > 
> > If you say 3. is not needed then we could just use --disable-shared also to
> > tell that static binaries are to be built.
> > 
> > 3. is always used for libv4l2subdev and libmediactl as the libraries do not
> > have stable APIs.
> 
> Sakari,
> 
> I can't see what you mean by scenario (2). I mean, if 
> --disable-shared is called, it *should not* use dynamic libraries
> for any library provided by v4l-utils, as the generated binaries will
> either:
> 
> a) don't work, because those libraries weren't built;
> b) will do the wrong thing, as they'll be dynamically linked
>to an older version of the library.
> 
> So, there are only 3 possible scenarios, IMHO:
> 
> 1) dynamic libraries, dynamic execs
> 2) static v4l-utils libraries, static execs
> 3) static v4l-utils libraries, static links for v4l-utils libs, dyn for the 
> rest.
> 
> In practice, I don't see any reason for keeping support for both (2)
> and (3), as all usecases for (3) can be covered by a fully static
> exec. It is also very confusing for one to understand that.
> For example, right now, we have those static/shared options:
> 
>   --enable-static[=PKGS]  build static libraries [default=yes]
>   --enable-shared[=PKGS]  build shared libraries [default=yes]
> 
> with, IMHO, sounds confusing, as those options don't seem to be
> orthogonal. I mean, what happens someone calls ./configure with:
> 
>   ./configure --disable-static --disable-shared

That doesn't make much sense --- to disable the build for both static and
dynamic libraries.

What would you prefer? Link binaries statically iff shared libraries are not
built? I'd just like to get this fixed. Currently building static binaries
is simply broken.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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 1/8] doc: DT: vidc: binding document for Qualcomm video driver

[Stanimir Varbanov]

Hi Rob,

Thanks for the review!

On 09/16/2016 05:19 PM, Rob Herring wrote:
> On Wed, Sep 07, 2016 at 02:37:02PM +0300, Stanimir Varbanov wrote:
>> Adds binding document for vidc video encoder/decoder driver
>>
>> Cc: Rob Herring 
>> Cc: Mark Rutland 
>> Cc: devicet...@vger.kernel.org
>> Signed-off-by: Stanimir Varbanov 
>> ---
>>  .../devicetree/bindings/media/qcom,vidc.txt| 61 
>> ++
>>  1 file changed, 61 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/media/qcom,vidc.txt
>>
>> diff --git a/Documentation/devicetree/bindings/media/qcom,vidc.txt 
>> b/Documentation/devicetree/bindings/media/qcom,vidc.txt
>> new file mode 100644
>> index ..0d50a7b2e3ed
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/qcom,vidc.txt
>> @@ -0,0 +1,61 @@
>> +* Qualcomm video encoder/decoder accelerator
>> +
>> +- compatible:
>> +Usage: required
>> +Value type: 
>> +Definition: Value should contain
> 
> ... one of:
> 
>> +- "qcom,vidc-msm8916"
>> +- "qcom,vidc-msm8996"
>> +- reg:
>> +Usage: required
>> +Value type: 
>> +Definition: Register ranges as listed in the reg-names property
>> +
>> +- interrupts:
>> +Usage: required
>> +Value type: 
>> +Definition:
> 
> How many interrupts?

It is one, thanks for the catch.

> 
>> +
>> +- power-domains:
>> +Usage: required
>> +Value type: 
>> +Definition: A phandle and power domain specifier pairs to the
>> +power domain which is responsible for collapsing
>> +and restoring power to the peripheral
> 
> How many power domains?

Good question, for vidc-msm8916 it is one power-domain, for vidc-msm8996
the power domains should be 3. Here the problem is that the genpd
doesn't permit more than one power-domain per device.

> 
>> +
>> +- clocks:
>> +Usage: required
>> +Value type: 
>> +Definition: List of phandle and clock specifier pairs as listed
>> +in clock-names property
>> +- clock-names:
>> +Usage: required
>> +Value type: 
>> +Definition: Should contain the following entries
>> +- "core"  Core video accelerator clock
>> +- "iface" Video accelerator AHB clock
>> +- "bus"   Video accelerator AXI clock
>> +- rproc:
>> +Usage: required
>> +Value type: 
>> +Definition: A phandle to remote processor responsible for
>> +firmware loading
>> +
>> +- iommus:
>> +Usage: required
>> +Value type: 
>> +Definition: A list of phandle and IOMMU specifier pairs
>> +
>> +* An Example
>> +qcom,vidc@1d0 {
> 
> node names should be generic: video-codec@

correct, will update it in next version.

-- 
regards,
Stan
--
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: [v4l-utils PATCH 2/2] Add --with-static-binaries option to link binaries statically

[Mauro Carvalho Chehab]

Em Mon, 26 Sep 2016 19:41:39 +0200
Gregor Jasny  escreveu:

> On 19/09/2016 16:21, Mauro Carvalho Chehab wrote:
> > Em Mon, 19 Sep 2016 16:22:30 +0300
> > Sakari Ailus  escreveu:
> >   
> >> Add a new variable STATIC_LDFLAGS to add the linker flags required for
> >> static linking for each binary built.
> >>
> >> Static and dynamic libraries are built by default but the binaries are
> >> otherwise linked dynamically. --with-static-binaries requires that static
> >> libraries are built.
> >>  
> > Instead of adding STATIC_LDFLAGS to all LDFLAGS, wouldn't be better to
> > add the flags to LDFLAGS on configure.ac?  
> 
> I don't really like adding all those build variants into the configure
> script itself. It is already way too complex and adding another
> dimension does not make it better.
> 
> Why is passing --disable-shared --enable-static LDLAGS="--static
> -static" to configure not sufficient?

That sounds better than adding an extra STATIC_LDFLAGS option, but,
IMHO, this sounds confusing, and it is not documented.

The advantage of having an option is that the expected behavior
can be documented in a way that the user will know what each option
would be doing by calling ./configure --help. Yet, IMHO, the above
parameters don't make clear about what type of output for executable
files (static, dynamic, "partially" dynamic).

We could (should?) also print, at the ./configure "summary" what
kind of libraries will be generated and what kind of executables.

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: [v4l-utils PATCH 2/2] Add --with-static-binaries option to link binaries statically

[Gregor Jasny]

On 19/09/2016 16:21, Mauro Carvalho Chehab wrote:
> Em Mon, 19 Sep 2016 16:22:30 +0300
> Sakari Ailus  escreveu:
> 
>> Add a new variable STATIC_LDFLAGS to add the linker flags required for
>> static linking for each binary built.
>>
>> Static and dynamic libraries are built by default but the binaries are
>> otherwise linked dynamically. --with-static-binaries requires that static
>> libraries are built.
>>
> Instead of adding STATIC_LDFLAGS to all LDFLAGS, wouldn't be better to
> add the flags to LDFLAGS on configure.ac?

I don't really like adding all those build variants into the configure
script itself. It is already way too complex and adding another
dimension does not make it better.

Why is passing --disable-shared --enable-static LDLAGS="--static
-static" to configure not sufficient?

Thanks,
Gregor

--
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: [v4l-utils PATCH 1/1] Fix static linking of v4l2-compliance and v4l2-ctl

[Mauro Carvalho Chehab]

Em Mon, 26 Sep 2016 18:46:40 +0300
Sakari Ailus  escreveu:

> Hi Mauro,
> 
> On Mon, Sep 19, 2016 at 11:19:12AM -0300, Mauro Carvalho Chehab wrote:
> > Em Mon, 19 Sep 2016 16:21:30 +0300
> > Sakari Ailus  escreveu:
> >   
> > > Hi Mauro,
> > > 
> > > On 09/19/16 14:22, Mauro Carvalho Chehab wrote:  
> > > > Em Mon, 19 Sep 2016 13:50:25 +0300
> > > > Sakari Ailus  escreveu:
> > > > 
> > > >> v4l2-compliance and v4l2-ctl depend on librt and libpthread. The 
> > > >> symbols
> > > >> are found by the linker only if these libraries are specified after the
> > > >> objects that depend on them.
> > > >>
> > > >> As LDFLAGS variable end up expanded on libtool command line before 
> > > >> LDADD,
> > > >> move the libraries to LDADD after local objects. -lpthread is added as 
> > > >> on
> > > >> some systems librt depends on libpthread. This is the case on Ubuntu 
> > > >> 16.04
> > > >> for instance.
> > > >>
> > > >> After this patch, creating a static build using the command
> > > >>
> > > >> LDFLAGS="--static -static" ./configure --disable-shared 
> > > >> --enable-static
> > > > 
> > > > It sounds weird to use LDFLAGS="--static -static" here, as the
> > > > configure options are already asking for static.
> > > > 
> > > > IMHO, the right way would be to change configure.ac to add those LDFLAGS
> > > > when --disable-shared is used.
> > > 
> > > That's one option, but then shared libraries won't be built at all.  
> > 
> > Well, my understanding is that  --disable-shared is meant to disable
> > building the shared library build :)
> >   
> > > I'm
> > > not sure what would be the use cases for that, though: static linking
> > > isn't very commonly needed except when you need to run the binaries
> > > elsewhere (for whatever reason) where you don't have the libraries you
> > > linked against available.  
> > 
> > Yeah, that's the common usage. It is also interesting if someone
> > wants to build 2 versions of the same utility, each using a
> > different library, for testing purposes.
> > 
> > The usecase I can't see is to use --disable-shared but keeping
> > using the dynamic library for the exec files.  
> 
> There are three primary options here,
> 
> 1. build an entirely static binary,
> 2. build a binary that relies on dynamic libraries as well and
> 3. build a binary that relies on dynamic libraries outside v4l-utils package
>but that links v4l-utils originating libraries statically.
> 
> If you say 3. is not needed then we could just use --disable-shared also to
> tell that static binaries are to be built.
> 
> 3. is always used for libv4l2subdev and libmediactl as the libraries do not
> have stable APIs.

Sakari,

I can't see what you mean by scenario (2). I mean, if 
--disable-shared is called, it *should not* use dynamic libraries
for any library provided by v4l-utils, as the generated binaries will
either:

a) don't work, because those libraries weren't built;
b) will do the wrong thing, as they'll be dynamically linked
   to an older version of the library.

So, there are only 3 possible scenarios, IMHO:

1) dynamic libraries, dynamic execs
2) static v4l-utils libraries, static execs
3) static v4l-utils libraries, static links for v4l-utils libs, dyn for the 
rest.

In practice, I don't see any reason for keeping support for both (2)
and (3), as all usecases for (3) can be covered by a fully static
exec. It is also very confusing for one to understand that.
For example, right now, we have those static/shared options:

  --enable-static[=PKGS]  build static libraries [default=yes]
  --enable-shared[=PKGS]  build shared libraries [default=yes]

with, IMHO, sounds confusing, as those options don't seem to be
orthogonal. I mean, what happens someone calls ./configure with:

./configure --disable-static --disable-shared




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: g_webcam Isoch high bandwidth transfer

[Laurent Pinchart]

Hi Felipe,

On Friday 23 Sep 2016 11:27:26 Felipe Balbi wrote:
> yfw  writes:
> >> Here's one that actually compiles, sorry about that.
> > 
> > No worries, I was sleeping ;-)
> > 
> > I will test it out early next week. Thanks.
>  
>  meanwhile, how about some instructions on how to test this out myself?
>  How are you using g_webcam and what are you running on host side? Got a
>  nice list of commands there I can use? I think I can get to bottom of
>  this much quicker if I can reproduce it locally ;-)
> >>> 
> >>> On device side:
> >>> - first patch g_webcam as in my first email in this thread to enable
> >>>   640x480@30fps;
> >>> - # modprobe g_webcam streaming_maxpacket=3072
> >>> - then run uvc-gadget to feed the YUV frames;
> >>>   http://git.ideasonboard.org/uvc-gadget.git
> >> 
> >> as is, g_webcam never enumerates to the host. It's calls to
> >> usb_function_active() and usb_function_deactivate() are unbalanced. Do
> >> you have any other changes to g_webcam?
> > 
> > With uvc function gadget driver, user daemon uvc-gadget must be started
> > before connect to host. Not sure whether g_webcam has same requirement.
> 
> f_uvc.c should be handling that by means for usb_function_deactivate().
> 
> I'll try keeping cable disconnected until uvc-gadget is running.

Things might have changed since we've discussed the issue several years ago, 
but back then at least the musb UDC started unconditionally connected.

-- 
Regards,

Laurent Pinchart

--
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: g_webcam Isoch high bandwidth transfer

[Laurent Pinchart]

Hi Felipe,

On Friday 23 Sep 2016 10:49:57 Felipe Balbi wrote:
> Bin Liu  writes:
> > +Fengwei Yin per his request.
> > 
> > On Thu, Sep 22, 2016 at 10:48:40PM +0300, Felipe Balbi wrote:
> >> Bin Liu  writes:
> >> 
> >> [...]
> >> 
>  Here's one that actually compiles, sorry about that.
> >>> 
> >>> No worries, I was sleeping ;-)
> >>> 
> >>> I will test it out early next week. Thanks.
> >> 
> >> meanwhile, how about some instructions on how to test this out myself?
> >> How are you using g_webcam and what are you running on host side? Got a
> >> nice list of commands there I can use? I think I can get to bottom of
> >> this much quicker if I can reproduce it locally ;-)
> > 
> > On device side:
> > - first patch g_webcam as in my first email in this thread to enable
> > 
> >   640x480@30fps;
> > 
> > - # modprobe g_webcam streaming_maxpacket=3072
> > - then run uvc-gadget to feed the YUV frames;
> > 
> > http://git.ideasonboard.org/uvc-gadget.git
> 
> as is, g_webcam never enumerates to the host. It's calls to
> usb_function_active() and usb_function_deactivate() are unbalanced. Do
> you have any other changes to g_webcam?
> 
> Also, uvc-gadget.git doesn't compile, had to modify it a bit:
> 
> -#include "../drivers/usb/gadget/uvc.h"
> +#include "../drivers/usb/gadget/function/uvc.h"
> 
> Also fixed a build warning:
> 
> @@ -732,6 +732,8 @@ int main(int argc, char *argv[])
> fd_set wfds = fds;
> 
> ret = select(dev->fd + 1, NULL, , , NULL);
> +   if (ret < 0)
> +   return ret;
> if (FD_ISSET(dev->fd, ))
> uvc_events_process(dev);
> if (FD_ISSET(dev->fd, ))
> 
> Laurent, have you tested g_webcam recently? What's the magic to get it
> working?

I'm afraid not, I haven't had time to work on UVC gadget for a few years now.

> Here's what I get out of dmesg:
> 
> [   58.568380] usb 1-9: new high-speed USB device number 5 using xhci_hcd
> [   58.738680] usb 1-9: New USB device found, idVendor=1d6b, idProduct=0102
> [   58.738683] usb 1-9: New USB device strings: Mfr=1, Product=2,
> SerialNumber=0 [   58.738685] usb 1-9: Product: Webcam gadget
> [   58.738687] usb 1-9: Manufacturer: Linux Foundation
> [   58.739133] g_webcam gadget: high-speed config #1: Video
> [   58.739138] g_webcam gadget: uvc_function_set_alt(0, 0)
> [   58.739139] g_webcam gadget: reset UVC Control
> [   58.739149] g_webcam gadget: uvc_function_set_alt(1, 0)
> [   58.804369] uvcvideo: Found UVC 1.00 device Webcam gadget (1d6b:0102)
> [   58.804479] g_webcam gadget: uvc_function_set_alt(1, 0)
> [   64.188459] uvcvideo: UVC non compliance - GET_DEF(PROBE) not supported.
> Enabling workaround. [   69.307458] uvcvideo: Failed to query (129) UVC
> probe control : -110 (exp. 26). [   69.307459] uvcvideo: Failed to
> initialize the device (-5).
> [   69.307505] usbcore: registered new interface driver uvcvideo
> [   69.307506] USB Video Class driver (1.1.1)
> [  146.646012] [ cut here ]
> [  146.646023] WARNING: CPU: 0 PID: 2616 at
> drivers/usb/gadget/composite.c:371 usb_function_activate+0x77/0x80
> [libcomposite] [  146.646024] Modules linked in: uvcvideo g_webcam
> usb_f_uvc videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core
> videodev libcomposite kvm_intel kvm psmouse e1000e input_leds hid_generic
> usbhid atkbd irqbypass evdev [  146.646054] CPU: 0 PID: 2616 Comm:
> gst-launch-1.0 Not tainted
> 4.8.0-rc7-next-20160922-4-gc71031593917-dirty #20 [  146.646055]
> Hardware name: Intel Corporation Skylake Client platform/Skylake Y LPDDR3
> RVP3, BIOS SKLSE2R1.R00.B097.B02.1509020030 09/02/2015 [  146.646058] 
> c9000769bb70
> [  146.646059]  8132d415
> [  146.646060]  
> [  146.646061]  
> 
> [  146.646063]  c9000769bbb0
> [  146.646063]  8105ec1b
> [  146.646064]  01730769bb90
> [  146.646066]  ffea
> [  146.646070]  88016c03a150
> [  146.646072]  0282 88016d793000 c9000769befc
> [  146.646077] Call Trace:
> [  146.646086]  [] dump_stack+0x68/0x93
> [  146.646090]  [] __warn+0xcb/0xf0
> [  146.646095]  [] warn_slowpath_null+0x1d/0x20
> [  146.646099]  [] usb_function_activate+0x77/0x80
> [libcomposite] [  146.646105]  []
> uvc_function_connect+0x1e/0x40 [usb_f_uvc] [  146.646110] 
> [] uvc_v4l2_open+0x6e/0x80 [usb_f_uvc] [  146.646116] 
> [] v4l2_open+0xa0/0x100 [videodev] [  146.646121] 
> [] chrdev_open+0xa1/0x1d0
> [  146.646125]  [] ? cdev_put+0x30/0x30
> [  146.646129]  [] do_dentry_open.isra.17+0x150/0x2e0
> [  146.646133]  [] vfs_open+0x45/0x60
> [  146.646137]  [] path_openat+0x62d/0x1370
> [  146.646141]  [] ? putname+0x54/0x60
> [  146.646146]  [] do_filp_open+0x7e/0xe0
> [  146.646150]  [] ? preempt_count_sub+0x48/0x70
> [  146.646154]  [] ? _raw_spin_unlock+0x16/0x30
> [  146.646160]  [] ? __alloc_fd+0xc9/0x180
> [  146.646164]  [] 

Re: [v4l-utils PATCH 1/1] Fix static linking of v4l2-compliance and v4l2-ctl

[Sakari Ailus]

Hi Mauro,

On Mon, Sep 19, 2016 at 11:19:12AM -0300, Mauro Carvalho Chehab wrote:
> Em Mon, 19 Sep 2016 16:21:30 +0300
> Sakari Ailus  escreveu:
> 
> > Hi Mauro,
> > 
> > On 09/19/16 14:22, Mauro Carvalho Chehab wrote:
> > > Em Mon, 19 Sep 2016 13:50:25 +0300
> > > Sakari Ailus  escreveu:
> > >   
> > >> v4l2-compliance and v4l2-ctl depend on librt and libpthread. The symbols
> > >> are found by the linker only if these libraries are specified after the
> > >> objects that depend on them.
> > >>
> > >> As LDFLAGS variable end up expanded on libtool command line before LDADD,
> > >> move the libraries to LDADD after local objects. -lpthread is added as on
> > >> some systems librt depends on libpthread. This is the case on Ubuntu 
> > >> 16.04
> > >> for instance.
> > >>
> > >> After this patch, creating a static build using the command
> > >>
> > >> LDFLAGS="--static -static" ./configure --disable-shared --enable-static  
> > > 
> > > It sounds weird to use LDFLAGS="--static -static" here, as the
> > > configure options are already asking for static.
> > > 
> > > IMHO, the right way would be to change configure.ac to add those LDFLAGS
> > > when --disable-shared is used.  
> > 
> > That's one option, but then shared libraries won't be built at all.
> 
> Well, my understanding is that  --disable-shared is meant to disable
> building the shared library build :)
> 
> > I'm
> > not sure what would be the use cases for that, though: static linking
> > isn't very commonly needed except when you need to run the binaries
> > elsewhere (for whatever reason) where you don't have the libraries you
> > linked against available.
> 
> Yeah, that's the common usage. It is also interesting if someone
> wants to build 2 versions of the same utility, each using a
> different library, for testing purposes.
> 
> The usecase I can't see is to use --disable-shared but keeping
> using the dynamic library for the exec files.

There are three primary options here,

1. build an entirely static binary,
2. build a binary that relies on dynamic libraries as well and
3. build a binary that relies on dynamic libraries outside v4l-utils package
   but that links v4l-utils originating libraries statically.

If you say 3. is not needed then we could just use --disable-shared also to
tell that static binaries are to be built.

3. is always used for libv4l2subdev and libmediactl as the libraries do not
have stable APIs.

> 
> > That's still a separate issue from what this patch fixes.
> > 
> > Ideally it should be possible to link the binaries statically while
> > still building shared libraries: both are built by default right now,
> > yet shared libraries are always used for linking unless you disable
> > shared libraries.
> 
> Well, the point is: if dynamic library build is disabled, it should
> be doing static links that are produced by the build, instead of using
> an already existing set of dynamic libraries present on the system
> (that may not contain the symbols needed by the tool, or miss some
> patches that were on -git).

No, it uses the static libraries that are built at the same time.

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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: g_webcam Isoch high bandwidth transfer

[Bin Liu]

On Fri, Sep 23, 2016 at 10:49:57AM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Bin Liu  writes:
> > +Fengwei Yin per his request.
> >
> > On Thu, Sep 22, 2016 at 10:48:40PM +0300, Felipe Balbi wrote:
> >> 
> >> Hi,
> >> 
> >> Bin Liu  writes:
> >> 
> >> [...]
> >> 
> >> >> Here's one that actually compiles, sorry about that.
> >> >
> >> > No worries, I was sleeping ;-)
> >> >
> >> > I will test it out early next week. Thanks.
> >> 
> >> meanwhile, how about some instructions on how to test this out myself?
> >> How are you using g_webcam and what are you running on host side? Got a
> >> nice list of commands there I can use? I think I can get to bottom of
> >> this much quicker if I can reproduce it locally ;-)
> >
> > On device side:
> > - first patch g_webcam as in my first email in this thread to enable
> >   640x480@30fps;
> > - # modprobe g_webcam streaming_maxpacket=3072
> > - then run uvc-gadget to feed the YUV frames;
> > http://git.ideasonboard.org/uvc-gadget.git
> 
> as is, g_webcam never enumerates to the host. It's calls to

Right, on mainline kernel (I tested 4.8.0-rc7) g_webcam is broken with
DWC3, g_webcam does not enumerate on the host. But it works on v4.4.21.

[snip]

> 
> uvc-gadget keeps printing this error message:
> 
>  159 if ((ret = ioctl(dev->fd, VIDIOC_DQBUF, )) < 0) {
>  160 printf("Unable to dequeue buffer: %s (%d).\n", 
> strerror(errno),
>  161 errno);
>  162 return ret;
>  163 }

I removed this printf, since it floods the console if start uvc-gadget
before connect to the host.

BTY, you don't have to start uvc-gadget first then connect usb cable. I
keep the cable always connected.

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

Re: [Camera Driver] Building as Static v/s Dynamic module

[Mauro Carvalho Chehab]

Em Mon, 26 Sep 2016 14:39:06 +0530
Ajith Raj  escreveu:

> Hi Maintainers,
> 
> I was working on a CPI based camera driver based on soc_camera framework
> which is compiled as a static module in kernel, due to the non-availability
> of modprobe framework.

Don't rely on soc_camera. We're in the process of rework such drivers
to use directly the V4L2 core or to remove them.

> While I was pushing the changes, I got a question from the internel  code
> review that why the driver is being compiled as static while all other
> drivers available in the open source are compiled as dynamic .ko modules.
> 
> I understand that camera as a component need not have to be built static and
> can be added later on the need basis. Is there any reason apart from this?
> Since the modprobe framework is not available, if I build it as dynamic .ko
> module, I need to insert all dependent modules independently and in the
> right order. There are many;
> 
> videobuf2-dma-contig.ko, videobuf2-v4l2.ko, videobuf2-memops.ko,
> videobuf2-vmalloc.ko, …..etc
> v4l2-common.ko, v4l2-mem2mem.ko, v4l2-dv-timings.ko
> soc_mediabus.ko,soc_camera.ko ,……etc
> media.ko, videodev.ko

You don't need to take care of the order, as modprobe inserts them
with the right dependencies automatically. You may need to use the
async probe inside V4L, though, in order to ensure that the main
driver will be initializing the sub-drivers in the right order, as
OF doesn't ensure that.

> Do you see any issues in submitting camera as a static module?
> Or it has to be dynamic? If so, could you please help me understand the
> reasons.

All media drivers should build with modprobe. The more important
reason (at least for my PoV) is that it should be built with
allmodconfig/allyesconfig, and on all architectures, if COMPILE_TEST
Kconfig define is defined.

The rationale is that building the driver this way is required
for us to avoid building problems. Also, some static code analyzers
we have (Coverity) only runs on x86.

Another thing is that drivers that don't accept dynamic module load 
very likely have hidden bugs (usually, race bugs, PM support issues,
dynamic bind/unbind issues).

> 
> Thanks in advance.
> 
> Regards,
> Ajith
> --
> 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



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: solo6010 modprobe lockup since e1ceb25a (v4.3 regression)

[Andrey Utkin]

On Mon, Sep 26, 2016 at 07:38:05AM +0200, Krzysztof Hałasa wrote:
> Andrey Utkin  writes:
> 
> > On Thu, Sep 22, 2016 at 10:51:37AM +0200, Krzysztof Hałasa wrote:
> >> I wonder if the following fixes the problem (completely untested).
> >
> > I have given this a run, and it still hangs.
> 
> Does (only) adding the
> 
>   pci_read_config_word(solo_dev->pdev, PCI_STATUS, );
> 
> in solo_reg_write() help?

Yes.
I have posted a patch with this change few days ago, I thought you have
noticed it.
--
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

[Camera Driver] Building as Static v/s Dynamic module

[Ajith Raj]

Hi Maintainers,

I was working on a CPI based camera driver based on soc_camera framework
which is compiled as a static module in kernel, due to the non-availability
of modprobe framework.
While I was pushing the changes, I got a question from the internel  code
review that why the driver is being compiled as static while all other
drivers available in the open source are compiled as dynamic .ko modules.

I understand that camera as a component need not have to be built static and
can be added later on the need basis. Is there any reason apart from this?
Since the modprobe framework is not available, if I build it as dynamic .ko
module, I need to insert all dependent modules independently and in the
right order. There are many;

videobuf2-dma-contig.ko, videobuf2-v4l2.ko, videobuf2-memops.ko,
videobuf2-vmalloc.ko, …..etc
v4l2-common.ko, v4l2-mem2mem.ko, v4l2-dv-timings.ko
soc_mediabus.ko,soc_camera.ko ,……etc
media.ko, videodev.ko

Do you see any issues in submitting camera as a static module?
Or it has to be dynamic? If so, could you please help me understand the
reasons.

Thanks in advance.

Regards,
Ajith
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] media: adv7604: automatic "default-input" selection

[Laurent Pinchart]

Hi Ulrich,

Thank you for the patch.

On Thursday 22 Sep 2016 15:19:00 Ulrich Hecht wrote:
> Documentation states that the "default-input" property should reside
> directly in the node of the device.  This adjusts the parsing to make the
> implementation consistent with the documentation.
> 
> Based on patch by William Towle .
> 
> Signed-off-by: Ulrich Hecht 
> Signed-off-by: Hans Verkuil 

Acked-by: Laurent Pinchart 

> ---
>  drivers/media/i2c/adv7604.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
> index 4003831..fa7046e 100644
> --- a/drivers/media/i2c/adv7604.c
> +++ b/drivers/media/i2c/adv7604.c
> @@ -3074,13 +3074,13 @@ static int adv76xx_parse_dt(struct adv76xx_state
> *state) return ret;
>   }
> 
> - if (!of_property_read_u32(endpoint, "default-input", ))
> + of_node_put(endpoint);
> +
> + if (!of_property_read_u32(np, "default-input", ))
>   state->pdata.default_input = v;
>   else
>   state->pdata.default_input = -1;
> 
> - of_node_put(endpoint);
> -
>   flags = bus_cfg.bus.parallel.flags;
> 
>   if (flags & V4L2_MBUS_HSYNC_ACTIVE_HIGH)

-- 
Regards,

Laurent Pinchart

--
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