On 11/21/16, Sean Young wrote:
>>
>> Ah. Here we have a problem. The device (/dev/input/event15)
>> doesn't have a corresponding rcX node, see ir-keytable output below.
>> I had it explained to me like this:
>
> As I said you would need to use a raw IR receiver which has rc-core support
> to deter
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: Tue Nov 22 05:00:22 CET 2016
media-tree git hash:8c1d254f2de803fc7d74269e8ded79047284c275
media_build git
Signed-off-by: Rick Chang
Signed-off-by: Minghsiu Tsai
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 93e9f42..a9e7ee0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7818,6 +7818,13 @@ L: net...@vger.kernel.org
S: Maintained
Signed-off-by: Rick Chang
Signed-off-by: Minghsiu Tsai
---
This patch depends on:
CCF "Add clock support for Mediatek MT2701"[1]
iommu and smi "Add the dtsi node of iommu and smi for mt2701"[2]
[1] http://lists.infradead.org/pipermail/linux-mediatek/2016-October/007271.html
[2] https://patc
Add v4l2 driver for Mediatek JPEG Decoder
Signed-off-by: Rick Chang
Signed-off-by: Minghsiu Tsai
---
drivers/media/platform/Kconfig | 15 +
drivers/media/platform/Makefile |2 +
drivers/media/platform/mtk-jpeg/Makefile |2 +
drivers/media/pla
This series of patches provide a v4l2 driver to control Mediatek JPEG decoder
for decoding JPEG image and Motion JPEG bitstream.
changes since v6:
- fix kbuild test fail
- Add patch for MAINTAINERS
changes since v5:
- remove redundant name from struct mtk_jpeg_fmt
- Set state of all buffers to VB
Add a DT binding documentation for Mediatek JPEG Decoder of
MT2701 SoC.
Signed-off-by: Rick Chang
Signed-off-by: Minghsiu Tsai
Acked-by: Rob Herring
---
.../bindings/media/mediatek-jpeg-decoder.txt | 37 ++
1 file changed, 37 insertions(+)
create mode 100644
Documen
Hi Hans,
On Mon, 2016-11-21 at 15:51 +0100, Hans Verkuil wrote:
> On 17/11/16 04:38, Rick Chang wrote:
> > Signed-off-by: Rick Chang
> > Signed-off-by: Minghsiu Tsai
> > ---
> > This patch depends on:
> > CCF "Add clock support for Mediatek MT2701"[1]
> > iommu and smi "Add the dtsi node of
Hi Hans,
Ok, I will include it in patch v7.
On Mon, 2016-11-21 at 15:53 +0100, Hans Verkuil wrote:
> I'm missing a MAINTAINERS patch for this new driver.
>
> Can you post a patch for that?
>
> It's the only thing preventing this from being merged.
>
> Regards,
>
> Hans
>
> On 17/11/16
Allow getting of subdevs from DT ports and endpoints.
The _get_pdata() function was larely inspired by (i.e. stolen from)
am437x-vpfe.c
Signed-off-by: Kevin Hilman
---
drivers/media/platform/davinci/vpif_capture.c | 130 +-
include/media/davinci/vpif_types.h|
Cc: Rob Herring
Signed-off-by: Kevin Hilman
---
.../bindings/media/ti,da850-vpif-capture.txt | 65 ++
.../devicetree/bindings/media/ti,da850-vpif.txt| 8 +++
2 files changed, 73 insertions(+)
create mode 100644
Documentation/devicetree/bindings/media/ti,da850-vpi
Add basic support for initialization via DT.
Signed-off-by: Kevin Hilman
---
drivers/media/platform/davinci/vpif.c | 9 +
drivers/media/platform/davinci/vpif_capture.c | 14 ++
2 files changed, 23 insertions(+)
diff --git a/drivers/media/platform/davinci/vpif.c
b/d
Video capture subdevs may be over I2C and may sleep during xfer, so we
cannot do IRQ-disabled locking when calling the subdev.
Signed-off-by: Kevin Hilman
---
drivers/media/platform/davinci/vpif_capture.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/media/platform/davinci/vpif_
Add DT support, including getting subdevs from DT ports/endpoints.
Changes since v1:
- more specific compatible strings, based on SoC: ti,da850-vpif*
- fix locking bug when unlocking over subdev s_stream
Kevin Hilman (4):
[media] davinci: add support for DT init
[media] davinci: vpif_capture:
Hans Verkuil writes:
> On 19/11/16 01:32, Kevin Hilman wrote:
>> Video capture subdevs may be over I2C and may sleep during xfer, so we
>> cannot do IRQ-disabled locking when calling the subdev.
>>
>> Signed-off-by: Kevin Hilman
>> ---
>> drivers/media/platform/davinci/vpif_capture.c | 4
>
Arnd Bergmann writes:
> On Friday, November 18, 2016 4:32:08 PM CET Kevin Hilman wrote:
>> +
>> +Required properties:
>> +- compatible: must be "ti,vpif-capture"
>> +- reg: physical base address and length of the registers set for the device;
>> +- interrupts: should contain IRQ line for the VPIF
Signed-off-by: Sean Young
---
MAINTAINERS | 6 +
drivers/media/rc/Kconfig | 17 +
drivers/media/rc/Makefile| 1 +
drivers/media/rc/serial_ir.c | 845 +++
drivers/staging/media/lirc/Kconfig
This makes transmission more reliable and the code much cleaner.
Signed-off-by: Sean Young
---
drivers/staging/media/lirc/lirc_serial.c | 286 +++
1 file changed, 65 insertions(+), 221 deletions(-)
diff --git a/drivers/staging/media/lirc/lirc_serial.c
b/drivers/stag
Tested with a homebrew serial ir. Remove last remmants of the nslu2
which could not be enabled, and fix checkpatch warnings.
Signed-off-by: Sean Young
---
drivers/staging/media/lirc/lirc_serial.c | 677 +--
1 file changed, 274 insertions(+), 403 deletions(-)
diff --g
On Mon, Nov 21, 2016 at 02:28:08PM -0200, Mauro Carvalho Chehab wrote:
> Em Fri, 11 Nov 2016 23:13:06 +
> Sean Young escreveu:
>
> > Tested with a homebrew serial ir. Remove last remmants of the nslu2
> > which could not be enabled.
>
> Thanks for this! It is really nice to see any efforts o
This is certainly not the first time this has been brought up, but I'd like to
try and get some consensus on the best way to move this forward. Allowing
devices to talk directly improves performance and reduces latency by avoiding
the use of staging buffers in system memory. Also in cases wher
Em Mon, 21 Nov 2016 16:44:28 +0100
Johannes Berg escreveu:
> > > > You had pointed me to this plugin before
> > > > https://pythonhosted.org/sphinxcontrib-aafig/
> > > >
> > > > but I don't think it can actually represent any of the pictures.
> > >
> > > No, but there are some ascii art image
Hi Sakari,
Thank you for your feedback.
On 11/17/2016 4:34 PM, Sakari Ailus wrote:
> Hi Ramiro,
>
> Thank you for the patchset. Please see my comments below.
>
> If you've got a CSI-2 receiver, why do you use the DV timing presets? What
> do you use those for?
>
Our CSI-2 Host has two differe
On Fri, Nov 11, 2016 at 08:09:08PM +0800, Andrew-CT Chen wrote:
> Hi linux-firmware maintainers,
>
> The following changes since commit a179db97914da5e650c21ba8f9b0bae04a0f8a41:
>
> amdgpu: update SMC firmware for VI parts (2016-10-05 10:30:11 -0700)
>
> are available in the git repository at:
On 11/21/2016 03:25 PM, Hans Verkuil wrote:
> On 18/11/16 12:25, Hugues Fruchet wrote:
>> This V4L2 driver enables DELTA multi-format video decoder
>> of STMicroelectronics STiH4xx SoC series.
>>
>> Signed-off-by: Hugues Fruchet
>> ---
>> drivers/media/platform/Kconfig| 20 +
>
On 11/21/2016 03:08 PM, Hans Verkuil wrote:
> On 18/11/16 12:25, Hugues Fruchet wrote:
>> Signed-off-by: Hugues Fruchet
>> ---
>> drivers/media/platform/sti/delta/Makefile | 2 +-
>> drivers/media/platform/sti/delta/delta-debug.c | 72
>> ++
>> drivers/media/platf
On Saturday, November 19, 2016 12:56:57 PM CET Mauro Carvalho Chehab wrote:
> As Arnd reported:
>
> With gcc-5 or higher on x86, we can get a bogus warning in the
> dvb-net code:
>
> drivers/media/dvb-core/dvb_net.c: In function ‘dvb_net_ule’:
> arch/x86/include/asm/string
I will add commit message and fix missing space before comment.
On 11/21/2016 02:58 PM, Hans Verkuil wrote:
> Same here: no commit message.
>
> On 18/11/16 12:25, Hugues Fruchet wrote:
>> Signed-off-by: Hugues Fruchet
>> ---
>> drivers/media/platform/sti/delta/delta-v4l2.c | 143
>>
Hi Hans,
Thanks for review, I will change the commit message to "[media]
st-delta: add memory allocator helper functions" and add commit messages.
BR,
Hugues.
On 11/21/2016 02:46 PM, Hans Verkuil wrote:
> This needs a proper commit message since it is not clear who will use this.
>
> I'm not sure
Em Fri, 11 Nov 2016 23:13:06 +
Sean Young escreveu:
> Tested with a homebrew serial ir. Remove last remmants of the nslu2
> which could not be enabled.
Thanks for this! It is really nice to see any efforts on moving the drivers
under staging.
IMHO, it is almost ready for upstream merge, bu
On 11/21/2016 05:33 PM, Hans Verkuil wrote:
> On 21/11/16 16:29, Stanimir Varbanov wrote:
>> Hi Hans,
>>
>> On 11/21/2016 05:04 PM, Hans Verkuil wrote:
>>> On 18/11/16 10:11, Stanimir Varbanov wrote:
Hi Hans,
>>> +
>>> +static int
>>> +vdec_reqbufs(struct file *file, void *f
On Mon, 2016-11-21 at 12:06 -0200, Mauro Carvalho Chehab wrote:
> Em Mon, 21 Nov 2016 11:39:41 +0100
> Johannes Berg escreveu:
> > On Sat, 2016-11-19 at 10:15 -0700, Jonathan Corbet wrote:
> >
> > > Rather than beating our heads against the wall trying to convert
> > > between various image forma
On Mon, 21 Nov 2016, Johannes Berg wrote:
> I had a hack elsewhere that would embed the fixed-width text if the
> plugin isn't present, which seemed like a decent compromise, but nobody
> is willing to let plugins be used in general to start with, it seems :)
FWIW I'm all for doing this stuff in
> > > You had pointed me to this plugin before
> > > https://pythonhosted.org/sphinxcontrib-aafig/
> > >
> > > but I don't think it can actually represent any of the pictures.
> >
> > No, but there are some ascii art images inside some txt/rst files
> > and inside some kernel-doc comments. We co
The following changes since commit f2709c206d8a3e11729e68d80c57e7470bbe8e5e:
Revert "[media] dvb_frontend: merge duplicate dvb_tuner_ops.release
implementations" (2016-11-18 20:44:33 -0200)
are available in the git repository at:
git://linuxtv.org/hverkuil/media_tree.git for-v4.10d
for y
On 21/11/16 16:29, Stanimir Varbanov wrote:
Hi Hans,
On 11/21/2016 05:04 PM, Hans Verkuil wrote:
On 18/11/16 10:11, Stanimir Varbanov wrote:
Hi Hans,
+
+static int
+vdec_reqbufs(struct file *file, void *fh, struct
v4l2_requestbuffers *b)
+{
+struct vb2_queue *queue = to_vb2q(file, b->typ
Hi Hans,
On 11/21/2016 05:04 PM, Hans Verkuil wrote:
> On 18/11/16 10:11, Stanimir Varbanov wrote:
>> Hi Hans,
>>
> +
> +static int
> +vdec_reqbufs(struct file *file, void *fh, struct
> v4l2_requestbuffers *b)
> +{
> +struct vb2_queue *queue = to_vb2q(file, b->type);
>>
Hello guys. I am facing the following error message when plugging in a nice
USB stick:
DVB: Unable to find symbol af9013_attach()
I think this may be very very well a problem of my setup and kernel config:
Linux version 4.9.0-rc5ho+ (mrkiko@gatosaldo) (gcc version 6.2.1 20160830 (GCC)
) #1 SMP
Some CEC adapters will receive messages that they initiated. Add a
check that will ignore such messages.
Most hardware behaves correctly in this respect, but I have seen
adapters that don't, so just filter this out in the framework.
Signed-off-by: Hans Verkuil
---
drivers/media/cec/cec-adap.c
Hi Pavel!
On 11/15/2016 12:10 PM, Pavel Machek wrote:
> Hi!
>
>> Add support for OV5647 sensor.
>>
>
>> +static int ov5647_write(struct v4l2_subdev *sd, u16 reg, u8 val)
>> +{
>> +int ret;
>> +unsigned char data[3] = { reg >> 8, reg & 0xff, val};
>> +struct i2c_client *client = v4l2_
On 18/11/16 10:11, Stanimir Varbanov wrote:
Hi Hans,
+
+static int
+vdec_reqbufs(struct file *file, void *fh, struct v4l2_requestbuffers *b)
+{
+ struct vb2_queue *queue = to_vb2q(file, b->type);
+
+ if (!queue)
+ return -EINVAL;
+
+ return vb2_reqbufs(queue, b);
I'm missing a MAINTAINERS patch for this new driver.
Can you post a patch for that?
It's the only thing preventing this from being merged.
Regards,
Hans
On 17/11/16 04:38, Rick Chang wrote:
This series of patches provide a v4l2 driver to control Mediatek JPEG decoder
for decoding JPE
On 17/11/16 04:38, Rick Chang wrote:
Signed-off-by: Rick Chang
Signed-off-by: Minghsiu Tsai
---
This patch depends on:
CCF "Add clock support for Mediatek MT2701"[1]
iommu and smi "Add the dtsi node of iommu and smi for mt2701"[2]
[1] http://lists.infradead.org/pipermail/linux-mediatek/201
On 19/11/16 01:32, Kevin Hilman wrote:
Video capture subdevs may be over I2C and may sleep during xfer, so we
cannot do IRQ-disabled locking when calling the subdev.
Signed-off-by: Kevin Hilman
---
drivers/media/platform/davinci/vpif_capture.c | 4
1 file changed, 4 insertions(+)
diff --
On 14/11/16 17:46, Jose Abreu wrote:
Hi Hans,
On 11-11-2016 14:52, Hans Verkuil wrote:
Hi Jose,
On 11/09/2016 06:43 PM, Jose Abreu wrote:
Hi All,
This is a RFC patch for Synopsys Designware HDMI RX PHY e405.
This phy receives and decodes HDMI video that is delivered to
a controller. The co
On 18/11/16 12:25, Hugues Fruchet wrote:
This V4L2 driver enables DELTA multi-format video decoder
of STMicroelectronics STiH4xx SoC series.
Signed-off-by: Hugues Fruchet
---
drivers/media/platform/Kconfig| 20 +
drivers/media/platform/Makefile |2 +
drivers
Em Mon, 31 Oct 2016 12:48:05 +0200
Felipe Balbi escreveu:
> We have introduced a helper to calculate multiplier
> value from wMaxPacketSize. Start using it.
Good idea! Btw, we have something similar at em28xx, stk1160-core.c and
tm6000 drivers. On them, we have this:
/* high bandwidth mu
See
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1275718.html for
details.
Also added a davinci compile warning fix that I encountered while
compiling this
series.
Regards,
Hans
The following changes since commit f2709c206d8a3e11729e68d80c57e7470bbe8e5e:
Revert "[m
On Friday, November 18, 2016 4:32:08 PM CET Kevin Hilman wrote:
> +
> +Required properties:
> +- compatible: must be "ti,vpif-capture"
> +- reg: physical base address and length of the registers set for the device;
> +- interrupts: should contain IRQ line for the VPIF
> +
>
Shouldn't this have a
Em Mon, 21 Nov 2016 11:39:41 +0100
Johannes Berg escreveu:
> On Sat, 2016-11-19 at 10:15 -0700, Jonathan Corbet wrote:
> >
> > I don't know what the ultimate source of these images is (Mauro,
> > perhaps you could shed some light there?).
>
> I'd argue that it probably no longer matters. Whet
Em Mon, 21 Nov 2016 15:51:56 +0200
Sakari Ailus escreveu:
> Hi Mauro,
>
> On 11/21/16 15:33, Mauro Carvalho Chehab wrote:
> > Em Thu, 27 Oct 2016 13:50:51 +0300
> > Sakari Ailus escreveu:
> >
> >> struct timeval and struct timespec are defined in linux/time.h. Explicitly
> >> include the hea
On 18/11/16 12:25, Hugues Fruchet wrote:
Signed-off-by: Hugues Fruchet
---
drivers/media/platform/sti/delta/Makefile | 2 +-
drivers/media/platform/sti/delta/delta-debug.c | 72 ++
drivers/media/platform/sti/delta/delta-debug.h | 18 +++
drivers/media/platform/
davinci/vpfe_capture.c: In function 'vpfe_probe':
davinci/vpfe_capture.c:1992:9: warning: 'ret' may be used uninitialized
in this function [-Wmaybe-uninitialized]
return ret;
^~~
This is indeed correct, so if the kmalloc fails set ret to -ENOMEM.
Signed-off-by: Hans Verkuil
---
dif
Same here: no commit message.
On 18/11/16 12:25, Hugues Fruchet wrote:
Signed-off-by: Hugues Fruchet
---
drivers/media/platform/sti/delta/delta-v4l2.c | 143 +-
drivers/media/platform/sti/delta/delta.h | 23 +
2 files changed, 165 insertions(+), 1 deletion(-)
Hi Mauro,
On 11/21/16 15:33, Mauro Carvalho Chehab wrote:
> Em Thu, 27 Oct 2016 13:50:51 +0300
> Sakari Ailus escreveu:
>
>> struct timeval and struct timespec are defined in linux/time.h. Explicitly
>> include the header if __KERNEL__ is defined.
>
> The patch below doesn't do what you're ment
This needs a proper commit message since it is not clear who will use this.
I'm not sure I would call it a 'contiguous memory allocator': this are
really
just helper functions, if I understand it correctly.
'contiguous memory allocator' is also what 'CMA' stands for, so that's
confusing.
No
Em Thu, 27 Oct 2016 13:50:51 +0300
Sakari Ailus escreveu:
> struct timeval and struct timespec are defined in linux/time.h. Explicitly
> include the header if __KERNEL__ is defined.
The patch below doesn't do what you're mentioned above. It unconditionally
include linux/time.h, and, for userspac
On Wed, 2016-11-16 at 19:16 +, Colin King wrote:
> From: Colin Ian King
>
> pdev is dereferenced using platform_get_drvdata before a check to
> see if it is null, hence there could be a potential null pointer
> dereference issue. Instead, first check if pdev is null and only then
> deference
On Sat, 2016-11-19 at 10:15 -0700, Jonathan Corbet wrote:
>
> I don't know what the ultimate source of these images is (Mauro,
> perhaps you could shed some light there?).
I'd argue that it probably no longer matters. Whether it's xfig, svg,
graphviz originally etc. - the source is probably long
59 matches
Mail list logo