Re: [PATCH 4/4] b2c2: Always turn off receive stream
On 22/05/15 21:28, Jemma Denson wrote:
When letting an external device control the receive stream, it won't
know when there's demand for any feeds, so won't be turning off our
receive stream. This patch bring back control of turning it off in
this sitation.
The demod can still delay turning it on until it has data to send,
and still turn it off temporarily whilst it knows there's no
stream, such as whilst tuning.
Signed-off-by: Jemma Denson jden...@gmail.com
---
drivers/media/common/b2c2/flexcop-hw-filter.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/common/b2c2/flexcop-hw-filter.c
b/drivers/media/common/b2c2/flexcop-hw-filter.c
index eceb9c5..8926c82 100644
--- a/drivers/media/common/b2c2/flexcop-hw-filter.c
+++ b/drivers/media/common/b2c2/flexcop-hw-filter.c
@@ -206,7 +206,7 @@ int flexcop_pid_feed_control(struct flexcop_device *fc,
/* if it was the first or last feed request change the stream-status */
if (fc-feedcount == onoff) {
- if (!fc-external_stream_control)
+ if (!fc-external_stream_control || onoff == 0)
flexcop_rcv_data_ctrl(fc, onoff);
if (fc-stream_control) /* device specific stream control */
Hmm, OK. I've done some further testing and this last patch needs either
ignoring or a rethink. It interferes with flexcop_pci_irq_check_work()
in pci/b2c2/flexcop-pci.c. That function will try and reset all the hw
filters with calls to flexcop_pid_feed_control() by turning them all off
and then back on again.
Including this patch causes the receive stream to be turned off and it
then doesn't get enabled again.
Jemma.
--
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
Outreachy Program
Hello Everybody! I am Helen and I've been selected by the Outreachy Program (https://gnome.org/outreachy) to work in the Media Controller Virtual Driver project (http://kernelnewbies.org/LaurentPinchart), mentored by Laurent Pinchart. The main goal of this project is to develop a media driver that can simulate a device with a user specified topology. I.e, the driver should have pre-defined sub-devices (scalers, bayer, debayer, RGB/YUV Capture, sensors, generating images inside the kernel as Vivid does) that can be linked together by user space in run-time and compose a video pipe-line. Thus, the user will be able to simulate many devices with different topologies. I'll be interacting with most of you to discuss a good API for a dynamic topology of a media device and I will probably post some kernel newbie questions on the way. The project goes from May 25 to August 25. Here is my blog: http://helenfornazier.blogspot.com.br/ I am going to post under Outreachy category at least once every two weeks: http://helenfornazier.blogspot.com.br/feeds/posts/default/-/Outreachy?alt=rss My nick on irc is koike (its my middle name). I do hope to learn a lot, do my best and have fun. Best regards, -- Helen Mae Koike Fornazier -- 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] v4l: subdev: Add pad config allocator and init
Hi Hans,
On Sunday 24 May 2015 10:00:44 Hans Verkuil wrote:
Hi Laurent,
Looks good, but I have one question. See below.
On 05/23/2015 08:24 PM, Laurent Pinchart wrote:
Add a new subdev operation to initialize a subdev pad config array, and
a helper function to allocate and initialize the array. This can be used
by bridge drivers to implement try format based on subdev pad
operations.
Signed-off-by: Laurent Pinchart laurent.pinch...@linaro.org
Acked-by: Vaibhav Hiremath vaibhav.hirem...@linaro.org
---
drivers/media/v4l2-core/v4l2-subdev.c | 19 ++-
include/media/v4l2-subdev.h | 3 +++
2 files changed, 21 insertions(+), 1 deletion(-)
[snip]
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 8f5da73dacff..7860d67574f5 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -483,6 +483,8 @@ struct v4l2_subdev_pad_config {
* may be adjusted by the subdev driver to device
capabilities. */
struct v4l2_subdev_pad_ops {
+ void (*init_cfg)(struct v4l2_subdev *sd,
+struct v4l2_subdev_pad_config *cfg);
int (*enum_mbus_code)(struct v4l2_subdev *sd,
struct v4l2_subdev_pad_config *cfg,
struct v4l2_subdev_mbus_code_enum *code);
@@ -675,6 +677,7 @@ int v4l2_subdev_link_validate_default(struct
v4l2_subdev *sd,
struct v4l2_subdev_format *source_fmt,
struct v4l2_subdev_format *sink_fmt);
int v4l2_subdev_link_validate(struct media_link *link);
+struct v4l2_subdev_pad_config *v4l2_subdev_alloc_pad_config(struct
v4l2_subdev *sd);
Would it make sense to add a simple static inline
v4l2_subdev_free_pad_config here? All it does is a kfree, but still it
makes it symmetrical and if we ever need to do more than a kfree, then we
are able to do so.
Yes it makes sense. I've sent a v2.
At the very least this header needs a comment if we don't add a
free_pad_config that the caller needs to kfree the pointer.
#endif /* CONFIG_MEDIA_CONTROLLER */
void v4l2_subdev_init(struct v4l2_subdev *sd,
const struct v4l2_subdev_ops *ops);
--
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 v2] v4l: subdev: Add pad config allocator and init
From: Laurent Pinchart laurent.pinch...@linaro.org
Add a new subdev operation to initialize a subdev pad config array, and
a helper function to allocate and initialize the array. This can be used
by bridge drivers to implement try format based on subdev pad
operations.
Signed-off-by: Laurent Pinchart laurent.pinch...@linaro.org
Acked-by: Vaibhav Hiremath vaibhav.hirem...@linaro.org
---
drivers/media/v4l2-core/v4l2-subdev.c | 19 ++-
include/media/v4l2-subdev.h | 10 ++
2 files changed, 28 insertions(+), 1 deletion(-)
Changes since v1:
- Added v4l2_subdev_free_pad_config
diff --git a/drivers/media/v4l2-core/v4l2-subdev.c
b/drivers/media/v4l2-core/v4l2-subdev.c
index 63596063b213..d594fe566be2 100644
--- a/drivers/media/v4l2-core/v4l2-subdev.c
+++ b/drivers/media/v4l2-core/v4l2-subdev.c
@@ -35,7 +35,7 @@
static int subdev_fh_init(struct v4l2_subdev_fh *fh, struct v4l2_subdev *sd)
{
#if defined(CONFIG_VIDEO_V4L2_SUBDEV_API)
- fh-pad = kzalloc(sizeof(*fh-pad) * sd-entity.num_pads, GFP_KERNEL);
+ fh-pad = v4l2_subdev_alloc_pad_config(sd);
if (fh-pad == NULL)
return -ENOMEM;
#endif
@@ -569,6 +569,23 @@ int v4l2_subdev_link_validate(struct media_link *link)
sink, link, source_fmt, sink_fmt);
}
EXPORT_SYMBOL_GPL(v4l2_subdev_link_validate);
+
+struct v4l2_subdev_pad_config *v4l2_subdev_alloc_pad_config(struct v4l2_subdev
*sd)
+{
+ struct v4l2_subdev_pad_config *cfg;
+
+ if (!sd-entity.num_pads)
+ return NULL;
+
+ cfg = kcalloc(sd-entity.num_pads, sizeof(*cfg), GFP_KERNEL);
+ if (!cfg)
+ return NULL;
+
+ v4l2_subdev_call(sd, pad, init_cfg, cfg);
+
+ return cfg;
+}
+EXPORT_SYMBOL_GPL(v4l2_subdev_alloc_pad_config);
#endif /* CONFIG_MEDIA_CONTROLLER */
void v4l2_subdev_init(struct v4l2_subdev *sd, const struct v4l2_subdev_ops
*ops)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 8f5da73dacff..cf2ee07b0745 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -483,6 +483,8 @@ struct v4l2_subdev_pad_config {
* may be adjusted by the subdev driver to device
capabilities.
*/
struct v4l2_subdev_pad_ops {
+ void (*init_cfg)(struct v4l2_subdev *sd,
+struct v4l2_subdev_pad_config *cfg);
int (*enum_mbus_code)(struct v4l2_subdev *sd,
struct v4l2_subdev_pad_config *cfg,
struct v4l2_subdev_mbus_code_enum *code);
@@ -675,7 +677,15 @@ int v4l2_subdev_link_validate_default(struct v4l2_subdev
*sd,
struct v4l2_subdev_format *source_fmt,
struct v4l2_subdev_format *sink_fmt);
int v4l2_subdev_link_validate(struct media_link *link);
+
+struct v4l2_subdev_pad_config *v4l2_subdev_alloc_pad_config(struct v4l2_subdev
*sd);
+
+static inline void v4l2_subdev_free_pad_config(struct v4l2_subdev_pad_config
*cfg)
+{
+ kfree(cfg);
+}
#endif /* CONFIG_MEDIA_CONTROLLER */
+
void v4l2_subdev_init(struct v4l2_subdev *sd,
const struct v4l2_subdev_ops *ops);
--
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 08/20] media: soc_camera pad-aware driver initialisation
On 05/24/2015 11:50 PM, Laurent Pinchart wrote: Hi Hans, On Sunday 24 May 2015 10:08:15 Hans Verkuil wrote: On 05/23/2015 08:32 PM, Laurent Pinchart wrote: On Thursday 21 May 2015 07:55:10 Hans Verkuil wrote: On 05/20/2015 06:39 PM, William Towle wrote: Add detection of source pad number for drivers aware of the media controller API, so that soc_camera/rcar_vin can create device nodes to support a driver such as adv7604.c (for HDMI on Lager) underneath. Signed-off-by: William Towle william.to...@codethink.co.uk Reviewed-by: Rob Taylor rob.tay...@codethink.co.uk --- drivers/media/platform/soc_camera/rcar_vin.c |4 drivers/media/platform/soc_camera/soc_camera.c | 27 - include/media/soc_camera.h |1 + 3 files changed, 31 insertions(+), 1 deletion(-) diff --git a/drivers/media/platform/soc_camera/rcar_vin.c b/drivers/media/platform/soc_camera/rcar_vin.c index 0f67646..b4e9b43 100644 --- a/drivers/media/platform/soc_camera/rcar_vin.c +++ b/drivers/media/platform/soc_camera/rcar_vin.c @@ -1364,8 +1364,12 @@ static int rcar_vin_get_formats(struct soc_camera_device *icd, unsigned int idx, struct v4l2_mbus_framefmt *mf = fmt.format; struct v4l2_rect rect; struct device *dev = icd-parent; + struct media_pad *remote_pad; int shift; + remote_pad = media_entity_remote_pad( + icd-vdev-entity.pads[0]); + fmt.pad = remote_pad-index; This won't work if CONFIG_MEDIA_CONTROLLER isn't defined. All these media calls would all have to be under #ifdef CONFIG_MEDIA_CONTROLLER. Unfortunately, if it is not defined, then you still have no way of finding the source pad. Laurent, do you think if it would make sense to add a new subdev core op that will return the default source pad (I'm saying 'default' in case there are more) of a subdev? That way it can be used in non-MC drivers. We never needed the source pad before, but now we do, and this op only needs to be implemented if the default source pad != 0. I'm not too fond of that. Is there something wrong with the method implemented in this patch ? Is the dependency on CONFIG_MEDIA_CONTROLLER an issue ? 1) it's a heck of a lot of code just to get a simple source pad that the subdev knows anyway, I don't think the subdev knows. If a subdev has multiple source pads there's no concept of a default source. It all depends on how the subdevs are connected, and media_entity_remote_pad() is the right way to find out. Note that with 'source pad' I am referring to the output pad of a subdev (ADV7604_PAD_SOURCE in the case of the adv7604). There may be some confusion here. In my experience subdevs in a capture path have usually multiple input (sink) pads, but only one output (source) pad. Subdevs in a video output path tend to have one input (sink) pad and multiple output (source) pads. The multiple inputs/outputs are things like composite, S-Video, HDMI, VGA, etc. and the single input/output pad is where the device is hooked up to the mediabus which in turn connects to a DMA engine. 2) soc-camera doesn't use the media controller today, so this would add a dependency on the mc just for this, I agree that we shouldn't pull the whole MC userspace API in just for this, but the kernel side of the API should be available as pad-level operations depend on MC. We could split the CONFIG_MEDIA_CONTROLLER option in two. The way it is now is pretty OK. We just miss the information about the pad that feeds the dma capture path and for output we miss the the pad that is fed by the dma output path. Bridge drivers currently just assume pad 0 in all cases, but that's obviously not always right as the adv7604 illustrates. The alternative would be to just hardcode it in platform data or card information. What this patch does is just enumerating pads until it finds the first one that fits the criteria, which fails as well if there are multiple pads that would match and is a lot more code than just have the subdev provide the information. Regards, Hans 3) it doesn't actually make a media device, it is just fakes enough to make the subdev think it there is an MC. It doesn't actually have to be a new op, it could be a new field in v4l2_subdev as well. For those bridge drivers that do not use the MC but do need to know the source pad this is important information. It might even simplify the device tree if the default source pad is implied unless stated otherwise (but that might be a step too far). I wonder if a default input pad might also be useful to expose. I suspect this might become important if we want to add MC support to all existing v4l2 drivers. The concept of a default sink pad makes more sense, but I'm not sure I like it too much either. I'd have to think about it. -- To unsubscribe from this list: send the line unsubscribe linux-media in the
Re: [PATCH 08/20] media: soc_camera pad-aware driver initialisation
Hi Hans, On Sunday 24 May 2015 10:08:15 Hans Verkuil wrote: On 05/23/2015 08:32 PM, Laurent Pinchart wrote: On Thursday 21 May 2015 07:55:10 Hans Verkuil wrote: On 05/20/2015 06:39 PM, William Towle wrote: Add detection of source pad number for drivers aware of the media controller API, so that soc_camera/rcar_vin can create device nodes to support a driver such as adv7604.c (for HDMI on Lager) underneath. Signed-off-by: William Towle william.to...@codethink.co.uk Reviewed-by: Rob Taylor rob.tay...@codethink.co.uk --- drivers/media/platform/soc_camera/rcar_vin.c |4 drivers/media/platform/soc_camera/soc_camera.c | 27 - include/media/soc_camera.h |1 + 3 files changed, 31 insertions(+), 1 deletion(-) diff --git a/drivers/media/platform/soc_camera/rcar_vin.c b/drivers/media/platform/soc_camera/rcar_vin.c index 0f67646..b4e9b43 100644 --- a/drivers/media/platform/soc_camera/rcar_vin.c +++ b/drivers/media/platform/soc_camera/rcar_vin.c @@ -1364,8 +1364,12 @@ static int rcar_vin_get_formats(struct soc_camera_device *icd, unsigned int idx, struct v4l2_mbus_framefmt *mf = fmt.format; struct v4l2_rect rect; struct device *dev = icd-parent; + struct media_pad *remote_pad; int shift; + remote_pad = media_entity_remote_pad( + icd-vdev-entity.pads[0]); + fmt.pad = remote_pad-index; This won't work if CONFIG_MEDIA_CONTROLLER isn't defined. All these media calls would all have to be under #ifdef CONFIG_MEDIA_CONTROLLER. Unfortunately, if it is not defined, then you still have no way of finding the source pad. Laurent, do you think if it would make sense to add a new subdev core op that will return the default source pad (I'm saying 'default' in case there are more) of a subdev? That way it can be used in non-MC drivers. We never needed the source pad before, but now we do, and this op only needs to be implemented if the default source pad != 0. I'm not too fond of that. Is there something wrong with the method implemented in this patch ? Is the dependency on CONFIG_MEDIA_CONTROLLER an issue ? 1) it's a heck of a lot of code just to get a simple source pad that the subdev knows anyway, I don't think the subdev knows. If a subdev has multiple source pads there's no concept of a default source. It all depends on how the subdevs are connected, and media_entity_remote_pad() is the right way to find out. 2) soc-camera doesn't use the media controller today, so this would add a dependency on the mc just for this, I agree that we shouldn't pull the whole MC userspace API in just for this, but the kernel side of the API should be available as pad-level operations depend on MC. We could split the CONFIG_MEDIA_CONTROLLER option in two. 3) it doesn't actually make a media device, it is just fakes enough to make the subdev think it there is an MC. It doesn't actually have to be a new op, it could be a new field in v4l2_subdev as well. For those bridge drivers that do not use the MC but do need to know the source pad this is important information. It might even simplify the device tree if the default source pad is implied unless stated otherwise (but that might be a step too far). I wonder if a default input pad might also be useful to expose. I suspect this might become important if we want to add MC support to all existing v4l2 drivers. The concept of a default sink pad makes more sense, but I'm not sure I like it too much either. I'd have to think about 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 v2] v4l: subdev: Add pad config allocator and init
On 05/24/2015 11:10 PM, Laurent Pinchart wrote:
From: Laurent Pinchart laurent.pinch...@linaro.org
Add a new subdev operation to initialize a subdev pad config array, and
a helper function to allocate and initialize the array. This can be used
by bridge drivers to implement try format based on subdev pad
operations.
Signed-off-by: Laurent Pinchart laurent.pinch...@linaro.org
Acked-by: Vaibhav Hiremath vaibhav.hirem...@linaro.org
Acked-by: Hans Verkuil hans.verk...@cisco.com
Note that before this goes in there should be at least one subdev driver that
implements init_cfg(). Perhaps adv7604?
Regards,
Hans
---
drivers/media/v4l2-core/v4l2-subdev.c | 19 ++-
include/media/v4l2-subdev.h | 10 ++
2 files changed, 28 insertions(+), 1 deletion(-)
Changes since v1:
- Added v4l2_subdev_free_pad_config
diff --git a/drivers/media/v4l2-core/v4l2-subdev.c
b/drivers/media/v4l2-core/v4l2-subdev.c
index 63596063b213..d594fe566be2 100644
--- a/drivers/media/v4l2-core/v4l2-subdev.c
+++ b/drivers/media/v4l2-core/v4l2-subdev.c
@@ -35,7 +35,7 @@
static int subdev_fh_init(struct v4l2_subdev_fh *fh, struct v4l2_subdev *sd)
{
#if defined(CONFIG_VIDEO_V4L2_SUBDEV_API)
- fh-pad = kzalloc(sizeof(*fh-pad) * sd-entity.num_pads, GFP_KERNEL);
+ fh-pad = v4l2_subdev_alloc_pad_config(sd);
if (fh-pad == NULL)
return -ENOMEM;
#endif
@@ -569,6 +569,23 @@ int v4l2_subdev_link_validate(struct media_link *link)
sink, link, source_fmt, sink_fmt);
}
EXPORT_SYMBOL_GPL(v4l2_subdev_link_validate);
+
+struct v4l2_subdev_pad_config *v4l2_subdev_alloc_pad_config(struct
v4l2_subdev *sd)
+{
+ struct v4l2_subdev_pad_config *cfg;
+
+ if (!sd-entity.num_pads)
+ return NULL;
+
+ cfg = kcalloc(sd-entity.num_pads, sizeof(*cfg), GFP_KERNEL);
+ if (!cfg)
+ return NULL;
+
+ v4l2_subdev_call(sd, pad, init_cfg, cfg);
+
+ return cfg;
+}
+EXPORT_SYMBOL_GPL(v4l2_subdev_alloc_pad_config);
#endif /* CONFIG_MEDIA_CONTROLLER */
void v4l2_subdev_init(struct v4l2_subdev *sd, const struct v4l2_subdev_ops
*ops)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 8f5da73dacff..cf2ee07b0745 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -483,6 +483,8 @@ struct v4l2_subdev_pad_config {
* may be adjusted by the subdev driver to device
capabilities.
*/
struct v4l2_subdev_pad_ops {
+ void (*init_cfg)(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg);
int (*enum_mbus_code)(struct v4l2_subdev *sd,
struct v4l2_subdev_pad_config *cfg,
struct v4l2_subdev_mbus_code_enum *code);
@@ -675,7 +677,15 @@ int v4l2_subdev_link_validate_default(struct v4l2_subdev
*sd,
struct v4l2_subdev_format *source_fmt,
struct v4l2_subdev_format *sink_fmt);
int v4l2_subdev_link_validate(struct media_link *link);
+
+struct v4l2_subdev_pad_config *v4l2_subdev_alloc_pad_config(struct
v4l2_subdev *sd);
+
+static inline void v4l2_subdev_free_pad_config(struct v4l2_subdev_pad_config
*cfg)
+{
+ kfree(cfg);
+}
#endif /* CONFIG_MEDIA_CONTROLLER */
+
void v4l2_subdev_init(struct v4l2_subdev *sd,
const struct v4l2_subdev_ops *ops);
--
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
Access to MPEG-TS?
Hello, I'm working on an application that - among other things - should be able to identify the programs in a MPEG transport stream broadcasted via DVB-C. This is what I have figured out so far: 1. Open the DVB frontend. 2. Fill struct dvb_frontend_parameters with transponder frequency etc. 3. Apply struct dvb_frontend_parameters with FE_SET_FRONTEND ioctl call. After performing these steps, I call the FE_READ_STATUS ioctl and the status is FE_HAS_LOCK. I should then parse the MPEG transport stream to identify the programs, pids etc. but my problem is that I don't know how to access the transport stream? I have tried to read the file descriptor returned from opening the frontend, but no MPEG data is found there. Can anyone point me in the right direction? -- 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: 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: Mon May 25 04:00:18 CEST 2015 git branch: test git hash: 2a80f296422a01178d0a993479369e94f5830127 gcc version:i686-linux-gcc (GCC) 5.1.0 sparse version: v0.5.0-44-g40791b9 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: WARNINGS 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: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS 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: ERRORS linux-3.2.37-i686: ERRORS linux-3.3.8-i686: ERRORS 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: WARNINGS linux-3.17.8-i686: WARNINGS linux-3.18.7-i686: WARNINGS linux-3.19-i686: WARNINGS linux-4.0-i686: WARNINGS linux-4.1-rc1-i686: WARNINGS 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: ERRORS linux-3.2.37-x86_64: ERRORS linux-3.3.8-x86_64: ERRORS 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: WARNINGS linux-4.1-rc1-x86_64: WARNINGS apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.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
Payment
Dear Winner, You have been awarded the sum of 8,000,000.00 (Eight Million Pounds sterling) with reference number 77100146. This compensation funds from the United Nation.Send us your personal details to deliver your funds. Gloria Peter -- 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] v4l: subdev: Add pad config allocator and init
Hi Laurent,
Looks good, but I have one question. See below.
On 05/23/2015 08:24 PM, Laurent Pinchart wrote:
Add a new subdev operation to initialize a subdev pad config array, and
a helper function to allocate and initialize the array. This can be used
by bridge drivers to implement try format based on subdev pad
operations.
Signed-off-by: Laurent Pinchart laurent.pinch...@linaro.org
Acked-by: Vaibhav Hiremath vaibhav.hirem...@linaro.org
---
drivers/media/v4l2-core/v4l2-subdev.c | 19 ++-
include/media/v4l2-subdev.h | 3 +++
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/v4l2-subdev.c
b/drivers/media/v4l2-core/v4l2-subdev.c
index 63596063b213..d594fe566be2 100644
--- a/drivers/media/v4l2-core/v4l2-subdev.c
+++ b/drivers/media/v4l2-core/v4l2-subdev.c
@@ -35,7 +35,7 @@
static int subdev_fh_init(struct v4l2_subdev_fh *fh, struct v4l2_subdev *sd)
{
#if defined(CONFIG_VIDEO_V4L2_SUBDEV_API)
- fh-pad = kzalloc(sizeof(*fh-pad) * sd-entity.num_pads, GFP_KERNEL);
+ fh-pad = v4l2_subdev_alloc_pad_config(sd);
if (fh-pad == NULL)
return -ENOMEM;
#endif
@@ -569,6 +569,23 @@ int v4l2_subdev_link_validate(struct media_link *link)
sink, link, source_fmt, sink_fmt);
}
EXPORT_SYMBOL_GPL(v4l2_subdev_link_validate);
+
+struct v4l2_subdev_pad_config *v4l2_subdev_alloc_pad_config(struct
v4l2_subdev *sd)
+{
+ struct v4l2_subdev_pad_config *cfg;
+
+ if (!sd-entity.num_pads)
+ return NULL;
+
+ cfg = kcalloc(sd-entity.num_pads, sizeof(*cfg), GFP_KERNEL);
+ if (!cfg)
+ return NULL;
+
+ v4l2_subdev_call(sd, pad, init_cfg, cfg);
+
+ return cfg;
+}
+EXPORT_SYMBOL_GPL(v4l2_subdev_alloc_pad_config);
#endif /* CONFIG_MEDIA_CONTROLLER */
void v4l2_subdev_init(struct v4l2_subdev *sd, const struct v4l2_subdev_ops
*ops)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 8f5da73dacff..7860d67574f5 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -483,6 +483,8 @@ struct v4l2_subdev_pad_config {
* may be adjusted by the subdev driver to device
capabilities.
*/
struct v4l2_subdev_pad_ops {
+ void (*init_cfg)(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg);
int (*enum_mbus_code)(struct v4l2_subdev *sd,
struct v4l2_subdev_pad_config *cfg,
struct v4l2_subdev_mbus_code_enum *code);
@@ -675,6 +677,7 @@ int v4l2_subdev_link_validate_default(struct v4l2_subdev
*sd,
struct v4l2_subdev_format *source_fmt,
struct v4l2_subdev_format *sink_fmt);
int v4l2_subdev_link_validate(struct media_link *link);
+struct v4l2_subdev_pad_config *v4l2_subdev_alloc_pad_config(struct
v4l2_subdev *sd);
Would it make sense to add a simple static inline v4l2_subdev_free_pad_config
here?
All it does is a kfree, but still it makes it symmetrical and if we ever need to
do more than a kfree, then we are able to do so.
At the very least this header needs a comment if we don't add a free_pad_config
that
the caller needs to kfree the pointer.
Regards,
Hans
#endif /* CONFIG_MEDIA_CONTROLLER */
void v4l2_subdev_init(struct v4l2_subdev *sd,
const struct v4l2_subdev_ops *ops);
--
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 08/20] media: soc_camera pad-aware driver initialisation
On 05/23/2015 08:32 PM, Laurent Pinchart wrote:
Hi Hans,
On Thursday 21 May 2015 07:55:10 Hans Verkuil wrote:
On 05/20/2015 06:39 PM, William Towle wrote:
Add detection of source pad number for drivers aware of the media
controller API, so that soc_camera/rcar_vin can create device nodes
to support a driver such as adv7604.c (for HDMI on Lager) underneath.
Signed-off-by: William Towle william.to...@codethink.co.uk
Reviewed-by: Rob Taylor rob.tay...@codethink.co.uk
---
drivers/media/platform/soc_camera/rcar_vin.c |4
drivers/media/platform/soc_camera/soc_camera.c | 27 ++-
include/media/soc_camera.h |1 +
3 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
b/drivers/media/platform/soc_camera/rcar_vin.c index 0f67646..b4e9b43
100644
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -1364,8 +1364,12 @@ static int rcar_vin_get_formats(struct
soc_camera_device *icd, unsigned int idx,
struct v4l2_mbus_framefmt *mf = fmt.format;
struct v4l2_rect rect;
struct device *dev = icd-parent;
+ struct media_pad *remote_pad;
int shift;
+ remote_pad = media_entity_remote_pad(
+ icd-vdev-entity.pads[0]);
+ fmt.pad = remote_pad-index;
This won't work if CONFIG_MEDIA_CONTROLLER isn't defined. All these media
calls would all have to be under #ifdef CONFIG_MEDIA_CONTROLLER.
Unfortunately, if it is not defined, then you still have no way of finding
the source pad.
Laurent, do you think if it would make sense to add a new subdev core op
that will return the default source pad (I'm saying 'default' in case there
are more) of a subdev? That way it can be used in non-MC drivers. We never
needed the source pad before, but now we do, and this op only needs to be
implemented if the default source pad != 0.
I'm not too fond of that. Is there something wrong with the method
implemented
in this patch ? Is the dependency on CONFIG_MEDIA_CONTROLLER an issue ?
1) it's a heck of a lot of code just to get a simple source pad that the subdev
knows anyway,
2) soc-camera doesn't use the media controller today, so this would add a
dependency on the mc just for this,
3) it doesn't actually make a media device, it is just fakes enough to make the
subdev think it there is an MC.
It doesn't actually have to be a new op, it could be a new field in v4l2_subdev
as well. For those bridge drivers that do not use the MC but do need to know
the source pad this is important information.
It might even simplify the device tree if the default source pad is implied
unless stated otherwise (but that might be a step too far).
I wonder if a default input pad might also be useful to expose. I suspect this
might become important if we want to add MC support to all existing v4l2
drivers.
Regards,
Hans
ret = v4l2_subdev_call(sd, pad, get_fmt, NULL, fmt);
if (ret 0)
return ret;
diff --git a/drivers/media/platform/soc_camera/soc_camera.c
b/drivers/media/platform/soc_camera/soc_camera.c index d708df4..126d645
100644
--- a/drivers/media/platform/soc_camera/soc_camera.c
+++ b/drivers/media/platform/soc_camera/soc_camera.c
@@ -1293,6 +1293,7 @@ static int soc_camera_probe_finish(struct
soc_camera_device *icd)
.which = V4L2_SUBDEV_FORMAT_ACTIVE,
};
struct v4l2_mbus_framefmt *mf = fmt.format;
+ int src_pad_idx = -1;
int ret;
sd-grp_id = soc_camera_grp_id(icd);
@@ -1311,7 +1312,25 @@ static int soc_camera_probe_finish(struct
soc_camera_device *icd)
}
/* At this point client .probe() should have run already */
- ret = soc_camera_init_user_formats(icd);
+ ret = media_entity_init(icd-vdev-entity, 1, icd-pad, 0);
+ if (!ret) {
+ for (src_pad_idx = 0; src_pad_idx sd-entity.num_pads;
+ src_pad_idx++)
+ if (sd-entity.pads[src_pad_idx].flags
+ == MEDIA_PAD_FL_SOURCE)
+ break;
+
+ if (src_pad_idx sd-entity.num_pads) {
+ if (!media_entity_create_link(
+ icd-vdev-entity, 0,
+ sd-entity, src_pad_idx,
+ MEDIA_LNK_FL_IMMUTABLE |
+ MEDIA_LNK_FL_ENABLED)) {
+ ret = soc_camera_init_user_formats(icd);
+ }
+ }
+ }
+
if (ret 0)
goto eusrfmt;
@@ -1322,6 +1341,7 @@ static int soc_camera_probe_finish(struct
soc_camera_device *icd)
goto evidstart;
/* Try to improve our guess of a reasonable window format */
+ fmt.pad = src_pad_idx;
if (!v4l2_subdev_call(sd, pad,
