I'll try to describe my thoughts.
The changed structure "dib0700_rc_response" is used in
dib0700_core.c:dib0700_rc_urb_completion(struct urb *purb) function:
struct dib0700_rc_response *poll_reply;
...
poll_reply = purb->transfer_buffer;
dib0700_rc_urb_completion() is then used in
dib0700_core.c
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: Thu Feb 12 04:00:26 CET 2015
git branch: test
git hash: d6d4c0e00fe559ef54b414e2e6266beaa50b4d8e
gcc versio
On Thu, Feb 12, 2015 at 01:42:45AM +0200, Antti Palosaari wrote:
> On 02/12/2015 01:38 AM, Luis de Bethencourt wrote:
> >On Wed, Feb 11, 2015 at 10:45:01PM +0100, Matthias Schwarzott wrote:
> >>On 11.02.2015 21:58, Christian Engelmayer wrote:
> >>>In case of an error function si2165_upload_firmware
Moikka!
On 02/12/2015 02:04 AM, Rafael Lourenço de Lima Chehab wrote:
Create a struct media_device and add it to the dvb adapter.
Please notice that the tuner is not mapped yet by the dvb core.
Signed-off-by: Rafael Lourenço de Lima Chehab
---
drivers/media/usb/dvb-usb-v2/dvb_usb.h |
On Tue, Feb 10, 2015 at 11:38:11AM +0100, David Cimbůrek wrote:
> Please include this patch to kernel! It takes too much time for such a
> simple fix!
>
The patch is simple but why it fixes the issue isn't that simple. Could you
explain why the order of the variables inside the structure is break
Create a struct media_device and add it to the dvb adapter.
Please notice that the tuner is not mapped yet by the dvb core.
Signed-off-by: Rafael Lourenço de Lima Chehab
---
drivers/media/usb/dvb-usb-v2/dvb_usb.h | 5 +++
drivers/media/usb/dvb-usb-v2/dvb_usb_core.c | 61 ++
On 02/12/2015 01:38 AM, Luis de Bethencourt wrote:
On Wed, Feb 11, 2015 at 10:45:01PM +0100, Matthias Schwarzott wrote:
On 11.02.2015 21:58, Christian Engelmayer wrote:
In case of an error function si2165_upload_firmware() releases the already
requested firmware in the exit path. However, there
On Wed, Feb 11, 2015 at 10:45:01PM +0100, Matthias Schwarzott wrote:
> On 11.02.2015 21:58, Christian Engelmayer wrote:
> > In case of an error function si2165_upload_firmware() releases the already
> > requested firmware in the exit path. However, there is one deviation where
> > the function dire
On 11.02.2015 21:58, Christian Engelmayer wrote:
> In case of an error function si2165_upload_firmware() releases the already
> requested firmware in the exit path. However, there is one deviation where
> the function directly returns. Use the correct cleanup so that the firmware
> memory gets free
In case of an error function si2165_upload_firmware() releases the already
requested firmware in the exit path. However, there is one deviation where
the function directly returns. Use the correct cleanup so that the firmware
memory gets freed correctly. Detected by Coverity CID 1269120.
Signed-of
Docos says for these pixel formats:
start... : Cb00 Cr00 Cb01 Cr01
start... : Cb10 Cr10 Cb11 Cr11
whereas it should read:
start... : Cb00 Cr00 Cb11 Cr11
start... : Cb20 Cr20 Cb21 Cr21
where ... depends on the exact multi/single planar format.
See e.g. http://linuxtv.org/downloads/v4l-dvb-apis/
Add support for vertical + horizontal subsampled formats to vivid and use it to
generate YU12, YV12, NV12, NV21 as defined in [1,2]. These formats are tightly
packed N planar, because they provide chroma(s) as a separate array, but they
are not mplanar yet, as discussed in the list.
The modus oper
Let me know what exactly do you want me to do (which commands, which
traces etc.). I'm not very familiar with the Linux media stuff...
2015-02-11 15:40 GMT+01:00 David Härdeman :
> Can you generate some scancodes before and after commit
> af3a4a9bbeb00df3e42e77240b4cdac5479812f9?
>
>
>
> On 2015-0
On Wed, Feb 11, 2015 at 01:20:24PM +0100, Marek Szyprowski wrote:
> Hello,
>
> On 2015-02-11 12:12, Russell King - ARM Linux wrote:
> >Which is a damn good reason to NAK it - by that admission, it's a half-baked
> >idea.
> >
> >If all we want to know is whether the importer can accept only contigu
Can you generate some scancodes before and after commit
af3a4a9bbeb00df3e42e77240b4cdac5479812f9?
On 2015-02-11 14:53, David Cimbůrek wrote:
David Härdeman: I'm using defaults, I have no custom modifications.
2015-02-11 14:24 GMT+01:00 David Härdeman :
David C: are you using the in-kernel k
+ CONFIG_USB=m,
CONFIG_MEDIA_SUPPORT=m, CONFIG_MEDIA_ANALOG_TV_SUPPORT=y
CONFIG_MEDIA_DIGITAL_TV_SUPPORT=y, (implies VIDEO_V4L2=m)
CONFIG_MEDIA_RADIO_SUPPORT=y, CONFIG_RADIO_SI470X=y
CONFIG_USB_SI470X=m
Patch is against 3.19.0 (localversion-next is -next-20150211)
drivers/media/radio/si470x/radio
return type of wait_for_completion_timeout is unsigned long not int. A
appropriately named variable of type unsigned long is added and the
assignments fixed up.
Signed-off-by: Nicholas Mc Guire
---
Patch was only compile tested with
Patch is against 3.19.0 (localversion-next is -next-20150211
David Härdeman: I'm using defaults, I have no custom modifications.
2015-02-11 14:24 GMT+01:00 David Härdeman :
> David C: are you using the in-kernel keymap or loading a custom one?
>
>
> On 2015-02-10 11:45, Antti Palosaari wrote:
>>
>> David Härdeman,
>> Could you look that as it is your patch
On Wed, Feb 11, 2015 at 7:56 AM, Daniel Vetter wrote:
> On Wed, Feb 11, 2015 at 06:23:52AM -0500, Rob Clark wrote:
>> On Wed, Feb 11, 2015 at 6:12 AM, Russell King - ARM Linux
>> wrote:
>> > As I've already pointed out, there's a major problem if you have already
>> > had a less restrictive attac
David C: are you using the in-kernel keymap or loading a custom one?
On 2015-02-10 11:45, Antti Palosaari wrote:
David Härdeman,
Could you look that as it is your patch which has broken it
commit af3a4a9bbeb00df3e42e77240b4cdac5479812f9
Author: David Härdeman
Date: Thu Apr 3 20:31:51 2014 -0
On 02/11/2015 01:08 PM, Luis de Bethencourt wrote:
Cleaning up the following compiler warning:
rtl2832.c:703:12: warning: 'tmp' may be used uninitialized in this function
Even though it could never happen since if rtl2832_rd_demod_reg () doesn't set
tmp, this line would never run because we go t
On Wed, Feb 11, 2015 at 06:23:52AM -0500, Rob Clark wrote:
> On Wed, Feb 11, 2015 at 6:12 AM, Russell King - ARM Linux
> wrote:
> > As I've already pointed out, there's a major problem if you have already
> > had a less restrictive attachment which has an active mapping, and a new
> > more restric
Hello,
On 2015-02-11 12:12, Russell King - ARM Linux wrote:
On Wed, Feb 11, 2015 at 09:28:37AM +0100, Marek Szyprowski wrote:
On 2015-01-27 09:25, Sumit Semwal wrote:
Add some helpers to share the constraints of devices while attaching
to the dmabuf buffer.
At each attach, the constraints are
Hello again,
does anyone have any suggestions why USERPTR still fails with dma-sg?
Could I just disable the corresponding capability for the moment so that
the patch could perhaps be merged, and investigate this separately?
Best, Florian
On 04.02.2015 16:30, Florian Echtler wrote:
> This patch
On Wed, Feb 11, 2015 at 6:12 AM, Russell King - ARM Linux
wrote:
> On Wed, Feb 11, 2015 at 09:28:37AM +0100, Marek Szyprowski wrote:
>> Hello,
>>
>> On 2015-01-27 09:25, Sumit Semwal wrote:
>> >Add some helpers to share the constraints of devices while attaching
>> >to the dmabuf buffer.
>> >
>> >
On Tue, Feb 10, 2015 at 09:35:52PM -0200, Mauro Carvalho Chehab wrote:
> Em Tue, 10 Feb 2015 12:57:24 +0200
> Antti Palosaari escreveu:
>
> > On 02/09/2015 12:44 AM, Luis de Bethencourt wrote:
> > > Cleaning the following compiler warning:
> > > rtl2832.c:703:12: warning: 'tmp' may be used uninit
On Wed, Feb 11, 2015 at 09:28:37AM +0100, Marek Szyprowski wrote:
> Hello,
>
> On 2015-01-27 09:25, Sumit Semwal wrote:
> >Add some helpers to share the constraints of devices while attaching
> >to the dmabuf buffer.
> >
> >At each attach, the constraints are calculated based on the following:
> >
Cleaning up the following compiler warning:
rtl2832.c:703:12: warning: 'tmp' may be used uninitialized in this function
Even though it could never happen since if rtl2832_rd_demod_reg () doesn't set
tmp, this line would never run because we go to err. It is still nice to avoid
compiler warnings.
Hello,
On 2015-02-11 11:33, Ricardo Ribalda Delgado wrote:
dma_map_sg returns the number of areas mapped by the hardware,
which could be different than the areas given as an input.
The output must be saved to nent.
Signed-off-by: Ricardo Ribalda Delgado
Reviewed-by: Marek Szyprowski
---
Hello,
On 2015-02-11 11:33, Ricardo Ribalda Delgado wrote:
dma_map_sg returns the number of areas mapped by the hardware,
which could be different than the areas given as an input.
The output must be saved to nent.
Signed-off-by: Ricardo Ribalda Delgado
Reviewed-by: Marek Szyprowski
---
Hello,
On 2015-02-11 11:33, Ricardo Ribalda Delgado wrote:
When sg_alloc_table_from_pages() does not fail it returns a sg_table
structure with nents and nents_orig initialized to the same value.
dma_map_sg returns the number of areas mapped by the hardware,
which could be different than the are
dma_map_sg returns the number of areas mapped by the hardware,
which could be different than the areas given as an input.
The output must be saved to nent.
Signed-off-by: Ricardo Ribalda Delgado
---
drivers/media/v4l2-core/videobuf2-dma-contig.c | 6 +++---
1 file changed, 3 insertions(+), 3 del
dma_map_sg returns the number of areas mapped by the hardware,
which could be different than the areas given as an input.
The output must be saved to nent.
Signed-off-by: Ricardo Ribalda Delgado
---
drivers/media/v4l2-core/videobuf2-vmalloc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deleti
When sg_alloc_table_from_pages() does not fail it returns a sg_table
structure with nents and nents_orig initialized to the same value.
dma_map_sg returns the number of areas mapped by the hardware,
which could be different than the areas given as an input.
The output must be saved to nent.
The o
Hello again
On Wed, Feb 11, 2015 at 10:00 AM, Marek Szyprowski
wrote:
> Well, this int return value seems to be misleading, but according to
> Documentation/DMA-API.txt, the only error value is zero:
>
> "As with the other mapping interfaces, dma_map_sg() can fail. When it
> does, 0 is returned
Hello,
On 2015-02-11 09:37, Ricardo Ribalda Delgado wrote:
Hello Marek
On Wed, Feb 11, 2015 at 9:06 AM, Marek Szyprowski
wrote:
Unfortunately nent differs in sign to the output of dma_map_sg, so an
intermediate value must be used.
I don't get this part. dma_map_sg() returns the number of sca
Hello Marek
On Wed, Feb 11, 2015 at 9:06 AM, Marek Szyprowski
wrote:
>> Unfortunately nent differs in sign to the output of dma_map_sg, so an
>> intermediate value must be used.
>
>
> I don't get this part. dma_map_sg() returns the number of scatter list
> entries mapped
> to the hardware or zero
Hello,
On 2015-01-27 09:25, Sumit Semwal wrote:
Add some helpers to share the constraints of devices while attaching
to the dmabuf buffer.
At each attach, the constraints are calculated based on the following:
- max_segment_size, max_segment_count, segment_boundary_mask from
device_dma_para
Hello,
On 2015-02-09 17:14, Ricardo Ribalda Delgado wrote:
when sg_alloc_table_from_pages() does not fail it returns a sg_table
structure with nents and nents_orig initialized to the same value.
dma_map_sg returns the dma_map_sg returns the number of areas mapped
by the hardware, which could be
Hello,
On 2015-02-09 17:14, Ricardo Ribalda Delgado wrote:
when sg_alloc_table_from_pages() does not fail it returns a sg_table
structure with nents and nents_orig initialized to the same value.
dma_map_sg returns the dma_map_sg returns the number of areas mapped
by the hardware, which could be
40 matches
Mail list logo
