Re: [PATCH] v4l2: don't warn before we release buffer
On 07/24/2014 05:53 AM, Scott Jiang wrote:
In fact we only need to give a warning if the driver still use the
buffer after we release all queued buffers.
Signed-off-by: Scott Jiang scott.jiang.li...@gmail.com
Nacked-by: Hans Verkuil hans.verk...@cisco.com
You're removing the warning telling you that your driver has a bug instead
of fixing the driver bug itself. In stop_streaming the driver must hand over
any buffers it owns to vb2 (vb2_buffer_done(..., STATE_ERROR)). If it doesn't
you'll get this warning and vb2 will forcefully reclaim them, quite possibly
leaving the driver with a corrupt buffer list.
The same should occur in start_streaming if an error occurs. In that case
start_streaming must return the buffers to STATE_DEQUEUED.
So fix your driver instead :-)
Regards,
Hans
---
drivers/media/v4l2-core/videobuf2-core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 7c4489c..fa5dd73 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2112,7 +2112,7 @@ static void __vb2_queue_cancel(struct vb2_queue *q)
if (q-start_streaming_called)
call_void_qop(q, stop_streaming, q);
- if (WARN_ON(atomic_read(q-owned_by_drv_count))) {
+ if (atomic_read(q-owned_by_drv_count)) {
for (i = 0; i q-num_buffers; ++i)
if (q-bufs[i]-state == VB2_BUF_STATE_ACTIVE)
vb2_buffer_done(q-bufs[i],
VB2_BUF_STATE_ERROR);
--
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 for v3.17] vb2: fix videobuf2-core.h comments
A lot of work was done in vb2 to regulate how drivers and the vb2 core handle
buffer ownership, but inexplicably the videobuf2-core.h comments were never
updated. Do so now. The same was true for the replacement of the -ENOBUFS
mechanism by the min_buffers_needed field.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 1a262ae..fc910a6 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -294,15 +294,19 @@ struct vb2_buffer {
* of already queued buffers in count parameter; driver
* can return an error if hardware fails, in that case all
* buffers that have been already given by the @buf_queue
- * callback are invalidated.
- * If there were not enough queued buffers to start
- * streaming, then this callback returns -ENOBUFS, and the
- * vb2 core will retry calling @start_streaming when a new
- * buffer is queued.
+ * callback are to be returned by the driver by calling
+ * @vb2_buffer_done(VB2_BUF_STATE_DEQUEUED).
+ * If you need a minimum number of buffers before you can
+ * start streaming, then set @min_buffers_needed in the
+ * vb2_queue structure. If that is non-zero then
+ * start_streaming won't be called until at least that
+ * many buffers have been queued up by userspace.
* @stop_streaming:called when 'streaming' state must be disabled; driver
* should stop any DMA transactions or wait until they
* finish and give back all buffers it got from buf_queue()
- * callback; may use vb2_wait_for_all_buffers() function
+ * callback by calling @vb2_buffer_done() with either
+ * VB2_BUF_STATE_DONE or VB2_BUF_STATE_ERROR; may use
+ * vb2_wait_for_all_buffers() function
* @buf_queue: passes buffer vb to the driver; driver may start
* hardware operation on this buffer; driver should give
* the buffer back by calling vb2_buffer_done() function;
--
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: [V4l2-library] FourCC support
On 07/23/2014 07:04 AM, Monica, Agnes wrote: Hi, It would be good if support exists for full and limited range. 1. So can we re-use(map) the existing colorspace for our different color format. Well, no, obviously. You need to propose new colorspace defines. The list of colorspace defines is in videodev2.h. the best procedure is to post an RFC to the linux-media mailinglist with the new defines that you need and explain why you need them. The next step would be to write patches adding those defines and updating the DocBook documentation (Documentation/DocBook/media/v4l/pixfmt.xml). Contact me first before working on the docbook since I plan on rewriting that section. There is always a chicken-and-egg problem in that a driver actually need to use the new defines before they can go in. However, in this case you can try to add support for it to e.g. adv7604 and/or adv7511. That might be the fastest way of getting it in. 2. Or is it a good way to use custom control command. Absolutely not. Colorspace handling is done through the colorspace defines. So if you need new ones, just add them properly. For what chip(s) are you developing? Quite a few adv drivers are already in the kernel. Perhaps it is wise to coordinate this? In particular, take a look at existing drivers like the adv7604 and adv7511. So in future if we come across some specific features with respect to our chip, is it good to use custom control or duplicate the functionality of the existing enums. First you ask on the mailinglist, then we can give an answer what the best approach will be. Abuse of existing APIs will make it very hard if not impossible to get such a driver merged in the kernel. So please don't do that. In general either proper support should be added to v4l2 for the feature you want to add, or it is a driver-specific control or ioctl. But all too often what you think is driver specific is really a lot more common than you thought. But above all, ask first on the mailinglist! If your goal is to upstream the drivers (I hope so, speaking as one customer of Analog), then please avoid taking shortcuts. It will only cause problems later. I'm happy to help out with pointers, review, etc. Regards, Hans Regards, Monica -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Tuesday, July 22, 2014 1:08 PM To: Monica, Agnes; v4l2-libr...@linuxtv.org; linux-media; Lars-Peter Clausen Subject: Re: [V4l2-library] FourCC support On 07/22/14 09:23, Hans Verkuil wrote: Hi Monica, The v4l2-library is not the best mailinglist for that so I've added linux-media as well, which is more appropriate. I've also added Lars-Peter since he does a lot of adv work as well. The short answer is that those colorspaces are not supported at the moment, but that it is not a problem to add them, provided the driver you are working on is going to be upstreamed (i.e., we'd like to have users for the API elements we add). One note of interest: there is currently no API mechanism to tell userspace if the image data is limited or full range. YCbCr is always assumed to be limited range and RGB full range. If you need to signal that, then let me know. A flags field has been added to struct v4l2_pix_format in the last few days that would allow you to add a 'ALT_RANGE' flag, telling userspace that the alternate quantization range is used. This flag doesn't exist yet, but it is no problem to add it. To prevent any confusion: the colorspace isn't determined by the format fourcc, it's a separate colorspace field using the V4L2_COLORSPACE_* defines. The pixelformat and colorspace are two very different things. Regards, Hans Hope this helps, Hans On 07/22/14 08:18, Monica, Agnes wrote: Hi , One of drivers which we are developing supports formats like sYcc , AdobeRGB and AdobeYCC601 which was added recently in HDMI spec1.4. So can you please tell me how will these formats be supported by fmt. Regards, Monica -- 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: [linuxtv-media:master 378/499] ERROR: __udivdi3 [drivers/media/dvb-frontends/rtl2832_sdr.ko] undefined!
Moikka! On 07/23/2014 02:20 PM, kbuild test robot wrote: tree: git://linuxtv.org/media_tree.git master head: eb9da073bd002f2968c84129a5c49625911a3199 commit: 77bbb2b049c1c3e935f5bec510bec337d94ae8f8 [378/499] rtl2832_sdr: move from staging to media config: i386-randconfig-ha2-0723 (attached as .config) Note: the linuxtv-media/master HEAD eb9da073bd002f2968c84129a5c49625911a3199 builds fine. It only hurts bisectibility. All error/warnings: ERROR: __udivdi3 [drivers/media/dvb-frontends/rtl2832_sdr.ko] undefined! Could you say what I should do for that? Bug is fixed and solution is merged as that patch: commit a98ccfcf4804beb2651b9f44a4bc5cbb387019ec Author: Antti Palosaari cr...@iki.fi Date: Tue Jul 22 00:18:19 2014 -0300 [media] rtl2832_sdr: remove plain 64-bit divisions Do you want Mauro to rebase whole media/master in order to make bisectibility possible in any case? regards Antti -- http://palosaari.fi/ -- 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 5/6] r8a7790.dtsi: add vin[0-3] nodes
Hi Ben,
Who is going to take this patch? Simon? It can go in independently from
the V4L part, right? We just have to be sure, that bindings don't have to
change, and this is likely to be the case. Doesn't it have to be Cc'ed to
DT maintainers and the list?
Thanks
Guennadi
On Sat, 5 Jul 2014, Ben Dooks wrote:
Add nodes for the four video input channels on the R8A7790.
Signed-off-by: Ben Dooks ben.do...@codethink.co.uk
---
arch/arm/boot/dts/r8a7790.dtsi | 36
1 file changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 7ff2960..a6f083d 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -33,6 +33,10 @@
spi2 = msiof1;
spi3 = msiof2;
spi4 = msiof3;
+ vin0 = vin0;
+ vin1 = vin1;
+ vin2 = vin2;
+ vin3 = vin3;
};
cpus {
@@ -462,6 +466,38 @@
status = disabled;
};
+ vin0: vin@e6ef {
+ compatible = renesas,vin-r8a7790;
+ clocks = mstp8_clks R8A7790_CLK_VIN0;
+ reg = 0 0xe6ef 0 0x1000;
+ interrupts = 0 188 IRQ_TYPE_LEVEL_HIGH;
+ status = disabled;
+ };
+
+ vin1: vin@e6ef1000 {
+ compatible = renesas,vin-r8a7790;
+ clocks = mstp8_clks R8A7790_CLK_VIN1;
+ reg = 0 0xe6ef1000 0 0x1000;
+ interrupts = 0 189 IRQ_TYPE_LEVEL_HIGH;
+ status = disabled;
+ };
+
+ vin2: vin@e6ef2000 {
+ compatible = renesas,vin-r8a7790;
+ clocks = mstp8_clks R8A7790_CLK_VIN2;
+ reg = 0 0xe6ef2000 0 0x1000;
+ interrupts = 0 190 IRQ_TYPE_LEVEL_HIGH;
+ status = disabled;
+ };
+
+ vin3: vin@e6ef3000 {
+ compatible = renesas,vin-r8a7790;
+ clocks = mstp8_clks R8A7790_CLK_VIN3;
+ reg = 0 0xe6ef3000 0 0x1000;
+ interrupts = 0 191 IRQ_TYPE_LEVEL_HIGH;
+ status = disabled;
+ };
+
clocks {
#address-cells = 2;
#size-cells = 2;
--
2.0.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: [PATCH 6/6] [PATCH v2] ARM: lager: add vin1 node
Same for this one - who takes it and is CC sufficient?
Thanks
Guennadi
On Sat, 5 Jul 2014, Ben Dooks wrote:
Add device-tree for vin1 (composite video in) on the
lager board.
Signed-off-by: Ben Dooks ben.do...@codethink.co.uk
---
Fixes since v1:
- Whitespace fixes as suggested by Sergei
---
arch/arm/boot/dts/r8a7790-lager.dts | 36
1 file changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7790-lager.dts
b/arch/arm/boot/dts/r8a7790-lager.dts
index 4805c9f..e00543b 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -214,6 +214,11 @@
renesas,groups = i2c2;
renesas,function = i2c2;
};
+
+ vin1_pins: vin {
+ renesas,groups = vin1_data8, vin1_clk;
+ renesas,function = vin1;
+ };
};
ether {
@@ -342,8 +347,39 @@
status = ok;
pinctrl-0 = i2c2_pins;
pinctrl-names = default;
+
+ composite-in@20 {
+ compatible = adi,adv7180;
+ reg = 0x20;
+ remote = vin1;
+
+ port {
+ adv7180: endpoint {
+ bus-width = 8;
+ remote-endpoint = vin1ep0;
+ };
+ };
+ };
};
i2c3{
status = ok;
};
+
+/* composite video input */
+vin1 {
+ pinctrl-0 = vin1_pins;
+ pinctrl-names = default;
+
+ status = ok;
+
+ port {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ vin1ep0: endpoint {
+ remote-endpoint = adv7180;
+ bus-width = 8;
+ };
+ };
+};
--
2.0.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: [linuxtv-media:master 378/499] ERROR: __udivdi3 [drivers/media/dvb-frontends/rtl2832_sdr.ko] undefined!
Hi Antti, This is just a notification. It's up to human to decide the impact and whether or not to do the rebase (which very much depends on the publicness of the tree and git committer's work style). Thanks, Fengguang On Wed, Jul 23, 2014 at 09:43:08AM +0300, Antti Palosaari wrote: Moikka! On 07/23/2014 02:20 PM, kbuild test robot wrote: tree: git://linuxtv.org/media_tree.git master head: eb9da073bd002f2968c84129a5c49625911a3199 commit: 77bbb2b049c1c3e935f5bec510bec337d94ae8f8 [378/499] rtl2832_sdr: move from staging to media config: i386-randconfig-ha2-0723 (attached as .config) Note: the linuxtv-media/master HEAD eb9da073bd002f2968c84129a5c49625911a3199 builds fine. It only hurts bisectibility. All error/warnings: ERROR: __udivdi3 [drivers/media/dvb-frontends/rtl2832_sdr.ko] undefined! Could you say what I should do for that? Bug is fixed and solution is merged as that patch: commit a98ccfcf4804beb2651b9f44a4bc5cbb387019ec Author: Antti Palosaari cr...@iki.fi Date: Tue Jul 22 00:18:19 2014 -0300 [media] rtl2832_sdr: remove plain 64-bit divisions Do you want Mauro to rebase whole media/master in order to make bisectibility possible in any case? regards Antti -- http://palosaari.fi/ -- 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] si2168: Fix unknown chip version message
Moikka! It is single character formatter, not string, = no need to terminate, so that patch is not valid. regards Antti On 07/22/2014 10:14 PM, Mauro Carvalho Chehab wrote: At least here with my PCTV 292e, it is printing this error: si2168 10-0064: si2168: unkown chip version Si21170- without a \n at the end. Probably because it is doing something weird or firmware didn't load well. Anyway, better to print it in hex, instead of using %c. While here, fix the typo. Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com --- drivers/media/dvb-frontends/si2168.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/media/dvb-frontends/si2168.c b/drivers/media/dvb-frontends/si2168.c index 41bdbc4d9f6c..842c4a555d01 100644 --- a/drivers/media/dvb-frontends/si2168.c +++ b/drivers/media/dvb-frontends/si2168.c @@ -414,9 +414,8 @@ static int si2168_init(struct dvb_frontend *fe) break; default: dev_err(s-client-dev, - %s: unkown chip version Si21%d-%c%c%c\n, - KBUILD_MODNAME, cmd.args[2], cmd.args[1], - cmd.args[3], cmd.args[4]); + %s: unknown chip version: 0x%04x\n, + KBUILD_MODNAME, chip_id); ret = -EINVAL; goto err; } -- http://palosaari.fi/ -- 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 5/6] r8a7790.dtsi: add vin[0-3] nodes
On Wed, Jul 23, 2014 at 10:09:46AM +0200, Guennadi Liakhovetski wrote:
Hi Ben,
Who is going to take this patch? Simon? It can go in independently from
the V4L part, right? We just have to be sure, that bindings don't have to
change, and this is likely to be the case. Doesn't it have to be Cc'ed to
DT maintainers and the list?
Hi Guennadi,
my expectation is that I will take this and patch once the bindings have
been accepted by the subsystem maintainer.
For the board DT change my expectation is as above plus that
someone has independently tested that the device is initialised
and usable (for some definition of usable).
With regards to CCing DT maintainers, I believe that they like to be CCed
on driver changes that add or update bindings. I'm unsure if they also like
to be CCed on DT file changes. Its not something I've blocked on in the
past with regards to DT file changes.
Thanks
Guennadi
On Sat, 5 Jul 2014, Ben Dooks wrote:
Add nodes for the four video input channels on the R8A7790.
Signed-off-by: Ben Dooks ben.do...@codethink.co.uk
---
arch/arm/boot/dts/r8a7790.dtsi | 36
1 file changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7790.dtsi b/arch/arm/boot/dts/r8a7790.dtsi
index 7ff2960..a6f083d 100644
--- a/arch/arm/boot/dts/r8a7790.dtsi
+++ b/arch/arm/boot/dts/r8a7790.dtsi
@@ -33,6 +33,10 @@
spi2 = msiof1;
spi3 = msiof2;
spi4 = msiof3;
+ vin0 = vin0;
+ vin1 = vin1;
+ vin2 = vin2;
+ vin3 = vin3;
};
cpus {
@@ -462,6 +466,38 @@
status = disabled;
};
+ vin0: vin@e6ef {
+ compatible = renesas,vin-r8a7790;
+ clocks = mstp8_clks R8A7790_CLK_VIN0;
+ reg = 0 0xe6ef 0 0x1000;
+ interrupts = 0 188 IRQ_TYPE_LEVEL_HIGH;
+ status = disabled;
+ };
+
+ vin1: vin@e6ef1000 {
+ compatible = renesas,vin-r8a7790;
+ clocks = mstp8_clks R8A7790_CLK_VIN1;
+ reg = 0 0xe6ef1000 0 0x1000;
+ interrupts = 0 189 IRQ_TYPE_LEVEL_HIGH;
+ status = disabled;
+ };
+
+ vin2: vin@e6ef2000 {
+ compatible = renesas,vin-r8a7790;
+ clocks = mstp8_clks R8A7790_CLK_VIN2;
+ reg = 0 0xe6ef2000 0 0x1000;
+ interrupts = 0 190 IRQ_TYPE_LEVEL_HIGH;
+ status = disabled;
+ };
+
+ vin3: vin@e6ef3000 {
+ compatible = renesas,vin-r8a7790;
+ clocks = mstp8_clks R8A7790_CLK_VIN3;
+ reg = 0 0xe6ef3000 0 0x1000;
+ interrupts = 0 191 IRQ_TYPE_LEVEL_HIGH;
+ status = disabled;
+ };
+
clocks {
#address-cells = 2;
#size-cells = 2;
--
2.0.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: [PATCH] si2168: Add ts_mode config.
Moikka
This cannot work. You refer config struct that is coming outside of
driver. That means, caller must keep stuct, but it does not, and I
really don't even like idea to leave it responsibility of caller. Due to
that you will need copy all config values to driver state before return
from probe().
regards
Antti
On 07/22/2014 06:54 PM, Luis Alves wrote:
This patch adds the TS mode as a config option:
- ts_mode added to config struct.
- Possible (interesting) values are
* Parallel mode = 0x06
* Serial mode = 0x03
Currently the modules using this demod only use parallel mode.
Regards,
Luis
Signed-off-by: Luis Alves lja...@gmail.com
---
drivers/media/dvb-frontends/si2168.c | 17 ++---
drivers/media/dvb-frontends/si2168.h | 6 ++
drivers/media/usb/dvb-usb/cxusb.c | 1 +
drivers/media/usb/em28xx/em28xx-dvb.c | 1 +
4 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/media/dvb-frontends/si2168.c
b/drivers/media/dvb-frontends/si2168.c
index 41bdbc4..d45a1c6 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -297,13 +297,6 @@ static int si2168_set_frontend(struct dvb_frontend *fe)
if (ret)
goto err;
- memcpy(cmd.args, \x14\x00\x01\x10\x16\x00, 6);
- cmd.wlen = 6;
- cmd.rlen = 4;
- ret = si2168_cmd_execute(s, cmd);
- if (ret)
- goto err;
-
memcpy(cmd.args, \x14\x00\x09\x10\xe3\x18, 6);
cmd.wlen = 6;
cmd.rlen = 4;
@@ -350,6 +343,7 @@ err:
static int si2168_init(struct dvb_frontend *fe)
{
struct si2168 *s = fe-demodulator_priv;
+ struct si2168_config *config = s-client-dev.platform_data;
int ret, len, remaining;
const struct firmware *fw = NULL;
u8 *fw_file;
@@ -479,6 +473,15 @@ static int si2168_init(struct dvb_frontend *fe)
dev_info(s-client-dev, %s: found a '%s' in warm state\n,
KBUILD_MODNAME, si2168_ops.info.name);
+ /* Set TSMODE */
+ memcpy(cmd.args, \x14\x00\x01\x10\x10\x00, 6);
+ cmd.args[4] |= config-ts_mode;
+ cmd.wlen = 6;
+ cmd.rlen = 4;
+ ret = si2168_cmd_execute(s, cmd);
+ if (ret)
+ goto err;
+
s-active = true;
return 0;
diff --git a/drivers/media/dvb-frontends/si2168.h
b/drivers/media/dvb-frontends/si2168.h
index 3c5b5ab..ebbf309 100644
--- a/drivers/media/dvb-frontends/si2168.h
+++ b/drivers/media/dvb-frontends/si2168.h
@@ -34,6 +34,12 @@ struct si2168_config {
* returned by driver
*/
struct i2c_adapter **i2c_adapter;
+
+ /* TS mode */
+ u8 ts_mode;
};
+#define SI2168_TSMODE_PARALLEL 0x06
+#define SI2168_TSMODE_SERIAL 0x03
+
#endif
diff --git a/drivers/media/usb/dvb-usb/cxusb.c
b/drivers/media/usb/dvb-usb/cxusb.c
index b7461ac..18a2720 100644
--- a/drivers/media/usb/dvb-usb/cxusb.c
+++ b/drivers/media/usb/dvb-usb/cxusb.c
@@ -1369,6 +1369,7 @@ static int cxusb_tt_ct2_4400_attach(struct
dvb_usb_adapter *adap)
/* attach frontend */
si2168_config.i2c_adapter = adapter;
si2168_config.fe = adap-fe_adap[0].fe;
+ si2168_config.ts_mode = SI2168_TSMODE_PARALLEL;
memset(info, 0, sizeof(struct i2c_board_info));
strlcpy(info.type, si2168, I2C_NAME_SIZE);
info.addr = 0x64;
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c
b/drivers/media/usb/em28xx/em28xx-dvb.c
index 96a0bdb..27d5d84 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -1525,6 +1525,7 @@ static int em28xx_dvb_init(struct em28xx *dev)
/* attach demod */
si2168_config.i2c_adapter = adapter;
si2168_config.fe = dvb-fe[0];
+ si2168_config.ts_mode = SI2168_TSMODE_PARALLEL;
memset(info, 0, sizeof(struct i2c_board_info));
strlcpy(info.type, si2168, I2C_NAME_SIZE);
info.addr = 0x64;
--
http://palosaari.fi/
--
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: [linuxtv-media:master 378/499] ERROR: __udivdi3 [drivers/media/dvb-frontends/rtl2832_sdr.ko] undefined!
Moikka Fengguang OK, lets Mauro decide how to handle that 32-bit(?) build error. Could you change kbuild test robot clock to current time. It seems to live still in future :) regards Antti On 07/23/2014 11:21 AM, Fengguang Wu wrote: Hi Antti, This is just a notification. It's up to human to decide the impact and whether or not to do the rebase (which very much depends on the publicness of the tree and git committer's work style). Thanks, Fengguang On Wed, Jul 23, 2014 at 09:43:08AM +0300, Antti Palosaari wrote: Moikka! On 07/23/2014 02:20 PM, kbuild test robot wrote: tree: git://linuxtv.org/media_tree.git master head: eb9da073bd002f2968c84129a5c49625911a3199 commit: 77bbb2b049c1c3e935f5bec510bec337d94ae8f8 [378/499] rtl2832_sdr: move from staging to media config: i386-randconfig-ha2-0723 (attached as .config) Note: the linuxtv-media/master HEAD eb9da073bd002f2968c84129a5c49625911a3199 builds fine. It only hurts bisectibility. All error/warnings: ERROR: __udivdi3 [drivers/media/dvb-frontends/rtl2832_sdr.ko] undefined! Could you say what I should do for that? Bug is fixed and solution is merged as that patch: commit a98ccfcf4804beb2651b9f44a4bc5cbb387019ec Author: Antti Palosaari cr...@iki.fi Date: Tue Jul 22 00:18:19 2014 -0300 [media] rtl2832_sdr: remove plain 64-bit divisions Do you want Mauro to rebase whole media/master in order to make bisectibility possible in any case? regards Antti -- http://palosaari.fi/ -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] get_dvb_firmware: Add firmware extractor for si2165
Moikka Matthias
On 07/22/2014 11:12 PM, Matthias Schwarzott wrote:
Signed-off-by: Matthias Schwarzott z...@gentoo.org
---
Documentation/dvb/get_dvb_firmware | 33 -
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/Documentation/dvb/get_dvb_firmware
b/Documentation/dvb/get_dvb_firmware
index d91b8be..26c623d 100755
--- a/Documentation/dvb/get_dvb_firmware
+++ b/Documentation/dvb/get_dvb_firmware
@@ -29,7 +29,7 @@ use IO::Handle;
af9015, ngene, az6027, lme2510_lg, lme2510c_s7395,
lme2510c_s7395_old, drxk, drxk_terratec_h5,
drxk_hauppauge_hvr930c, tda10071, it9135, drxk_pctv,
- drxk_terratec_htc_stick, sms1xxx_hcw);
+ drxk_terratec_htc_stick, sms1xxx_hcw, si2165);
# Check args
syntax() if (scalar(@ARGV) != 1);
@@ -783,6 +783,37 @@ sub sms1xxx_hcw {
$allfiles;
}
+sub si2165 {
+my $sourcefile = model_111xxx_122xxx_driver_6_0_119_31191_WHQL.zip;
+my $url = http://www.hauppauge.de/files/drivers/;;
+my $hash = 76633e7c76b0edee47c3ba18ded99336;
+my $fwfile = dvb-demod-si2165.fw;
+my $tmpdir = tempdir(DIR = /tmp, CLEANUP = 1);
+
+checkstandard();
+
+wgetfile($sourcefile, $url . $sourcefile);
+verify($sourcefile, $hash);
+unzip($sourcefile, $tmpdir);
+extract($tmpdir/Driver10/Hcw10bda.sys, 0x80788, 0x81E08-0x80788,
$tmpdir/fw1);
+
+delzero($tmpdir/fw1,$tmpdir/fw1-1);
+#verify($tmpdir/fw1,5e0909858fdf0b5b09ad48b9fe622e70);
+
+my $CRC=\x0A\xCC;
+my $BLOCKS_MAIN=\x27;
+open FW,$fwfile;
+print FW \x01\x00; # just a version id for the driver itself
+print FW \x9A; # fw version
+print FW \x00; # padding
+print FW $BLOCKS_MAIN; # number of blocks of main part
+print FW \x00; # padding
+print FW $CRC; # 16bit crc value of main part
+appendfile(FW,$tmpdir/fw1);
I have to say I little bit dislike that kind of own headers. There is no
way to read firmware version from binary itself (very often there is)?
Whats is benefit of telling how many blocks there is? Isn't it possible
to detect somehow by examining firmware image itself runtime?
Anyhow, you are the author of that driver and even I don't personally
like those, I think it is up to your decision as a author.
regards
Antti
+
+$fwfile;
+}
+
# ---
# Utilities
--
http://palosaari.fi/
--
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: [linuxtv-media:master 378/499] ERROR: __udivdi3 [drivers/media/dvb-frontends/rtl2832_sdr.ko] undefined!
On Wed, Jul 23, 2014 at 12:10:12PM +0300, Antti Palosaari wrote: Moikka Fengguang OK, lets Mauro decide how to handle that 32-bit(?) build error. Could you change kbuild test robot clock to current time. It seems to live still in future :) It looks like a time zone issue. :) Thanks, Fengguang On 07/23/2014 11:21 AM, Fengguang Wu wrote: Hi Antti, This is just a notification. It's up to human to decide the impact and whether or not to do the rebase (which very much depends on the publicness of the tree and git committer's work style). Thanks, Fengguang On Wed, Jul 23, 2014 at 09:43:08AM +0300, Antti Palosaari wrote: Moikka! On 07/23/2014 02:20 PM, kbuild test robot wrote: tree: git://linuxtv.org/media_tree.git master head: eb9da073bd002f2968c84129a5c49625911a3199 commit: 77bbb2b049c1c3e935f5bec510bec337d94ae8f8 [378/499] rtl2832_sdr: move from staging to media config: i386-randconfig-ha2-0723 (attached as .config) Note: the linuxtv-media/master HEAD eb9da073bd002f2968c84129a5c49625911a3199 builds fine. It only hurts bisectibility. All error/warnings: ERROR: __udivdi3 [drivers/media/dvb-frontends/rtl2832_sdr.ko] undefined! Could you say what I should do for that? Bug is fixed and solution is merged as that patch: commit a98ccfcf4804beb2651b9f44a4bc5cbb387019ec Author: Antti Palosaari cr...@iki.fi Date: Tue Jul 22 00:18:19 2014 -0300 [media] rtl2832_sdr: remove plain 64-bit divisions Do you want Mauro to rebase whole media/master in order to make bisectibility possible in any case? regards Antti -- http://palosaari.fi/ -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/2] media: soc_camera: pxa_camera device-tree support
Hi Robert,
Thanks for an updated patch. One question:
On Sun, 29 Jun 2014, Robert Jarzmik wrote:
Add device-tree support to pxa_camera host driver.
Signed-off-by: Robert Jarzmik robert.jarz...@free.fr
---
Since V1: Mark's review
- tmp u32 to long conversion for clock rate
- use device-tree clock binding for mclk output clock
- wildcard pxa27x becomes pxa270
---
drivers/media/platform/soc_camera/pxa_camera.c | 80
+-
1 file changed, 78 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/soc_camera/pxa_camera.c
b/drivers/media/platform/soc_camera/pxa_camera.c
index d4df305..e76c2ab 100644
--- a/drivers/media/platform/soc_camera/pxa_camera.c
+++ b/drivers/media/platform/soc_camera/pxa_camera.c
@@ -34,6 +34,7 @@
#include media/videobuf-dma-sg.h
#include media/soc_camera.h
#include media/soc_mediabus.h
+#include media/v4l2-of.h
#include linux/videodev2.h
@@ -1650,6 +1651,67 @@ static struct soc_camera_host_ops
pxa_soc_camera_host_ops = {
.set_bus_param = pxa_camera_set_bus_param,
};
+static int pxa_camera_pdata_from_dt(struct device *dev,
+ struct pxa_camera_dev *pcdev)
+{
+ int err = 0;
+ u32 mclk_rate = 0;
+ struct device_node *np = dev-of_node;
+ struct v4l2_of_endpoint ep;
+
+ err = of_property_read_u32(np, clock-frequency,
+mclk_rate);
+ if (!err) {
+ pcdev-platform_flags |= PXA_CAMERA_MCLK_EN;
+ pcdev-mclk = mclk_rate;
+ }
+
+ np = of_graph_get_next_endpoint(np, NULL);
Isn't an of_node_put() required after this?
Thanks
Guennadi
+ if (!np) {
+ dev_err(dev, could not find endpoint\n);
+ return -EINVAL;
+ }
+
+ err = v4l2_of_parse_endpoint(np, ep);
+ if (err) {
+ dev_err(dev, could not parse endpoint\n);
+ return err;
+ }
+
+ switch (ep.bus.parallel.bus_width) {
+ case 4:
+ pcdev-platform_flags |= PXA_CAMERA_DATAWIDTH_4;
+ break;
+ case 5:
+ pcdev-platform_flags |= PXA_CAMERA_DATAWIDTH_5;
+ break;
+ case 8:
+ pcdev-platform_flags |= PXA_CAMERA_DATAWIDTH_8;
+ break;
+ case 9:
+ pcdev-platform_flags |= PXA_CAMERA_DATAWIDTH_9;
+ break;
+ case 10:
+ pcdev-platform_flags |= PXA_CAMERA_DATAWIDTH_10;
+ break;
+ default:
+ break;
+ };
+
+ if (ep.bus.parallel.flags V4L2_MBUS_MASTER)
+ pcdev-platform_flags |= PXA_CAMERA_MASTER;
+ if (ep.bus.parallel.flags V4L2_MBUS_HSYNC_ACTIVE_HIGH)
+ pcdev-platform_flags |= PXA_CAMERA_HSP;
+ if (ep.bus.parallel.flags V4L2_MBUS_VSYNC_ACTIVE_HIGH)
+ pcdev-platform_flags |= PXA_CAMERA_VSP;
+ if (ep.bus.parallel.flags V4L2_MBUS_PCLK_SAMPLE_RISING)
+ pcdev-platform_flags |= PXA_CAMERA_PCLK_EN | PXA_CAMERA_PCP;
+ if (ep.bus.parallel.flags V4L2_MBUS_PCLK_SAMPLE_FALLING)
+ pcdev-platform_flags |= PXA_CAMERA_PCLK_EN;
+
+ return 0;
+}
+
static int pxa_camera_probe(struct platform_device *pdev)
{
struct pxa_camera_dev *pcdev;
@@ -1676,7 +1738,15 @@ static int pxa_camera_probe(struct platform_device
*pdev)
pcdev-res = res;
pcdev-pdata = pdev-dev.platform_data;
- pcdev-platform_flags = pcdev-pdata-flags;
+ if (pdev-dev.of_node !pcdev-pdata) {
+ err = pxa_camera_pdata_from_dt(pdev-dev, pcdev);
+ } else {
+ pcdev-platform_flags = pcdev-pdata-flags;
+ pcdev-mclk = pcdev-pdata-mclk_10khz * 1;
+ }
+ if (err 0)
+ return err;
+
if (!(pcdev-platform_flags (PXA_CAMERA_DATAWIDTH_8 |
PXA_CAMERA_DATAWIDTH_9 | PXA_CAMERA_DATAWIDTH_10))) {
/*
@@ -1693,7 +1763,6 @@ static int pxa_camera_probe(struct platform_device
*pdev)
pcdev-width_flags |= 1 8;
if (pcdev-platform_flags PXA_CAMERA_DATAWIDTH_10)
pcdev-width_flags |= 1 9;
- pcdev-mclk = pcdev-pdata-mclk_10khz * 1;
if (!pcdev-mclk) {
dev_warn(pdev-dev,
mclk == 0! Please, fix your platform data.
@@ -1799,10 +1868,17 @@ static const struct dev_pm_ops pxa_camera_pm = {
.resume = pxa_camera_resume,
};
+static const struct of_device_id pxa_camera_of_match[] = {
+ { .compatible = marvell,pxa270-qci, },
+ {},
+};
+MODULE_DEVICE_TABLE(of, pxa_camera_of_match);
+
static struct platform_driver pxa_camera_driver = {
.driver = {
.name = PXA_CAM_DRV_NAME,
.pm = pxa_camera_pm,
+ .of_match_table = of_match_ptr(pxa_camera_of_match),
},
.probe = pxa_camera_probe,
.remove
Re: [PATCH] si2168: Add ts_mode config.
Hi Antti,
Yes, I know. I already had asked Mauro to reject it (on irc).
I'll send a fixed one soon.
Regards,
Luis
On Wed, Jul 23, 2014 at 10:04 AM, Antti Palosaari cr...@iki.fi wrote:
Moikka
This cannot work. You refer config struct that is coming outside of driver.
That means, caller must keep stuct, but it does not, and I really don't even
like idea to leave it responsibility of caller. Due to that you will need
copy all config values to driver state before return from probe().
regards
Antti
On 07/22/2014 06:54 PM, Luis Alves wrote:
This patch adds the TS mode as a config option:
- ts_mode added to config struct.
- Possible (interesting) values are
* Parallel mode = 0x06
* Serial mode = 0x03
Currently the modules using this demod only use parallel mode.
Regards,
Luis
Signed-off-by: Luis Alves lja...@gmail.com
---
drivers/media/dvb-frontends/si2168.c | 17 ++---
drivers/media/dvb-frontends/si2168.h | 6 ++
drivers/media/usb/dvb-usb/cxusb.c | 1 +
drivers/media/usb/em28xx/em28xx-dvb.c | 1 +
4 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/media/dvb-frontends/si2168.c
b/drivers/media/dvb-frontends/si2168.c
index 41bdbc4..d45a1c6 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -297,13 +297,6 @@ static int si2168_set_frontend(struct dvb_frontend
*fe)
if (ret)
goto err;
- memcpy(cmd.args, \x14\x00\x01\x10\x16\x00, 6);
- cmd.wlen = 6;
- cmd.rlen = 4;
- ret = si2168_cmd_execute(s, cmd);
- if (ret)
- goto err;
-
memcpy(cmd.args, \x14\x00\x09\x10\xe3\x18, 6);
cmd.wlen = 6;
cmd.rlen = 4;
@@ -350,6 +343,7 @@ err:
static int si2168_init(struct dvb_frontend *fe)
{
struct si2168 *s = fe-demodulator_priv;
+ struct si2168_config *config = s-client-dev.platform_data;
int ret, len, remaining;
const struct firmware *fw = NULL;
u8 *fw_file;
@@ -479,6 +473,15 @@ static int si2168_init(struct dvb_frontend *fe)
dev_info(s-client-dev, %s: found a '%s' in warm state\n,
KBUILD_MODNAME, si2168_ops.info.name);
+ /* Set TSMODE */
+ memcpy(cmd.args, \x14\x00\x01\x10\x10\x00, 6);
+ cmd.args[4] |= config-ts_mode;
+ cmd.wlen = 6;
+ cmd.rlen = 4;
+ ret = si2168_cmd_execute(s, cmd);
+ if (ret)
+ goto err;
+
s-active = true;
return 0;
diff --git a/drivers/media/dvb-frontends/si2168.h
b/drivers/media/dvb-frontends/si2168.h
index 3c5b5ab..ebbf309 100644
--- a/drivers/media/dvb-frontends/si2168.h
+++ b/drivers/media/dvb-frontends/si2168.h
@@ -34,6 +34,12 @@ struct si2168_config {
* returned by driver
*/
struct i2c_adapter **i2c_adapter;
+
+ /* TS mode */
+ u8 ts_mode;
};
+#define SI2168_TSMODE_PARALLEL 0x06
+#define SI2168_TSMODE_SERIAL 0x03
+
#endif
diff --git a/drivers/media/usb/dvb-usb/cxusb.c
b/drivers/media/usb/dvb-usb/cxusb.c
index b7461ac..18a2720 100644
--- a/drivers/media/usb/dvb-usb/cxusb.c
+++ b/drivers/media/usb/dvb-usb/cxusb.c
@@ -1369,6 +1369,7 @@ static int cxusb_tt_ct2_4400_attach(struct
dvb_usb_adapter *adap)
/* attach frontend */
si2168_config.i2c_adapter = adapter;
si2168_config.fe = adap-fe_adap[0].fe;
+ si2168_config.ts_mode = SI2168_TSMODE_PARALLEL;
memset(info, 0, sizeof(struct i2c_board_info));
strlcpy(info.type, si2168, I2C_NAME_SIZE);
info.addr = 0x64;
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c
b/drivers/media/usb/em28xx/em28xx-dvb.c
index 96a0bdb..27d5d84 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -1525,6 +1525,7 @@ static int em28xx_dvb_init(struct em28xx *dev)
/* attach demod */
si2168_config.i2c_adapter = adapter;
si2168_config.fe = dvb-fe[0];
+ si2168_config.ts_mode = SI2168_TSMODE_PARALLEL;
memset(info, 0, sizeof(struct i2c_board_info));
strlcpy(info.type, si2168, I2C_NAME_SIZE);
info.addr = 0x64;
--
http://palosaari.fi/
--
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/3] v4l2: bfin: Ensure delete and reinit list entry on NOMMU architecture
From: Sonic Zhang sonic.zh...@analog.com
On NOMMU architecture page fault is not triggered if a deleted list entry is
accessed without reinit.
Signed-off-by: Sonic Zhang sonic.zh...@analog.com
---
drivers/media/platform/blackfin/bfin_capture.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/blackfin/bfin_capture.c
b/drivers/media/platform/blackfin/bfin_capture.c
index 2759cb6..4a8c4f0 100644
--- a/drivers/media/platform/blackfin/bfin_capture.c
+++ b/drivers/media/platform/blackfin/bfin_capture.c
@@ -446,7 +446,7 @@ static void bcap_stop_streaming(struct vb2_queue *vq)
while (!list_empty(bcap_dev-dma_queue)) {
bcap_dev-cur_frm = list_entry(bcap_dev-dma_queue.next,
struct bcap_buffer, list);
- list_del(bcap_dev-cur_frm-list);
+ list_del_init(bcap_dev-cur_frm-list);
vb2_buffer_done(bcap_dev-cur_frm-vb, VB2_BUF_STATE_ERROR);
}
}
@@ -533,7 +533,7 @@ static irqreturn_t bcap_isr(int irq, void *dev_id)
}
bcap_dev-cur_frm = list_entry(bcap_dev-dma_queue.next,
struct bcap_buffer, list);
- list_del(bcap_dev-cur_frm-list);
+ list_del_init(bcap_dev-cur_frm-list);
} else {
/* clear error flag, we will get a new frame */
if (ppi-err)
@@ -583,7 +583,7 @@ static int bcap_streamon(struct file *file, void *priv,
bcap_dev-cur_frm = list_entry(bcap_dev-dma_queue.next,
struct bcap_buffer, list);
/* remove buffer from the dma queue */
- list_del(bcap_dev-cur_frm-list);
+ list_del_init(bcap_dev-cur_frm-list);
addr = vb2_dma_contig_plane_dma_addr(bcap_dev-cur_frm-vb, 0);
/* update DMA address */
ppi-ops-update_addr(ppi, (unsigned long)addr);
--
1.8.2.3
--
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 3/3] v4l2: blackfin: select proper pinctrl state in ppi_set_params if CONFIG_PINCTRL is enabled
From: Sonic Zhang sonic.zh...@analog.com
Multiple pinctrl states are defined for 8, 16 and 24 data pin groups in PPI
peripheral.
The driver should select correct group before set up further PPI parameters.
Signed-off-by: Sonic Zhang sonic.zh...@analog.com
---
drivers/media/platform/blackfin/ppi.c | 17 +
include/media/blackfin/ppi.h | 1 +
2 files changed, 18 insertions(+)
diff --git a/drivers/media/platform/blackfin/ppi.c
b/drivers/media/platform/blackfin/ppi.c
index 90c4a93..cff63e5 100644
--- a/drivers/media/platform/blackfin/ppi.c
+++ b/drivers/media/platform/blackfin/ppi.c
@@ -206,6 +206,20 @@ static int ppi_set_params(struct ppi_if *ppi, struct
ppi_params *params)
int dma_config, bytes_per_line;
int hcount, hdelay, samples_per_line;
+#ifdef CONFIG_PINCTRL
+ static const char * const pin_state[] = {8bit, 16bit, 24bit};
+ struct pinctrl *pctrl;
+ struct pinctrl_state *pstate;
+
+ if (params-dlen 24 || params-dlen = 0)
+ return -EINVAL;
+ pctrl = devm_pinctrl_get(ppi-dev);
+ pstate = pinctrl_lookup_state(pctrl,
+ pin_state[(params-dlen + 7) / 8 - 1]);
+ if (pinctrl_select_state(pctrl, pstate))
+ return -EINVAL;
+#endif
+
bytes_per_line = params-width * params-bpp / 8;
/* convert parameters unit from pixels to samples */
hcount = params-width * params-bpp / params-dlen;
@@ -316,10 +330,12 @@ struct ppi_if *ppi_create_instance(struct platform_device
*pdev,
if (!info || !info-pin_req)
return NULL;
+#ifndef CONFIG_PINCTRL
if (peripheral_request_list(info-pin_req, KBUILD_MODNAME)) {
dev_err(pdev-dev, request peripheral failed\n);
return NULL;
}
+#endif
ppi = kzalloc(sizeof(*ppi), GFP_KERNEL);
if (!ppi) {
@@ -329,6 +345,7 @@ struct ppi_if *ppi_create_instance(struct platform_device
*pdev,
}
ppi-ops = ppi_ops;
ppi-info = info;
+ ppi-dev = pdev-dev;
pr_info(ppi probe success\n);
return ppi;
diff --git a/include/media/blackfin/ppi.h b/include/media/blackfin/ppi.h
index 61a283f..4900bae 100644
--- a/include/media/blackfin/ppi.h
+++ b/include/media/blackfin/ppi.h
@@ -83,6 +83,7 @@ struct ppi_info {
};
struct ppi_if {
+ struct device *dev;
unsigned long ppi_control;
const struct ppi_ops *ops;
const struct ppi_info *info;
--
1.8.2.3
--
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/3] media: blackfin: ppi: Pass device pointer to request peripheral pins
From: Sonic Zhang sonic.zh...@analog.com
if the pinctrl driver is enabled.
Signed-off-by: Sonic Zhang sonic.zh...@analog.com
---
drivers/media/platform/blackfin/bfin_capture.c | 2 +-
drivers/media/platform/blackfin/ppi.c | 8 +---
include/media/blackfin/ppi.h | 3 ++-
3 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/media/platform/blackfin/bfin_capture.c
b/drivers/media/platform/blackfin/bfin_capture.c
index 16e4b1c..2759cb6 100644
--- a/drivers/media/platform/blackfin/bfin_capture.c
+++ b/drivers/media/platform/blackfin/bfin_capture.c
@@ -939,7 +939,7 @@ static int bcap_probe(struct platform_device *pdev)
bcap_dev-cfg = config;
- bcap_dev-ppi = ppi_create_instance(config-ppi_info);
+ bcap_dev-ppi = ppi_create_instance(pdev, config-ppi_info);
if (!bcap_dev-ppi) {
v4l2_err(pdev-dev.driver, Unable to create ppi\n);
ret = -ENODEV;
diff --git a/drivers/media/platform/blackfin/ppi.c
b/drivers/media/platform/blackfin/ppi.c
index 15e9c2b..90c4a93 100644
--- a/drivers/media/platform/blackfin/ppi.c
+++ b/drivers/media/platform/blackfin/ppi.c
@@ -19,6 +19,7 @@
#include linux/module.h
#include linux/slab.h
+#include linux/platform_device.h
#include asm/bfin_ppi.h
#include asm/blackfin.h
@@ -307,7 +308,8 @@ static void ppi_update_addr(struct ppi_if *ppi, unsigned
long addr)
set_dma_start_addr(ppi-info-dma_ch, addr);
}
-struct ppi_if *ppi_create_instance(const struct ppi_info *info)
+struct ppi_if *ppi_create_instance(struct platform_device *pdev,
+ const struct ppi_info *info)
{
struct ppi_if *ppi;
@@ -315,14 +317,14 @@ struct ppi_if *ppi_create_instance(const struct ppi_info
*info)
return NULL;
if (peripheral_request_list(info-pin_req, KBUILD_MODNAME)) {
- pr_err(request peripheral failed\n);
+ dev_err(pdev-dev, request peripheral failed\n);
return NULL;
}
ppi = kzalloc(sizeof(*ppi), GFP_KERNEL);
if (!ppi) {
peripheral_free_list(info-pin_req);
- pr_err(unable to allocate memory for ppi handle\n);
+ dev_err(pdev-dev, unable to allocate memory for ppi
handle\n);
return NULL;
}
ppi-ops = ppi_ops;
diff --git a/include/media/blackfin/ppi.h b/include/media/blackfin/ppi.h
index d0697f4..61a283f 100644
--- a/include/media/blackfin/ppi.h
+++ b/include/media/blackfin/ppi.h
@@ -91,6 +91,7 @@ struct ppi_if {
void *priv;
};
-struct ppi_if *ppi_create_instance(const struct ppi_info *info);
+struct ppi_if *ppi_create_instance(struct platform_device *pdev,
+ const struct ppi_info *info);
void ppi_delete_instance(struct ppi_if *ppi);
#endif
--
1.8.2.3
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Media bus pixel code and pixel format enumeration (was: )
Hello Sakari, thank you for your reply (and finding a nice subject for this)! On Mon, Jul 21, 2014 at 02:35:39PM +0200, Peter Meerwald wrote: how can I query the supported pixel format(s) of a sensor connected via media-ctl and exposed via /dev/videoX there is VIDIOC_ENUM_FMT (which fails) and VIDIOC_SUBDEV_ENUM_MBUS_CODE (which works, but on a subdev, not on /dev/videoX) v4l2_subdev_video_ops has .enum_mbus_fmt (this is SoC camera stuff?) v4l2_subdev_pad_ops has .enum_mbus_code the application just sees /dev/videoX and cannot do VIDIOC_ENUM_FMT what is the logic behind this? shouldn't a compabatibility layer be added turning VIDIOC_ENUM_FMT into VIDIOC_SUBDEV_ENUM_MBUS_CODE? The issue has been that enumerating should not change the state of the device. Within a single device node things are fine, but in this case the media bus pixel code at the other end of the link affects the result of the enumeration. good to know this has been considered before There hasn't been really a solution for this in the past; what has been discussed as possible options have been (at least to my recollection) but none has been implemented: 1) Use the media bux pixel code from the other end of the link. As there is no common file handle to share the state with, the link configuration and setting the media bus pixel code are necessary state changes before the enumeration can take place, and the two must not be changed during the it. This breaks the separation between configuration and enumeration. (There has been a patch to the omap3isp driver which essentially did this long time ago AFAIR.) 2) Use a reserved field in struct v4l2_fmtdesc to tell the pixel code. This way enumeration can stay separate from configuration and is probably easier for the user space as well. I vote for this: it's clean, simple and gets the job done. I not sure if I fully understand your suggestion let's assume the following setup: sensor (subdev8) - OMAP3 CCDC (subdev2) - output (video2) userspace would query VIDIOC_ENUM_FMT on video2; what is the expected answer? and how would it be obtained? for me it would be good enough if first configuration via media-ctl is done, and ENUM_FMT video2 would just return at least one FMT that can be set so configuration would be fixed, I'm not interested in all possible FMTs regards, p. -- Peter Meerwald +43-664-218 (mobile) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] rcar_vin: add devicetree support
Hi Ben,
I'd love to push this for 3.17, but we have to at least show this to DT
maintainers... Personally, I have one remark:
On Sat, 5 Jul 2014, Ben Dooks wrote:
Add support for devicetree probe for the rcar-vin
driver.
Signed-off-by: Ben Dooks ben.do...@codethink.co.uk
---
.../devicetree/bindings/media/rcar_vin.txt | 86
++
drivers/media/platform/soc_camera/rcar_vin.c | 72 --
2 files changed, 151 insertions(+), 7 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/rcar_vin.txt
diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt
b/Documentation/devicetree/bindings/media/rcar_vin.txt
new file mode 100644
index 000..10fefa9
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
@@ -0,0 +1,86 @@
+Renesas RCar Video Input driver (rcar_vin)
+--
+
+The rcar_vin device provides video input capabilities for the Renesas R-Car
+family of devices. The current blocks are always slaves and suppot one input
+channel which can be either RGB, YUYV or BT656.
+
+ - compatible: Must be one of the following
+ - renesas,vin-r8a7791 for the R8A7791 device
+ - renesas,vin-r8a7790 for the R8A7790 device
+ - renesas,vin-r8a7779 for the R8A7779 device
+ - renesas,vin-r8a7778 for the R8A7778 device
+ - reg: the register base and size for the device registers
+ - interrupts: the interrupt for the device
+ - clocks: Reference to the parent clock
+
+Additionally, an alias named vinX will need to be created to specify
+which video input device this is.
+
+The per-board settings:
+ - port sub-node describing a single endpoint connected to the vin
+ as described in video-interfaces.txt[1]. Only the first one will
+ be considered as each vin interface has one input port.
+
+ These settings are used to work out video input format and widths
+ into the system.
+
+
+Device node example
+---
+
+ aliases {
+vin0 = vin0;
+ };
+
+vin0: vin@0xe6ef {
+compatible = renesas,vin-r8a7790;
+clocks = mstp8_clks R8A7790_CLK_VIN0;
+reg = 0 0xe6ef 0 0x1000;
+interrupts = 0 188 IRQ_TYPE_LEVEL_HIGH;
+status = disabled;
+};
+
+Board setup example (vin1 composite video input)
+
+
+i2c2 {
+status = ok;
+pinctrl-0 = i2c2_pins;
+pinctrl-names = default;
+
+adv7180@020 {
The above should be
+adv7180@20 {
no 0 in the I2C address. 020 looks like an octal number, which it isn't.
I'll fix this and try to resubmit today with extended Cc.
Thanks
Guennadi
+compatible = adi,adv7180;
+reg = 0x20;
+remote = vin1;
+
+port {
+adv7180: endpoint {
+bus-width = 8;
+remote-endpoint = vin1ep0;
+};
+};
+};
+};
+
+/* composite video input */
+vin1 {
+pinctrl-0 = vin1_pins;
+pinctrl-names = default;
+
+status = ok;
+
+port {
+#address-cells = 1;
+#size-cells = 0;
+
+vin1ep0: endpoint {
+remote-endpoint = adv7180;
+bus-width = 8;
+};
+};
+};
+
+
+
+[1] video-interfaces.txt common video media interface
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index 7c4299d..eb196ef 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -24,6 +24,8 @@
#include linux/pm_runtime.h
#include linux/slab.h
#include linux/videodev2.h
+#include linux/of.h
+#include linux/of_device.h
#include media/soc_camera.h
#include media/soc_mediabus.h
@@ -32,6 +34,7 @@
#include media/v4l2-device.h
#include media/v4l2-mediabus.h
#include media/v4l2-subdev.h
+#include media/v4l2-of.h
#include media/videobuf2-dma-contig.h
#include soc_scale_crop.h
@@ -1390,6 +1393,17 @@ static struct soc_camera_host_ops rcar_vin_host_ops = {
.init_videobuf2 = rcar_vin_init_videobuf2,
};
+#ifdef CONFIG_OF
+static struct of_device_id rcar_vin_of_table[] = {
+ { .compatible = renesas,vin-r8a7791, .data = (void *)RCAR_GEN2 },
+ { .compatible = renesas,vin-r8a7790, .data = (void *)RCAR_GEN2 },
+ { .compatible = renesas,vin-r8a7779, .data = (void *)RCAR_H1 },
+ { .compatible = renesas,vin-r8a7778, .data = (void *)RCAR_M1 },
+ { },
+};
+MODULE_DEVICE_TABLE(of, rcar_vin_of_table);
+#endif
+
static struct platform_device_id rcar_vin_id_table[] = {
{ r8a7791-vin, RCAR_GEN2 },
{
Re: Media bus pixel code and pixel format enumeration (was: )
Hi Peter, On Wed, Jul 23, 2014 at 11:58:24AM +0200, Peter Meerwald wrote: Hello Sakari, thank you for your reply (and finding a nice subject for this)! On Mon, Jul 21, 2014 at 02:35:39PM +0200, Peter Meerwald wrote: how can I query the supported pixel format(s) of a sensor connected via media-ctl and exposed via /dev/videoX there is VIDIOC_ENUM_FMT (which fails) and VIDIOC_SUBDEV_ENUM_MBUS_CODE (which works, but on a subdev, not on /dev/videoX) v4l2_subdev_video_ops has .enum_mbus_fmt (this is SoC camera stuff?) v4l2_subdev_pad_ops has .enum_mbus_code the application just sees /dev/videoX and cannot do VIDIOC_ENUM_FMT what is the logic behind this? shouldn't a compabatibility layer be added turning VIDIOC_ENUM_FMT into VIDIOC_SUBDEV_ENUM_MBUS_CODE? The issue has been that enumerating should not change the state of the device. Within a single device node things are fine, but in this case the media bus pixel code at the other end of the link affects the result of the enumeration. good to know this has been considered before There hasn't been really a solution for this in the past; what has been discussed as possible options have been (at least to my recollection) but none has been implemented: 1) Use the media bux pixel code from the other end of the link. As there is no common file handle to share the state with, the link configuration and setting the media bus pixel code are necessary state changes before the enumeration can take place, and the two must not be changed during the it. This breaks the separation between configuration and enumeration. (There has been a patch to the omap3isp driver which essentially did this long time ago AFAIR.) 2) Use a reserved field in struct v4l2_fmtdesc to tell the pixel code. This way enumeration can stay separate from configuration and is probably easier for the user space as well. I vote for this: it's clean, simple and gets the job done. I not sure if I fully understand your suggestion let's assume the following setup: sensor (subdev8) - OMAP3 CCDC (subdev2) - output (video2) userspace would query VIDIOC_ENUM_FMT on video2; what is the expected answer? and how would it be obtained? In addition to the index, the user would also supply the media bus pixel code to VIDIOC_ENUM_FMT (see URL:http://hverkuil.home.xs4all.nl/spec/media.html#v4l2-mbus-pixelcode) that corresponds to pixel code at the output pad of the OMAP3 CCDC above. This way you can make the connection between media bus pixel codes you have on sub-devices and the pixel formats you can use on video devices. Albeit there are common connections between the two, the mapping ultimately depends on hardware. -- 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: [linuxtv-media:master 378/499] ERROR: __udivdi3 [drivers/media/dvb-frontends/rtl2832_sdr.ko] undefined!
Em Wed, 23 Jul 2014 12:10:12 +0300 Antti Palosaari cr...@iki.fi escreveu: Moikka Fengguang OK, lets Mauro decide how to handle that 32-bit(?) build error. Once the patch is merged, I don't care anymore about avoiding bisect, especially on 32 bits kernels. The harm of rebasing my tree is worse than breaking bisectability, specially on 32 bits, as almost all developers do git bisect on x86_64 nowadays. Could you change kbuild test robot clock to current time. It seems to live still in future :) regards Antti On 07/23/2014 11:21 AM, Fengguang Wu wrote: Hi Antti, This is just a notification. It's up to human to decide the impact and whether or not to do the rebase (which very much depends on the publicness of the tree and git committer's work style). Thanks, Fengguang On Wed, Jul 23, 2014 at 09:43:08AM +0300, Antti Palosaari wrote: Moikka! On 07/23/2014 02:20 PM, kbuild test robot wrote: tree: git://linuxtv.org/media_tree.git master head: eb9da073bd002f2968c84129a5c49625911a3199 commit: 77bbb2b049c1c3e935f5bec510bec337d94ae8f8 [378/499] rtl2832_sdr: move from staging to media config: i386-randconfig-ha2-0723 (attached as .config) Note: the linuxtv-media/master HEAD eb9da073bd002f2968c84129a5c49625911a3199 builds fine. It only hurts bisectibility. All error/warnings: ERROR: __udivdi3 [drivers/media/dvb-frontends/rtl2832_sdr.ko] undefined! Could you say what I should do for that? Bug is fixed and solution is merged as that patch: commit a98ccfcf4804beb2651b9f44a4bc5cbb387019ec Author: Antti Palosaari cr...@iki.fi Date: Tue Jul 22 00:18:19 2014 -0300 [media] rtl2832_sdr: remove plain 64-bit divisions Do you want Mauro to rebase whole media/master in order to make bisectibility possible in any case? regards Antti -- http://palosaari.fi/ -- 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/28] IPUv3 prep for video capture
Hi Steve, On Thursday 17 July 2014 13:44:12 Steve Longerbeam wrote: On 07/17/2014 04:10 AM, Hans Verkuil wrote: Hi Steve, I don't know what your plan is, but when you want to mainline this it is the gpu subsystem that needs to review it. I noticed it wasn't cross-posted to the dri-devel mailinglist. Hi Hans, I'm reworking these patches, I've merged in some of the changes posted by Philip Zabel ([RFC PATCH 00/26] i.MX5/6 IPUv3 CSI/IC), specifically I've decided to use their version of ipu-ic.c, and also brought in their video-mux subdev driver. So I'm fine with cancelling this patch set. When/if I post the reworked v4l2 drivers that implement the media entity/device framework I will post the ipu-v3 specific changes to dri-devel as well. The reason I like Philip's version of ipu-ic is that it implements tiling to allow resizing output frames larger than 1024x1024. We (Mentor Graphics) did the same IC tiling, but it was done inside a separate mem2mem driver. By moving the tiling into ipu-ic, it allows 1024x1024 resizing to be part of an imx-ipuv3-ic media entity, and this entity can be part of multiple video pipelines (capture, video output, mem2mem). I am a bit worried about the amount of v4l2-specific stuff that is going into drivers/gpu/ipu-v3. Do things like csc and csi really belong there instead of under drivers/media? The current philosophy of the ipu-v3 driver seems to be that it is a library of IPU register-level primitives, so ipu-csi and ipu-ic follow that model. There will be nothing v4l2-specific in ipu-csi and ipu-ic, although the v4l2 subdev's will be the only clients of ipu-csi and ipu-ic. I have a bit of trouble following up, due to my lack of knowledge of the Freescale platforms. It would help if you could explain briefly how the various IPU modules interact with each other at the hardware and software level, and what the acronyms stand for (I assume IPU means Image Processing Unit, CSI means Camera Serial Interface, but I don't know what IC is in this context). Are the CSI receivers linked to the graphics IP cores at the hardware level ? Let me know if this was just preliminary code, or if this was intended to be the final code. I suspect the former. This is all been reworked so go ahead and cancel it. -- 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: [PATCH] si2168: Fix unknown chip version message
Em Wed, 23 Jul 2014 11:22:40 +0300 Antti Palosaari cr...@iki.fi escreveu: Moikka! It is single character formatter, not string, = no need to terminate, so that patch is not valid. Well, what happened with an invalid firmware is that the first %c was a 0x00 character, causing that the \n at the end and the others %c to be discarded. In other words, if you want to print the data with %c, you should be validating that it is a printable character before using %c. On a separate issue, it is not unkown but unknown. Regards, Mauro regards Antti On 07/22/2014 10:14 PM, Mauro Carvalho Chehab wrote: At least here with my PCTV 292e, it is printing this error: si2168 10-0064: si2168: unkown chip version Si21170- without a \n at the end. Probably because it is doing something weird or firmware didn't load well. Anyway, better to print it in hex, instead of using %c. While here, fix the typo. Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com --- drivers/media/dvb-frontends/si2168.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/media/dvb-frontends/si2168.c b/drivers/media/dvb-frontends/si2168.c index 41bdbc4d9f6c..842c4a555d01 100644 --- a/drivers/media/dvb-frontends/si2168.c +++ b/drivers/media/dvb-frontends/si2168.c @@ -414,9 +414,8 @@ static int si2168_init(struct dvb_frontend *fe) break; default: dev_err(s-client-dev, - %s: unkown chip version Si21%d-%c%c%c\n, - KBUILD_MODNAME, cmd.args[2], cmd.args[1], - cmd.args[3], cmd.args[4]); + %s: unknown chip version: 0x%04x\n, + KBUILD_MODNAME, chip_id); ret = -EINVAL; goto err; } -- 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/11] OMAP3 ISP BT.656 support
On Tue, Jul 22, 2014 at 6:32 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Enrico, On Tuesday 22 July 2014 18:26:52 Enrico wrote: On Tue, Jul 22, 2014 at 6:04 PM, Laurent Pinchart wrote: Hi Enrico, You will need to upgrade media-ctl and yavta to versions that support interlaced formats. media-ctl has been moved to v4l-utils (http://git.linuxtv.org/cgit.cgi/v4l-utils.git/) and yavta is hosted at git://git.ideasonboard.org/yavta.git. You want to use the master branch for both trees. It seems that in v4l-utils there is no field support in media-ctl, am i wrong? Oops, my bad, you're absolutely right. I forgot to add that i'm using yavta master and media-ctl field branch (from ideasonboard). Could you please try media-ctl from git://linuxtv.org/pinchartl/v4l-utils.git field The IOB repository is deprecated, although the version of media-ctl present there might work, I'd like to rule out that issue. The media-ctl output you've posted doesn't show field information, so you're probably running either the wrong media-ctl version or the wrong kernel version. You were right i was using the wrong binary, now the output is: ... - entity 5: OMAP3 ISP CCDC (3 pads, 9 links) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev2 pad0: Sink [fmt:UYVY2X8/720x625 field:interlaced] ... pad1: Source [fmt:UYVY/720x624 field:interlaced crop.bounds:(0,0)/720x624 crop:(0,0)/720x624] ... - entity 16: tvp5150 1-005c (1 pad, 1 link) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev8 pad0: Source [fmt:UYVY2X8/720x625 field:interlaced] but i still get the same error: root@igep00x0:~/field# ./yavta -f UYVY -n4 -s 720x624 -c100 /dev/video2 Device /dev/video2 opened. Device `OMAP3 ISP CCDC output' on `media' is a video output (without mplanes) device. Video format set: UYVY (59565955) 720x624 (stride 1440) field none buffer size 898560 Video format: UYVY (59565955) 720x624 (stride 1440) field none buffer size 898560 4 buffers requested. length: 898560 offset: 0 timestamp type/source: mono/EoF Buffer 0/0 mapped at address 0xb6d95000. length: 898560 offset: 901120 timestamp type/source: mono/EoF Buffer 1/0 mapped at address 0xb6cb9000. length: 898560 offset: 1802240 timestamp type/source: mono/EoF Buffer 2/0 mapped at address 0xb6bdd000. length: 898560 offset: 2703360 timestamp type/source: mono/EoF Buffer 3/0 mapped at address 0xb6b01000. Unable to start streaming: Invalid argument (22). 4 buffers released. And ccdc pad1: Source (entity 5) is strange, i think it should be field:none (because ccdc output is deinterlaced). Enrico -- 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/11] OMAP3 ISP BT.656 support
On Wed, Jul 23, 2014 at 3:54 PM, Enrico ebut...@users.sourceforge.net wrote: On Tue, Jul 22, 2014 at 6:32 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Enrico, On Tuesday 22 July 2014 18:26:52 Enrico wrote: On Tue, Jul 22, 2014 at 6:04 PM, Laurent Pinchart wrote: Hi Enrico, You will need to upgrade media-ctl and yavta to versions that support interlaced formats. media-ctl has been moved to v4l-utils (http://git.linuxtv.org/cgit.cgi/v4l-utils.git/) and yavta is hosted at git://git.ideasonboard.org/yavta.git. You want to use the master branch for both trees. It seems that in v4l-utils there is no field support in media-ctl, am i wrong? Oops, my bad, you're absolutely right. I forgot to add that i'm using yavta master and media-ctl field branch (from ideasonboard). Could you please try media-ctl from git://linuxtv.org/pinchartl/v4l-utils.git field The IOB repository is deprecated, although the version of media-ctl present there might work, I'd like to rule out that issue. The media-ctl output you've posted doesn't show field information, so you're probably running either the wrong media-ctl version or the wrong kernel version. You were right i was using the wrong binary, now the output is: ... - entity 5: OMAP3 ISP CCDC (3 pads, 9 links) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev2 pad0: Sink [fmt:UYVY2X8/720x625 field:interlaced] ... pad1: Source [fmt:UYVY/720x624 field:interlaced crop.bounds:(0,0)/720x624 crop:(0,0)/720x624] ... - entity 16: tvp5150 1-005c (1 pad, 1 link) type V4L2 subdev subtype Unknown flags 0 device node name /dev/v4l-subdev8 pad0: Source [fmt:UYVY2X8/720x625 field:interlaced] but i still get the same error: root@igep00x0:~/field# ./yavta -f UYVY -n4 -s 720x624 -c100 /dev/video2 Device /dev/video2 opened. Device `OMAP3 ISP CCDC output' on `media' is a video output (without mplanes) device. Video format set: UYVY (59565955) 720x624 (stride 1440) field none buffer size 898560 Video format: UYVY (59565955) 720x624 (stride 1440) field none buffer size 898560 4 buffers requested. length: 898560 offset: 0 timestamp type/source: mono/EoF Buffer 0/0 mapped at address 0xb6d95000. length: 898560 offset: 901120 timestamp type/source: mono/EoF Buffer 1/0 mapped at address 0xb6cb9000. length: 898560 offset: 1802240 timestamp type/source: mono/EoF Buffer 2/0 mapped at address 0xb6bdd000. length: 898560 offset: 2703360 timestamp type/source: mono/EoF Buffer 3/0 mapped at address 0xb6b01000. Unable to start streaming: Invalid argument (22). 4 buffers released. Same error adding field parameter to yavta: ./yavta -f UYVY -n4 -s 720x624 -c100 --field interlaced /dev/video2 Enrico -- 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/3] omap3isp: resizer: Remove slow debugging message from interrupt handler
The resizer_set_input_size() function prints a debugging message with the input width and height values. As the function is called from interrupt context, printing that message to the serial console could slow down the interrupt handler and cause it to miss the start of the next frame, causing image corruption. Fix this by reorganizing the resizer debug messages. The driver now prints the input size, the crop rectangle and the output size in the set selection handler instead of scattering debug messages in various places. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- drivers/media/platform/omap3isp/ispresizer.c | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/drivers/media/platform/omap3isp/ispresizer.c b/drivers/media/platform/omap3isp/ispresizer.c index 8515793..c8676e1 100644 --- a/drivers/media/platform/omap3isp/ispresizer.c +++ b/drivers/media/platform/omap3isp/ispresizer.c @@ -367,7 +367,6 @@ static void resizer_set_output_size(struct isp_res_device *res, struct isp_device *isp = to_isp_device(res); u32 rgval; - dev_dbg(isp-dev, Output size[w/h]: %dx%d\n, width, height); rgval = (width ISPRSZ_OUT_SIZE_HORZ_SHIFT) ISPRSZ_OUT_SIZE_HORZ_MASK; rgval |= (height ISPRSZ_OUT_SIZE_VERT_SHIFT) @@ -431,8 +430,6 @@ static void resizer_set_input_size(struct isp_res_device *res, struct isp_device *isp = to_isp_device(res); u32 rgval; - dev_dbg(isp-dev, Input size[w/h]: %dx%d\n, width, height); - rgval = (width ISPRSZ_IN_SIZE_HORZ_SHIFT) ISPRSZ_IN_SIZE_HORZ_MASK; rgval |= (height ISPRSZ_IN_SIZE_VERT_SHIFT) @@ -1302,12 +1299,10 @@ static int resizer_set_selection(struct v4l2_subdev *sd, format_source = __resizer_get_format(res, fh, RESZ_PAD_SOURCE, sel-which); - dev_dbg(isp-dev, %s: L=%d,T=%d,W=%d,H=%d,which=%d\n, __func__, - sel-r.left, sel-r.top, sel-r.width, sel-r.height, - sel-which); - - dev_dbg(isp-dev, %s: input=%dx%d, output=%dx%d\n, __func__, + dev_dbg(isp-dev, %s(%s): req %ux%u - (%d,%d)/%ux%u - %ux%u\n, + __func__, sel-which == V4L2_SUBDEV_FORMAT_TRY ? try : act, format_sink-width, format_sink-height, + sel-r.left, sel-r.top, sel-r.width, sel-r.height, format_source-width, format_source-height); /* Clamp the crop rectangle to the bounds, and then mangle it further to @@ -1322,6 +1317,12 @@ static int resizer_set_selection(struct v4l2_subdev *sd, *__resizer_get_crop(res, fh, sel-which) = sel-r; resizer_calc_ratios(res, sel-r, format_source, ratio); + dev_dbg(isp-dev, %s(%s): got %ux%u - (%d,%d)/%ux%u - %ux%u\n, + __func__, sel-which == V4L2_SUBDEV_FORMAT_TRY ? try : act, + format_sink-width, format_sink-height, + sel-r.left, sel-r.top, sel-r.width, sel-r.height, + format_source-width, format_source-height); + if (sel-which == V4L2_SUBDEV_FORMAT_TRY) return 0; -- 1.8.5.5 -- 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 3/3] omap3isp: resizer: Protect against races when updating crop
When updating the crop rectangle during streaming, the IRQ handler will
reprogram the resizer after the current frame. A race condition
currently exists between the set selection operation and the IRQ
handler: if the set selection operation is called twice in a row and the
IRQ handler runs only during the second call, it could reprogram the
hardware with partially updated values. Use a spinlock to protect
against that.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/platform/omap3isp/ispresizer.c | 43
drivers/media/platform/omap3isp/ispresizer.h | 3 ++
2 files changed, 34 insertions(+), 12 deletions(-)
diff --git a/drivers/media/platform/omap3isp/ispresizer.c
b/drivers/media/platform/omap3isp/ispresizer.c
index c8676e1..5fcf3cf 100644
--- a/drivers/media/platform/omap3isp/ispresizer.c
+++ b/drivers/media/platform/omap3isp/ispresizer.c
@@ -1072,10 +1072,13 @@ static void resizer_isr_buffer(struct isp_res_device
*res)
void omap3isp_resizer_isr(struct isp_res_device *res)
{
struct v4l2_mbus_framefmt *informat, *outformat;
+ unsigned long flags;
if (omap3isp_module_sync_is_stopping(res-wait, res-stopping))
return;
+ spin_lock_irqsave(res-lock, flags);
+
if (res-applycrop) {
outformat = __resizer_get_format(res, NULL, RESZ_PAD_SOURCE,
V4L2_SUBDEV_FORMAT_ACTIVE);
@@ -1085,6 +1088,8 @@ void omap3isp_resizer_isr(struct isp_res_device *res)
res-applycrop = 0;
}
+ spin_unlock_irqrestore(res-lock, flags);
+
resizer_isr_buffer(res);
}
@@ -1287,8 +1292,10 @@ static int resizer_set_selection(struct v4l2_subdev *sd,
{
struct isp_res_device *res = v4l2_get_subdevdata(sd);
struct isp_device *isp = to_isp_device(res);
- struct v4l2_mbus_framefmt *format_sink, *format_source;
+ const struct v4l2_mbus_framefmt *format_sink;
+ struct v4l2_mbus_framefmt format_source;
struct resizer_ratio ratio;
+ unsigned long flags;
if (sel-target != V4L2_SEL_TGT_CROP ||
sel-pad != RESZ_PAD_SINK)
@@ -1296,14 +1303,14 @@ static int resizer_set_selection(struct v4l2_subdev *sd,
format_sink = __resizer_get_format(res, fh, RESZ_PAD_SINK,
sel-which);
- format_source = __resizer_get_format(res, fh, RESZ_PAD_SOURCE,
-sel-which);
+ format_source = *__resizer_get_format(res, fh, RESZ_PAD_SOURCE,
+ sel-which);
dev_dbg(isp-dev, %s(%s): req %ux%u - (%d,%d)/%ux%u - %ux%u\n,
__func__, sel-which == V4L2_SUBDEV_FORMAT_TRY ? try : act,
format_sink-width, format_sink-height,
sel-r.left, sel-r.top, sel-r.width, sel-r.height,
- format_source-width, format_source-height);
+ format_source.width, format_source.height);
/* Clamp the crop rectangle to the bounds, and then mangle it further to
* fulfill the TRM equations. Store the clamped but otherwise unmangled
@@ -1313,29 +1320,39 @@ static int resizer_set_selection(struct v4l2_subdev *sd,
* smaller input crop rectangle every time the output size is set if we
* stored the mangled rectangle.
*/
- resizer_try_crop(format_sink, format_source, sel-r);
+ resizer_try_crop(format_sink, format_source, sel-r);
*__resizer_get_crop(res, fh, sel-which) = sel-r;
- resizer_calc_ratios(res, sel-r, format_source, ratio);
+ resizer_calc_ratios(res, sel-r, format_source, ratio);
dev_dbg(isp-dev, %s(%s): got %ux%u - (%d,%d)/%ux%u - %ux%u\n,
__func__, sel-which == V4L2_SUBDEV_FORMAT_TRY ? try : act,
format_sink-width, format_sink-height,
sel-r.left, sel-r.top, sel-r.width, sel-r.height,
- format_source-width, format_source-height);
+ format_source.width, format_source.height);
- if (sel-which == V4L2_SUBDEV_FORMAT_TRY)
+ if (sel-which == V4L2_SUBDEV_FORMAT_TRY) {
+ *__resizer_get_format(res, fh, RESZ_PAD_SOURCE, sel-which) =
+ format_source;
return 0;
+ }
+
+ /* Update the source format, resizing ratios and crop rectangle. If
+* streaming is on the IRQ handler will reprogram the resizer after the
+* current frame. We thus we need to protect against race conditions.
+*/
+ spin_lock_irqsave(res-lock, flags);
+
+ *__resizer_get_format(res, fh, RESZ_PAD_SOURCE, sel-which) =
+ format_source;
res-ratio = ratio;
res-crop.active = sel-r;
- /*
-* set_selection can be called while streaming is on. In this case the
-* crop values will be set in the next IRQ.
-*/
if
[PATCH 0/3] OMAP3 ISP resizer live zoom fixes
Hello, This patch set fixes two issues occuring when performing live zoom with the OMAP3 ISP resizer. The first issue has been observed when using the digital zoom of the live application (http://git.ideasonboard.org/omap3-isp-live.git) on a beagleboard. It leads to image corruption due to interrupt handling latency. Patch 2/3 fixes it. The second issue is a race condition that I haven't observed in practice. It's fixed by patch 3/3. As usual with race conditions and locking, careful review will be appreciated. Laurent Pinchart (3): omap3isp: resizer: Remove needless variable initializations omap3isp: resizer: Remove slow debugging message from interrupt handler omap3isp: resizer: Protect against races when updating crop drivers/media/platform/omap3isp/ispresizer.c | 70 ++-- drivers/media/platform/omap3isp/ispresizer.h | 3 ++ 2 files changed, 48 insertions(+), 25 deletions(-) -- 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
[PATCH 1/3] omap3isp: resizer: Remove needless variable initializations
There's no need to initialize local variables to zero when they're
explicitly assigned another value right after. Remove the needless
initializations.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/platform/omap3isp/ispresizer.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/media/platform/omap3isp/ispresizer.c
b/drivers/media/platform/omap3isp/ispresizer.c
index 6f077c2..8515793 100644
--- a/drivers/media/platform/omap3isp/ispresizer.c
+++ b/drivers/media/platform/omap3isp/ispresizer.c
@@ -239,7 +239,7 @@ static void resizer_set_phase(struct isp_res_device *res,
u32 h_phase,
u32 v_phase)
{
struct isp_device *isp = to_isp_device(res);
- u32 rgval = 0;
+ u32 rgval;
rgval = isp_reg_readl(isp, OMAP3_ISP_IOMEM_RESZ, ISPRSZ_CNT)
~(ISPRSZ_CNT_HSTPH_MASK | ISPRSZ_CNT_VSTPH_MASK);
@@ -275,7 +275,7 @@ static void resizer_set_luma(struct isp_res_device *res,
struct resizer_luma_yenh *luma)
{
struct isp_device *isp = to_isp_device(res);
- u32 rgval = 0;
+ u32 rgval;
rgval = (luma-algo ISPRSZ_YENH_ALGO_SHIFT)
ISPRSZ_YENH_ALGO_MASK;
@@ -322,7 +322,7 @@ static void resizer_set_ratio(struct isp_res_device *res,
{
struct isp_device *isp = to_isp_device(res);
const u16 *h_filter, *v_filter;
- u32 rgval = 0;
+ u32 rgval;
rgval = isp_reg_readl(isp, OMAP3_ISP_IOMEM_RESZ, ISPRSZ_CNT)
~(ISPRSZ_CNT_HRSZ_MASK | ISPRSZ_CNT_VRSZ_MASK);
@@ -365,7 +365,7 @@ static void resizer_set_output_size(struct isp_res_device
*res,
u32 width, u32 height)
{
struct isp_device *isp = to_isp_device(res);
- u32 rgval = 0;
+ u32 rgval;
dev_dbg(isp-dev, Output size[w/h]: %dx%d\n, width, height);
rgval = (width ISPRSZ_OUT_SIZE_HORZ_SHIFT)
@@ -409,7 +409,7 @@ static void resizer_set_output_offset(struct isp_res_device
*res, u32 offset)
static void resizer_set_start(struct isp_res_device *res, u32 left, u32 top)
{
struct isp_device *isp = to_isp_device(res);
- u32 rgval = 0;
+ u32 rgval;
rgval = (left ISPRSZ_IN_START_HORZ_ST_SHIFT)
ISPRSZ_IN_START_HORZ_ST_MASK;
@@ -429,7 +429,7 @@ static void resizer_set_input_size(struct isp_res_device
*res,
u32 width, u32 height)
{
struct isp_device *isp = to_isp_device(res);
- u32 rgval = 0;
+ u32 rgval;
dev_dbg(isp-dev, Input size[w/h]: %dx%d\n, width, height);
--
1.8.5.5
--
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: drx39xyj - fix to return actual error codes instead of -EIO
Several functions ignore the return values in error legs and always return -EIO. This makes it hard to debug and take proper action in calling routines. Signed-off-by: Shuah Khan shuah...@samsung.com --- drivers/media/dvb-frontends/drx39xyj/drxj.c | 112 +-- 1 file changed, 56 insertions(+), 56 deletions(-) diff --git a/drivers/media/dvb-frontends/drx39xyj/drxj.c b/drivers/media/dvb-frontends/drx39xyj/drxj.c index 54855a9..c3931cc 100644 --- a/drivers/media/dvb-frontends/drx39xyj/drxj.c +++ b/drivers/media/dvb-frontends/drx39xyj/drxj.c @@ -2159,7 +2159,7 @@ int drxj_dap_atomic_read_write_block(struct i2c_device_addr *dev_addr, return 0; rw_error: - return -EIO; + return rc; } @@ -2252,7 +2252,7 @@ static int hi_cfg_command(const struct drx_demod_instance *demod) return 0; rw_error: - return -EIO; + return rc; } /** @@ -2363,7 +2363,7 @@ hi_command(struct i2c_device_addr *dev_addr, const struct drxj_hi_cmd *cmd, u16 /* if ( powerdown_cmd == true ) */ return 0; rw_error: - return -EIO; + return rc; } /** @@ -2434,7 +2434,7 @@ static int init_hi(const struct drx_demod_instance *demod) return 0; rw_error: - return -EIO; + return rc; } /**/ @@ -2650,7 +2650,7 @@ static int get_device_capabilities(struct drx_demod_instance *demod) return 0; rw_error: - return -EIO; + return rc; } /** @@ -3338,7 +3338,7 @@ ctrl_set_cfg_mpeg_output(struct drx_demod_instance *demod, struct drx_cfg_mpeg_o return 0; rw_error: - return -EIO; + return rc; } /**/ @@ -3421,7 +3421,7 @@ static int set_mpegtei_handling(struct drx_demod_instance *demod) return 0; rw_error: - return -EIO; + return rc; } /**/ @@ -3464,7 +3464,7 @@ static int bit_reverse_mpeg_output(struct drx_demod_instance *demod) return 0; rw_error: - return -EIO; + return rc; } /**/ @@ -3508,7 +3508,7 @@ static int set_mpeg_start_width(struct drx_demod_instance *demod) return 0; rw_error: - return -EIO; + return rc; } /**/ @@ -3652,7 +3652,7 @@ static int ctrl_set_uio_cfg(struct drx_demod_instance *demod, struct drxuio_cfg return 0; rw_error: - return -EIO; + return rc; } /** @@ -3854,7 +3854,7 @@ ctrl_uio_write(struct drx_demod_instance *demod, struct drxuio_data *uio_data) return 0; rw_error: - return -EIO; + return rc; } /*---*/ @@ -3969,7 +3969,7 @@ static int smart_ant_init(struct drx_demod_instance *demod) return 0; rw_error: - return -EIO; + return rc; } static int scu_command(struct i2c_device_addr *dev_addr, struct drxjscu_cmd *cmd) @@ -4109,7 +4109,7 @@ static int scu_command(struct i2c_device_addr *dev_addr, struct drxjscu_cmd *cmd return 0; rw_error: - return -EIO; + return rc; } /** @@ -4178,7 +4178,7 @@ int drxj_dap_scu_atomic_read_write_block(struct i2c_device_addr *dev_addr, u32 a return 0; rw_error: - return -EIO; + return rc; } @@ -4290,7 +4290,7 @@ static int adc_sync_measurement(struct drx_demod_instance *demod, u16 *count) return 0; rw_error: - return -EIO; + return rc; } /** @@ -4349,7 +4349,7 @@ static int adc_synchronization(struct drx_demod_instance *demod) return 0; rw_error: - return -EIO; + return rc; } /**/ @@ -4734,7 +4734,7 @@ static int init_agc(struct drx_demod_instance *demod) return 0; rw_error: - return -EIO; + return rc; } /** @@ -4831,7 +4831,7 @@ set_frequency(struct drx_demod_instance *demod, return 0; rw_error: - return -EIO; + return rc; } /** @@ -4879,7 +4879,7 @@ static int get_acc_pkt_err(struct drx_demod_instance *demod, u16 *packet_err) return 0; rw_error: - return -EIO; + return rc; } #endif @@ -5097,7 +5097,7 @@ set_agc_rf(struct drx_demod_instance *demod, struct drxj_cfg_agc *agc_settings, return 0; rw_error: - return -EIO; + return rc; } /** @@ -5326,7 +5326,7 @@ set_agc_if(struct drx_demod_instance *demod, struct drxj_cfg_agc *agc_settings, return 0; rw_error: - return -EIO; + return rc; } /** @@ -5362,7 +5362,7 @@ static int set_iqm_af(struct drx_demod_instance *demod, bool active)
[PATCH 3/8] [media] coda: add context ops
Add a struct coda_context_ops that encapsulates context specific operations.
This will simplify adding JPEG support in the future and helps to avoid
exporting all functions individually when they move out of the main code
file.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/media/platform/coda/coda-common.c | 85 ++-
drivers/media/platform/coda/coda.h| 13 +
2 files changed, 63 insertions(+), 35 deletions(-)
diff --git a/drivers/media/platform/coda/coda-common.c
b/drivers/media/platform/coda/coda-common.c
index 4649395..ecab30a 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -802,7 +802,7 @@ static const struct v4l2_ioctl_ops coda_ioctl_ops = {
.vidioc_unsubscribe_event = v4l2_event_unsubscribe,
};
-static int coda_start_decoding(struct coda_ctx *ctx);
+static int __coda_start_decoding(struct coda_ctx *ctx);
static inline int coda_get_bitstream_payload(struct coda_ctx *ctx)
{
@@ -978,7 +978,7 @@ static int coda_prepare_decode(struct coda_ctx *ctx)
/* Run coda_start_decoding (again) if not yet initialized */
if (!ctx-initialized) {
- int ret = coda_start_decoding(ctx);
+ int ret = __coda_start_decoding(ctx);
if (ret 0) {
v4l2_err(dev-v4l2_dev, failed to start decoding\n);
v4l2_m2m_job_finish(ctx-dev-m2m_dev, ctx-fh.m2m_ctx);
@@ -1043,7 +1043,7 @@ static int coda_prepare_decode(struct coda_ctx *ctx)
return 0;
}
-static void coda_prepare_encode(struct coda_ctx *ctx)
+static int coda_prepare_encode(struct coda_ctx *ctx)
{
struct coda_q_data *q_data_src, *q_data_dst;
struct vb2_buffer *src_buf, *dst_buf;
@@ -1185,6 +1185,8 @@ static void coda_prepare_encode(struct coda_ctx *ctx)
ctx-bit_stream_param |= CODA_BIT_STREAM_END_FLAG;
coda_write(dev, ctx-bit_stream_param,
CODA_REG_BIT_BIT_STREAM_PARAM);
}
+
+ return 0;
}
static void coda_device_run(void *m2m_priv)
@@ -1235,16 +1237,12 @@ static void coda_pic_run_work(struct work_struct *work)
mutex_lock(ctx-buffer_mutex);
mutex_lock(dev-coda_mutex);
- if (ctx-inst_type == CODA_INST_DECODER) {
- ret = coda_prepare_decode(ctx);
- if (ret 0) {
- mutex_unlock(dev-coda_mutex);
- mutex_unlock(ctx-buffer_mutex);
- /* job_finish scheduled by prepare_decode */
- return;
- }
- } else {
- coda_prepare_encode(ctx);
+ ret = ctx-ops-prepare_run(ctx);
+ if (ret 0 ctx-inst_type == CODA_INST_DECODER) {
+ mutex_unlock(dev-coda_mutex);
+ mutex_unlock(ctx-buffer_mutex);
+ /* job_finish scheduled by prepare_decode */
+ return;
}
if (dev-devtype-product != CODA_DX6)
@@ -1262,10 +1260,7 @@ static void coda_pic_run_work(struct work_struct *work)
coda_hw_reset(ctx);
} else if (!ctx-aborting) {
- if (ctx-inst_type == CODA_INST_DECODER)
- coda_finish_decode(ctx);
- else
- coda_finish_encode(ctx);
+ ctx-ops-finish_run(ctx);
}
if (ctx-aborting || (!ctx-streamon_cap !ctx-streamon_out))
@@ -1848,7 +1843,7 @@ err:
return ret;
}
-static int coda_start_decoding(struct coda_ctx *ctx)
+static int __coda_start_decoding(struct coda_ctx *ctx)
{
struct coda_q_data *q_data_src, *q_data_dst;
u32 bitstream_buf, bitstream_size;
@@ -2039,6 +2034,18 @@ static int coda_start_decoding(struct coda_ctx *ctx)
return 0;
}
+static int coda_start_decoding(struct coda_ctx *ctx)
+{
+ struct coda_dev *dev = ctx-dev;
+ int ret;
+
+ mutex_lock(dev-coda_mutex);
+ ret = __coda_start_decoding(ctx);
+ mutex_unlock(dev-coda_mutex);
+
+ return ret;
+}
+
static int coda_encode_header(struct coda_ctx *ctx, struct vb2_buffer *buf,
int header_code, u8 *header, int *size)
{
@@ -2083,7 +2090,6 @@ static int coda_start_streaming(struct vb2_queue *q,
unsigned int count)
{
struct coda_ctx *ctx = vb2_get_drv_priv(q);
struct v4l2_device *v4l2_dev = ctx-dev-v4l2_dev;
- struct coda_dev *dev = ctx-dev;
struct coda_q_data *q_data_src, *q_data_dst;
u32 dst_fourcc;
int ret = 0;
@@ -2135,16 +2141,12 @@ static int coda_start_streaming(struct vb2_queue *q,
unsigned int count)
if (ret 0)
return ret;
+ ret = ctx-ops-start_streaming(ctx);
if (ctx-inst_type == CODA_INST_DECODER) {
- mutex_lock(dev-coda_mutex);
- ret = coda_start_decoding(ctx);
- mutex_unlock(dev-coda_mutex);
if (ret == -EAGAIN)
[PATCH 4/8] [media] coda: move BIT processor command execution out of pic_run_work
In preparation for the split, move the AXI_SRAM_USE register access and the
PIC_RUN command execution out of pic_run_work into prepare_encode/decode.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/media/platform/coda/coda-common.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/media/platform/coda/coda-common.c
b/drivers/media/platform/coda/coda-common.c
index ecab30a..04a7b12 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -1040,6 +1040,13 @@ static int coda_prepare_decode(struct coda_ctx *ctx)
coda_write(dev, 0, CODA_CMD_DEC_PIC_BB_START);
coda_write(dev, 0, CODA_CMD_DEC_PIC_START_BYTE);
+ if (dev-devtype-product != CODA_DX6)
+ coda_write(dev, ctx-iram_info.axi_sram_use,
+ CODA7_REG_BIT_AXI_SRAM_USE);
+
+ coda_kfifo_sync_to_device_full(ctx);
+ coda_command_async(ctx, CODA_COMMAND_PIC_RUN);
+
return 0;
}
@@ -1186,6 +1193,12 @@ static int coda_prepare_encode(struct coda_ctx *ctx)
coda_write(dev, ctx-bit_stream_param,
CODA_REG_BIT_BIT_STREAM_PARAM);
}
+ if (dev-devtype-product != CODA_DX6)
+ coda_write(dev, ctx-iram_info.axi_sram_use,
+ CODA7_REG_BIT_AXI_SRAM_USE);
+
+ coda_command_async(ctx, CODA_COMMAND_PIC_RUN);
+
return 0;
}
@@ -1245,14 +1258,6 @@ static void coda_pic_run_work(struct work_struct *work)
return;
}
- if (dev-devtype-product != CODA_DX6)
- coda_write(dev, ctx-iram_info.axi_sram_use,
- CODA7_REG_BIT_AXI_SRAM_USE);
-
- if (ctx-inst_type == CODA_INST_DECODER)
- coda_kfifo_sync_to_device_full(ctx);
- coda_command_async(ctx, CODA_COMMAND_PIC_RUN);
-
if (!wait_for_completion_timeout(ctx-completion,
msecs_to_jiffies(1000))) {
dev_err(dev-plat_dev-dev, CODA PIC_RUN timeout\n);
--
2.0.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 5/8] [media] coda: add coda_bit_stream_set_flag helper
This adds a helper function to consolidate three occurences where
the bitstream parameter stream end flag is set during operation.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/media/platform/coda/coda-common.c | 52 +++
1 file changed, 19 insertions(+), 33 deletions(-)
diff --git a/drivers/media/platform/coda/coda-common.c
b/drivers/media/platform/coda/coda-common.c
index 04a7b12..547744a 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -187,6 +187,20 @@ static int coda_hw_reset(struct coda_ctx *ctx)
return ret;
}
+static void coda_bit_stream_end_flag(struct coda_ctx *ctx)
+{
+ struct coda_dev *dev = ctx-dev;
+
+ ctx-bit_stream_param |= CODA_BIT_STREAM_END_FLAG;
+
+ if ((dev-devtype-product == CODA_960)
+ coda_isbusy(dev)
+ (ctx-idx == coda_read(dev, CODA_REG_BIT_RUN_INDEX))) {
+ /* If this context is currently running, update the hardware
flag */
+ coda_write(dev, ctx-bit_stream_param,
CODA_REG_BIT_BIT_STREAM_PARAM);
+ }
+}
+
static struct coda_q_data *get_q_data(struct coda_ctx *ctx,
enum v4l2_buf_type type)
{
@@ -732,7 +746,6 @@ static int coda_decoder_cmd(struct file *file, void *fh,
struct v4l2_decoder_cmd *dc)
{
struct coda_ctx *ctx = fh_to_ctx(fh);
- struct coda_dev *dev = ctx-dev;
int ret;
ret = coda_try_decoder_cmd(file, fh, dc);
@@ -743,15 +756,8 @@ static int coda_decoder_cmd(struct file *file, void *fh,
if (ctx-inst_type != CODA_INST_DECODER)
return 0;
- /* Set the strem-end flag on this context */
- ctx-bit_stream_param |= CODA_BIT_STREAM_END_FLAG;
-
- if ((dev-devtype-product == CODA_960)
- coda_isbusy(dev)
- (ctx-idx == coda_read(dev, CODA_REG_BIT_RUN_INDEX))) {
- /* If this context is currently running, update the hardware
flag */
- coda_write(dev, ctx-bit_stream_param,
CODA_REG_BIT_BIT_STREAM_PARAM);
- }
+ /* Set the stream-end flag on this context */
+ coda_bit_stream_end_flag(ctx);
ctx-hold = false;
v4l2_m2m_try_schedule(ctx-fh.m2m_ctx);
@@ -1474,7 +1480,6 @@ static int coda_buf_prepare(struct vb2_buffer *vb)
static void coda_buf_queue(struct vb2_buffer *vb)
{
struct coda_ctx *ctx = vb2_get_drv_priv(vb-vb2_queue);
- struct coda_dev *dev = ctx-dev;
struct coda_q_data *q_data;
q_data = get_q_data(ctx, vb-vb2_queue-type);
@@ -1489,15 +1494,8 @@ static void coda_buf_queue(struct vb2_buffer *vb)
* For backwards compatibility, queuing an empty buffer marks
* the stream end
*/
- if (vb2_get_plane_payload(vb, 0) == 0) {
- ctx-bit_stream_param |= CODA_BIT_STREAM_END_FLAG;
- if ((dev-devtype-product == CODA_960)
- coda_isbusy(dev)
- (ctx-idx == coda_read(dev,
CODA_REG_BIT_RUN_INDEX))) {
- /* if this decoder instance is running, set the
stream end flag */
- coda_write(dev, ctx-bit_stream_param,
CODA_REG_BIT_BIT_STREAM_PARAM);
- }
- }
+ if (vb2_get_plane_payload(vb, 0) == 0)
+ coda_bit_stream_end_flag(ctx);
mutex_lock(ctx-bitstream_mutex);
v4l2_m2m_buf_queue(ctx-fh.m2m_ctx, vb);
if (vb2_is_streaming(vb-vb2_queue))
@@ -2494,19 +2492,7 @@ static void coda_stop_streaming(struct vb2_queue *q)
%s: output\n, __func__);
ctx-streamon_out = 0;
- if (ctx-inst_type == CODA_INST_DECODER
- coda_isbusy(dev) ctx-idx == coda_read(dev,
CODA_REG_BIT_RUN_INDEX)) {
- /* if this decoder instance is running, set the stream
end flag */
- if (dev-devtype-product == CODA_960) {
- u32 val = coda_read(dev,
CODA_REG_BIT_BIT_STREAM_PARAM);
-
- val |= CODA_BIT_STREAM_END_FLAG;
- coda_write(dev, val,
CODA_REG_BIT_BIT_STREAM_PARAM);
- ctx-bit_stream_param = val;
- }
- }
- ctx-bit_stream_param |= CODA_BIT_STREAM_END_FLAG;
-
+ coda_bit_stream_end_flag(ctx);
ctx-isequence = 0;
} else {
v4l2_dbg(1, coda_debug, dev-v4l2_dev,
--
2.0.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 7/8] [media] coda: move H.264 helper function into separate file
Currently there is only the coda_h264_padding function, but
we will have to add more H.264 specific helpers later.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/media/platform/coda/Makefile | 2 +-
drivers/media/platform/coda/coda-common.c | 22 ---
drivers/media/platform/coda/coda-h264.c | 36 +++
drivers/media/platform/coda/coda.h| 2 ++
4 files changed, 39 insertions(+), 23 deletions(-)
create mode 100644 drivers/media/platform/coda/coda-h264.c
diff --git a/drivers/media/platform/coda/Makefile
b/drivers/media/platform/coda/Makefile
index 13d9ad6..0e59fbd 100644
--- a/drivers/media/platform/coda/Makefile
+++ b/drivers/media/platform/coda/Makefile
@@ -1,3 +1,3 @@
-coda-objs := coda-common.o
+coda-objs := coda-common.o coda-h264.o
obj-$(CONFIG_VIDEO_CODA) += coda.o
diff --git a/drivers/media/platform/coda/coda-common.c
b/drivers/media/platform/coda/coda-common.c
index df0470e..5226dea 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -72,10 +72,6 @@ struct coda_fmt {
u32 fourcc;
};
-static const u8 coda_filler_nal[14] = { 0x00, 0x00, 0x00, 0x01, 0x0c, 0xff,
- 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x80 };
-static const u8 coda_filler_size[8] = { 0, 7, 14, 13, 12, 11, 10, 9 };
-
void coda_write(struct coda_dev *dev, u32 data, u32 reg)
{
v4l2_dbg(1, coda_debug, dev-v4l2_dev,
@@ -1629,24 +1625,6 @@ static int coda_alloc_framebuffers(struct coda_ctx *ctx,
struct coda_q_data *q_d
return 0;
}
-static int coda_h264_padding(int size, char *p)
-{
- int nal_size;
- int diff;
-
- diff = size - (size ~0x7);
- if (diff == 0)
- return 0;
-
- nal_size = coda_filler_size[diff];
- memcpy(p, coda_filler_nal, nal_size);
-
- /* Add rbsp stop bit and trailing at the end */
- *(p + nal_size - 1) = 0x80;
-
- return nal_size;
-}
-
static phys_addr_t coda_iram_alloc(struct coda_iram_info *iram, size_t size)
{
phys_addr_t ret;
diff --git a/drivers/media/platform/coda/coda-h264.c
b/drivers/media/platform/coda/coda-h264.c
new file mode 100644
index 000..0b2fdbe
--- /dev/null
+++ b/drivers/media/platform/coda/coda-h264.c
@@ -0,0 +1,36 @@
+/*
+ * Coda multi-standard codec IP - H.264 helper functions
+ *
+ * Copyright (C) 2012 Vista Silicon S.L.
+ *Javier Martin, javier.mar...@vista-silicon.com
+ *Xavier Duret
+ *
+ * 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 linux/kernel.h
+
+static const u8 coda_filler_nal[14] = { 0x00, 0x00, 0x00, 0x01, 0x0c, 0xff,
+ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x80 };
+static const u8 coda_filler_size[8] = { 0, 7, 14, 13, 12, 11, 10, 9 };
+
+int coda_h264_padding(int size, char *p)
+{
+ int nal_size;
+ int diff;
+
+ diff = size - (size ~0x7);
+ if (diff == 0)
+ return 0;
+
+ nal_size = coda_filler_size[diff];
+ memcpy(p, coda_filler_nal, nal_size);
+
+ /* Add rbsp stop bit and trailing at the end */
+ *(p + nal_size - 1) = 0x80;
+
+ return nal_size;
+}
diff --git a/drivers/media/platform/coda/coda.h
b/drivers/media/platform/coda/coda.h
index c98270c..84e0829 100644
--- a/drivers/media/platform/coda/coda.h
+++ b/drivers/media/platform/coda/coda.h
@@ -227,3 +227,5 @@ struct coda_ctx {
int display_idx;
struct dentry *debugfs_entry;
};
+
+int coda_h264_padding(int size, char *p);
--
2.0.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 2/8] [media] coda: move defines, enums, and structs into shared header
These will have to be shared between multiple code files.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/media/platform/coda/coda-common.c | 193 +-
drivers/media/platform/coda/coda.h| 216 ++
2 files changed, 219 insertions(+), 190 deletions(-)
create mode 100644 drivers/media/platform/coda/coda.h
diff --git a/drivers/media/platform/coda/coda-common.c
b/drivers/media/platform/coda/coda-common.c
index 1f68201..4649395 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -38,6 +38,7 @@
#include media/videobuf2-core.h
#include media/videobuf2-dma-contig.h
+#include coda.h
#include coda_regs.h
#define CODA_NAME coda
@@ -50,10 +51,6 @@
#define CODA7_PS_BUF_SIZE 0x28000
#define CODA9_PS_SAVE_SIZE (512 * 1024)
-#define CODA_MAX_FRAMEBUFFERS 8
-
-#define CODA_MAX_FRAME_SIZE0x10
-#define FMO_SLICE_SAVE_BUF_SIZE (32)
#define CODA_DEFAULT_GAMMA 4096
#define CODA9_DEFAULT_GAMMA24576 /* 0.75 * 32768 */
@@ -70,207 +67,23 @@ static int coda_debug;
module_param(coda_debug, int, 0644);
MODULE_PARM_DESC(coda_debug, Debug level (0-1));
-enum {
- V4L2_M2M_SRC = 0,
- V4L2_M2M_DST = 1,
-};
-
-enum coda_inst_type {
- CODA_INST_ENCODER,
- CODA_INST_DECODER,
-};
-
-enum coda_product {
- CODA_DX6 = 0xf001,
- CODA_7541 = 0xf012,
- CODA_960 = 0xf020,
-};
-
struct coda_fmt {
char *name;
u32 fourcc;
};
-struct coda_codec {
- u32 mode;
- u32 src_fourcc;
- u32 dst_fourcc;
- u32 max_w;
- u32 max_h;
-};
-
-struct coda_devtype {
- char*firmware;
- enum coda_product product;
- const struct coda_codec *codecs;
- unsigned intnum_codecs;
- size_t workbuf_size;
- size_t tempbuf_size;
- size_t iram_size;
-};
-
-/* Per-queue, driver-specific private data */
-struct coda_q_data {
- unsigned intwidth;
- unsigned intheight;
- unsigned intbytesperline;
- unsigned intsizeimage;
- unsigned intfourcc;
- struct v4l2_rectrect;
-};
-
-struct coda_aux_buf {
- void*vaddr;
- dma_addr_t paddr;
- u32 size;
- struct debugfs_blob_wrapper blob;
- struct dentry *dentry;
-};
-
-struct coda_dev {
- struct v4l2_device v4l2_dev;
- struct video_device vfd[2];
- struct platform_device *plat_dev;
- const struct coda_devtype *devtype;
-
- void __iomem*regs_base;
- struct clk *clk_per;
- struct clk *clk_ahb;
- struct reset_control*rstc;
-
- struct coda_aux_buf codebuf;
- struct coda_aux_buf tempbuf;
- struct coda_aux_buf workbuf;
- struct gen_pool *iram_pool;
- struct coda_aux_buf iram;
-
- spinlock_t irqlock;
- struct mutexdev_mutex;
- struct mutexcoda_mutex;
- struct workqueue_struct *workqueue;
- struct v4l2_m2m_dev *m2m_dev;
- struct vb2_alloc_ctx*alloc_ctx;
- struct list_headinstances;
- unsigned long instance_mask;
- struct dentry *debugfs_root;
-};
-
-struct coda_params {
- u8 rot_mode;
- u8 h264_intra_qp;
- u8 h264_inter_qp;
- u8 h264_min_qp;
- u8 h264_max_qp;
- u8 h264_deblk_enabled;
- u8 h264_deblk_alpha;
- u8 h264_deblk_beta;
- u8 mpeg4_intra_qp;
- u8 mpeg4_inter_qp;
- u8 gop_size;
- int intra_refresh;
- int codec_mode;
- int codec_mode_aux;
- enum v4l2_mpeg_video_multi_slice_mode slice_mode;
- u32 framerate;
- u16 bitrate;
- u32 slice_max_bits;
- u32 slice_max_mb;
-};
-
-struct coda_iram_info {
- u32 axi_sram_use;
- phys_addr_t buf_bit_use;
- phys_addr_t buf_ip_ac_dc_use;
- phys_addr_t buf_dbk_y_use;
- phys_addr_t buf_dbk_c_use;
- phys_addr_t buf_ovl_use;
- phys_addr_t buf_btp_use;
- phys_addr_t search_ram_paddr;
- int search_ram_size;
- int remaining;
- phys_addr_t next_paddr;
-};
-
-struct gdi_tiled_map {
- int xy2ca_map[16];
- int
[PATCH 6/8] [media] coda: move per-instance buffer allocation and cleanup
This patch moves the context buffer allocation into the context start_streaming
callbacks. The context buffer and internal framebuffer cleanup is moved into
the context release callback.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/media/platform/coda/coda-common.c | 31 +--
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/drivers/media/platform/coda/coda-common.c
b/drivers/media/platform/coda/coda-common.c
index 547744a..df0470e 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -1863,6 +1863,11 @@ static int __coda_start_decoding(struct coda_ctx *ctx)
bitstream_size = ctx-bitstream.size;
src_fourcc = q_data_src-fourcc;
+ /* Allocate per-instance buffers */
+ ret = coda_alloc_context_buffers(ctx, q_data_src);
+ if (ret 0)
+ return ret;
+
coda_write(dev, ctx-parabuf.paddr, CODA_REG_BIT_PARA_BUF_ADDR);
/* Update coda bitstream read and write pointers from kfifo */
@@ -2139,11 +2144,6 @@ static int coda_start_streaming(struct vb2_queue *q,
unsigned int count)
return -EINVAL;
}
- /* Allocate per-instance buffers */
- ret = coda_alloc_context_buffers(ctx, q_data_src);
- if (ret 0)
- return ret;
-
ret = ctx-ops-start_streaming(ctx);
if (ctx-inst_type == CODA_INST_DECODER) {
if (ret == -EAGAIN)
@@ -2170,6 +2170,11 @@ static int coda_start_encoding(struct coda_ctx *ctx)
q_data_dst = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_CAPTURE);
dst_fourcc = q_data_dst-fourcc;
+ /* Allocate per-instance buffers */
+ ret = coda_alloc_context_buffers(ctx, q_data_src);
+ if (ret 0)
+ return ret;
+
buf = v4l2_m2m_next_dst_buf(ctx-fh.m2m_ctx);
bitstream_buf = vb2_dma_contig_plane_dma_addr(buf, 0);
bitstream_size = q_data_dst-sizeimage;
@@ -2840,7 +2845,6 @@ static int coda_open(struct file *file, enum
coda_inst_type inst_type,
return 0;
err_dma_writecombine:
- coda_free_context_buffers(ctx);
if (ctx-dev-devtype-product == CODA_DX6)
coda_free_aux_buf(dev, ctx-workbuf);
coda_free_aux_buf(dev, ctx-parabuf);
@@ -2863,12 +2867,19 @@ err_coda_max:
return ret;
}
+static void coda_bit_release(struct coda_ctx *ctx)
+{
+ coda_free_framebuffers(ctx);
+ coda_free_context_buffers(ctx);
+}
+
struct coda_context_ops coda_encode_ops = {
.queue_init = coda_encoder_queue_init,
.start_streaming = coda_start_encoding,
.prepare_run = coda_prepare_encode,
.finish_run = coda_finish_encode,
.seq_end_work = coda_seq_end_work,
+ .release = coda_bit_release,
};
struct coda_context_ops coda_decode_ops = {
@@ -2876,7 +2887,8 @@ struct coda_context_ops coda_decode_ops = {
.start_streaming = coda_start_decoding,
.prepare_run = coda_prepare_decode,
.finish_run = coda_finish_decode,
- .seq_end_work = coda_seq_end_work
+ .seq_end_work = coda_seq_end_work,
+ .release = coda_bit_release,
};
static int coda_encoder_open(struct file *file)
@@ -2908,15 +2920,12 @@ static int coda_release(struct file *file)
flush_work(ctx-seq_end_work);
}
- coda_free_framebuffers(ctx);
-
coda_lock(ctx);
list_del(ctx-list);
coda_unlock(ctx);
dma_free_writecombine(dev-plat_dev-dev, ctx-bitstream.size,
ctx-bitstream.vaddr, ctx-bitstream.paddr);
- coda_free_context_buffers(ctx);
if (ctx-dev-devtype-product == CODA_DX6)
coda_free_aux_buf(dev, ctx-workbuf);
@@ -2928,6 +2937,8 @@ static int coda_release(struct file *file)
v4l2_fh_del(ctx-fh);
v4l2_fh_exit(ctx-fh);
clear_bit(ctx-idx, dev-instance_mask);
+ if (ctx-ops-release)
+ ctx-ops-release(ctx);
kfree(ctx);
return 0;
--
2.0.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 1/8] [media] coda: move coda driver into its own directory
The coda driver has grown significantly and will continue to grow.
Move the coda driver into its own directory so it can be split.
Rename coda.h to coda_regs.h as it contains the register defines.
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/media/platform/Makefile | 2 +-
drivers/media/platform/coda/Makefile | 3 +++
drivers/media/platform/{coda.c = coda/coda-common.c} | 2 +-
drivers/media/platform/{coda.h = coda/coda_regs.h} | 0
4 files changed, 5 insertions(+), 2 deletions(-)
create mode 100644 drivers/media/platform/coda/Makefile
rename drivers/media/platform/{coda.c = coda/coda-common.c} (99%)
rename drivers/media/platform/{coda.h = coda/coda_regs.h} (100%)
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index e5269da..4ac4c91 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -22,7 +22,7 @@ obj-$(CONFIG_VIDEO_MEM2MEM_TESTDEV) += mem2mem_testdev.o
obj-$(CONFIG_VIDEO_TI_VPE) += ti-vpe/
obj-$(CONFIG_VIDEO_MX2_EMMAPRP)+= mx2_emmaprp.o
-obj-$(CONFIG_VIDEO_CODA) += coda.o
+obj-$(CONFIG_VIDEO_CODA) += coda/
obj-$(CONFIG_VIDEO_SH_VEU) += sh_veu.o
diff --git a/drivers/media/platform/coda/Makefile
b/drivers/media/platform/coda/Makefile
new file mode 100644
index 000..13d9ad6
--- /dev/null
+++ b/drivers/media/platform/coda/Makefile
@@ -0,0 +1,3 @@
+coda-objs := coda-common.o
+
+obj-$(CONFIG_VIDEO_CODA) += coda.o
diff --git a/drivers/media/platform/coda.c
b/drivers/media/platform/coda/coda-common.c
similarity index 99%
rename from drivers/media/platform/coda.c
rename to drivers/media/platform/coda/coda-common.c
index 3edbef6..1f68201 100644
--- a/drivers/media/platform/coda.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -38,7 +38,7 @@
#include media/videobuf2-core.h
#include media/videobuf2-dma-contig.h
-#include coda.h
+#include coda_regs.h
#define CODA_NAME coda
diff --git a/drivers/media/platform/coda.h
b/drivers/media/platform/coda/coda_regs.h
similarity index 100%
rename from drivers/media/platform/coda.h
rename to drivers/media/platform/coda/coda_regs.h
--
2.0.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 0/8] Split CODA driver into multiple files
Hi,
Hans suggested to split the CODA driver, so this series moves it into
its own subdirectory and splits it roughly in half by moving the BIT
processor handling and H.264 specific helper function out into their
own files.
The coda-bit.c will get its coda-jpeg.c counterpart in the future
for JPEG encoding and decoding on i.MX6.
regards
Philipp
Philipp Zabel (8):
[media] coda: move coda driver into its own directory
[media] coda: move defines, enums, and structs into shared header
[media] coda: add context ops
[media] coda: move BIT processor command execution out of pic_run_work
[media] coda: add coda_bit_stream_set_flag helper
[media] coda: move per-instance buffer allocation and cleanup
[media] coda: move H.264 helper function into separate file
[media] coda: move BIT specific functions into separate file
drivers/media/platform/Makefile|2 +-
drivers/media/platform/coda.c | 4000
drivers/media/platform/coda/Makefile |3 +
drivers/media/platform/coda/coda-bit.c | 1810 +
drivers/media/platform/coda/coda-common.c | 2003 ++
drivers/media/platform/coda/coda-h264.c| 36 +
drivers/media/platform/coda/coda.h | 287 ++
.../media/platform/{coda.h = coda/coda_regs.h}|0
8 files changed, 4140 insertions(+), 4001 deletions(-)
delete mode 100644 drivers/media/platform/coda.c
create mode 100644 drivers/media/platform/coda/Makefile
create mode 100644 drivers/media/platform/coda/coda-bit.c
create mode 100644 drivers/media/platform/coda/coda-common.c
create mode 100644 drivers/media/platform/coda/coda-h264.c
create mode 100644 drivers/media/platform/coda/coda.h
rename drivers/media/platform/{coda.h = coda/coda_regs.h} (100%)
--
2.0.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] correct formats info in s5p-mfc encoder
I have tested it in exynos 4412. I enable MFC and with 64MB buffer in echo bank. ayaka (1): s5p-mfc: correct the formats info for encoder drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) -- 1.9.3 -- 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] s5p-mfc: correct the formats info for encoder
The NV12M is supported by all the version of MFC, so it is better
to use it as default OUTPUT format.
MFC v5 doesn't support NV21, I have tested it, for the SEC doc
it is not supported either.
---
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index d26b248..4ea3796 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -32,7 +32,7 @@
#include s5p_mfc_intr.h
#include s5p_mfc_opr.h
-#define DEF_SRC_FMT_ENCV4L2_PIX_FMT_NV12MT
+#define DEF_SRC_FMT_ENCV4L2_PIX_FMT_NV12M
#define DEF_DST_FMT_ENCV4L2_PIX_FMT_H264
static struct s5p_mfc_fmt formats[] = {
@@ -67,8 +67,7 @@ static struct s5p_mfc_fmt formats[] = {
.codec_mode = S5P_MFC_CODEC_NONE,
.type = MFC_FMT_RAW,
.num_planes = 2,
- .versions = MFC_V5_BIT | MFC_V6_BIT | MFC_V7_BIT |
- MFC_V8_BIT,
+ .versions = MFC_V6_BIT | MFC_V7_BIT | MFC_V8_BIT,
},
{
.name = H264 Encoded Stream,
--
1.9.3
--
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: Removal of regulator framework
On Sat, Jul 19, 2014 at 9:19 AM, Hauke Mehrtens ha...@hauke-m.de wrote: Maintaining the regulator drivers in backports costs some time and I do not need them. Is anybody using the regulator drivers from backports? I would like to remove them. That came simply from collateral of backporting media drivers, eventually I started running into device drivers that used the regulator framework. Since we have tons of media drivers perhaps the more sensible thing to do is to white list a set of media divers that people actually care and then we just nuke both regulator and media drivers that no one cares for. For that though I'd like to ask media folks. Here's a list of media drivers I know SUSE does support, in case that helps. Right now backports carries all of drivers/media though. drivers/media/common/btcx-risc # some code shared by bttv and cx88xx drivers drivers/media/common/cx2341x drivers/media/common/saa7146/saa7146 drivers/media/common/saa7146/saa7146_vv drivers/media/common/tveeprom drivers/media/i2c/adv7170 # Analog Devices ADV7170 video encoder driver drivers/media/i2c/adv7175 # Analog Devices ADV7175 video encoder driver drivers/media/i2c/bt819 # Brooktree-819 video decoder driver drivers/media/i2c/bt856 # Brooktree-856A video encoder driver drivers/media/i2c/cs5345 drivers/media/i2c/cs53l32a # cs53l32a (Adaptec AVC-2010 and AVC-2410) i2c ivtv driver drivers/media/i2c/cx25840/cx25840 # Conexant CX25840 audio/video decoder driver drivers/media/i2c/ir-kbd-i2c# input driver for i2c IR remote controls drivers/media/i2c/ks0127 drivers/media/i2c/m52790 drivers/media/i2c/msp3400 # device driver for msp34xx TV sound processor drivers/media/i2c/saa6588 # Philips SAA6588 RDS decoder drivers/media/i2c/saa7110 # Philips SAA7110 video decoder driver drivers/media/i2c/saa7115 # Philips SAA7111/13/14/15/18 video decoder driver drivers/media/i2c/saa7127 # Philips SAA7127/SAA7129 video encoder driver drivers/media/i2c/saa717x drivers/media/i2c/saa7185 # Philips SAA7185 video encoder driver drivers/media/i2c/tda7432 # bttv driver for the tda7432 audio processor chip drivers/media/i2c/tda9840 drivers/media/i2c/tea6415c drivers/media/i2c/tea6420 drivers/media/i2c/tvaudio # device driver for various i2c TV sound decoder / audiomux chips drivers/media/i2c/tvp5150 # Texas Instruments TVP5150A(M) video decoder driver drivers/media/i2c/upd64031a drivers/media/i2c/upd64083 drivers/media/i2c/vp27smpx drivers/media/i2c/vpx3220 # vpx3220a/vpx3216b/vpx3214c video encoder driver drivers/media/i2c/wm8739 drivers/media/i2c/wm8775 drivers/media/pci/bt8xx/bttv drivers/media/pci/cx88/cx88-alsa drivers/media/pci/cx88/cx88-blackbird drivers/media/pci/cx88/cx8800 drivers/media/pci/cx88/cx8802 drivers/media/pci/cx88/cx88xx drivers/media/pci/ivtv/ivtv drivers/media/pci/ivtv/ivtvfb drivers/media/pci/meye/meye drivers/media/pci/saa7134/saa6752hs # device driver for saa6752hs MPEG2 encoder drivers/media/pci/saa7134/saa7134 drivers/media/pci/saa7134/saa7134-alsa drivers/media/pci/saa7134/saa7134-empress drivers/media/pci/saa7146/hexium_gemini drivers/media/pci/saa7146/hexium_orion drivers/media/pci/saa7146/mxb # video4linux-2 driver for the Siemens-Nixdorf 'Multimedia eXtension board' drivers/media/pci/zoran/videocodec # Intermediate API module for video codecs drivers/media/pci/zoran/zr36016 drivers/media/pci/zoran/zr36050 drivers/media/pci/zoran/zr36060 drivers/media/pci/zoran/zr36067 drivers/media/platform/vivi drivers/media/radio/dsbr100 drivers/media/radio/radio-maxiradio # Radio driver for the Guillemot Maxi Radio FM2000 radio. drivers/media/radio/si470x/radio-usb-si470x
[PATCH v4 1/2] media: soc_camera: pxa_camera device-tree support
Add device-tree support to pxa_camera host driver.
Signed-off-by: Robert Jarzmik robert.jarz...@free.fr
[g.liakhovet...@gmx.de: added of_node_put()]
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Robert, could you review and test this version, please?
Thanks
Guennadi
drivers/media/platform/soc_camera/pxa_camera.c | 81 +-
1 file changed, 79 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/soc_camera/pxa_camera.c
b/drivers/media/platform/soc_camera/pxa_camera.c
index d4df305..64dc80c 100644
--- a/drivers/media/platform/soc_camera/pxa_camera.c
+++ b/drivers/media/platform/soc_camera/pxa_camera.c
@@ -34,6 +34,7 @@
#include media/videobuf-dma-sg.h
#include media/soc_camera.h
#include media/soc_mediabus.h
+#include media/v4l2-of.h
#include linux/videodev2.h
@@ -1650,6 +1651,68 @@ static struct soc_camera_host_ops
pxa_soc_camera_host_ops = {
.set_bus_param = pxa_camera_set_bus_param,
};
+static int pxa_camera_pdata_from_dt(struct device *dev,
+ struct pxa_camera_dev *pcdev)
+{
+ u32 mclk_rate;
+ struct device_node *np = dev-of_node;
+ struct v4l2_of_endpoint ep;
+ int err = of_property_read_u32(np, clock-frequency,
+ mclk_rate);
+ if (!err) {
+ pcdev-platform_flags |= PXA_CAMERA_MCLK_EN;
+ pcdev-mclk = mclk_rate;
+ }
+
+ np = of_graph_get_next_endpoint(np, NULL);
+ if (!np) {
+ dev_err(dev, could not find endpoint\n);
+ return -EINVAL;
+ }
+
+ err = v4l2_of_parse_endpoint(np, ep);
+ if (err) {
+ dev_err(dev, could not parse endpoint\n);
+ goto out;
+ }
+
+ switch (ep.bus.parallel.bus_width) {
+ case 4:
+ pcdev-platform_flags |= PXA_CAMERA_DATAWIDTH_4;
+ break;
+ case 5:
+ pcdev-platform_flags |= PXA_CAMERA_DATAWIDTH_5;
+ break;
+ case 8:
+ pcdev-platform_flags |= PXA_CAMERA_DATAWIDTH_8;
+ break;
+ case 9:
+ pcdev-platform_flags |= PXA_CAMERA_DATAWIDTH_9;
+ break;
+ case 10:
+ pcdev-platform_flags |= PXA_CAMERA_DATAWIDTH_10;
+ break;
+ default:
+ break;
+ };
+
+ if (ep.bus.parallel.flags V4L2_MBUS_MASTER)
+ pcdev-platform_flags |= PXA_CAMERA_MASTER;
+ if (ep.bus.parallel.flags V4L2_MBUS_HSYNC_ACTIVE_HIGH)
+ pcdev-platform_flags |= PXA_CAMERA_HSP;
+ if (ep.bus.parallel.flags V4L2_MBUS_VSYNC_ACTIVE_HIGH)
+ pcdev-platform_flags |= PXA_CAMERA_VSP;
+ if (ep.bus.parallel.flags V4L2_MBUS_PCLK_SAMPLE_RISING)
+ pcdev-platform_flags |= PXA_CAMERA_PCLK_EN | PXA_CAMERA_PCP;
+ if (ep.bus.parallel.flags V4L2_MBUS_PCLK_SAMPLE_FALLING)
+ pcdev-platform_flags |= PXA_CAMERA_PCLK_EN;
+
+out:
+ of_node_put(np);
+
+ return err;
+}
+
static int pxa_camera_probe(struct platform_device *pdev)
{
struct pxa_camera_dev *pcdev;
@@ -1676,7 +1739,15 @@ static int pxa_camera_probe(struct platform_device *pdev)
pcdev-res = res;
pcdev-pdata = pdev-dev.platform_data;
- pcdev-platform_flags = pcdev-pdata-flags;
+ if (pdev-dev.of_node !pcdev-pdata) {
+ err = pxa_camera_pdata_from_dt(pdev-dev, pcdev);
+ } else {
+ pcdev-platform_flags = pcdev-pdata-flags;
+ pcdev-mclk = pcdev-pdata-mclk_10khz * 1;
+ }
+ if (err 0)
+ return err;
+
if (!(pcdev-platform_flags (PXA_CAMERA_DATAWIDTH_8 |
PXA_CAMERA_DATAWIDTH_9 | PXA_CAMERA_DATAWIDTH_10))) {
/*
@@ -1693,7 +1764,6 @@ static int pxa_camera_probe(struct platform_device *pdev)
pcdev-width_flags |= 1 8;
if (pcdev-platform_flags PXA_CAMERA_DATAWIDTH_10)
pcdev-width_flags |= 1 9;
- pcdev-mclk = pcdev-pdata-mclk_10khz * 1;
if (!pcdev-mclk) {
dev_warn(pdev-dev,
mclk == 0! Please, fix your platform data.
@@ -1799,10 +1869,17 @@ static const struct dev_pm_ops pxa_camera_pm = {
.resume = pxa_camera_resume,
};
+static const struct of_device_id pxa_camera_of_match[] = {
+ { .compatible = marvell,pxa270-qci, },
+ {},
+};
+MODULE_DEVICE_TABLE(of, pxa_camera_of_match);
+
static struct platform_driver pxa_camera_driver = {
.driver = {
.name = PXA_CAM_DRV_NAME,
.pm = pxa_camera_pm,
+ .of_match_table = of_match_ptr(pxa_camera_of_match),
},
.probe = pxa_camera_probe,
.remove = pxa_camera_remove,
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message
Re: [PATCH v4 1/2] media: soc_camera: pxa_camera device-tree support
Guennadi Liakhovetski g.liakhovet...@gmx.de writes: Add device-tree support to pxa_camera host driver. Signed-off-by: Robert Jarzmik robert.jarz...@free.fr [g.liakhovet...@gmx.de: added of_node_put()] Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- Robert, could you review and test this version, please? Yeah, sure, a couple of hours and it will be tested. Cheers. -- Robert -- 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: Removal of regulator framework
Em Wed, 23 Jul 2014 10:13:28 -0700 Luis R. Rodriguez mcg...@do-not-panic.com escreveu: On Sat, Jul 19, 2014 at 9:19 AM, Hauke Mehrtens ha...@hauke-m.de wrote: Maintaining the regulator drivers in backports costs some time and I do not need them. Is anybody using the regulator drivers from backports? I would like to remove them. That came simply from collateral of backporting media drivers, eventually I started running into device drivers that used the regulator framework. Since we have tons of media drivers perhaps the more sensible thing to do is to white list a set of media divers that people actually care and then we just nuke both regulator and media drivers that no one cares for. For that though I'd like to ask media folks. Hi Luis, The drivers that currently use regulators are mostly the ones at drivers/media/platform, plus the corresponding I2C drivers for their webcam sensors, under drivers/media/i2c. I think that there's one exception though: em28xx. This driver can use some sensor drivers, as it supports a few webcams. This is one of the most used USB media driver, as there are lots of USB supported on it, supporting 4 types of devices on it: analog TV, capture card, digital TV and webcam. The webcam part of em28xx is not that relevant, as there are very few models using it. However, currently, it is not possible to just disable webcam support. It shouldn't be hard to make webcam support optional on it, as it has already sub-drivers for V4L2, DVB, ALSA and remote controller. One additional driver for webcam, that could be disabled at the backport tree shouldn't be hard to do. If you want it, patches are welcome. Here's a list of media drivers I know SUSE does support, in case that helps. Right now backports carries all of drivers/media though. drivers/media/common/btcx-risc # some code shared by bttv and cx88xx drivers drivers/media/common/cx2341x drivers/media/common/saa7146/saa7146 drivers/media/common/saa7146/saa7146_vv drivers/media/common/tveeprom drivers/media/i2c/adv7170 # Analog Devices ADV7170 video encoder driver drivers/media/i2c/adv7175 # Analog Devices ADV7175 video encoder driver drivers/media/i2c/bt819 # Brooktree-819 video decoder driver drivers/media/i2c/bt856 # Brooktree-856A video encoder driver drivers/media/i2c/cs5345 drivers/media/i2c/cs53l32a # cs53l32a (Adaptec AVC-2010 and AVC-2410) i2c ivtv driver drivers/media/i2c/cx25840/cx25840 # Conexant CX25840 audio/video decoder driver drivers/media/i2c/ir-kbd-i2c# input driver for i2c IR remote controls drivers/media/i2c/ks0127 drivers/media/i2c/m52790 drivers/media/i2c/msp3400 # device driver for msp34xx TV sound processor drivers/media/i2c/saa6588 # Philips SAA6588 RDS decoder drivers/media/i2c/saa7110 # Philips SAA7110 video decoder driver drivers/media/i2c/saa7115 # Philips SAA7111/13/14/15/18 video decoder driver drivers/media/i2c/saa7127 # Philips SAA7127/SAA7129 video encoder driver drivers/media/i2c/saa717x drivers/media/i2c/saa7185 # Philips SAA7185 video encoder driver drivers/media/i2c/tda7432 # bttv driver for the tda7432 audio processor chip drivers/media/i2c/tda9840 drivers/media/i2c/tea6415c drivers/media/i2c/tea6420 drivers/media/i2c/tvaudio # device driver for various i2c TV sound decoder / audiomux chips drivers/media/i2c/tvp5150 # Texas Instruments TVP5150A(M) video decoder driver drivers/media/i2c/upd64031a drivers/media/i2c/upd64083 drivers/media/i2c/vp27smpx drivers/media/i2c/vpx3220 # vpx3220a/vpx3216b/vpx3214c video encoder driver drivers/media/i2c/wm8739 drivers/media/i2c/wm8775 drivers/media/pci/bt8xx/bttv drivers/media/pci/cx88/cx88-alsa drivers/media/pci/cx88/cx88-blackbird drivers/media/pci/cx88/cx8800 drivers/media/pci/cx88/cx8802 drivers/media/pci/cx88/cx88xx drivers/media/pci/ivtv/ivtv drivers/media/pci/ivtv/ivtvfb drivers/media/pci/meye/meye
Re: [PATCH 4/6] [V3] soc_camera: add support for dt binding soc_camera drivers
Hi Ben,
Thanks for a patch update. According to my calculations, this is a v5, not
a v3. And please follow the subject line convention like
[PATCH V5 4/6] subject text follows
and use the same version in all patches of a series - this simplifies
their handling. You can use something like
--subject-prefix=PATCH V6
for your git format-patch to automate this.
On Sat, 5 Jul 2014, Ben Dooks wrote:
Add initial support for OF based soc-camera devices that may be used
by any of the soc-camera drivers. The driver itself will need converting
to use OF.
These changes allow the soc-camera driver to do the connecting of any
async capable v4l2 device to the soc-camera driver. This has currently
been tested on the Renesas Lager board.
It currently only supports one input device per driver as this seems
to be the standard connection for these devices.
Signed-off-by: Ben Dooks ben.do...@codethink.co.uk
---
Fixes since v1:
- Fix i2c mclk name compatible with other drivers
- Ensure of_node is put after use
Fixes since v2:
- Updated freeing of dyn-pdev as requested
- Coding style fixes
- Allocate initial resources in one go
---
drivers/media/platform/soc_camera/soc_camera.c | 123
-
1 file changed, 122 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/soc_camera/soc_camera.c
b/drivers/media/platform/soc_camera/soc_camera.c
index 7fec8cd..e25fc8e 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -36,6 +36,7 @@
#include media/v4l2-common.h
#include media/v4l2-ioctl.h
#include media/v4l2-dev.h
+#include media/v4l2-of.h
#include media/videobuf-core.h
#include media/videobuf2-core.h
@@ -1581,6 +1582,124 @@ static void scan_async_host(struct soc_camera_host
*ici)
#define scan_async_host(ici) do {} while (0)
#endif
+#ifdef CONFIG_OF
+
+struct soc_of_info {
+ struct soc_camera_async_subdev sasd;
+ struct v4l2_async_subdev*subdevs[2];
+};
Yes, this is a right direction, however, why do you use an array of 2
subdev pointers? You only seem to be using one of them?
+
+static int soc_of_bind(struct soc_camera_host *ici,
+struct device_node *ep,
+struct device_node *remote)
+{
+ struct soc_camera_device *icd;
+ struct soc_camera_desc sdesc = {.host_desc.bus_id = ici-nr,};
+ struct soc_camera_async_client *sasc;
+ struct soc_of_info *info;
+ struct i2c_client *client;
+ char clk_name[V4L2_SUBDEV_NAME_SIZE];
+ int ret;
+
+ /* allocate a new subdev and add match info to it */
+ info = devm_kzalloc(ici-v4l2_dev.dev, sizeof(struct soc_of_info),
+ GFP_KERNEL);
+ if (!info)
+ return -ENOMEM;
+
+ info-sasd.asd.match.of.node = remote;
+ info-sasd.asd.match_type = V4L2_ASYNC_MATCH_OF;
+ info-subdevs[0] = info-sasd.asd;
+
+ /* Or shall this be managed by the soc-camera device? */
+ sasc = devm_kzalloc(ici-v4l2_dev.dev, sizeof(*sasc), GFP_KERNEL);
Why not also add struct soc_camera_async_client to struct soc_of_info?
Thanks
Guennadi
+ if (!sasc)
+ return -ENOMEM;
+
+ /* HACK: just need a != NULL */
+ sdesc.host_desc.board_info = ERR_PTR(-ENODATA);
+
+ ret = soc_camera_dyn_pdev(sdesc, sasc);
+ if (ret 0)
+ goto eallocpdev;
+
+ sasc-sensor = info-sasd.asd;
+
+ icd = soc_camera_add_pdev(sasc);
+ if (!icd) {
+ ret = -ENOMEM;
+ goto eaddpdev;
+ }
+
+ sasc-notifier.subdevs = info-subdevs;
+ sasc-notifier.num_subdevs = 1;
+ sasc-notifier.bound = soc_camera_async_bound;
+ sasc-notifier.unbind = soc_camera_async_unbind;
+ sasc-notifier.complete = soc_camera_async_complete;
+
+ icd-sasc = sasc;
+ icd-parent = ici-v4l2_dev.dev;
+
+ client = of_find_i2c_device_by_node(remote);
+
+ if (client)
+ snprintf(clk_name, sizeof(clk_name), %d-%04x,
+ client-adapter-nr, client-addr);
+ else
+ snprintf(clk_name, sizeof(clk_name), of-%s,
+ of_node_full_name(remote));
+
+ icd-clk = v4l2_clk_register(soc_camera_clk_ops, clk_name, mclk,
icd);
+ if (IS_ERR(icd-clk)) {
+ ret = PTR_ERR(icd-clk);
+ goto eclkreg;
+ }
+
+ ret = v4l2_async_notifier_register(ici-v4l2_dev, sasc-notifier);
+ if (!ret)
+ return 0;
+eclkreg:
+ icd-clk = NULL;
+ platform_device_del(sasc-pdev);
+eaddpdev:
+ platform_device_put(sasc-pdev);
+eallocpdev:
+ devm_kfree(ici-v4l2_dev.dev, sasc);
+ dev_err(ici-v4l2_dev.dev, group probe failed: %d\n, ret);
+
+ return ret;
+}
+
+static void scan_of_host(struct soc_camera_host *ici)
+{
+ struct device_node *np = ici-v4l2_dev.dev-of_node;
[PATCH v6 4/6] soc_camera: add support for dt binding soc_camera drivers
Add initial support for OF based soc-camera devices that may be used
by any of the soc-camera drivers. The driver itself will need converting
to use OF.
These changes allow the soc-camera driver to do the connecting of any
async capable v4l2 device to the soc-camera driver. This has currently
been tested on the Renesas Lager board.
It currently only supports one input device per driver as this seems
to be the standard connection for these devices.
Signed-off-by: Ben Dooks ben.do...@codethink.co.uk
[g.liakhovet...@gmx.de add check for multiple subdevices]
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Hi Ben,
How about this version? Could you review and test?
Thanks
Guennadi
drivers/media/platform/soc_camera/soc_camera.c | 129 -
1 file changed, 128 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/soc_camera/soc_camera.c
b/drivers/media/platform/soc_camera/soc_camera.c
index dc626b9..f4308fe 100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -36,6 +36,7 @@
#include media/v4l2-common.h
#include media/v4l2-ioctl.h
#include media/v4l2-dev.h
+#include media/v4l2-of.h
#include media/videobuf-core.h
#include media/videobuf2-core.h
@@ -1585,6 +1586,130 @@ static void scan_async_host(struct soc_camera_host *ici)
#define scan_async_host(ici) do {} while (0)
#endif
+#ifdef CONFIG_OF
+
+struct soc_of_info {
+ struct soc_camera_async_subdev sasd;
+ struct soc_camera_async_client sasc;
+ struct v4l2_async_subdev*subdev;
+};
+
+static int soc_of_bind(struct soc_camera_host *ici,
+ struct device_node *ep,
+ struct device_node *remote)
+{
+ struct soc_camera_device *icd;
+ struct soc_camera_desc sdesc = {.host_desc.bus_id = ici-nr,};
+ struct soc_camera_async_client *sasc;
+ struct soc_of_info *info;
+ struct i2c_client *client;
+ char clk_name[V4L2_SUBDEV_NAME_SIZE];
+ int ret;
+
+ /* allocate a new subdev and add match info to it */
+ info = devm_kzalloc(ici-v4l2_dev.dev, sizeof(struct soc_of_info),
+ GFP_KERNEL);
+ if (!info)
+ return -ENOMEM;
+
+ info-sasd.asd.match.of.node = remote;
+ info-sasd.asd.match_type = V4L2_ASYNC_MATCH_OF;
+ info-subdev = info-sasd.asd;
+
+ /* Or shall this be managed by the soc-camera device? */
+ sasc = info-sasc;
+
+ /* HACK: just need a != NULL */
+ sdesc.host_desc.board_info = ERR_PTR(-ENODATA);
+
+ ret = soc_camera_dyn_pdev(sdesc, sasc);
+ if (ret 0)
+ goto eallocpdev;
+
+ sasc-sensor = info-sasd.asd;
+
+ icd = soc_camera_add_pdev(sasc);
+ if (!icd) {
+ ret = -ENOMEM;
+ goto eaddpdev;
+ }
+
+ sasc-notifier.subdevs = info-subdev;
+ sasc-notifier.num_subdevs = 1;
+ sasc-notifier.bound = soc_camera_async_bound;
+ sasc-notifier.unbind = soc_camera_async_unbind;
+ sasc-notifier.complete = soc_camera_async_complete;
+
+ icd-sasc = sasc;
+ icd-parent = ici-v4l2_dev.dev;
+
+ client = of_find_i2c_device_by_node(remote);
+
+ if (client)
+ snprintf(clk_name, sizeof(clk_name), %d-%04x,
+client-adapter-nr, client-addr);
+ else
+ snprintf(clk_name, sizeof(clk_name), of-%s,
+of_node_full_name(remote));
+
+ icd-clk = v4l2_clk_register(soc_camera_clk_ops, clk_name, mclk,
icd);
+ if (IS_ERR(icd-clk)) {
+ ret = PTR_ERR(icd-clk);
+ goto eclkreg;
+ }
+
+ ret = v4l2_async_notifier_register(ici-v4l2_dev, sasc-notifier);
+ if (!ret)
+ return 0;
+eclkreg:
+ icd-clk = NULL;
+ platform_device_del(sasc-pdev);
+eaddpdev:
+ platform_device_put(sasc-pdev);
+eallocpdev:
+ devm_kfree(ici-v4l2_dev.dev, sasc);
+ dev_err(ici-v4l2_dev.dev, group probe failed: %d\n, ret);
+
+ return ret;
+}
+
+static void scan_of_host(struct soc_camera_host *ici)
+{
+ struct device *dev = ici-v4l2_dev.dev;
+ struct device_node *np = dev-of_node;
+ struct device_node *epn = NULL, *ren;
+ unsigned int i;
+
+ for (i = 0; ; i++) {
+ epn = of_graph_get_next_endpoint(np, epn);
+ if (!epn)
+ break;
+
+ ren = of_graph_get_remote_port(epn);
+ if (!ren) {
+ dev_notice(dev, no remote for %s\n,
+ of_node_full_name(epn));
+ continue;
+ }
+
+ /* so we now have a remote node to connect */
+ if (!i)
+ soc_of_bind(ici, epn, ren-parent);
+
+ of_node_put(epn);
+ of_node_put(ren);
+
+ if (i) {
+
[PATCH v6 3/6] rcar_vin: add devicetree support
Add support for devicetree probe for the rcar-vin
driver.
Signed-off-by: Ben Dooks ben.do...@codethink.co.uk
[g.liakhovet...@gmx.de fix a typo, sort headers alphabetically]
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Ben, is this version ok?
.../devicetree/bindings/media/rcar_vin.txt | 86 ++
drivers/media/platform/soc_camera/rcar_vin.c | 72 --
2 files changed, 151 insertions(+), 7 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/rcar_vin.txt
diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt
b/Documentation/devicetree/bindings/media/rcar_vin.txt
new file mode 100644
index 000..ba61782
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
@@ -0,0 +1,86 @@
+Renesas RCar Video Input driver (rcar_vin)
+--
+
+The rcar_vin device provides video input capabilities for the Renesas R-Car
+family of devices. The current blocks are always slaves and suppot one input
+channel which can be either RGB, YUYV or BT656.
+
+ - compatible: Must be one of the following
+ - renesas,vin-r8a7791 for the R8A7791 device
+ - renesas,vin-r8a7790 for the R8A7790 device
+ - renesas,vin-r8a7779 for the R8A7779 device
+ - renesas,vin-r8a7778 for the R8A7778 device
+ - reg: the register base and size for the device registers
+ - interrupts: the interrupt for the device
+ - clocks: Reference to the parent clock
+
+Additionally, an alias named vinX will need to be created to specify
+which video input device this is.
+
+The per-board settings:
+ - port sub-node describing a single endpoint connected to the vin
+ as described in video-interfaces.txt[1]. Only the first one will
+ be considered as each vin interface has one input port.
+
+ These settings are used to work out video input format and widths
+ into the system.
+
+
+Device node example
+---
+
+ aliases {
+ vin0 = vin0;
+ };
+
+vin0: vin@0xe6ef {
+compatible = renesas,vin-r8a7790;
+clocks = mstp8_clks R8A7790_CLK_VIN0;
+reg = 0 0xe6ef 0 0x1000;
+interrupts = 0 188 IRQ_TYPE_LEVEL_HIGH;
+status = disabled;
+};
+
+Board setup example (vin1 composite video input)
+
+
+i2c2 {
+status = ok;
+pinctrl-0 = i2c2_pins;
+pinctrl-names = default;
+
+adv7180@20 {
+compatible = adi,adv7180;
+reg = 0x20;
+remote = vin1;
+
+port {
+adv7180: endpoint {
+bus-width = 8;
+remote-endpoint = vin1ep0;
+};
+};
+};
+};
+
+/* composite video input */
+vin1 {
+pinctrl-0 = vin1_pins;
+pinctrl-names = default;
+
+status = ok;
+
+port {
+#address-cells = 1;
+#size-cells = 0;
+
+vin1ep0: endpoint {
+remote-endpoint = adv7180;
+bus-width = 8;
+};
+};
+};
+
+
+
+[1] video-interfaces.txt common video media interface
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c
index 7c4299d..85d579f 100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -19,6 +19,8 @@
#include linux/io.h
#include linux/kernel.h
#include linux/module.h
+#include linux/of.h
+#include linux/of_device.h
#include linux/platform_data/camera-rcar.h
#include linux/platform_device.h
#include linux/pm_runtime.h
@@ -31,6 +33,7 @@
#include media/v4l2-dev.h
#include media/v4l2-device.h
#include media/v4l2-mediabus.h
+#include media/v4l2-of.h
#include media/v4l2-subdev.h
#include media/videobuf2-dma-contig.h
@@ -1390,6 +1393,17 @@ static struct soc_camera_host_ops rcar_vin_host_ops = {
.init_videobuf2 = rcar_vin_init_videobuf2,
};
+#ifdef CONFIG_OF
+static struct of_device_id rcar_vin_of_table[] = {
+ { .compatible = renesas,vin-r8a7791, .data = (void *)RCAR_GEN2 },
+ { .compatible = renesas,vin-r8a7790, .data = (void *)RCAR_GEN2 },
+ { .compatible = renesas,vin-r8a7779, .data = (void *)RCAR_H1 },
+ { .compatible = renesas,vin-r8a7778, .data = (void *)RCAR_M1 },
+ { },
+};
+MODULE_DEVICE_TABLE(of, rcar_vin_of_table);
+#endif
+
static struct platform_device_id rcar_vin_id_table[] = {
{ r8a7791-vin, RCAR_GEN2 },
{ r8a7790-vin, RCAR_GEN2 },
@@ -1402,15 +1416,52 @@ MODULE_DEVICE_TABLE(platform, rcar_vin_id_table);
static int rcar_vin_probe(struct platform_device *pdev)
{
+ const struct of_device_id *match = NULL;
struct rcar_vin_priv *priv;
struct resource *mem;
struct
Re: Removal of regulator framework
On Wed, Jul 23, 2014 at 10:57 AM, Mauro Carvalho Chehab m.che...@samsung.com wrote: Em Wed, 23 Jul 2014 10:13:28 -0700 Luis R. Rodriguez mcg...@do-not-panic.com escreveu: On Sat, Jul 19, 2014 at 9:19 AM, Hauke Mehrtens ha...@hauke-m.de wrote: Maintaining the regulator drivers in backports costs some time and I do not need them. Is anybody using the regulator drivers from backports? I would like to remove them. That came simply from collateral of backporting media drivers, eventually I started running into device drivers that used the regulator framework. Since we have tons of media drivers perhaps the more sensible thing to do is to white list a set of media divers that people actually care and then we just nuke both regulator and media drivers that no one cares for. For that though I'd like to ask media folks. Hi Luis, The drivers that currently use regulators are mostly the ones at drivers/media/platform, plus the corresponding I2C drivers for their webcam sensors, under drivers/media/i2c. I think that there's one exception though: em28xx. This driver can use some sensor drivers, as it supports a few webcams. This is one of the most used USB media driver, as there are lots of USB supported on it, supporting 4 types of devices on it: analog TV, capture card, digital TV and webcam. The webcam part of em28xx is not that relevant, as there are very few models using it. However, currently, it is not possible to just disable webcam support. It shouldn't be hard to make webcam support optional on it, as it has already sub-drivers for V4L2, DVB, ALSA and remote controller. One additional driver for webcam, that could be disabled at the backport tree shouldn't be hard to do. If you want it, patches are welcome. Thanks for the details Mauro, are you aware of current or future uses of backports for media at this point? Adding media drivers was more of an experiment to see how hard or easy it would be to add a new unrelated subsystem, we carry it now and as collateral also carry some regulator drivers but its not clear the value in terms of users, so hence Hauke's question of removal of the regulator drivers. It'd be good to limit the drivers we carry to what folks actually use and care about. Luis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] get_dvb_firmware: Add firmware extractor for si2165
On 23.07.2014 11:20, Antti Palosaari wrote: Moikka Matthias Moikka Antti, On 07/22/2014 11:12 PM, Matthias Schwarzott wrote: + +my $CRC=\x0A\xCC; +my $BLOCKS_MAIN=\x27; +open FW,$fwfile; +print FW \x01\x00; # just a version id for the driver itself +print FW \x9A; # fw version +print FW \x00; # padding +print FW $BLOCKS_MAIN; # number of blocks of main part +print FW \x00; # padding +print FW $CRC; # 16bit crc value of main part +appendfile(FW,$tmpdir/fw1); I have to say I little bit dislike that kind of own headers. There is no way to read firmware version from binary itself (very often there is)? Whats is benefit of telling how many blocks there is? Isn't it possible to detect somehow by examining firmware image itself runtime? Anyhow, you are the author of that driver and even I don't personally like those, I think it is up to your decision as a author. I thought a bit about the need for the header. And yes, some fields I can get rid of. firmware version: I guess that the exact version number is not really needed - it is just written to a seperate register - and later only read to check if firmware was already downloaded (but for documentation it might be interesting). I have no clue where it could be in the raw block - it looks like it is writing to just some memory addresses. But for the pure process it would also work to write a random number != 0x00. For $BLOCKS_MAIN: The firmware is downloaded like this: * write 1 block * reset crc logic * write $BLOCKS_MAIN * read out crc and compare against $CRC in header * write last 5 blocks so the number of blocks in $BLOCKS_MAIN could be checked by iterating over all blocks counting them and then substracting 6. The crc value: It protects the content of the file until it is in the demod - so calculating it on my own would only check if the data is correctly transferred from the driver into the chip. But for this I needed to know the algorithm and which data is checksummed exactly. Are the different algorithms for CRC values that give 16 bit of output? Matthias -- 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: Removal of regulator framework
On 07/23/2014 08:23 PM, Luis R. Rodriguez wrote: On Wed, Jul 23, 2014 at 10:57 AM, Mauro Carvalho Chehab m.che...@samsung.com wrote: Em Wed, 23 Jul 2014 10:13:28 -0700 Luis R. Rodriguez mcg...@do-not-panic.com escreveu: On Sat, Jul 19, 2014 at 9:19 AM, Hauke Mehrtens ha...@hauke-m.de wrote: Maintaining the regulator drivers in backports costs some time and I do not need them. Is anybody using the regulator drivers from backports? I would like to remove them. That came simply from collateral of backporting media drivers, eventually I started running into device drivers that used the regulator framework. Since we have tons of media drivers perhaps the more sensible thing to do is to white list a set of media divers that people actually care and then we just nuke both regulator and media drivers that no one cares for. For that though I'd like to ask media folks. Hi Luis, The drivers that currently use regulators are mostly the ones at drivers/media/platform, plus the corresponding I2C drivers for their webcam sensors, under drivers/media/i2c. I think that there's one exception though: em28xx. This driver can use some sensor drivers, as it supports a few webcams. This is one of the most used USB media driver, as there are lots of USB supported on it, supporting 4 types of devices on it: analog TV, capture card, digital TV and webcam. The webcam part of em28xx is not that relevant, as there are very few models using it. However, currently, it is not possible to just disable webcam support. It shouldn't be hard to make webcam support optional on it, as it has already sub-drivers for V4L2, DVB, ALSA and remote controller. One additional driver for webcam, that could be disabled at the backport tree shouldn't be hard to do. If you want it, patches are welcome. Thanks for the details Mauro, are you aware of current or future uses of backports for media at this point? Adding media drivers was more of an experiment to see how hard or easy it would be to add a new unrelated subsystem, we carry it now and as collateral also carry some regulator drivers but its not clear the value in terms of users, so hence Hauke's question of removal of the regulator drivers. It'd be good to limit the drivers we carry to what folks actually use and care about. Luis Hi, carrying some regularity drivers which are needed for some specific media driver does not look like a big problem. The current problem from my side is that we carry all regularity drivers by default and that causes some problems. Many of these driver are used only on one specific SoC product line and uses their often changing interface, so they break often. When all the regulator drivers are only needed for the media driver I would add just add the driver which are actually used by a shipped media driver and nothing more. Hauke -- 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: Removal of regulator framework
On Wed, Jul 23, 2014 at 11:56 AM, Hauke Mehrtens ha...@hauke-m.de wrote: carrying some regularity drivers which are needed for some specific media driver does not look like a big problem. The current problem from my side is that we carry all regularity drivers by default and that causes some problems. Many of these driver are used only on one specific SoC product line and uses their often changing interface, so they break often. When all the regulator drivers are only needed for the media driver I would add just add the driver which are actually used by a shipped media driver and nothing more. Makes sense. I'm suggesting we can trim even more by only keeping media drivers we really should care for and its dependencies. We need a white list then, do we want to start off with perhaps the list I posted? Media folks, is there anything else we should carry that would help the media folks? Luis -- 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
cxusb: How to add CI support?
Hi everyone, I'm in need of advice when it comes to the implementation of the drivers. I recently added support for TechnoTrend CT2-4400 DVB-T2 tuner into the dvb-usb-cxusb module. Now I have gotten another TechnoTrend device CT2-4650 and it seems this is more or less the same device as CT2-4400 but with an added CI slot. The CI is realized using a CIMaX SP2HF chip. There seems to be support already for the said CIMaX chip, but only in combination with cx23885 (drivers/media/pci/cx23885/ cimax2.c). This cannot be reused directly in my case. When I look at the other dvb-usb devices that have CI slot the support for CI has been implemented directly in the code of the USB device (for example, pctv452e or az6027). Of course, an easy way to do it is to reuse a lot of code from the existing cimax2 and add it in the cxusb. However, I'm not sure if that's an ok approach. As I'm relatively new to linux kernel coding, I'd like to ask your recommendation for implementing the CI support here before the endeavour. Thanks! Cheers, -olli -- 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 0/9] rc: Add IR encode based wakeup filtering
Em Fri, 14 Mar 2014 23:04:10 + James Hogan ja...@albanarts.com escreveu: A recent discussion about proposed interfaces for setting up the hardware wakeup filter lead to the conclusion that it could help to have the generic capability to encode and modulate scancodes into raw IR events so that drivers for hardware with a low level wake filter (on the level of pulse/space durations) can still easily implement the higher level scancode interface that is proposed. I posted an RFC patchset showing how this could work, and Antti Seppälä posted additional patches to support rc5-sz and nuvoton-cir. This patchset improves the original RFC patches and combines updates Antti's patches. I'm happy these patches are a good start at tackling the problem, as long as Antti is happy with them and they work for him of course. Future work could include: - Encoders for more protocols. - Carrier signal events (no use unless a driver makes use of it). Patch 1 adds the new encode API. Patches 2-3 adds some modulation helpers. Patches 4-6 adds some raw encode implementations. Patch 7 adds some rc-core support for encode based wakeup filtering. Patch 8 adds debug loopback of encoded scancode when filter set. Patch 9 (untested) adds encode based wakeup filtering to nuvoton-cir. Changes in v2: Any news about this patch series? There are some comments about them, so I'll be tagging it as changes requested at patchwork, waiting for a v3 (or is it already there in the middle of the 49 patches from David?). Regards, 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: [PATCH 0/3] OMAP3 ISP resizer live zoom fixes
On Wednesday 23 July 2014 08:14:45 Raymond Jender wrote: Please remove me from this mail list! If you cannot, please forward to someone who can! This damn thing is so easy to join, but a bitch to un-subscribe, I did the email with the unsubscribe in the body a few days ago! Just send an e-mail in plain text format (no HTML) to majord...@vger.kernel.org. The e-mail body must contain unsubscribe linux-media and nothing else. You will receive a reply with instructions and a confirmation code. -- 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: [PATCH 1/8] get_dvb_firmware: Add firmware extractor for si2165
On Wed, 23 Jul 2014 21:03:14 +0200
Matthias Schwarzott z...@gentoo.org wrote:
[...]
The crc value:
It protects the content of the file until it is in the demod - so
calculating it on my own would only check if the data is correctly
transferred from the driver into the chip.
But for this I needed to know the algorithm and which data is
checksummed exactly.
Are the different algorithms for CRC values that give 16 bit of output?
You could try jacksum[1] and see if any algorithm it supports
gives you the expected result, there is a handful of 16 bits ones:
jacksum -a all -F #ALGONAME{i} = #CHECKSUM{i} payload.bin
Ciao,
Antonio
[1] http://www.jonelo.de/java/jacksum/
--
Antonio Ospite
http://ao2.it
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
--
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] imon: Fix internal key table for 15c2:0034
Hi Ulrich,
Em Sat, 15 Mar 2014 17:02:30 +0100
Ulrich Eckhardt uli-l...@uli-eckhardt.de escreveu:
The front panel of the Thermaltake DH102 is not working since the
internal key table does not contain the correct definitions. Some of the
key table entries required for this device are conflicting with existing
ones. So I had to extend the code to allow to define a key table for
each USB id.
Signed-off-by: Ulrich Eckhardt u...@uli-eckhardt.de
diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c
--- a/drivers/media/rc/imon.c
+++ b/drivers/media/rc/imon.c
@@ -47,7 +47,7 @@
#define MOD_AUTHOR Jarod Wilson ja...@wilsonet.com
#define MOD_DESC Driver for SoundGraph iMON MultiMedia IR/Display
#define MOD_NAME imon
First of all, your emailer mangled the patch. It added extra spaces,
converted tab into spaces, etc. The patch can't be applied like that.
-#define MOD_VERSION0.9.4
+#define MOD_VERSION0.9.5
#define DISPLAY_MINOR_BASE 144
#define DEVICE_NAMElcd%d
@@ -87,6 +87,18 @@ static ssize_t lcd_write(struct file *fi
/*** G L O B A L S ***/
+struct imon_panel_key_table {
+ u64 hw_code;
+ u32 keycode;
+};
+
+struct imon_usb_dev_descr {
+ __u16 flags;
+#define IMON_NO_FLAGS 0
+#define IMON_NEED_20MS_PKT_DELAY 1
+ struct imon_panel_key_table key_table[];
+};
+
It seems that you're merging two different issues at the same patch.
Please split it into one patch per logical change.
struct imon_context {
struct device *dev;
/* Newer devices have two interfaces */
@@ -150,6 +162,9 @@ struct imon_context {
struct timer_list ttimer; /* touch screen timer */
int touch_x;/* x coordinate on touchscreen */
int touch_y;/* y coordinate on touchscreen */
+
+ struct imon_usb_dev_descr *dev_descr; /* device description with key
+table for front panels */
};
#define TOUCH_TIMEOUT (HZ/30)
@@ -186,8 +201,122 @@ enum {
IMON_KEY_PANEL = 2,
};
-enum {
- IMON_NEED_20MS_PKT_DELAY = 1
+/*
+ * Key tables for imon receiver front panel/knob.
+ */
+
+static const struct imon_usb_dev_descr imon_default_table = {
+ .flags = IMON_NO_FLAGS,
+ .key_table = {
+ { 0x0f00ffeell, KEY_MEDIA }, /* Go */
+ { 0x1200ffeell, KEY_UP },
+ { 0x1300ffeell, KEY_DOWN },
+ { 0x1400ffeell, KEY_LEFT },
+ { 0x1500ffeell, KEY_RIGHT },
+ { 0x1600ffeell, KEY_ENTER },
+ { 0x1700ffeell, KEY_ESC },
+ { 0x1f00ffeell, KEY_AUDIO },
+ { 0x2000ffeell, KEY_VIDEO },
+ { 0x2100ffeell, KEY_CAMERA },
+ { 0x2700ffeell, KEY_DVD },
+ { 0x2300ffeell, KEY_TV },
+ { 0x2b00ffeell, KEY_EXIT },
+ { 0x2c00ffeell, KEY_SELECT },
+ { 0x2d00ffeell, KEY_MENU },
+ { 0x0500ffeell, KEY_PREVIOUS },
+ { 0x0700ffeell, KEY_REWIND },
+ { 0x0400ffeell, KEY_STOP },
+ { 0x3c00ffeell, KEY_PLAYPAUSE },
+ { 0x0800ffeell, KEY_FASTFORWARD },
+ { 0x0600ffeell, KEY_NEXT },
+ { 0x0001ffeell, KEY_RIGHT },
+ { 0x0100ffeell, KEY_LEFT },
+ { 0x3d00ffeell, KEY_SELECT },
+ { 0x0001ffeell, KEY_VOLUMEUP },
+ { 0x0100ffeell, KEY_VOLUMEDOWN },
+ { 0x0100ffeell, KEY_MUTE },
+ /* 0xffdc iMON MCE VFD */
+ { 0x0001ffeell, KEY_VOLUMEUP },
+ { 0x0100ffeell, KEY_VOLUMEDOWN },
+ { 0x0001ffeell, KEY_MUTE },
+ { 0x000fffeell, KEY_MEDIA },
+ { 0x0012ffeell, KEY_UP },
+ { 0x0013ffeell, KEY_DOWN },
+ { 0x0014ffeell, KEY_LEFT },
+ { 0x0015ffeell, KEY_RIGHT },
+ { 0x0016ffeell, KEY_ENTER },
+ { 0x0017ffeell, KEY_ESC },
+ /* iMON Knob values */
+ { 0x000100eell, KEY_VOLUMEUP },
+ { 0x01eell, KEY_VOLUMEDOWN },
+ { 0x08eell, KEY_MUTE },
+ { 0, KEY_RESERVED }
+ }
+};
+
+static const struct imon_usb_dev_descr imon_OEM_VFD = {
+ .flags = IMON_NEED_20MS_PKT_DELAY,
+ .key_table = {
+ { 0x0f00ffeell, KEY_MEDIA }, /* Go */
+ { 0x1200ffeell, KEY_UP },
+ {
Re: Lirc codec and starting space event
Em Tue, 1 Apr 2014 10:04:16 +1000 Austin Lund austin.l...@gmail.com escreveu: Hi, I've been having a problem with a GPIO ir device in an i.mx6 arm system that I have (cubox-i). It seems to all work ok, except the output on /dev/lirc0 is not quite what lircd seems to expect. Lircd wants a long space before the starting pulse before processing any output. However, no long space is sent when I check the output (doing mode2 and a plain hexdump /dev/lirc0). This causes problems in detecting button presses on remotes. Sometimes it works if you press the buttons quick enough, but after waiting a while it doesn't work. I have been looking at the code for a while now, and it seems that it has something to do with the lirc codec ignoring reset events (just returns 0). I've made up this patch, but I'm travelling at the moment and haven't had a chance to actually test it. What I'm wondering is if this issue is known, and if my approach is going down the right path. The only alternative I could see is to change the way the gpio ir driver handles events. It seems to just call ir_raw_event_store_edge which put a zeroed reset event into the queue. I'm assuming there are other users of these functions and that it's probably best not to fiddle with that if possible. Thanks. PS Please CC me as I'm not subscribed. You forgot to add a: Signed-off-by: your name your@email on your patch. Please add it and resend. 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: [PATCH 0/3] OMAP3 ISP resizer live zoom fixes
On Wed, Jul 23, 2014 at 04:57:08PM +0200, Laurent Pinchart wrote: Hello, This patch set fixes two issues occuring when performing live zoom with the OMAP3 ISP resizer. The first issue has been observed when using the digital zoom of the live application (http://git.ideasonboard.org/omap3-isp-live.git) on a beagleboard. It leads to image corruption due to interrupt handling latency. Patch 2/3 fixes it. The second issue is a race condition that I haven't observed in practice. It's fixed by patch 3/3. As usual with race conditions and locking, careful review will be appreciated. Laurent Pinchart (3): omap3isp: resizer: Remove needless variable initializations omap3isp: resizer: Remove slow debugging message from interrupt handler omap3isp: resizer: Protect against races when updating crop For the set: Acked-by: Sakari Ailus sakari.ai...@linux.intel.com -- 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
[linuxtv-media:master 497/499] drivers/hid/hid-picolcd_cir.c:117:6: error: 'struct rc_dev' has no member named 'allowed_protos'
tree: git://linuxtv.org/media_tree.git master head: 1ee70cd7f5da2278445baf1634f7d30d514380f1 commit: 0dd0e92836cc6469e62600f981c289752ac42ac9 [497/499] [media] rc-core: remove protocol arrays config: make ARCH=microblaze allyesconfig All error/warnings: drivers/hid/hid-picolcd_cir.c: In function 'picolcd_init_cir': drivers/hid/hid-picolcd_cir.c:117:6: error: 'struct rc_dev' has no member named 'allowed_protos' rdev-allowed_protos = RC_BIT_ALL; ^ vim +117 drivers/hid/hid-picolcd_cir.c 111 rdev = rc_allocate_device(); 112 if (!rdev) 113 return -ENOMEM; 114 115 rdev-priv = data; 116 rdev-driver_type = RC_DRIVER_IR_RAW; 117 rdev-allowed_protos = RC_BIT_ALL; 118 rdev-open = picolcd_cir_open; 119 rdev-close= picolcd_cir_close; 120 rdev-input_name = data-hdev-name; --- 0-DAY kernel build testing backend Open Source Technology Center http://lists.01.org/mailman/listinfo/kbuild Intel Corporation -- 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 30/49] rc-core: leave the internals of rc_dev alone
Em Fri, 04 Apr 2014 01:33:47 +0200
David Härdeman da...@hardeman.nu escreveu:
Several drivers poke around in the internals of rc_dev, try to
fix them up in preparation for the next round of patches.
You're not fixing them. You're just removing code that are there
to fix some things. Before removing those, we need to test each
one of the affected drivers, to see if they won't be introducing
any regressions. Also, we should break it into one change per patch,
to make easier to revert if someone later complains.
Regards,
Mauro
drivers/media/rc/ati_remote.c:
Removing the REP_DELAY setting on the input device should not
change how to driver works (as it does a keydown/keyup and has
no real repeat handling).
drivers/media/rc/img-ir/img-ir-hw.c
Changing the protocol does not imply that the keymap changes.
drivers/media/rc/ir-nec-decoder.c
Obvious fix, leave repeat handling to rc-core
drivers/media/rc/ir-raw.c
Replaced the REP_DELAY value with a static value, which makes more
sense anyway. Why should the time before automatic repeat handling
kicks in define the drivers idea of a long time?
drivers/media/rc/ir-sanyo-decoder.c
Obvious fix, leave repeat handling to rc-core
drivers/media/video/cx231xx/cx231xx-input.c
Just some debug statements to change
drivers/media/video/tm6000/tm6000-input.c
Not sure what the driver is trying to do, however, IR
handling seems incomplete ATM so deleting the offending
parts shouldn't affect functionality
Signed-off-by: David Härdeman da...@hardeman.nu
---
drivers/media/rc/ati_remote.c |3 ---
drivers/media/rc/img-ir/img-ir-hw.c |4
drivers/media/rc/ir-nec-decoder.c | 10 +++---
drivers/media/rc/ir-raw.c |4 +---
drivers/media/rc/ir-sanyo-decoder.c | 10 +++---
drivers/media/usb/cx231xx/cx231xx-input.c |5 ++---
drivers/media/usb/tm6000/tm6000-input.c |4
7 files changed, 9 insertions(+), 31 deletions(-)
diff --git a/drivers/media/rc/ati_remote.c b/drivers/media/rc/ati_remote.c
index 3ada4dc..6ef5716 100644
--- a/drivers/media/rc/ati_remote.c
+++ b/drivers/media/rc/ati_remote.c
@@ -932,9 +932,6 @@ static int ati_remote_probe(struct usb_interface
*interface,
if (err)
goto exit_kill_urbs;
- /* use our delay for rc_dev */
- ati_remote-rdev-input_dev-rep[REP_DELAY] = repeat_delay;
-
/* Set up and register mouse input device */
if (mouse) {
input_dev = input_allocate_device();
diff --git a/drivers/media/rc/img-ir/img-ir-hw.c
b/drivers/media/rc/img-ir/img-ir-hw.c
index 9fc41780..3bb6a32 100644
--- a/drivers/media/rc/img-ir/img-ir-hw.c
+++ b/drivers/media/rc/img-ir/img-ir-hw.c
@@ -666,10 +666,6 @@ static void img_ir_set_protocol(struct img_ir_priv
*priv, u64 proto)
{
struct rc_dev *rdev = priv-hw.rdev;
- spin_lock_irq(rdev-rc_map.lock);
- rdev-rc_map.rc_type = __ffs64(proto);
- spin_unlock_irq(rdev-rc_map.lock);
-
mutex_lock(rdev-lock);
rdev-enabled_protocols = proto;
rdev-allowed_wakeup_protocols = proto;
diff --git a/drivers/media/rc/ir-nec-decoder.c
b/drivers/media/rc/ir-nec-decoder.c
index 1683aaa..861fd86 100644
--- a/drivers/media/rc/ir-nec-decoder.c
+++ b/drivers/media/rc/ir-nec-decoder.c
@@ -89,13 +89,9 @@ static int ir_nec_decode(struct rc_dev *dev, struct
ir_raw_event ev)
data-state = STATE_BIT_PULSE;
return 0;
} else if (eq_margin(ev.duration, NEC_REPEAT_SPACE, NEC_UNIT /
2)) {
- if (!dev-keypressed) {
- IR_dprintk(1, Discarding last key repeat:
event after key up\n);
- } else {
- rc_repeat(dev);
- IR_dprintk(1, Repeat last key\n);
- data-state = STATE_TRAILER_PULSE;
- }
+ rc_repeat(dev);
+ IR_dprintk(1, Repeat last key\n);
+ data-state = STATE_TRAILER_PULSE;
return 0;
}
diff --git a/drivers/media/rc/ir-raw.c b/drivers/media/rc/ir-raw.c
index af23f4d..aa2503d 100644
--- a/drivers/media/rc/ir-raw.c
+++ b/drivers/media/rc/ir-raw.c
@@ -109,20 +109,18 @@ int ir_raw_event_store_edge(struct rc_dev *dev, enum
raw_event_type type)
s64 delta; /* ns */
DEFINE_IR_RAW_EVENT(ev);
int rc = 0;
- int delay;
if (!dev-raw)
return -EINVAL;
now = ktime_get();
delta = ktime_to_ns(ktime_sub(now, dev-raw-last_event));
- delay = MS_TO_NS(dev-input_dev-rep[REP_DELAY]);
/* Check for a long duration since last event or if we're
* being called for the
cron job: media_tree daily build: ERRORS
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 Jul 24 04:00:23 CEST 2014 git branch: test git hash: 1ee70cd7f5da2278445baf1634f7d30d514380f1 gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-16-g1db35d0 host hardware: x86_64 host os:3.15-5.slh.2-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: ERRORS linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16-rc1-i686: OK linux-2.6.32.27-x86_64: ERRORS linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16-rc1-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.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
[linuxtv-media:master 496/499] drivers/media/rc/st_rc.c:290:6: error: 'struct rc_dev' has no member named 'allowed_protos'
tree: git://linuxtv.org/media_tree.git master head: 488046c237f3b78f91046d45662b318cd2415f64 commit: 0dd0e92836cc6469e62600f981c289752ac42ac9 [496/499] [media] rc-core: remove protocol arrays config: make ARCH=arm allmodconfig Note: the linuxtv-media/master HEAD 488046c237f3b78f91046d45662b318cd2415f64 builds fine. It only hurts bisectibility. All error/warnings: drivers/media/rc/st_rc.c: In function 'st_rc_probe': drivers/media/rc/st_rc.c:290:6: error: 'struct rc_dev' has no member named 'allowed_protos' rdev-allowed_protos = RC_BIT_ALL; ^ -- drivers/media/rc/sunxi-cir.c: In function 'sunxi_ir_probe': drivers/media/rc/sunxi-cir.c:213:2: error: called object is not a function or function pointer ir-rc-allowed_protocols(ir-rc, RC_BIT_ALL); ^ vim +290 drivers/media/rc/st_rc.c 284 285 rc_dev-dev = dev; 286 platform_set_drvdata(pdev, rc_dev); 287 st_rc_hardware_init(rc_dev); 288 289 rdev-driver_type = RC_DRIVER_IR_RAW; 290 rdev-allowed_protos = RC_BIT_ALL; 291 /* rx sampling rate is 10Mhz */ 292 rdev-rx_resolution = 100; 293 rdev-timeout = US_TO_NS(MAX_SYMB_TIME); --- 0-DAY kernel build testing backend Open Source Technology Center http://lists.01.org/mailman/listinfo/kbuild Intel Corporation -- 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
[linuxtv-media:master 248/499] mt9v022.c:undefined reference to `__divdi3'
tree: git://linuxtv.org/media_tree.git master head: 488046c237f3b78f91046d45662b318cd2415f64 commit: 0ba2aeb6dab80920edd9cf5b93b1ea4d6913b8f3 [248/499] [media] v4l2-ctrls: increase internal min/max/step/def to 64 bit config: i386-randconfig-ha3-0724 (attached as .config) Note: the linuxtv-media/master HEAD 488046c237f3b78f91046d45662b318cd2415f64 builds fine. It only hurts bisectibility. All error/warnings: drivers/built-in.o: In function `mt9m001_s_ctrl': mt9m001.c:(.text+0x19a2a8): undefined reference to `__divdi3' mt9m001.c:(.text+0x19a37a): undefined reference to `__divdi3' mt9m001.c:(.text+0x19a4ca): undefined reference to `__divdi3' drivers/built-in.o: In function `mt9v022_s_ctrl': mt9v022.c:(.text+0x19b28e): undefined reference to `__divdi3' mt9v022.c:(.text+0x19b3e3): undefined reference to `__divdi3' drivers/built-in.o: In function `validate_new': v4l2-ctrls.c:(.text+0x1d030e): undefined reference to `__udivdi3' v4l2-ctrls.c:(.text+0x1d039a): undefined reference to `__udivdi3' v4l2-ctrls.c:(.text+0x1d04e9): undefined reference to `__umoddi3' --- 0-DAY kernel build testing backend Open Source Technology Center http://lists.01.org/mailman/listinfo/kbuild Intel Corporation # # Automatically generated file; DO NOT EDIT. # Linux/i386 3.16.0-rc1 Kernel Configuration # # CONFIG_64BIT is not set CONFIG_X86_32=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT=elf32-i386 CONFIG_ARCH_DEFCONFIG=arch/x86/configs/i386_defconfig CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y CONFIG_ARCH_WANT_GENERAL_HUGETLB=y # CONFIG_ZONE_DMA32 is not set # CONFIG_AUDIT_ARCH is not set CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_X86_32_LAZY_GS=y CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-ecx -fcall-saved-edx CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE= # CONFIG_COMPILE_TEST is not set CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME=(none) CONFIG_SWAP=y # CONFIG_SYSVIPC is not set CONFIG_POSIX_MQUEUE=y CONFIG_POSIX_MQUEUE_SYSCTL=y CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_FHANDLE=y # CONFIG_USELIB is not set CONFIG_AUDIT=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_WATCH=y CONFIG_AUDIT_TREE=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_IRQ_DOMAIN=y # CONFIG_IRQ_DOMAIN_DEBUG is not set CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_KTIME_SCALAR=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_HZ_PERIODIC=y # CONFIG_NO_HZ_IDLE is not set # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_IRQ_TIME_ACCOUNTING is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # # RCU Subsystem # CONFIG_TINY_RCU=y # CONFIG_PREEMPT_RCU is not set # CONFIG_RCU_STALL_COMMON is not set # CONFIG_TREE_RCU_TRACE is not set CONFIG_IKCONFIG=y # CONFIG_IKCONFIG_PROC is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE=y CONFIG_CGROUPS=y CONFIG_CGROUP_DEBUG=y CONFIG_CGROUP_FREEZER=y CONFIG_CGROUP_DEVICE=y # CONFIG_CPUSETS is not set # CONFIG_CGROUP_CPUACCT is not set # CONFIG_RESOURCE_COUNTERS is not set # CONFIG_CGROUP_PERF is not set CONFIG_CGROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y CONFIG_CFS_BANDWIDTH=y # CONFIG_RT_GROUP_SCHED is not set CONFIG_BLK_CGROUP=y # CONFIG_DEBUG_BLK_CGROUP is not set # CONFIG_CHECKPOINT_RESTORE is not set CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set CONFIG_IPC_NS=y CONFIG_USER_NS=y # CONFIG_PID_NS is not set CONFIG_NET_NS=y CONFIG_SCHED_AUTOGROUP=y # CONFIG_SYSFS_DEPRECATED is not set
