Re: MAINTAINERS/s5p: Kamil Debski no longer with Samsung?
Hi, On Sunday, August 02, 2015 01:40:40 PM Joe Perches wrote: On Sun, 2015-08-02 at 20:31 +, Mail Delivery System wrote: k.deb...@samsung.com: host mailin.samsung.com[203.254.224.12] said: 550 5.1.1 Recipient address rejected: User unknown (in reply to RCPT TO command) His email address bounces. Should MAINTAINERS be updated? Please wait with these changes, the situation should be clarified soon (I've added Kamil to Cc). Best regards, -- Bartlomiej Zolnierkiewicz Samsung RD Institute Poland Samsung Electronics --- MAINTAINERS | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 826affa..b5197c7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1442,7 +1442,6 @@ F:arch/arm/mach-s5pv210/ ARM/SAMSUNG S5P SERIES 2D GRAPHICS ACCELERATION (G2D) SUPPORT M: Kyungmin Park kyungmin.p...@samsung.com -M: Kamil Debski k.deb...@samsung.com L: linux-arm-ker...@lists.infradead.org L: linux-media@vger.kernel.org S: Maintained @@ -1450,7 +1449,6 @@ F:drivers/media/platform/s5p-g2d/ ARM/SAMSUNG S5P SERIES Multi Format Codec (MFC) SUPPORT M: Kyungmin Park kyungmin.p...@samsung.com -M: Kamil Debski k.deb...@samsung.com M: Jeongtae Park jtp.p...@samsung.com L: linux-arm-ker...@lists.infradead.org L: linux-media@vger.kernel.org @@ -8248,9 +8246,8 @@ S:Maintained F: drivers/media/usb/pwc/* PWM FAN DRIVER -M: Kamil Debski k.deb...@samsung.com L: lm-sens...@lm-sensors.org -S: Supported +S: Orphan F: Documentation/devicetree/bindings/hwmon/pwm-fan.txt F: Documentation/hwmon/pwm-fan F: drivers/hwmon/pwm-fan.c @@ -8906,9 +8903,8 @@ T: https://github.com/lmajewski/linux-samsung-thermal.git F: drivers/thermal/samsung/ SAMSUNG USB2 PHY DRIVER -M: Kamil Debski k.deb...@samsung.com L: linux-ker...@vger.kernel.org -S: Supported +S: Orphan F: Documentation/devicetree/bindings/phy/samsung-phy.txt F: Documentation/phy/samsung-usb2.txt F: drivers/phy/phy-exynos4210-usb2.c -- 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] coda: drop zero payload bitstream buffers
Am Montag, den 03.08.2015, 13:57 +0200 schrieb Zahari Doychev: The buffers with zero payload are now dumped in coda_fill_bitstream and not passed to coda_bitstream_queue. This avoids unnecessary fifo addition and buffer sequence counter increment. Signed-off-by: Zahari Doychev zahari.doyc...@linux.com Yes, that looks better. Acked-by: Philipp Zabel p.za...@pengutronix.de thanks Philipp -- 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 3/3] [media] videobuf2: add trace events
On Tue, 28 Jul 2015 09:53:20 +0200 Philipp Zabel p.za...@pengutronix.de wrote: I tried this yesterday and failed to figure out a satisfactory way to do it since the vb2 trace point macros reuse the v4l2 enum definitions and __print_symbolic/flags macros. The alternative would be to just export the vb2 trace points from videodev. Or do what some other drivers do, which is to make a separate file to hold the creation of the tracepoints, and have it included in whatever needs it. Export them if there's more than one module. drivers/media/v4l2-core/v4l2-trace.c: #define CREATE_TRACE_POINTS #include v4l2-trace.h See fs/xfs/xfs_trace.c as an example. -- Steve -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2] lib: scatterlist: add sg splitting function
On Sat, 1 Aug 2015 15:17:13 +0200 Robert Jarzmik robert.jarz...@free.fr wrote: Sometimes a scatter-gather has to be split into several chunks, or sub scatter lists. This happens for example if a scatter list will be handled by multiple DMA channels, each one filling a part of it. A concrete example comes with the media V4L2 API, where the scatter list is allocated from userspace to hold an image, regardless of the knowledge of how many DMAs will fill it : - in a simple RGB565 case, one DMA will pump data from the camera ISP to memory - in the trickier YUV422 case, 3 DMAs will pump data from the camera ISP pipes, one for pipe Y, one for pipe U and one for pipe V For these cases, it is necessary to split the original scatter list into multiple scatter lists, which is the purpose of this patch. ... include/linux/scatterlist.h | 5 ++ lib/scatterlist.c | 189 2 files changed, 194 insertions(+) It's quite a bit of code for a fairly specialised thing. How ugly would it be to put this in a new .c file and have subsystems select it in Kconfig? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: OK
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Tue Aug 4 04:00:17 CEST 2015 git branch: test git hash: 4dc102b2f53d63207fa12a6ad49c7b6448bc3301 gcc version:i686-linux-gcc (GCC) 5.1.0 sparse version: v0.5.0-51-ga53cea2 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:4.0.0-3.slh.1-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-bf561: 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: OK 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.7-i686: OK linux-3.17.8-i686: OK linux-3.18.7-i686: OK linux-3.19-i686: OK linux-4.0-i686: OK linux-4.1.1-i686: OK linux-4.2-rc1-i686: OK linux-2.6.32.27-x86_64: OK 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.7-x86_64: OK linux-3.17.8-x86_64: OK linux-3.18.7-x86_64: OK linux-3.19-x86_64: OK linux-4.0-x86_64: OK linux-4.1.1-x86_64: OK linux-4.2-rc1-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] staging:media:lirc Remove the extra braces in if statement of lirc_imon
Normally, I wait overnight between writing a patch and sending it. There is no rush and the delay helps me to be more careful. The subject is still not perfect. Do: git log --oneline drivers/staging/media/lirc/lirc_imon.c On Mon, Aug 03, 2015 at 02:56:31AM -0500, Pradheep Shrinivasan wrote: From: pradheep pradheep...@gmail.com This is still wrong. regards, dan carpenter -- 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] vivid: support cvt, gtf timings for video out
The generation of cvt, gtf timings is already supported by v4l2-ctl.
This patch adds support for setting cvt,gtf timings for video out.
While enabling cvt,gtf in vivid capture, the vivid video out was
missed out. Adding it now.
Cc: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Prashant Laddha prlad...@cisco.com
---
drivers/media/platform/vivid/vivid-vid-out.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/vivid/vivid-vid-out.c
b/drivers/media/platform/vivid/vivid-vid-out.c
index 0862c1f..c404e27 100644
--- a/drivers/media/platform/vivid/vivid-vid-out.c
+++ b/drivers/media/platform/vivid/vivid-vid-out.c
@@ -1124,15 +1124,26 @@ int vivid_vid_out_s_std(struct file *file, void *priv,
v4l2_std_id id)
return 0;
}
+static bool valid_cvt_gtf_timings(struct v4l2_dv_timings *timings)
+{
+ struct v4l2_bt_timings *bt = timings-bt;
+
+ if ((bt-standards (V4L2_DV_BT_STD_CVT | V4L2_DV_BT_STD_GTF))
+ v4l2_valid_dv_timings(timings, vivid_dv_timings_cap, NULL, NULL))
+ return true;
+
+ return false;
+}
+
int vivid_vid_out_s_dv_timings(struct file *file, void *_fh,
struct v4l2_dv_timings *timings)
{
struct vivid_dev *dev = video_drvdata(file);
-
if (!vivid_is_hdmi_out(dev))
return -ENODATA;
if (!v4l2_find_dv_timings_cap(timings, vivid_dv_timings_cap,
- 0, NULL, NULL))
+ 0, NULL, NULL)
+ !valid_cvt_gtf_timings(timings))
return -EINVAL;
if (v4l2_match_dv_timings(timings, dev-dv_timings_out, 0))
return 0;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] staging:media:lirc Remove the extra braces in if statement of lirc_imon
From: pradheep pradheep...@gmail.com
This patche removes the extra braces found in
drivers/staging/media/lirc/lirc_imon.c to fix the warning thrown by
checkpatch.pl
Signed-off-by: Pradheep Shrinivasan pradheep...@gmail.com
---
drivers/staging/media/lirc/lirc_imon.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/media/lirc/lirc_imon.c
b/drivers/staging/media/lirc/lirc_imon.c
index 62ec9f7..05d47dc 100644
--- a/drivers/staging/media/lirc/lirc_imon.c
+++ b/drivers/staging/media/lirc/lirc_imon.c
@@ -785,13 +785,13 @@ static int imon_probe(struct usb_interface *interface,
}
driver = kzalloc(sizeof(struct lirc_driver), GFP_KERNEL);
- if (!driver) {
+ if (!driver)
goto free_context;
- }
+
rbuf = kmalloc(sizeof(struct lirc_buffer), GFP_KERNEL);
- if (!rbuf) {
+ if (!rbuf)
goto free_driver;
- }
+
if (lirc_buffer_init(rbuf, BUF_CHUNK_SIZE, BUF_SIZE)) {
dev_err(dev, %s: lirc_buffer_init failed\n, __func__);
goto free_rbuf;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] staging:media:lirc This fix changes the spaces to tab in lirc_sasem.c
This fix changes the space in the code to tab to fix the ERROR ERROR: code indent should use tabs where possible Signed-off-by: Pradheep Shrinivasan pradheep...@gmail.com --- drivers/staging/media/lirc/lirc_sasem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/media/lirc/lirc_sasem.c b/drivers/staging/media/lirc/lirc_sasem.c index 8ebee96..c14ca7e 100644 --- a/drivers/staging/media/lirc/lirc_sasem.c +++ b/drivers/staging/media/lirc/lirc_sasem.c @@ -185,7 +185,7 @@ static void deregister_from_lirc(struct sasem_context *context) __func__, retval); else dev_info(context-dev-dev, -Deregistered Sasem driver (minor:%d)\n, minor); +Deregistered Sasem driver (minor:%d)\n, minor); } -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] [media] coda: fix sequence counter increment
On Tue, Jul 28, 2015 at 12:25:31PM +0200, Philipp Zabel wrote: Am Dienstag, den 28.07.2015, 10:54 +0200 schrieb Hans Verkuil: On 07/08/2015 05:49 PM, Philipp Zabel wrote: Hi Zahari, Am Mittwoch, den 08.07.2015, 15:37 +0200 schrieb Zahari Doychev: The coda context queue sequence counter is incremented only if the vb2 source buffer payload is non zero. This makes possible to signal EOS otherwise the condition in coda_buf_is_end_of_stream is never met or more precisely buf-v4l2_buf.sequence == (ctx-qsequence - 1) never happens. Signed-off-by: Zahari Doychev zahari.doyc...@linux.com I think we should instead avoid calling coda_bitstream_queue with zero payload buffers altogether and dump them in coda_fill_bitstream already. Philipp, is this still outstanding or did you fix this already according to the suggestion you made above? Just wondering whether to set this bug report to 'Rejected' or 'Changes Requested'. Changes requested. Ok, I will send a corected version of the patch. regards Zahari Is this something I should do myself for coda patches in the future? regards Philipp -- 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: [lm-sensors] MAINTAINERS/s5p: Kamil Debski no longer with Samsung?
On Mon, 2015-08-03 at 19:06 +0200, Jean Delvare wrote: Hi Bartlomiej, Le Monday 03 August 2015 à 17:33 +0200, Bartlomiej Zolnierkiewicz a écrit : Hi, On Sunday, August 02, 2015 01:40:40 PM Joe Perches wrote: On Sun, 2015-08-02 at 20:31 +, Mail Delivery System wrote: k.deb...@samsung.com: host mailin.samsung.com[203.254.224.12] said: 550 5.1.1 Recipient address rejected: User unknown (in reply to RCPT TO command) His email address bounces. Should MAINTAINERS be updated? Please wait with these changes, the situation should be clarified soon (I've added Kamil to Cc). Already clarified behind the scenes ;-) The patch should be discarded. It wasn't a patch, it was a question with a list of sections that might be modified, and it wasn't signed. -- 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: [lm-sensors] MAINTAINERS/s5p: Kamil Debski no longer with Samsung?
Hi Bartlomiej, Le Monday 03 August 2015 à 17:33 +0200, Bartlomiej Zolnierkiewicz a écrit : Hi, On Sunday, August 02, 2015 01:40:40 PM Joe Perches wrote: On Sun, 2015-08-02 at 20:31 +, Mail Delivery System wrote: k.deb...@samsung.com: host mailin.samsung.com[203.254.224.12] said: 550 5.1.1 Recipient address rejected: User unknown (in reply to RCPT TO command) His email address bounces. Should MAINTAINERS be updated? Please wait with these changes, the situation should be clarified soon (I've added Kamil to Cc). Already clarified behind the scenes ;-) The patch should be discarded. Thanks, -- Jean Delvare SUSE L3 Support -- 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] coda: drop zero payload bitstream buffers
The buffers with zero payload are now dumped in coda_fill_bitstream and not
passed to coda_bitstream_queue. This avoids unnecessary fifo addition and
buffer sequence counter increment.
Signed-off-by: Zahari Doychev zahari.doyc...@linux.com
---
drivers/media/platform/coda/coda-bit.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/media/platform/coda/coda-bit.c
b/drivers/media/platform/coda/coda-bit.c
index 3d434a4..fd7819d 100644
--- a/drivers/media/platform/coda/coda-bit.c
+++ b/drivers/media/platform/coda/coda-bit.c
@@ -256,6 +256,13 @@ void coda_fill_bitstream(struct coda_ctx *ctx, bool
streaming)
continue;
}
+ /* Dump empty buffers */
+ if (!vb2_get_plane_payload(src_buf, 0)) {
+ src_buf = v4l2_m2m_src_buf_remove(ctx-fh.m2m_ctx);
+ v4l2_m2m_buf_done(src_buf, VB2_BUF_STATE_DONE);
+ continue;
+ }
+
/* Buffer start position */
start = ctx-bitstream_fifo.kfifo.in
ctx-bitstream_fifo.kfifo.mask;
--
2.4.6
--
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] uvcvideo: Disable hardware timestamps by default
On 07/27/2015 04:18 PM, Laurent Pinchart wrote: The hardware timestamping implementation has been reported as not working correctly on at least the Logitech C920. Until this can be fixed, disable it by default. As stated earlier on freenode#v4l - this patch seems to do the job for me as well. Thanks a lot! Are there extra steps necessary to get this merged into media_tree.git ? Cheers -- 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
drivers/media/platform/am437x/am437x-vpfe.c:1698: bad test ?
Hello there,
drivers/media/platform/am437x/am437x-vpfe.c:1698:27: warning: self-comparison
always evaluates to true [-Wtautological-compare]
if (client-addr == curr_client-addr
client-adapter-nr == client-adapter-nr) {
maybe
if (client-addr == curr_client-addr
client-adapter-nr == curr_client-adapter-nr) {
Regards
David Binderman
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] Media Controller, the next generation
Hi all,
During last week's brainstorm meeting in Espoo, Finland, we discussed
how to proceed with the MC API. Trying to apply the existing API to DVB
devices caused a lot of controversy and this meeting was an attempt to
resolve these issues.
This RFC is the proposal for the public API (NOT the internal API!) we
came up with.
The main change is that interfaces (such as devices in /dev) get their own
object: struct media_interface. The struct media_entity as is used today
will not refer to interfaces anymore.
Since interfaces control entities we also want to tell userspace which
entities are controlled by which interfaces. We want to keep things simple
and avoid having to create a new link structure just for this, so instead
a struct media_link just provides two object IDs and a flags field. The
object IDs refer to pads (for data links) or entity/interface IDs (for
associating interfaces with entities).
To make this work we need unique pad IDs.
We will need to represent connectors as well. The media_entity struct is
used for that, but it will be marked as a connector since connectors work
slightly different from an entity: if an entity has both input and output
pads, then that means that the entity processes the input data in some way
before passing it on to the output pads. But for a connector the input and
output pads are just hooked up to input and output pins or buses and not
to one another.
Finally we would like to get all this information atomically in userspace.
Atomicity is desired since some of this information well be dynamic. Currently
the only dynamic thing is enabling/disabling links, but that is too limiting
for devices like FPGAs where the entities can change on the fly as well.
Being able to get all the information with a single ioctl will simplify
implementing this atomic behavior, and it is also more efficient than calling
lots of ENUM ioctls.
We decided to keep the existing structs and ioctls and introduce new versions
of these structs redesigned to cope with the new insights. The sizes of the
reserved fields are suggestions only.
We had a discussion about the object IDs. Currently we have only entity IDs, but
in the redesign we'll have interface, connector and pad IDs as well.
The idea from the meeting was to use the least significant X bits of the ID to
tell the difference of entity, interface and pad types and to use a flag for
marking connector entities. After thinking some more I would suggest this scheme
instead:
#define MEDIA_ID_T_ENTITY 0
#define MEDIA_ID_T_CONNECTOR1
#define MEDIA_ID_T_INTERFACE2
#define MEDIA_ID_T_PAD 3
#define MEDIA_ID_TYPE(id) ((id) 24)
#define MEDIA_ID_VAL(id)((id) 0xff)
#define MEDIA_ID_CREATE(type, id) (((type) 24) | id)
One objection was that the IDs would be unwieldy for users when using e.g.
media-ctl since you'll get IDs = 0x100. However, I think that media-ctl
can easily either deduce the type (i.e. setting up the data path would always
assume type 'pad' or require that the user specifies the type and ID value
(i.e. only the lowest 24 bits).
Since MEDIA_ID_T_ENTITY == 0 this will be backwards compatible with the existing
entity IDs. Note that currently there are no unique pad IDs: adding this
requires
a single change to struct media_pad_desc where one of the reserved fields is
used
to export the unique pad ID. Existing apps can ignore this.
The new media_entity_desc struct looks like this:
struct mc_entity {
__u32 id;
__u16 num_pads;
__u16 reserved[13];
};
I'm going with mc_entity for now. An alternative name might be: mediav2_entity
or
media_entity_v2 (I never liked the _desc suffix and media_entity can't be used
due
to clashed with the internal media_entity struct).
A third alternative might be to use mc_entity for the internal data structs and
media_entity for the external. As you can see, we didn't have time to discuss
the
naming for these new structs. But for the purposes of this RFC I'm going with
mc_
for now.
This struct is much smaller than the original: both name and type will be stored
as properties of the entity (properties will be the topic of a separate
upcoming RFC).
Pretty much everything else has been removed except for num_pads: while even
this
is not strictly necessary, it was considered to be useful to know for
applications that
use this API.
The new mc_interface struct is defined as follows:
#define MEDIA_INTF_T_DVB_FE (MEDIA_ENT_T_DEVNODE + 4)
#define MEDIA_INTF_T_DVB_DEMUX (MEDIA_ENT_T_DEVNODE + 5)
#define MEDIA_INTF_T_DVB_DVR(MEDIA_ENT_T_DEVNODE + 6)
#define MEDIA_INTF_T_DVB_CA (MEDIA_ENT_T_DEVNODE + 7)
#define MEDIA_INTF_T_DVB_NET(MEDIA_ENT_T_DEVNODE + 8)
// TBC: #define MEDIA_INTF_T_NETIF_DVB(MEDIA_ENT_T_DEVNODE + 9)
#define MEDIA_INTF_T_V4L_VIDEO (MEDIA_ENT_T_DEVNODE + 10)
#define MEDIA_INTF_T_V4L_VBI(MEDIA_ENT_T_DEVNODE + 11)
#define
Re: [PATCH 2/2] media: atmel-isi: move configure_geometry() to start_streaming()
Hi Josh,
On Monday 03 August 2015 11:56:01 Josh Wu wrote:
On 7/31/2015 10:37 PM, Laurent Pinchart wrote:
On Wednesday 17 June 2015 18:39:39 Josh Wu wrote:
As in set_fmt() function we only need to know which format is been set,
we don't need to access the ISI hardware in this moment.
So move the configure_geometry(), which access the ISI hardware, to
start_streaming() will make code more consistent and simpler.
Signed-off-by: Josh Wu josh...@atmel.com
---
drivers/media/platform/soc_camera/atmel-isi.c | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
b/drivers/media/platform/soc_camera/atmel-isi.c index 8bc40ca..b01086d
100644
--- a/drivers/media/platform/soc_camera/atmel-isi.c
+++ b/drivers/media/platform/soc_camera/atmel-isi.c
@@ -390,6 +390,11 @@ static int start_streaming(struct vb2_queue *vq,
unsigned int count) /* Disable all interrupts */
isi_writel(isi, ISI_INTDIS, (u32)~0UL);
+ ret = configure_geometry(isi, icd-user_width, icd-user_height,
+ icd-current_fmt-code);
I would also make configure_geometry a void function, as the only failure
case really can't occur.
I think this case can be reached if user require a RGB565 format to
capture and sensor also support RGB565 format.
As atmel-isi driver will provide RGB565 support via the pass-through
mode (maybe we need re-consider this part).
So that will cause the configure_geometry() returns an error since it
found the bus format is not Y8 or YUV422.
In my opinion, we should not change configure_geometry()'s return type,
until we add a insanity format check before we call configure_geometry()
in future.
It will really confuse the user if S_FMT accepts a format but STREAMON fails
due to the format being unsupported. Could that be fixed by defaulting to a
known supported format in S_FMT if the requested format isn't support ? You
could then remove the error check in configure_geometry().
Apart from that,
Reviewed-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Thanks for the review.
Best Regards,
Josh Wu
+ if (ret 0)
+ return ret;
+
spin_lock_irq(isi-lock);
/* Clear any pending interrupt */
isi_readl(isi, ISI_STATUS);
@@ -477,8 +482,6 @@ static int isi_camera_init_videobuf(struct vb2_queue
*q, static int isi_camera_set_fmt(struct soc_camera_device *icd,
struct v4l2_format *f)
{
- struct soc_camera_host *ici = to_soc_camera_host(icd-parent);
- struct atmel_isi *isi = ici-priv;
struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
const struct soc_camera_format_xlate *xlate;
struct v4l2_pix_format *pix = f-fmt.pix;
@@ -511,16 +514,6 @@ static int isi_camera_set_fmt(struct
soc_camera_device
*icd, if (mf-code != xlate-code)
return -EINVAL;
- /* Enable PM and peripheral clock before operate isi registers */
- pm_runtime_get_sync(ici-v4l2_dev.dev);
-
- ret = configure_geometry(isi, pix-width, pix-height, xlate-code);
-
- pm_runtime_put(ici-v4l2_dev.dev);
-
- if (ret 0)
- return ret;
-
pix-width = mf-width;
pix-height = mf-height;
pix-field = mf-field;
--
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
zajam ponuda
Bok Pozdrav od sunca EAST Savezne Kreditna unija, mi smo dobro uspostavljen i odobren uk zajam tvrtki, tijekom godina, razvili smo dobro razumijevanje Vašim potrebama i individualnim potrebama. odlučni smo nas prema našim kupcima pošteno i ponuditi uslugu koja je profesionalni i prijateljski, mi smo u jedinstvenoj poziciji da ponudi sve vrste kredita na sve pojedince kao niska kao i 1.5% kamatna stopa, tako da ako imate bilo kakve financijske teškoće i trebate kredit, kontaktirajte nas ako ste zainteresirani za naše e-mail: sunea...@gmail.com * Tvoje puno ime: * Vaša zemlja i kućnu adresu: * Broj telefona: * Iznos kredita je potrebno: * Trajanje: * Svrha: * Spol i dob: * Zanimanje: Mi očekujemo Vaš odgovor u vezi napuni kalup Iako je naša e-pošte. Hvala za odgovor. Susane. -- 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
