[GIT PULL v2] of: Add of-graph helpers to loop over endpoints and find ports by id
Hi Grant, Rob, this series has been around for quite some time now, basically unchanged except for adding fixes for new users of the API that keep appearing over time in different subsystems. It would be really helpful to get this merged for v4.0. Could you still make this happen? Alternatively, could I please get your ack to allow this tag to be merged into the other subsystem trees for v4.1 so that patches that depend on it don't have to wait for yet another merge window? best regards Philipp The following changes since commit c517d838eb7d07bbe9507871fab3931deccff539: Linux 4.0-rc1 (2015-02-22 18:21:14 -0800) are available in the git repository at: git://git.pengutronix.de/git/pza/linux.git tags/of-graph-for-4.0 for you to fetch changes up to bfe446e37c4efd8ade454911e8f80414bcbfc10d: of: Add of_graph_get_port_by_id function (2015-02-23 11:42:24 +0100) of: Add of-graph helpers to loop over endpoints and find ports by id This series converts of_graph_get_next_endpoint to decrement the refcount of the passed prev parameter. This allows to add a for_each_endpoint_of_node helper macro to loop over all endpoints in a device tree node. The of_graph_get_port_by_id function is added to retrieve a port by its known port id (contained in the reg property) from the device tree. Philipp Zabel (3): of: Decrement refcount of previous endpoint in of_graph_get_next_endpoint of: Add for_each_endpoint_of_node helper macro of: Add of_graph_get_port_by_id function drivers/coresight/of_coresight.c | 13 ++- drivers/gpu/drm/imx/imx-drm-core.c| 11 +- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 15 +++-- drivers/media/platform/am437x/am437x-vpfe.c | 1 - drivers/media/platform/soc_camera/soc_camera.c| 3 +- drivers/of/base.c | 41 ++- drivers/video/fbdev/omap2/dss/omapdss-boot-init.c | 7 +--- include/linux/of_graph.h | 18 ++ 8 files changed, 61 insertions(+), 48 deletions(-) -- 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 v8 0/3] Add of-graph helpers to loop over endpoints and find ports by id
Hi Laurent, Am Sonntag, den 01.03.2015, 18:20 +0200 schrieb Laurent Pinchart: > Hi Philipp and all, > > This series has been around for a long time, it seems to be time to get it > merged. > > What's the plan ? If we wait for the v4.1 merge window there's a chance we'll > get more conflicts, especially on patch 1/3. Could it be merged in v4.0-rc to > avoid that ? I've just sent another pull request to Grant and Rob. My favorite outcome would be for the tag to be merged in time for v4.0 via the device tree branch. My second most favorite outcome would be maintainer approval to merge the same tag into both drm, media, etc. for v4.1. regards Philipp > On Monday 23 February 2015 11:54:03 Philipp Zabel wrote: > > Hi, > > > > Since there now is a merge conflict in imx-drm-core, I've rebased the series > > onto v4.0-rc1. Also a new driver touched by this change appeared, so the > > first patch now includes a fix for am437x-vfpe, too. I'd be happy to get an > > ack for that. > > > > This series converts all existing users of of_graph_get_next_endpoint that > > pass a non-NULL prev argument to the function and decrement its refcount > > themselves to stop doing that. The of_node_put is moved into > > of_graph_get_next_endpoint instead. > > This allows to add a for_each_endpoint_of_node helper macro to loop over all > > endpoints in a device tree node. > > > > Changes since v8: > > - Rebased onto v4.0-rc1 > > - Added fix to am437x-vpfe > > > > The previous version can be found here: https://lkml.org/lkml/2014/12/23/219 > > > > regards > > Philipp > > > > Philipp Zabel (3): > > of: Decrement refcount of previous endpoint in > > of_graph_get_next_endpoint > > of: Add for_each_endpoint_of_node helper macro > > of: Add of_graph_get_port_by_id function > > > > drivers/coresight/of_coresight.c | 13 ++- > > drivers/gpu/drm/imx/imx-drm-core.c| 11 +- > > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 15 +++-- > > drivers/media/platform/am437x/am437x-vpfe.c | 1 - > > drivers/media/platform/soc_camera/soc_camera.c| 3 +- > > drivers/of/base.c | 41 +++- > > drivers/video/fbdev/omap2/dss/omapdss-boot-init.c | 7 +--- > > include/linux/of_graph.h | 18 ++ > > 8 files changed, 61 insertions(+), 48 deletions(-) > -- 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: STK1160 driver connected to usb hub
Hi Ezequiel Garcia, Thanks for your interpretation and as you said, USB host controller isochronous bandwidth's limitation influences the multiple channels video transmission. We have tried our best to also use USB Hub to support multiple channels video transmission, while the bandwidth problem exist for USB Hub solution as well. Therefore, we are trying wireless module for multiple camera system now. Currently, it goes well. Regards, Ling Yin On Mon, Feb 9, 2015 at 12:17 AM, Ezequiel Garcia wrote: > (Ccing the media ML) > > See my reply below. > > On Fri, Feb 6, 2015 at 4:36 AM, Yin Ling wrote: >> Hi Ezequiel Garcia, >> >> Sorry for this bother. We are researcher at University and working on >> STK1160 usb connection related solusion. As our system needs multiple >> STK1160 to input video data, we plan to use usb Hub to connect >> multiple STK1160. Nevertheless, currently only one STK1160 with driver >> can be operated by one usb Hub host from the information below, >> http://www.linuxtv.org/wiki/index.php/Stk1160_based_USB_2.0_video_and_audio_capture_devices#Known_issues >> It wrote that "To one root hub port can connect only one device. Can >> connect multiple, but at the same time only one operate. This not an >> power supply issue, since the device consumes only 200mA in operation >> mode. Number of devices that can simultaneously connect to PC depends >> on the amount root hub ports." >> >> If try to operate multiple STK1160 by one usb Hub, is it possible? >> Could you help to provide any hints or technological ways to achieve >> this goal? >> > > As far as I can recall, the only constraint is the USB host controller > isochronous bandwidth. > Given the stk1160 chip streams raw video, and given I have found no > way to implement frame size in-chip reduction, > your USB host must be able to deal with raw full frames. Roughly > speaking you need as much as 20 MB/s for each stk1160 video input. > > Such throughput is more or less close, to USB2.0 maximum throughput. > > I hope someone can jump in and correct me if I'm wrong here. > >> Additionally, if this way is not feasible, we have to work on >> capturing 4 channel video data from one STK1160 at the same time. We >> have to switch channel to capture each specific channel video data. We >> found that if we switch channel with the frequency as 1s, the quality >> of images are not well. Do you know how we can capture 4 channel good >> quality video data, lower switch frequency? How much it could be? >> > > I think this is a hardware limitation. The stk1160 is not able to > capture from the multiple channels > simultaneously. I honestly don't recall how it performs when fast > switching between channels, but I wouldn't expect much. > >> As we are very busy with the system, and are confusing with these >> problems at this period, we are highly looking forward to receiving >> your information. or else, if anyone may knows the solution, could you >> help to provide to us as well? >> > > Maybe you can get yourself a video capture device that can stream > compressed video? That will certainly reduce the USB bandwidth > requirement. > > Hope this helps! > -- > Ezequiel García, VanguardiaSur > www.vanguardiasur.com.ar -- 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] DocBook media: fix typos in YUV420M description
NV12M -> YUV420M YVU420M -> YUV420M Signed-off-by: Hans Verkuil --- Documentation/DocBook/media/v4l/pixfmt-yuv420m.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/DocBook/media/v4l/pixfmt-yuv420m.xml b/Documentation/DocBook/media/v4l/pixfmt-yuv420m.xml index 60308f1..e781cc6 100644 --- a/Documentation/DocBook/media/v4l/pixfmt-yuv420m.xml +++ b/Documentation/DocBook/media/v4l/pixfmt-yuv420m.xml @@ -29,12 +29,12 @@ and Cr planes have half as many pad bytes after their rows. In other words, two Cx rows (including padding) is exactly as long as one Y row (including padding). - V4L2_PIX_FMT_NV12M is intended to be + V4L2_PIX_FMT_YUV420M is intended to be used only in drivers and applications that support the multi-planar API, described in . - V4L2_PIX_FMT_YVU420M 4 × 4 + V4L2_PIX_FMT_YUV420M 4 × 4 pixel image -- 2.1.4 -- 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 00/15] media: blackfin: bfin_capture enhancements
On 03/02/2015 08:57 AM, Scott Jiang wrote: > Hi Lad and Hans, > > 2015-02-22 2:39 GMT+08:00 Lad Prabhakar : >> From: "Lad, Prabhakar" >> >> This patch series, enhances blackfin capture driver with >> vb2 helpers. >> >> Changes for v3: >> 1: patches unchanged except for patch 8/15 fixing starting of ppi only >>after we have the resources. >> 2: Rebased on media tree. >> >> v2: http://lkml.iu.edu/hypermail/linux/kernel/1501.2/04655.html >> >> v1: https://lkml.org/lkml/2014/12/20/27 >> >> Lad, Prabhakar (15): >> media: blackfin: bfin_capture: drop buf_init() callback >> media: blackfin: bfin_capture: release buffers in case >> start_streaming() call back fails >> media: blackfin: bfin_capture: set min_buffers_needed >> media: blackfin: bfin_capture: improve buf_prepare() callback >> media: blackfin: bfin_capture: improve queue_setup() callback >> media: blackfin: bfin_capture: use vb2_fop_mmap/poll >> media: blackfin: bfin_capture: use v4l2_fh_open and vb2_fop_release >> media: blackfin: bfin_capture: use vb2_ioctl_* helpers >> media: blackfin: bfin_capture: make sure all buffers are returned on >> stop_streaming() callback >> media: blackfin: bfin_capture: return -ENODATA for *std calls >> media: blackfin: bfin_capture: return -ENODATA for *dv_timings calls >> media: blackfin: bfin_capture: add support for vidioc_create_bufs >> media: blackfin: bfin_capture: add support for VB2_DMABUF >> media: blackfin: bfin_capture: add support for VIDIOC_EXPBUF >> media: blackfin: bfin_capture: set v4l2 buffer sequence >> >> drivers/media/platform/blackfin/bfin_capture.c | 306 >> - >> 1 file changed, 94 insertions(+), 212 deletions(-) >> >> -- > > For all these patches, > Acked-by: Scott Jiang > Tested-by: Scott Jiang Thanks! Is it possible for you to run 'v4l2-compliance -s' with this driver and report the results? I'd be interested in that. Regards, Hans -- 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: i2c: s5c73m3: make sure we destroy the mutex
On 03/02/2015 04:00 PM, Lad Prabhakar wrote: > From: "Lad, Prabhakar" > > Make sure to call mutex_destroy() in case of probe failure or module > unload. It's not actually necessary to destroy a mutex. Most drivers never do this. It only helps a bit in debugging. I'll delegate this patch to Kamil, and he can decide whether or not to apply this. Regards, Hans > > Signed-off-by: Lad, Prabhakar > --- > drivers/media/i2c/s5c73m3/s5c73m3-core.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/media/i2c/s5c73m3/s5c73m3-core.c > b/drivers/media/i2c/s5c73m3/s5c73m3-core.c > index ee0f57e..da0b3a3 100644 > --- a/drivers/media/i2c/s5c73m3/s5c73m3-core.c > +++ b/drivers/media/i2c/s5c73m3/s5c73m3-core.c > @@ -1658,7 +1658,6 @@ static int s5c73m3_probe(struct i2c_client *client, > if (ret < 0) > return ret; > > - mutex_init(&state->lock); > sd = &state->sensor_sd; > oif_sd = &state->oif_sd; > > @@ -1695,6 +1694,8 @@ static int s5c73m3_probe(struct i2c_client *client, > if (ret < 0) > return ret; > > + mutex_init(&state->lock); > + > ret = s5c73m3_configure_gpios(state); > if (ret) > goto out_err; > @@ -1754,6 +1755,7 @@ out_err1: > s5c73m3_unregister_spi_driver(state); > out_err: > media_entity_cleanup(&sd->entity); > + mutex_destroy(&state->lock); > return ret; > } > > @@ -1772,6 +1774,7 @@ static int s5c73m3_remove(struct i2c_client *client) > media_entity_cleanup(&sensor_sd->entity); > > s5c73m3_unregister_spi_driver(state); > + mutex_destroy(&state->lock); > > return 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 v3 00/15] media: blackfin: bfin_capture enhancements
Hi Hans, On Tue, Mar 3, 2015 at 8:49 AM, Hans Verkuil wrote: > On 03/02/2015 08:57 AM, Scott Jiang wrote: >> Hi Lad and Hans, >> >> 2015-02-22 2:39 GMT+08:00 Lad Prabhakar : >>> From: "Lad, Prabhakar" >>> >>> This patch series, enhances blackfin capture driver with >>> vb2 helpers. >>> >>> Changes for v3: >>> 1: patches unchanged except for patch 8/15 fixing starting of ppi only >>>after we have the resources. >>> 2: Rebased on media tree. >>> >>> v2: http://lkml.iu.edu/hypermail/linux/kernel/1501.2/04655.html >>> >>> v1: https://lkml.org/lkml/2014/12/20/27 >>> >>> Lad, Prabhakar (15): >>> media: blackfin: bfin_capture: drop buf_init() callback >>> media: blackfin: bfin_capture: release buffers in case >>> start_streaming() call back fails >>> media: blackfin: bfin_capture: set min_buffers_needed >>> media: blackfin: bfin_capture: improve buf_prepare() callback >>> media: blackfin: bfin_capture: improve queue_setup() callback >>> media: blackfin: bfin_capture: use vb2_fop_mmap/poll >>> media: blackfin: bfin_capture: use v4l2_fh_open and vb2_fop_release >>> media: blackfin: bfin_capture: use vb2_ioctl_* helpers >>> media: blackfin: bfin_capture: make sure all buffers are returned on >>> stop_streaming() callback >>> media: blackfin: bfin_capture: return -ENODATA for *std calls >>> media: blackfin: bfin_capture: return -ENODATA for *dv_timings calls >>> media: blackfin: bfin_capture: add support for vidioc_create_bufs >>> media: blackfin: bfin_capture: add support for VB2_DMABUF >>> media: blackfin: bfin_capture: add support for VIDIOC_EXPBUF >>> media: blackfin: bfin_capture: set v4l2 buffer sequence >>> >>> drivers/media/platform/blackfin/bfin_capture.c | 306 >>> - >>> 1 file changed, 94 insertions(+), 212 deletions(-) >>> >>> -- >> >> For all these patches, >> Acked-by: Scott Jiang >> Tested-by: Scott Jiang > > Thanks! > > Is it possible for you to run 'v4l2-compliance -s' with this driver and > report the results? I'd be interested in that. > Fyi.. v4l2-utils can't be compiled under uClibc. Regards, --Prabhakar Lad -- 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 00/15] media: blackfin: bfin_capture enhancements
On 03/03/2015 10:30 AM, Lad, Prabhakar wrote: > Hi Hans, > > On Tue, Mar 3, 2015 at 8:49 AM, Hans Verkuil wrote: >> On 03/02/2015 08:57 AM, Scott Jiang wrote: >>> Hi Lad and Hans, >>> >>> 2015-02-22 2:39 GMT+08:00 Lad Prabhakar : From: "Lad, Prabhakar" This patch series, enhances blackfin capture driver with vb2 helpers. Changes for v3: 1: patches unchanged except for patch 8/15 fixing starting of ppi only after we have the resources. 2: Rebased on media tree. v2: http://lkml.iu.edu/hypermail/linux/kernel/1501.2/04655.html v1: https://lkml.org/lkml/2014/12/20/27 Lad, Prabhakar (15): media: blackfin: bfin_capture: drop buf_init() callback media: blackfin: bfin_capture: release buffers in case start_streaming() call back fails media: blackfin: bfin_capture: set min_buffers_needed media: blackfin: bfin_capture: improve buf_prepare() callback media: blackfin: bfin_capture: improve queue_setup() callback media: blackfin: bfin_capture: use vb2_fop_mmap/poll media: blackfin: bfin_capture: use v4l2_fh_open and vb2_fop_release media: blackfin: bfin_capture: use vb2_ioctl_* helpers media: blackfin: bfin_capture: make sure all buffers are returned on stop_streaming() callback media: blackfin: bfin_capture: return -ENODATA for *std calls media: blackfin: bfin_capture: return -ENODATA for *dv_timings calls media: blackfin: bfin_capture: add support for vidioc_create_bufs media: blackfin: bfin_capture: add support for VB2_DMABUF media: blackfin: bfin_capture: add support for VIDIOC_EXPBUF media: blackfin: bfin_capture: set v4l2 buffer sequence drivers/media/platform/blackfin/bfin_capture.c | 306 - 1 file changed, 94 insertions(+), 212 deletions(-) -- >>> >>> For all these patches, >>> Acked-by: Scott Jiang >>> Tested-by: Scott Jiang >> >> Thanks! >> >> Is it possible for you to run 'v4l2-compliance -s' with this driver and >> report the results? I'd be interested in that. >> > Fyi.. > v4l2-utils can't be compiled under uClibc. Do you know what exactly fails? Is it possible to manually compile v4l2-compliance? I.e., try this: cd utils/v4l2-compliance cat *.cpp >x.cpp g++ -o v4l2-compliance x.cpp -I . -I ../../include/ -DNO_LIBV4L2 I've never used uclibc, so I don't know what the limitations are. Regards, Hans -- 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 00/15] media: blackfin: bfin_capture enhancements
Hi Hans, On Tue, Mar 3, 2015 at 9:39 AM, Hans Verkuil wrote: > On 03/03/2015 10:30 AM, Lad, Prabhakar wrote: >> Hi Hans, >> >> On Tue, Mar 3, 2015 at 8:49 AM, Hans Verkuil wrote: >>> On 03/02/2015 08:57 AM, Scott Jiang wrote: Hi Lad and Hans, 2015-02-22 2:39 GMT+08:00 Lad Prabhakar : > From: "Lad, Prabhakar" > > This patch series, enhances blackfin capture driver with > vb2 helpers. > > Changes for v3: > 1: patches unchanged except for patch 8/15 fixing starting of ppi only >after we have the resources. > 2: Rebased on media tree. > > v2: http://lkml.iu.edu/hypermail/linux/kernel/1501.2/04655.html > > v1: https://lkml.org/lkml/2014/12/20/27 > > Lad, Prabhakar (15): > media: blackfin: bfin_capture: drop buf_init() callback > media: blackfin: bfin_capture: release buffers in case > start_streaming() call back fails > media: blackfin: bfin_capture: set min_buffers_needed > media: blackfin: bfin_capture: improve buf_prepare() callback > media: blackfin: bfin_capture: improve queue_setup() callback > media: blackfin: bfin_capture: use vb2_fop_mmap/poll > media: blackfin: bfin_capture: use v4l2_fh_open and vb2_fop_release > media: blackfin: bfin_capture: use vb2_ioctl_* helpers > media: blackfin: bfin_capture: make sure all buffers are returned on > stop_streaming() callback > media: blackfin: bfin_capture: return -ENODATA for *std calls > media: blackfin: bfin_capture: return -ENODATA for *dv_timings calls > media: blackfin: bfin_capture: add support for vidioc_create_bufs > media: blackfin: bfin_capture: add support for VB2_DMABUF > media: blackfin: bfin_capture: add support for VIDIOC_EXPBUF > media: blackfin: bfin_capture: set v4l2 buffer sequence > > drivers/media/platform/blackfin/bfin_capture.c | 306 > - > 1 file changed, 94 insertions(+), 212 deletions(-) > > -- For all these patches, Acked-by: Scott Jiang Tested-by: Scott Jiang >>> >>> Thanks! >>> >>> Is it possible for you to run 'v4l2-compliance -s' with this driver and >>> report the results? I'd be interested in that. >>> >> Fyi.. >> v4l2-utils can't be compiled under uClibc. > > Do you know what exactly fails? Is it possible to manually compile > v4l2-compliance? > > I.e., try this: > > cd utils/v4l2-compliance > cat *.cpp >x.cpp > g++ -o v4l2-compliance x.cpp -I . -I ../../include/ -DNO_LIBV4L2 > > I've never used uclibc, so I don't know what the limitations are. > Not sure what exactly fails, I haven’t tried compiling it, that was a response from Scott for v2 series. Thanks, --Prabhakar Lad -- 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: adv7604: improve usage of gpiod API
Hi Uwe,
On 03/02/2015 08:00 AM, Uwe Kleine-König wrote:
> Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
> which appeared in v3.17-rc1, the gpiod_get* functions take an additional
> parameter that allows to specify direction and initial value for output.
> Simplify accordingly.
>
> Moreover use devm_gpiod_get_index_optional instead of
> devm_gpiod_get_index with ignoring all errors.
>
> Signed-off-by: Uwe Kleine-König
> ---
> BTW, sparse fails to check this file with many errors like:
>
> drivers/media/i2c/adv7604.c:311:11: error: unknown field name in
> initializer
>
> Didn't look into that.
That's a sparse bug that's been fixed in the sparse repo, but not in the 0.5.0
release (they really should make a new sparse release IMHO).
Some comments below:
> ---
> drivers/media/i2c/adv7604.c | 16 ++--
> 1 file changed, 6 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
> index 5a7c9389a605..ddeeb6695a4b 100644
> --- a/drivers/media/i2c/adv7604.c
> +++ b/drivers/media/i2c/adv7604.c
> @@ -537,12 +537,8 @@ static void adv7604_set_hpd(struct adv7604_state *state,
> unsigned int hpd)
> {
> unsigned int i;
>
> - for (i = 0; i < state->info->num_dv_ports; ++i) {
> - if (IS_ERR(state->hpd_gpio[i]))
> - continue;
Why this change? See also below:
> -
> + for (i = 0; i < state->info->num_dv_ports; ++i)
> gpiod_set_value_cansleep(state->hpd_gpio[i], hpd & BIT(i));
> - }
>
> v4l2_subdev_notify(&state->sd, ADV7604_HOTPLUG, &hpd);
> }
> @@ -2720,13 +2716,13 @@ static int adv7604_probe(struct i2c_client *client,
> /* Request GPIOs. */
> for (i = 0; i < state->info->num_dv_ports; ++i) {
> state->hpd_gpio[i] =
> - devm_gpiod_get_index(&client->dev, "hpd", i);
> + devm_gpiod_get_index_optional(&client->dev, "hpd", i,
> + GPIOD_OUT_LOW);
> if (IS_ERR(state->hpd_gpio[i]))
> - continue;
> -
> - gpiod_direction_output(state->hpd_gpio[i], 0);
> + return PTR_ERR(state->hpd_gpio[i]);
This isn't correct. The use of gpio is optional, on some boards a different
mechanism is used to control the hpd, and there devm_gpiod_get_index will just
return an error. That's OK, we just continue in that case.
Regards,
Hans
>
> - v4l_info(client, "Handling HPD %u GPIO\n", i);
> + if (state->hpd_gpio[i])
> + v4l_info(client, "Handling HPD %u GPIO\n", i);
> }
>
> state->timings = cea640x480;
>
--
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: adv7604: improve usage of gpiod API
On 03/03/2015 10:55 AM, Hans Verkuil wrote:
> Hi Uwe,
>
> On 03/02/2015 08:00 AM, Uwe Kleine-König wrote:
>> Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
>> which appeared in v3.17-rc1, the gpiod_get* functions take an additional
>> parameter that allows to specify direction and initial value for output.
>> Simplify accordingly.
>>
>> Moreover use devm_gpiod_get_index_optional instead of
>> devm_gpiod_get_index with ignoring all errors.
>>
>> Signed-off-by: Uwe Kleine-König
>> ---
>> BTW, sparse fails to check this file with many errors like:
>>
>> drivers/media/i2c/adv7604.c:311:11: error: unknown field name in
>> initializer
>>
>> Didn't look into that.
>
> That's a sparse bug that's been fixed in the sparse repo, but not in the 0.5.0
> release (they really should make a new sparse release IMHO).
>
> Some comments below:
Never mind those comments, after checking what devm_gpiod_get_index_optional
does it's clear that this patch is correct.
Sorry about the noise.
Hans
>
>> ---
>> drivers/media/i2c/adv7604.c | 16 ++--
>> 1 file changed, 6 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
>> index 5a7c9389a605..ddeeb6695a4b 100644
>> --- a/drivers/media/i2c/adv7604.c
>> +++ b/drivers/media/i2c/adv7604.c
>> @@ -537,12 +537,8 @@ static void adv7604_set_hpd(struct adv7604_state
>> *state, unsigned int hpd)
>> {
>> unsigned int i;
>>
>> -for (i = 0; i < state->info->num_dv_ports; ++i) {
>> -if (IS_ERR(state->hpd_gpio[i]))
>> -continue;
>
> Why this change? See also below:
>
>> -
>> +for (i = 0; i < state->info->num_dv_ports; ++i)
>> gpiod_set_value_cansleep(state->hpd_gpio[i], hpd & BIT(i));
>> -}
>>
>> v4l2_subdev_notify(&state->sd, ADV7604_HOTPLUG, &hpd);
>> }
>> @@ -2720,13 +2716,13 @@ static int adv7604_probe(struct i2c_client *client,
>> /* Request GPIOs. */
>> for (i = 0; i < state->info->num_dv_ports; ++i) {
>> state->hpd_gpio[i] =
>> -devm_gpiod_get_index(&client->dev, "hpd", i);
>> +devm_gpiod_get_index_optional(&client->dev, "hpd", i,
>> + GPIOD_OUT_LOW);
>> if (IS_ERR(state->hpd_gpio[i]))
>> -continue;
>> -
>> -gpiod_direction_output(state->hpd_gpio[i], 0);
>> +return PTR_ERR(state->hpd_gpio[i]);
>
> This isn't correct. The use of gpio is optional, on some boards a different
> mechanism is used to control the hpd, and there devm_gpiod_get_index will just
> return an error. That's OK, we just continue in that case.
>
> Regards,
>
> Hans
>
>>
>> -v4l_info(client, "Handling HPD %u GPIO\n", i);
>> +if (state->hpd_gpio[i])
>> +v4l_info(client, "Handling HPD %u GPIO\n", i);
>> }
>>
>> state->timings = cea640x480;
>>
>
> --
> 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: [PATCH] media: adv7604: improve usage of gpiod API
Hello Hans, On Tue, Mar 03, 2015 at 10:59:22AM +0100, Hans Verkuil wrote: > Never mind those comments, after checking what devm_gpiod_get_index_optional > does it's clear that this patch is correct. > > Sorry about the noise. No problem. Is this an Ack then? Who picks up this patch? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- 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: adv7604: improve usage of gpiod API
On 03/03/2015 11:09 AM, Uwe Kleine-König wrote: > Hello Hans, > > On Tue, Mar 03, 2015 at 10:59:22AM +0100, Hans Verkuil wrote: >> Never mind those comments, after checking what devm_gpiod_get_index_optional >> does it's clear that this patch is correct. >> >> Sorry about the noise. > No problem. Is this an Ack then? Who picks up this patch? I do, I've just accepted it and will post a pull request for v4.1 in a minute. Regards, Hans -- 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 06/15] media: blackfin: bfin_capture: use vb2_fop_mmap/poll
On 02/21/2015 07:39 PM, Lad Prabhakar wrote:
> From: "Lad, Prabhakar"
>
> No need to reinvent the wheel. Just use the already existing
> functions provided by vb2.
>
> Signed-off-by: Lad, Prabhakar
> ---
> drivers/media/platform/blackfin/bfin_capture.c | 28
> +++---
> 1 file changed, 3 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/media/platform/blackfin/bfin_capture.c
> b/drivers/media/platform/blackfin/bfin_capture.c
> index be0d0a2b..ee0e848 100644
> --- a/drivers/media/platform/blackfin/bfin_capture.c
> +++ b/drivers/media/platform/blackfin/bfin_capture.c
> @@ -244,18 +244,6 @@ static int bcap_release(struct file *file)
> return 0;
> }
>
> -static int bcap_mmap(struct file *file, struct vm_area_struct *vma)
> -{
> - struct bcap_device *bcap_dev = video_drvdata(file);
> - int ret;
> -
> - if (mutex_lock_interruptible(&bcap_dev->mutex))
> - return -ERESTARTSYS;
> - ret = vb2_mmap(&bcap_dev->buffer_queue, vma);
> - mutex_unlock(&bcap_dev->mutex);
> - return ret;
> -}
> -
> #ifndef CONFIG_MMU
> static unsigned long bcap_get_unmapped_area(struct file *file,
> unsigned long addr,
> @@ -273,17 +261,6 @@ static unsigned long bcap_get_unmapped_area(struct file
> *file,
This can also be replaced by vb2_fop_get_unmapped_area().
Patch is welcome :-)
Regards,
Hans
--
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
[GIT PULL FOR v4.1] Various fixes/improvements
Hi Mauro, Just a pile of fixes/improvements, nothing that stands out. Regards, Hans The following changes since commit b44b2e06ae463327334235bf160e804632b9b37c: [media] media: i2c: ADV7604: Rename adv7604 prefixes (2015-03-02 16:59:32 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v4.1c for you to fetch changes up to 6e10c830b20252981b3896648fafcec60fb74dc5: media: adv7604: improve usage of gpiod API (2015-03-03 11:01:51 +0100) Fabian Frederick (1): saa7146: replace current->state by set_current_state() Gilles Risch (1): Basic support for the Elgato EyeTV Hybrid INT 2008 USB Stick Hans Verkuil (1): DocBook media: fix typos in YUV420M description Lad, Prabhakar (4): media: au0828: drop vbi_buffer_filled() and re-use buffer_filled() media: drop call to v4l2_device_unregister_subdev() media: i2c: ths7303: drop module param debug media: omap/omap_vout: fix type of input members to omap_vout_setup_vrfb_bufs() Olli Salonen (1): saa7164: free_irq before pci_disable_device Shuah Khan (3): media: au0828 replace printk KERN_DEBUG with pr_debug media: em28xx replace printk in dprintk macros media: au0828 - embed vdev and vbi_dev structs in au0828_dev Simon Farnsworth (1): cx18: Fix bytes_per_line Tapasweni Pathak (1): drivers: media: i2c : s5c73m3: Replace dev_err with pr_err Uwe Kleine-König (1): media: adv7604: improve usage of gpiod API Wei Yongjun (1): v4l2: remove unused including Documentation/DocBook/media/v4l/pixfmt-yuv420m.xml | 4 +-- drivers/media/common/saa7146/saa7146_vbi.c | 4 +-- drivers/media/i2c/adv7343.c| 1 - drivers/media/i2c/adv7604.c| 17 + drivers/media/i2c/mt9v032.c| 1 - drivers/media/i2c/s5c73m3/s5c73m3-spi.c| 2 +- drivers/media/i2c/soc_camera/mt9m111.c | 1 - drivers/media/i2c/ths7303.c| 4 --- drivers/media/i2c/ths8200.c| 1 - drivers/media/i2c/tvp514x.c| 1 - drivers/media/i2c/tvp7002.c| 1 - drivers/media/pci/cx18/cx18-driver.h | 1 + drivers/media/pci/cx18/cx18-ioctl.c| 9 --- drivers/media/pci/saa7164/saa7164-core.c | 4 +-- drivers/media/platform/omap/omap_vout.c| 2 +- drivers/media/platform/omap/omap_vout_vrfb.c | 1 + drivers/media/platform/omap/omap_vout_vrfb.h | 4 +-- drivers/media/platform/soc_camera/sh_mobile_csi2.c | 1 - drivers/media/usb/au0828/au0828-video.c| 100 ++--- drivers/media/usb/au0828/au0828.h | 6 ++--- drivers/media/usb/em28xx/em28xx-audio.c| 3 +-- drivers/media/usb/em28xx/em28xx-cards.c| 13 +- drivers/media/usb/em28xx/em28xx-dvb.c | 3 ++- drivers/media/usb/em28xx/em28xx-input.c| 2 +- drivers/media/usb/em28xx/em28xx.h | 1 + drivers/media/usb/pvrusb2/pvrusb2-v4l2.c | 1 - 26 files changed, 80 insertions(+), 108 deletions(-) -- 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
[GIT PULL FOR v4.1] Blackfin cleanups
Hi Mauro, This pull request improves the blackfin driver. Regards, Hans The following changes since commit b44b2e06ae463327334235bf160e804632b9b37c: [media] media: i2c: ADV7604: Rename adv7604 prefixes (2015-03-02 16:59:32 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v4.1d for you to fetch changes up to 7686f35fec9745fd9e4fe0c7bff6ba468e742047: media: blackfin: bfin_capture: set v4l2 buffer sequence (2015-03-03 11:07:26 +0100) Lad, Prabhakar (15): media: blackfin: bfin_capture: drop buf_init() callback media: blackfin: bfin_capture: release buffers in case start_streaming() call back fails media: blackfin: bfin_capture: set min_buffers_needed media: blackfin: bfin_capture: improve buf_prepare() callback media: blackfin: bfin_capture: improve queue_setup() callback media: blackfin: bfin_capture: use vb2_fop_mmap/poll media: blackfin: bfin_capture: use v4l2_fh_open and vb2_fop_release media: blackfin: bfin_capture: use vb2_ioctl_* helpers media: blackfin: bfin_capture: make sure all buffers are returned on stop_streaming() callback media: blackfin: bfin_capture: return -ENODATA for *std calls media: blackfin: bfin_capture: return -ENODATA for *dv_timings calls media: blackfin: bfin_capture: add support for vidioc_create_bufs media: blackfin: bfin_capture: add support for VB2_DMABUF media: blackfin: bfin_capture: add support for VIDIOC_EXPBUF media: blackfin: bfin_capture: set v4l2 buffer sequence drivers/media/platform/blackfin/bfin_capture.c | 306 - 1 file changed, 94 insertions(+), 212 deletions(-) -- 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/10] ARM: orion: use clkdev_create()
Dear Russell King,
On Mon, 02 Mar 2015 17:06:42 +, Russell King wrote:
> clkdev_create() is a shorter way to write clkdev_alloc() followed by
> clkdev_add(). Use this instead.
>
> Signed-off-by: Russell King
> ---
> arch/arm/plat-orion/common.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/arch/arm/plat-orion/common.c b/arch/arm/plat-orion/common.c
> index f5b00f41c4f6..2235081a04ee 100644
> --- a/arch/arm/plat-orion/common.c
> +++ b/arch/arm/plat-orion/common.c
> @@ -28,11 +28,7 @@
> void __init orion_clkdev_add(const char *con_id, const char *dev_id,
>struct clk *clk)
> {
> - struct clk_lookup *cl;
> -
> - cl = clkdev_alloc(clk, con_id, dev_id);
> - if (cl)
> - clkdev_add(cl);
> + clkdev_create(clk, con_id, "%s", dev_id);
> }
>
> /* Create clkdev entries for all orion platforms except kirkwood.
Looks good, but instead of having orion_clkdev_add() being just an
alias for clkdev_create(), what about going ahead and simply reoving
orion_clkdev_add() entirely? Something like the below patch (not even
compile tested) :
diff --git a/arch/arm/mach-dove/common.c b/arch/arm/mach-dove/common.c
index 0d1a892..ec00183 100644
--- a/arch/arm/mach-dove/common.c
+++ b/arch/arm/mach-dove/common.c
@@ -109,28 +109,28 @@ static void __init dove_clk_init(void)
gephy = dove_register_gate("gephy", "tclk", CLOCK_GATING_BIT_GIGA_PHY);
ge = dove_register_gate("ge", "gephy", CLOCK_GATING_BIT_GBE);
- orion_clkdev_add(NULL, "orion_spi.0", tclk);
- orion_clkdev_add(NULL, "orion_spi.1", tclk);
- orion_clkdev_add(NULL, "orion_wdt", tclk);
- orion_clkdev_add(NULL, "mv64xxx_i2c.0", tclk);
-
- orion_clkdev_add(NULL, "orion-ehci.0", usb0);
- orion_clkdev_add(NULL, "orion-ehci.1", usb1);
- orion_clkdev_add(NULL, "mv643xx_eth_port.0", ge);
- orion_clkdev_add(NULL, "sata_mv.0", sata);
- orion_clkdev_add("0", "pcie", pex0);
- orion_clkdev_add("1", "pcie", pex1);
- orion_clkdev_add(NULL, "sdhci-dove.0", sdio0);
- orion_clkdev_add(NULL, "sdhci-dove.1", sdio1);
- orion_clkdev_add(NULL, "orion_nand", nand);
- orion_clkdev_add(NULL, "cafe1000-ccic.0", camera);
- orion_clkdev_add(NULL, "mvebu-audio.0", i2s0);
- orion_clkdev_add(NULL, "mvebu-audio.1", i2s1);
- orion_clkdev_add(NULL, "mv_crypto", crypto);
- orion_clkdev_add(NULL, "dove-ac97", ac97);
- orion_clkdev_add(NULL, "dove-pdma", pdma);
- orion_clkdev_add(NULL, MV_XOR_NAME ".0", xor0);
- orion_clkdev_add(NULL, MV_XOR_NAME ".1", xor1);
+ clkdev_create(tclk, NULL, "%s", "orion_spi.0");
+ clkdev_create(tclk, NULL, "%s", "orion_spi.1");
+ clkdev_create(tclk, NULL, "%s", "orion_wdt");
+ clkdev_create(tclk, NULL, "%s", "mv64xxx_i2c.0");
+
+ clkdev_create(usb0, NULL, "%s", "orion-ehci.0");
+ clkdev_create(usb1, NULL, "%s", "orion-ehci.1");
+ clkdev_create(ge, NULL, "%s", "mv643xx_eth_port.0");
+ clkdev_create(sata, NULL, "%s", "sata_mv.0");
+ clkdev_create(pex0, "0", "%s", "pcie");
+ clkdev_create(pex1, "1", "%s", "pcie");
+ clkdev_create(sdio0, NULL, "%s", "sdhci-dove.0");
+ clkdev_create(sdio1, NULL, "%s", "sdhci-dove.1");
+ clkdev_create(nand, NULL, "%s", "orion_nand");
+ clkdev_create(camera, NULL, "%s", "cafe1000-ccic.0");
+ clkdev_create(i2s0, NULL, "%s", "mvebu-audio.0");
+ clkdev_create(i2s1, NULL, "%s", "mvebu-audio.1");
+ clkdev_create(crypto, NULL, "%s", "mv_crypto");
+ clkdev_create(ac97, NULL, "%s", "dove-ac97");
+ clkdev_create(pdma, NULL, "%s", "dove-pdma");
+ clkdev_create(xor0, NULL, "%s", MV_XOR_NAME ".0");
+ clkdev_create(xor1, NULL, "%s", MV_XOR_NAME ".1");
}
/*
diff --git a/arch/arm/plat-orion/common.c b/arch/arm/plat-orion/common.c
index f5b00f4..6ac3549 100644
--- a/arch/arm/plat-orion/common.c
+++ b/arch/arm/plat-orion/common.c
@@ -24,31 +24,20 @@
#include
#include
-/* Create a clkdev entry for a given device/clk */
-void __init orion_clkdev_add(const char *con_id, const char *dev_id,
-struct clk *clk)
-{
- struct clk_lookup *cl;
-
- cl = clkdev_alloc(clk, con_id, dev_id);
- if (cl)
- clkdev_add(cl);
-}
-
/* Create clkdev entries for all orion platforms except kirkwood.
Kirkwood has gated clocks for some of its peripherals, so creates
its own clkdev entries. For all the other orion devices, create
clkdev entries to the tclk. */
void __init orion_clkdev_init(struct clk *tclk)
{
- orion_clkdev_add(NULL, "orion_spi.0", tclk);
- orion_clkdev_add(NULL, "orion_spi.1", tclk);
- orion_clkdev_add(NULL, MV643XX_ETH_NAME ".0", tclk);
- orion_clkdev_add(NULL, MV643XX_ETH_NAME ".1", tclk);
- orion_clkdev_add(NULL, MV643XX_ETH_NAME ".2
[PATCH] vb2: check if vb2_fop_write/read is allowed
Return -EINVAL if read() or write() is not supported by the queue. This makes it possible to provide both vb2_fop_read and vb2_fop_write in a struct v4l2_file_operations since the vb2_fop_* function will check if the file operation is allowed. A similar check exists in __vb2_init_fileio() which is called from __vb2_perform_fileio(), but that check is only done if no file I/O is active. So the sequence of read() followed by write() would be allowed, which is obviously a bug. In addition, vb2_fop_write/read should always return -EINVAL if the operation is not allowed, and by putting the check in the lower levels of the code it is possible that other error codes are returned (EBUSY or ERESTARTSYS). All these issues are avoided by just doing a quick explicit check. Signed-off-by: Hans Verkuil diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c index bc08a82..167c1d9 100644 --- a/drivers/media/v4l2-core/videobuf2-core.c +++ b/drivers/media/v4l2-core/videobuf2-core.c @@ -3416,6 +3416,8 @@ ssize_t vb2_fop_write(struct file *file, const char __user *buf, struct mutex *lock = vdev->queue->lock ? vdev->queue->lock : vdev->lock; int err = -EBUSY; + if (!(vdev->queue->io_modes & VB2_WRITE)) + return -EINVAL; if (lock && mutex_lock_interruptible(lock)) return -ERESTARTSYS; if (vb2_queue_is_busy(vdev, file)) @@ -3438,6 +3440,8 @@ ssize_t vb2_fop_read(struct file *file, char __user *buf, struct mutex *lock = vdev->queue->lock ? vdev->queue->lock : vdev->lock; int err = -EBUSY; + if (!(vdev->queue->io_modes & VB2_READ)) + return -EINVAL; if (lock && mutex_lock_interruptible(lock)) return -ERESTARTSYS; if (vb2_queue_is_busy(vdev, file)) -- 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 v5 6/8] v4l: xilinx: Add Xilinx Video IP core
Hi Laurent,
Thanks for this patch. I do have a few comments, see below. Note that I am
OK with the new DT format description.
On 03/02/2015 02:48 AM, Laurent Pinchart wrote:
> Xilinx platforms have no hardwired video capture or video processing
> interface. Users create capture and memory to memory processing
> pipelines in the FPGA fabric to suit their particular needs, by
> instantiating video IP cores from a large library.
>
> The Xilinx Video IP core is a framework that models a video pipeline
> described in the device tree and expose the pipeline to userspace
> through the media controller and V4L2 APIs.
>
> Signed-off-by: Laurent Pinchart
> Signed-off-by: Hyun Kwon
> Signed-off-by: Radhey Shyam Pandey
> Signed-off-by: Michal Simek
>
> ---
> diff --git a/drivers/media/platform/xilinx/xilinx-dma.c
> b/drivers/media/platform/xilinx/xilinx-dma.c
> new file mode 100644
> index 000..afed6c3
> --- /dev/null
> +++ b/drivers/media/platform/xilinx/xilinx-dma.c
> @@ -0,0 +1,753 @@
> +/*
> + * Xilinx Video DMA
> + *
> + * Copyright (C) 2013-2014 Ideas on Board
> + * Copyright (C) 2013-2014 Xilinx, Inc.
> + *
> + * Contacts: Hyun Kwon
> + * Laurent Pinchart
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "xilinx-dma.h"
> +#include "xilinx-vip.h"
> +#include "xilinx-vipp.h"
> +
> +#define XVIP_DMA_DEF_FORMAT V4L2_PIX_FMT_YUYV
> +#define XVIP_DMA_DEF_WIDTH 1920
> +#define XVIP_DMA_DEF_HEIGHT 1080
> +
> +/* Minimum and maximum widths are expressed in bytes */
> +#define XVIP_DMA_MIN_WIDTH 1U
> +#define XVIP_DMA_MAX_WIDTH 65535U
> +#define XVIP_DMA_MIN_HEIGHT 1U
> +#define XVIP_DMA_MAX_HEIGHT 8191U
> +
> +/*
> -
> + * Helper functions
> + */
> +
> +static struct v4l2_subdev *
> +xvip_dma_remote_subdev(struct media_pad *local, u32 *pad)
> +{
> + struct media_pad *remote;
> +
> + remote = media_entity_remote_pad(local);
> + if (remote == NULL ||
> + media_entity_type(remote->entity) != MEDIA_ENT_T_V4L2_SUBDEV)
> + return NULL;
> +
> + if (pad)
> + *pad = remote->index;
> +
> + return media_entity_to_v4l2_subdev(remote->entity);
> +}
> +
> +static int xvip_dma_verify_format(struct xvip_dma *dma)
> +{
> + struct v4l2_subdev_format fmt;
> + struct v4l2_subdev *subdev;
> + int ret;
> +
> + subdev = xvip_dma_remote_subdev(&dma->pad, &fmt.pad);
> + if (subdev == NULL)
> + return -EPIPE;
> +
> + fmt.which = V4L2_SUBDEV_FORMAT_ACTIVE;
> + ret = v4l2_subdev_call(subdev, pad, get_fmt, NULL, &fmt);
> + if (ret < 0)
> + return ret == -ENOIOCTLCMD ? -EINVAL : ret;
> +
> + if (dma->fmtinfo->code != fmt.format.code ||
> + dma->format.height != fmt.format.height ||
> + dma->format.width != fmt.format.width ||
> + dma->format.colorspace != fmt.format.colorspace)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +/*
> -
> + * Pipeline Stream Management
> + */
> +
> +/**
> + * xvip_pipeline_start_stop - Start ot stop streaming on a pipeline
> + * @pipe: The pipeline
> + * @start: Start (when true) or stop (when false) the pipeline
> + *
> + * Walk the entities chain starting at the pipeline output video node and
> start
> + * or stop all of them.
> + *
> + * Return: 0 if successful, or the return value of the failed video::s_stream
> + * operation otherwise.
> + */
> +static int xvip_pipeline_start_stop(struct xvip_pipeline *pipe, bool start)
> +{
> + struct xvip_dma *dma = pipe->output;
> + struct media_entity *entity;
> + struct media_pad *pad;
> + struct v4l2_subdev *subdev;
> + int ret;
> +
> + entity = &dma->video.entity;
> + while (1) {
> + pad = &entity->pads[0];
> + if (!(pad->flags & MEDIA_PAD_FL_SINK))
> + break;
> +
> + pad = media_entity_remote_pad(pad);
> + if (pad == NULL ||
> + media_entity_type(pad->entity) != MEDIA_ENT_T_V4L2_SUBDEV)
> + break;
> +
> + entity = pad->entity;
> + subdev = media_entity_to_v4l2_subdev(entity);
> +
> + ret = v4l2_subdev_call(subdev, video, s_stream, start);
> + if (start && ret < 0 && ret != -ENOIOCTLCMD)
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +/**
> + * xvip_pipeline_set_stream - Enable/disable streaming on a pipeline
> + * @pipe: The pipeline
> + * @on: Turn t
Re: PCTV 800i
>> I have a pair of 800i's with the S5H1409 demodulator, probably from >> when I did the original 800i support (2008): >> http://marc.info/?l=linux-dvb&m=120032380226094&w=2 >> >> I don't have a 800i with a s5h1411, so I can't really help without it. >> > Dear John and Steven, > > Back in 2012 I twice submitted a patch that got my pctv 800i with an s5h1411 > working. Both times > either my email or something along the way wrapped lines and spoiled the > patch for testing. I've > patched several kernels since then, but not any very recently. I just > checked and that machine is running > Fedora 3.14.4-200.fc20.x86_64. > > I've attached what I believe is the patch I made then. Since then, I've just > edited the v4l source > whenever and built a modified module whenever I upgraded. I put instructions > on fedora forum back > then: http://forums.fedoraforum.org/showthread.php?t=281161 > > I hope this helps. Mack, thanks. I've seen this patch in the past. Its perfect for end users who only need to support the newer board, but isn't too helpful for the kernel as it disables support for the prior board. What the kernel needs is a single patch that (probably) reads the card eeprom and deterministically attaches the correct demodulator for the hardware, so users can mix'n'match old and new cards. If the eeprom doesn't help then we'll need to figure something else out. It's on my todo-list at somepoint. I traded a card with John a few weeks ago so I have everything I need to make it happen, other than time! Thanks again, - Steve -- Steven Toth - Kernel Labs http://www.kernellabs.com -- 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: [PATCHv2] Si2168: increase timeout to fix firmware loading
On Thu, Feb 26, 2015 at 11:41:54PM +0200, Antti Palosaari wrote:
> From: Jurgen Kramer
>
> Increase si2168 cmd execute timeout to prevent firmware load failures. Tests
> shows it takes up to 52ms to load the 'dvb-demod-si2168-a30-01.fw' firmware.
> Increase timeout to a safe value of 70ms.
>
> Cc: # v3.16+
> Signed-off-by: Jurgen Kramer
> Reviewed-by: Antti Palosaari
> Signed-off-by: Antti Palosaari
> ---
> Changes since v1:
> * I added my SOB
>
> Patch for stable 3.16+
>
> That patch is already applied to master as commit
> 551c33e729f654ecfaed00ad399f5d2a631b72cb
> There was some mistake and Cc stable tag I added to patchwork [1] was lost.
>
Thank you Antti, I'll queue this for the 3.16 kernel.
Cheers,
--
Luís
> [1] https://patchwork.linuxtv.org/patch/27382/
> ---
> drivers/media/dvb-frontends/si2168.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/dvb-frontends/si2168.c
> b/drivers/media/dvb-frontends/si2168.c
> index 2e3cdcf..fbc1fa8 100644
> --- a/drivers/media/dvb-frontends/si2168.c
> +++ b/drivers/media/dvb-frontends/si2168.c
> @@ -39,7 +39,7 @@ static int si2168_cmd_execute(struct si2168 *s, struct
> si2168_cmd *cmd)
>
> if (cmd->rlen) {
> /* wait cmd execution terminate */
> - #define TIMEOUT 50
> + #define TIMEOUT 70
> timeout = jiffies + msecs_to_jiffies(TIMEOUT);
> while (!time_after(jiffies, timeout)) {
> ret = i2c_master_recv(s->client, cmd->args, cmd->rlen);
> --
> http://palosaari.fi/
>
> --
> To unsubscribe from this list: send the line "unsubscribe stable" 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: [PATCH v3 05/15] media: blackfin: bfin_capture: improve queue_setup() callback
Lad,
Em Sat, 21 Feb 2015 18:39:51 +
Lad Prabhakar escreveu:
> From: "Lad, Prabhakar"
>
> this patch improves the queue_setup() callback.
Please improve your comments. The above description doesn't tell
anything that it wasn't said before at the patch subject.
It "improves" how? Why?
Please fix the comments and resubmit this patch series.
Thanks,
Mauro
>
> Signed-off-by: Lad, Prabhakar
> ---
> drivers/media/platform/blackfin/bfin_capture.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/platform/blackfin/bfin_capture.c
> b/drivers/media/platform/blackfin/bfin_capture.c
> index 8f62a84..be0d0a2b 100644
> --- a/drivers/media/platform/blackfin/bfin_capture.c
> +++ b/drivers/media/platform/blackfin/bfin_capture.c
> @@ -44,7 +44,6 @@
> #include
>
> #define CAPTURE_DRV_NAME"bfin_capture"
> -#define BCAP_MIN_NUM_BUF2
>
> struct bcap_format {
> char *desc;
> @@ -292,11 +291,14 @@ static int bcap_queue_setup(struct vb2_queue *vq,
> {
> struct bcap_device *bcap_dev = vb2_get_drv_priv(vq);
>
> - if (*nbuffers < BCAP_MIN_NUM_BUF)
> - *nbuffers = BCAP_MIN_NUM_BUF;
> + if (fmt && fmt->fmt.pix.sizeimage < bcap_dev->fmt.sizeimage)
> + return -EINVAL;
> +
> + if (vq->num_buffers + *nbuffers < 2)
> + *nbuffers = 2;
>
> *nplanes = 1;
> - sizes[0] = bcap_dev->fmt.sizeimage;
> + sizes[0] = fmt ? fmt->fmt.pix.sizeimage : bcap_dev->fmt.sizeimage;
> alloc_ctxs[0] = bcap_dev->alloc_ctx;
>
> return 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
[PATCH] staging: media: omap4iss: video: Don't WARN() on unknown pixel formats
When mapping from a V4L2 pixel format to a media bus format in the
VIDIOC_TRY_FMT and VIDIOC_S_FMT handlers, the requested format may be
unsupported by the driver. Return a hardcoded default format instead of
WARN()ing in that case.
Signed-off-by: Laurent Pinchart
---
drivers/staging/media/omap4iss/iss_video.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/media/omap4iss/iss_video.c
b/drivers/staging/media/omap4iss/iss_video.c
index 6955044..e949b6f 100644
--- a/drivers/staging/media/omap4iss/iss_video.c
+++ b/drivers/staging/media/omap4iss/iss_video.c
@@ -171,14 +171,14 @@ static void iss_video_pix_to_mbus(const struct
v4l2_pix_format *pix,
mbus->width = pix->width;
mbus->height = pix->height;
- for (i = 0; i < ARRAY_SIZE(formats); ++i) {
+ /* Skip the last format in the loop so that it will be selected if no
+* match is found.
+*/
+ for (i = 0; i < ARRAY_SIZE(formats) - 1; ++i) {
if (formats[i].pixelformat == pix->pixelformat)
break;
}
- if (WARN_ON(i == ARRAY_SIZE(formats)))
- return;
-
mbus->code = formats[i].code;
mbus->colorspace = pix->colorspace;
mbus->field = pix->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
Re: [GIT PULL FOR v4.1] Various fixes/improvements
Em Tue, 03 Mar 2015 11:17:10 +0100 Hans Verkuil escreveu: > Hi Mauro, > > Just a pile of fixes/improvements, nothing that stands out. > > Regards, > > Hans > > The following changes since commit b44b2e06ae463327334235bf160e804632b9b37c: > > [media] media: i2c: ADV7604: Rename adv7604 prefixes (2015-03-02 16:59:32 > -0300) > > are available in the git repository at: > > git://linuxtv.org/hverkuil/media_tree.git for-v4.1c > > for you to fetch changes up to 6e10c830b20252981b3896648fafcec60fb74dc5: > > media: adv7604: improve usage of gpiod API (2015-03-03 11:01:51 +0100) > > > Fabian Frederick (1): > saa7146: replace current->state by set_current_state() > > Gilles Risch (1): > Basic support for the Elgato EyeTV Hybrid INT 2008 USB Stick > > Hans Verkuil (1): > DocBook media: fix typos in YUV420M description > > Lad, Prabhakar (4): > media: au0828: drop vbi_buffer_filled() and re-use buffer_filled() > media: drop call to v4l2_device_unregister_subdev() > media: i2c: ths7303: drop module param debug > media: omap/omap_vout: fix type of input members to > omap_vout_setup_vrfb_bufs() > > Olli Salonen (1): > saa7164: free_irq before pci_disable_device > > Shuah Khan (3): > media: au0828 replace printk KERN_DEBUG with pr_debug > media: em28xx replace printk in dprintk macros I nacked the two above patches, as it requires to both pass a modprobe parameter to the driver and to enable the dynamic printks. We should either use one way or the other (or to use a better solution as Joe Perches is proposing). The rest of this pull request is OK and got merged. > media: au0828 - embed vdev and vbi_dev structs in au0828_dev > > Simon Farnsworth (1): > cx18: Fix bytes_per_line > > Tapasweni Pathak (1): > drivers: media: i2c : s5c73m3: Replace dev_err with pr_err > > Uwe Kleine-König (1): > media: adv7604: improve usage of gpiod API > > Wei Yongjun (1): > v4l2: remove unused including > > Documentation/DocBook/media/v4l/pixfmt-yuv420m.xml | 4 +-- > drivers/media/common/saa7146/saa7146_vbi.c | 4 +-- > drivers/media/i2c/adv7343.c| 1 - > drivers/media/i2c/adv7604.c| 17 + > drivers/media/i2c/mt9v032.c| 1 - > drivers/media/i2c/s5c73m3/s5c73m3-spi.c| 2 +- > drivers/media/i2c/soc_camera/mt9m111.c | 1 - > drivers/media/i2c/ths7303.c| 4 --- > drivers/media/i2c/ths8200.c| 1 - > drivers/media/i2c/tvp514x.c| 1 - > drivers/media/i2c/tvp7002.c| 1 - > drivers/media/pci/cx18/cx18-driver.h | 1 + > drivers/media/pci/cx18/cx18-ioctl.c| 9 --- > drivers/media/pci/saa7164/saa7164-core.c | 4 +-- > drivers/media/platform/omap/omap_vout.c| 2 +- > drivers/media/platform/omap/omap_vout_vrfb.c | 1 + > drivers/media/platform/omap/omap_vout_vrfb.h | 4 +-- > drivers/media/platform/soc_camera/sh_mobile_csi2.c | 1 - > drivers/media/usb/au0828/au0828-video.c| 100 > ++--- > drivers/media/usb/au0828/au0828.h | 6 ++--- > drivers/media/usb/em28xx/em28xx-audio.c| 3 +-- > drivers/media/usb/em28xx/em28xx-cards.c| 13 +- > drivers/media/usb/em28xx/em28xx-dvb.c | 3 ++- > drivers/media/usb/em28xx/em28xx-input.c| 2 +- > drivers/media/usb/em28xx/em28xx.h | 1 + > drivers/media/usb/pvrusb2/pvrusb2-v4l2.c | 1 - > 26 files changed, 80 insertions(+), 108 deletions(-) > -- > 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
[PATCH] s5p-mfc: Fix NULL pointer dereference caused by not set q->lock
The patch "media: s5p-mfc: use vb2_ops_wait_prepare/finish helper"
(654a731be1a0b6f606f3f3d12b50db08f2ae3c3) introduced a kernel panic.
The q->lock was set for just one queue, the other was not set thus causing
a NULL pointer dereference.
Reported-by: Marek Szyprowski
Signed-off-by: Kamil Debski
---
drivers/media/platform/s5p-mfc/s5p_mfc.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 9fe4d90..8333fbc 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -833,6 +833,7 @@ static int s5p_mfc_open(struct file *file)
q->type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE;
q->io_modes = VB2_MMAP;
q->drv_priv = &ctx->fh;
+ q->lock = &dev->mfc_mutex;
if (vdev == dev->vfd_dec) {
q->io_modes = VB2_MMAP;
q->ops = get_dec_queue_ops();
--
1.7.9.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
RE: [PATCH] media: i2c: s5c73m3: make sure we destroy the mutex
From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Tuesday, March 03, 2015 10:09 AM > > On 03/02/2015 04:00 PM, Lad Prabhakar wrote: > > From: "Lad, Prabhakar" > > > > Make sure to call mutex_destroy() in case of probe failure or module > > unload. > > It's not actually necessary to destroy a mutex. Most drivers never do > this. > It only helps a bit in debugging. > > I'll delegate this patch to Kamil, and he can decide whether or not to > apply this. I agree with Hans here, the patch is not necessary. > > Regards, > > Hans > Best wishes, -- Kamil Debski Samsung R&D Institute Poland > > > > Signed-off-by: Lad, Prabhakar > > --- > > drivers/media/i2c/s5c73m3/s5c73m3-core.c | 5 - > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/media/i2c/s5c73m3/s5c73m3-core.c > > b/drivers/media/i2c/s5c73m3/s5c73m3-core.c > > index ee0f57e..da0b3a3 100644 > > --- a/drivers/media/i2c/s5c73m3/s5c73m3-core.c > > +++ b/drivers/media/i2c/s5c73m3/s5c73m3-core.c > > @@ -1658,7 +1658,6 @@ static int s5c73m3_probe(struct i2c_client > *client, > > if (ret < 0) > > return ret; > > > > - mutex_init(&state->lock); > > sd = &state->sensor_sd; > > oif_sd = &state->oif_sd; > > > > @@ -1695,6 +1694,8 @@ static int s5c73m3_probe(struct i2c_client > *client, > > if (ret < 0) > > return ret; > > > > + mutex_init(&state->lock); > > + > > ret = s5c73m3_configure_gpios(state); > > if (ret) > > goto out_err; > > @@ -1754,6 +1755,7 @@ out_err1: > > s5c73m3_unregister_spi_driver(state); > > out_err: > > media_entity_cleanup(&sd->entity); > > + mutex_destroy(&state->lock); > > return ret; > > } > > > > @@ -1772,6 +1774,7 @@ static int s5c73m3_remove(struct i2c_client > *client) > > media_entity_cleanup(&sensor_sd->entity); > > > > s5c73m3_unregister_spi_driver(state); > > + mutex_destroy(&state->lock); > > > > return 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 v3 04/15] media: blackfin: bfin_capture: improve buf_prepare() callback
On 02/21/2015 07:39 PM, Lad Prabhakar wrote:
> From: "Lad, Prabhakar"
>
> this patch improves the buf_prepare() callback.
>
> Signed-off-by: Lad, Prabhakar
> ---
> drivers/media/platform/blackfin/bfin_capture.c | 12
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/media/platform/blackfin/bfin_capture.c
> b/drivers/media/platform/blackfin/bfin_capture.c
> index 332f8c9..8f62a84 100644
> --- a/drivers/media/platform/blackfin/bfin_capture.c
> +++ b/drivers/media/platform/blackfin/bfin_capture.c
> @@ -305,16 +305,12 @@ static int bcap_queue_setup(struct vb2_queue *vq,
> static int bcap_buffer_prepare(struct vb2_buffer *vb)
> {
> struct bcap_device *bcap_dev = vb2_get_drv_priv(vb->vb2_queue);
> - struct bcap_buffer *buf = to_bcap_vb(vb);
> - unsigned long size;
>
> - size = bcap_dev->fmt.sizeimage;
> - if (vb2_plane_size(vb, 0) < size) {
> - v4l2_err(&bcap_dev->v4l2_dev, "buffer too small (%lu < %lu)\n",
> - vb2_plane_size(vb, 0), size);
I would keep this error. Since you need to update patches 4 & 5 anyway to
improve the commit message, it's probably good to reinstate this.
Regards,
Hans
> + vb2_set_plane_payload(vb, 0, bcap_dev->fmt.sizeimage);
> + if (vb2_get_plane_payload(vb, 0) > vb2_plane_size(vb, 0))
> return -EINVAL;
> - }
> - vb2_set_plane_payload(&buf->vb, 0, size);
> +
> + vb->v4l2_buf.field = bcap_dev->fmt.field;
>
> return 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] s5p-jpeg: Fix possible NULL pointer dereference in s_fmt
Hi Jacek,
On 28/11/14 14:10, Jacek Anaszewski wrote:
> Some formats are not supported in encoding or decoding
> mode for given type of buffer (e.g. V4L2_PIX_FMT_JPEG
> is supported on output buffer only while in decoding
> mode). Make S_FMT failing if not suitable format
> is found.
>
> Signed-off-by: Jacek Anaszewski
> ---
> drivers/media/platform/s5p-jpeg/jpeg-core.c |8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c
> b/drivers/media/platform/s5p-jpeg/jpeg-core.c
> index d7571cd..dfab848 100644
> --- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
> +++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
> @@ -1345,6 +1345,14 @@ static int s5p_jpeg_s_fmt(struct s5p_jpeg_ctx *ct,
> struct v4l2_format *f)
> FMT_TYPE_OUTPUT : FMT_TYPE_CAPTURE;
>
> q_data->fmt = s5p_jpeg_find_format(ct, pix->pixelformat, f_type);
> +
> + if (!q_data->fmt) {
> + v4l2_err(&ct->jpeg->v4l2_dev,
> + "Fourcc format (0x%08x) invalid.\n",
> + f->fmt.pix.pixelformat);
> + return -EINVAL;
> + }
> +
How about forcing one of valid formats instead ? VIDIOC_S_FMT is not
supposed to return an error just because a not supported fourcc
was passed from user space.
--
Thanks,
Sylwester
--
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/10] initial clkdev cleanups
On Mon, 2015-03-02 at 13:50 -0800, Stephen Boyd wrote: > On 03/02/15 09:05, Russell King - ARM Linux wrote: > > Here's some initial clkdev cleanups. These are targetted for the next > > merge window, and while the initial patches can be merged independently, > > I'd prefer to keep the series together as further work on solving the > > problems which unique struct clk's has introduced is needed. > > I'm also killing a chunk of seemingly unused code in the omap3isp driver. > > > > Lastly, I'm introducing a clkdev_create() helper, which combines the > > clkdev_alloc() + clkdev_add() pattern which keeps cropping up. > > > > We already have a solution to that problem with clk_register_clkdev(). > Andy has done some work to make clk_register_clkdev() return a struct > clk_lookup pointer[1]. Maybe we can do that instead of introducing a new > clkdev_create() function. There is some benefit to having a new function > though so that we can avoid a flag day, although it looks like the flag > day is small in this case so it might not actually matter. > [1] https://www.marc.info/?l=linux-kernel&m=142469226512289 Agree with Stephen, why should we have the second function doing the same? Just name changing? I think you may just incorporate that patch into your series. -- Andy Shevchenko Intel Finland Oy -- 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
[GIT PULL FOR v4.1] v4l2-subdev: removal of duplicate video enum ops
Hi Mauro, This patch series prepares for the removal of duplicate video enum ops. See this post for the background for this series: http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/87869 The patches in this pull request are the same as the posted series, except for being rebased and with patch 6/7 being dropped. This patch is found here: https://patchwork.linuxtv.org/patch/28220/ The reason for dropping it is that I don't have an Ack from Jon Corbet yet. I'm trying to test it myself, at least on my OLPC laptop, but that's painful and takes longer than I hoped. So I don't want to wait for that and I am posting the other patches now. Laurent needs these patches as well so he can rebase his xilinx driver on top of it. Patch 6/7 will be posted in a later pull request, once I (or Jon) managed to test it. Regards, Hans The following changes since commit 269bd1324fbfaa52832bb3efe9f5105c9146a33a: [media] media: adv7604: improve usage of gpiod API (2015-03-03 11:26:40 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v4.1e for you to fetch changes up to 95d3a905e017568456fa1ec3fd7833987bc9edd3: DocBook media: document the new 'which' field. (2015-03-03 16:48:26 +0100) Hans Verkuil (6): v4l2-subdev: replace v4l2_subdev_fh by v4l2_subdev_pad_config v4l2-subdev.h: add 'which' field for the enum structs v4l2-subdev.c: add 'which' checks for enum ops. v4l2-subdev: support new 'which' field in enum_mbus_code v4l2-subdev: add support for the new enum_frame_size 'which' field. DocBook media: document the new 'which' field. Documentation/DocBook/media/v4l/vidioc-subdev-enum-frame-interval.xml | 13 ++--- Documentation/DocBook/media/v4l/vidioc-subdev-enum-frame-size.xml | 13 ++--- Documentation/DocBook/media/v4l/vidioc-subdev-enum-mbus-code.xml | 11 +-- drivers/media/i2c/adv7180.c | 10 +++ drivers/media/i2c/adv7511.c | 16 ++- drivers/media/i2c/adv7604.c | 12 drivers/media/i2c/m5mols/m5mols_core.c| 16 +-- drivers/media/i2c/mt9m032.c | 34 +++--- drivers/media/i2c/mt9p031.c | 36 +++ drivers/media/i2c/mt9t001.c | 36 +++ drivers/media/i2c/mt9v032.c | 36 +++ drivers/media/i2c/noon010pc30.c | 17 +-- drivers/media/i2c/ov9650.c| 16 +-- drivers/media/i2c/s5c73m3/s5c73m3-core.c | 72 -- drivers/media/i2c/s5k4ecgx.c | 16 +-- drivers/media/i2c/s5k5baf.c | 38 drivers/media/i2c/s5k6a3.c| 18 ++-- drivers/media/i2c/s5k6aa.c| 34 +++--- drivers/media/i2c/smiapp/smiapp-core.c| 80 +-- drivers/media/i2c/tvp514x.c | 12 drivers/media/i2c/tvp7002.c | 14 - drivers/media/platform/exynos4-is/fimc-capture.c | 22 +++--- drivers/media/platform/exynos4-is/fimc-isp.c | 28 +- drivers/media/platform/exynos4-is/fimc-lite.c | 33 ++--- drivers/media/platform/exynos4-is/mipi-csis.c | 16 +-- drivers/media/platform/omap3isp/ispccdc.c | 86 +++ drivers/media/platform/omap3isp/ispccp2.c | 46 ++--- drivers/media/platform/omap3isp/ispcsi2.c | 42 +-- drivers/media/platform/omap3isp/isppreview.c | 70 ++-- drivers/media/platform/omap3isp/ispresizer.c | 80 +-- drivers/media/platform/s3c-camif/camif-capture.c | 18 ++-- drivers/media/platform/vsp1/vsp1_bru.c| 42 ++- drivers/media/platform/vsp1/vsp1_entity.c | 16 +-- drivers/media/
[PATCH] si2157: extend frequency range for ATSC
The Si2157 tuner supports ATSC in addition to DVB-T and DVB-C. Extend
minimum frequency range to cover the complete ATSC/QAM-B range.
Signed-off-by: Olli Salonen
---
drivers/media/tuners/si2157.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/tuners/si2157.c b/drivers/media/tuners/si2157.c
index d8309b9..d74ae26 100644
--- a/drivers/media/tuners/si2157.c
+++ b/drivers/media/tuners/si2157.c
@@ -349,7 +349,7 @@ static int si2157_get_if_frequency(struct dvb_frontend *fe,
u32 *frequency)
static const struct dvb_tuner_ops si2157_ops = {
.info = {
.name = "Silicon Labs Si2146/2147/2148/2157/2158",
- .frequency_min = 11000,
+ .frequency_min = 5500,
.frequency_max = 86200,
},
--
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 v4 2/2] V4L: add CCF support to the v4l2_clk API
Em Mon, 02 Mar 2015 20:52:41 +
laurent.pinch...@ideasonboard.com escreveu:
> Hi Mauro,
>
> On Mon Mar 02 2015 18:55:23 GMT+0200 (EET), Mauro Carvalho Chehab wrote:
> > Em Sun, 1 Feb 2015 12:12:33 +0100 (CET)
> > Guennadi Liakhovetski escreveu:
> >
> > > V4L2 clocks, e.g. used by camera sensors for their master clock, do not
> > > have to be supplied by a different V4L2 driver, they can also be
> > > supplied by an independent source. In this case the standart kernel
> > > clock API should be used to handle such clocks. This patch adds support
> > > for such cases.
> > >
> > > Signed-off-by: Guennadi Liakhovetski
> > > Acked-by: Laurent Pinchart
> > > ---
> > >
> > > v4: sizeof(*clk) :)
> > >
> > > drivers/media/v4l2-core/v4l2-clk.c | 48
> > > +++---
> > > include/media/v4l2-clk.h | 2 ++
> > > 2 files changed, 47 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/media/v4l2-core/v4l2-clk.c
> > > b/drivers/media/v4l2-core/v4l2-clk.c
> > > index 3ff0b00..9f8cb20 100644
> > > --- a/drivers/media/v4l2-core/v4l2-clk.c
> > > +++ b/drivers/media/v4l2-core/v4l2-clk.c
> > > @@ -9,6 +9,7 @@
> > > */
> > >
> > > #include
> > > +#include
> > > #include
> > > #include
> > > #include
> > > @@ -37,6 +38,21 @@ static struct v4l2_clk *v4l2_clk_find(const char
> > > *dev_id)
> > > struct v4l2_clk *v4l2_clk_get(struct device *dev, const char *id)
> > > {
> > > struct v4l2_clk *clk;
> > > + struct clk *ccf_clk = clk_get(dev, id);
> > > +
> > > + if (PTR_ERR(ccf_clk) == -EPROBE_DEFER)
> > > + return ERR_PTR(-EPROBE_DEFER);
> >
> > Why not do just:
> > return ccf_clk;
>
> I find the explicit error slightly more readable, but that's a matter of
> taste.
Well, return(ccf_clk) will likely produce a smaller instruction code
than return (long).
>
> > > +
> > > + if (!IS_ERR_OR_NULL(ccf_clk)) {
> > > + clk = kzalloc(sizeof(*clk), GFP_KERNEL);
> > > + if (!clk) {
> > > + clk_put(ccf_clk);
> > > + return ERR_PTR(-ENOMEM);
> > > + }
> > > + clk->clk = ccf_clk;
> > > +
> > > + return clk;
> > > + }
> >
> > The error condition here looks a little weird to me. I mean, if the
> > CCF clock returns an error, shouldn't it fail instead of silently
> > run some logic to find another clock source? Isn't it risky on getting
> > a wrong value?
>
> The idea is that, in the long term, everything should use CCF directly.
> However, we have clock providers on platforms where CCF isn't avalaible. V4L2
> clock has been introduced as a single API usable by V4L2 clock users
> allowing them to retrieve and use clocks regardless of whether the provider
> uses CCF or not. Internally it first tries CCF, and then falls back to the
> non-CCF implementation in case of failure.
Yeah, I got that the non-CCF is a fallback code, to be used on
platforms that CCF isn't available.
However, the above code doesn't seem to look if CCF is available
or not. Instead, it assumes that *all* error codes, or even NULL,
means that CCF isn't available.
Shouldn't it be, instead, either waiting for NULL or for some
specific error code, in order to:
- return the error code, if CCF is available but getting
the clock failed;
- run the backward-compat code when CCF is not available.
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
[GIT PULL] s5p fixes
Hi Mauro, Please pull the following s5p driver fixes. The following changes since commit ce037f19aaef992c634af653b17e61eee30a9404: [media] media: atmel-isi: increase the burst length to improve the performance (2015-03-02 13:27:11 -0300) are available in the git repository at: git://linuxtv.org/snawrocki/samsung.git for-v4.0/media/fixes for you to fetch changes up to 8278294b92b0a2b49a262342ea1d8ced109ea685: s5p-mfc: Fix NULL pointer dereference caused by not set q->lock (2015-03-03 16:52:50 +0100) Arnd Bergmann (1): s5p-tv: hdmi needs I2C support Jacek Anaszewski (1): s5p-jpeg: exynos3250: fix erroneous reset procedure Kamil Debski (1): s5p-mfc: Fix NULL pointer dereference caused by not set q->lock Tony K Nadackal (1): s5p-jpeg: Initialize cb and cr to zero drivers/media/platform/s5p-jpeg/jpeg-core.c|3 +++ .../media/platform/s5p-jpeg/jpeg-hw-exynos3250.c |2 +- drivers/media/platform/s5p-mfc/s5p_mfc.c |1 + drivers/media/platform/s5p-tv/Kconfig |1 + 4 files changed, 6 insertions(+), 1 deletion(-) Regards, Sylwester -- 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 01/10] media: omap3isp: remove unused clkdev
Hi Laurent, On Tue, Mar 03, 2015 at 02:39:14AM +0200, Laurent Pinchart wrote: > Hi Russell, > > On Monday 02 March 2015 23:54:35 Russell King - ARM Linux wrote: > > (Combining replies...) > > > > On Tue, Mar 03, 2015 at 12:53:37AM +0200, Sakari Ailus wrote: > > > Hi Laurent and Russell, > > > > > > On Tue, Mar 03, 2015 at 12:33:44AM +0200, Laurent Pinchart wrote: > > > > Sakari, does it conflict with the omap3isp DT support ? If so, how would > > > > you prefer to resolve the conflict ? Russell, would it be fine to merge > > > > this through Mauro's tree ? > > > > As other changes will depend on this, I'd prefer not to. The whole > > "make clk_get() return a unique struct clk" wasn't well tested, and > > several places broke - and currently clk_add_alias() is broken as a > > result of that. > > > > I'm trying to get to the longer term solution, where clkdev internally > > uses a struct clk_hw pointer rather than a struct clk pointer, and I > > want to clean stuff up first. > > > > If omap3isp needs to keep this code, then so be it - I'll come up with > > a different patch improving its use of clkdev instead. > > I'm totally fine with removing clkdev from the omap3isp driver if that's > easier for you, I'm just concerned about the merge conflict that will result. There actually appears to be one more dependency, so four patches in total. What we could also do is to rebase the omap3isp DT support set on top of Russell's single patch. This way there probably would be no merge conflict, assuming the patches are exactly the same, and you have no other patches changing the omap3isp driver. Alternatively we could postpone the DT support for the omap3isp, but I'd rather want to avoid that. -- 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: [PATCH v5 6/8] v4l: xilinx: Add Xilinx Video IP core
Hi Hans,
Thank you for the review.
On Tuesday 03 March 2015 12:28:24 Hans Verkuil wrote:
> Hi Laurent,
>
> Thanks for this patch. I do have a few comments, see below. Note that I am
> OK with the new DT format description.
>
> On 03/02/2015 02:48 AM, Laurent Pinchart wrote:
> > Xilinx platforms have no hardwired video capture or video processing
> > interface. Users create capture and memory to memory processing
> > pipelines in the FPGA fabric to suit their particular needs, by
> > instantiating video IP cores from a large library.
> >
> > The Xilinx Video IP core is a framework that models a video pipeline
> > described in the device tree and expose the pipeline to userspace
> > through the media controller and V4L2 APIs.
> >
> > Signed-off-by: Laurent Pinchart
> > Signed-off-by: Hyun Kwon
> > Signed-off-by: Radhey Shyam Pandey
> > Signed-off-by: Michal Simek
> >
> > ---
>
>
>
> > diff --git a/drivers/media/platform/xilinx/xilinx-dma.c
> > b/drivers/media/platform/xilinx/xilinx-dma.c new file mode 100644
> > index 000..afed6c3
> > --- /dev/null
> > +++ b/drivers/media/platform/xilinx/xilinx-dma.c
> > @@ -0,0 +1,753 @@
[snip]
> > +static void xvip_dma_complete(void *param)
> > +{
> > + struct xvip_dma_buffer *buf = param;
> > + struct xvip_dma *dma = buf->dma;
> > +
> > + spin_lock(&dma->queued_lock);
> > + list_del(&buf->queue);
> > + spin_unlock(&dma->queued_lock);
> > +
> > + buf->buf.v4l2_buf.sequence = dma->sequence++;
>
> buf->buf.v4l2_buf.field isn't set. I think you only support progressive
> formats at the moment, so this should be set to V4L2_FIELD_NONE.
Agreed, that was an oversight. I'll fix it.
> > + v4l2_get_timestamp(&buf->buf.v4l2_buf.timestamp);
> > + vb2_set_plane_payload(&buf->buf, 0, dma->format.sizeimage);
> > + vb2_buffer_done(&buf->buf, VB2_BUF_STATE_DONE);
> > +}
> > +
> > +static int
> > +xvip_dma_queue_setup(struct vb2_queue *vq, const struct v4l2_format *fmt,
> > +unsigned int *nbuffers, unsigned int *nplanes,
> > +unsigned int sizes[], void *alloc_ctxs[])
> > +{
> > + struct xvip_dma *dma = vb2_get_drv_priv(vq);
> > +
> > + *nplanes = 1;
> > +
> > + sizes[0] = dma->format.sizeimage;
>
> I would suggest that you add support for vb2_ioctl_create_bufs by changing
> this code to:
>
> if (fmt && fmt->fmt.pix.sizeimage < dma->format.sizeimage)
> return -EINVAL;
> sizes[0] = fmt ? fmt->fmt.pix.sizeimage : dma->format.sizeimage;
Looks good, I'll fix that.
> > + alloc_ctxs[0] = dma->alloc_ctx;
> > +
> > + return 0;
> > +}
[snip]
> > +static int xvip_dma_start_streaming(struct vb2_queue *vq, unsigned int
> > count) +{
> > + struct xvip_dma *dma = vb2_get_drv_priv(vq);
> > + struct xvip_dma_buffer *buf, *nbuf;
> > + struct xvip_pipeline *pipe;
> > + int ret;
> > +
> > + dma->sequence = 0;
> > +
> > + /*
> > +* Start streaming on the pipeline. No link touching an entity in the
> > +* pipeline can be activated or deactivated once streaming is
started.
> > +*
> > +* Use the pipeline object embedded in the first DMA object that
starts
> > +* streaming.
> > +*/
> > + pipe = dma->video.entity.pipe
> > +? to_xvip_pipeline(&dma->video.entity) : &dma->pipe;
> > +
> > + ret = media_entity_pipeline_start(&dma->video.entity, &pipe->pipe);
> > + if (ret < 0)
> > + goto error;
> > +
> > + /* Verify that the configured format matches the output of the
> > +* connected subdev.
> > +*/
> > + ret = xvip_dma_verify_format(dma);
> > + if (ret < 0)
> > + goto error_stop;
> > +
> > + ret = xvip_pipeline_prepare(pipe, dma);
> > + if (ret < 0)
> > + goto error_stop;
> > +
> > + /* Start the DMA engine. This must be done before starting the blocks
> > +* in the pipeline to avoid DMA synchronization issues.
> > +*/
> > + dma_async_issue_pending(dma->dma);
>
> Question: can the DMA engine be started without any buffers queued?
Yes. In that case the dma_async_issue_pending() call will be a no-op, as there
will be no pending DMA transfer queued.
> The vb2_queue struct has a min_buffers_needed field that can be set to a
> non-zero value. In that case start_streaming won't be called until at least
> that many buffers have been queued. Many DMA engines need that so this was
> added to the vb2 core to avoid having to hack around this in the driver.
I don't see a need for that here. I actually think the min_buffers_needed
field shouldn't be set, even if it could be set to 1, to avoid reporting
VIDIOC_STREAMON errors at VIDIOC_QBUF time. The alternative would be to move
the validation code to a custom .video_streamon handler, but that seems
pointless to me.
> > +
> > + /* Start the pipeline. */
> > + xvip_pipeline_set_stream(pipe, true);
> > +
> > + return 0;
> > +
> > +error_stop:
> > + media_entity_pipeline_stop(&dma->video.entity);
> > +
> > +error:
> > + /* Give back all que
Re: [PATCH] vb2: check if vb2_fop_write/read is allowed
On Tue, Mar 03, 2015 at 12:23:59PM +0100, Hans Verkuil wrote: > Return -EINVAL if read() or write() is not supported by the queue. This > makes it possible to provide both vb2_fop_read and vb2_fop_write in a > struct v4l2_file_operations since the vb2_fop_* function will check if > the file operation is allowed. > > A similar check exists in __vb2_init_fileio() which is called from > __vb2_perform_fileio(), but that check is only done if no file I/O is > active. So the sequence of read() followed by write() would be allowed, > which is obviously a bug. > > In addition, vb2_fop_write/read should always return -EINVAL if the > operation is not allowed, and by putting the check in the lower levels > of the code it is possible that other error codes are returned (EBUSY > or ERESTARTSYS). > > All these issues are avoided by just doing a quick explicit check. > > Signed-off-by: Hans Verkuil Acked-by: Sakari Ailus -- 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: [PATCH v4 2/2] V4L: add CCF support to the v4l2_clk API
Hi Mauro,
On Tuesday 03 March 2015 13:40:50 Mauro Carvalho Chehab wrote:
> Em Mon, 02 Mar 2015 20:52:41 + Laurent Pinchart escreveu:
> > On Mon Mar 02 2015 18:55:23 GMT+0200 (EET), Mauro Carvalho Chehab wrote:
> >> Em Sun, 1 Feb 2015 12:12:33 +0100 (CET) Guennadi Liakhovetski escreveu:
> >>> V4L2 clocks, e.g. used by camera sensors for their master clock, do
> >>> not have to be supplied by a different V4L2 driver, they can also be
> >>> supplied by an independent source. In this case the standart kernel
> >>> clock API should be used to handle such clocks. This patch adds
> >>> support for such cases.
> >>>
> >>> Signed-off-by: Guennadi Liakhovetski
> >>> Acked-by: Laurent Pinchart
> >>> ---
> >>>
> >>> v4: sizeof(*clk) :)
> >>>
> >>> drivers/media/v4l2-core/v4l2-clk.c | 48 ++---
> >>> include/media/v4l2-clk.h | 2 ++
> >>> 2 files changed, 47 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/drivers/media/v4l2-core/v4l2-clk.c
> >>> b/drivers/media/v4l2-core/v4l2-clk.c index 3ff0b00..9f8cb20 100644
> >>> --- a/drivers/media/v4l2-core/v4l2-clk.c
> >>> +++ b/drivers/media/v4l2-core/v4l2-clk.c
[snip]
> >>> @@ -37,6 +38,21 @@ static struct v4l2_clk *v4l2_clk_find(const char
> >>> *dev_id)
> >>> struct v4l2_clk *v4l2_clk_get(struct device *dev, const char *id)
> >>> {
> >>> struct v4l2_clk *clk;
> >>>
> >>> + struct clk *ccf_clk = clk_get(dev, id);
> >>> +
> >>> + if (PTR_ERR(ccf_clk) == -EPROBE_DEFER)
> >>> + return ERR_PTR(-EPROBE_DEFER);
> >>
> >> Why not do just:
> >>return ccf_clk;
> >
> > I find the explicit error slightly more readable, but that's a matter of
> > taste.
>
> Well, return(ccf_clk) will likely produce a smaller instruction code
> than return (long).
Not if the compiler is smart :-)
> >>> +
> >>> + if (!IS_ERR_OR_NULL(ccf_clk)) {
> >>> + clk = kzalloc(sizeof(*clk), GFP_KERNEL);
> >>> + if (!clk) {
> >>> + clk_put(ccf_clk);
> >>> + return ERR_PTR(-ENOMEM);
> >>> + }
> >>> + clk->clk = ccf_clk;
> >>> +
> >>> + return clk;
> >>> + }
> >>
> >> The error condition here looks a little weird to me. I mean, if the
> >> CCF clock returns an error, shouldn't it fail instead of silently
> >> run some logic to find another clock source? Isn't it risky on getting
> >> a wrong value?
> >
> > The idea is that, in the long term, everything should use CCF directly.
> > However, we have clock providers on platforms where CCF isn't avalaible.
> > V4L2 clock has been introduced as a single API usable by V4L2 clock
> > users allowing them to retrieve and use clocks regardless of whether the
> > provider uses CCF or not. Internally it first tries CCF, and then falls
> > back to the non-CCF implementation in case of failure.
>
> Yeah, I got that the non-CCF is a fallback code, to be used on
> platforms that CCF isn't available.
>
> However, the above code doesn't seem to look if CCF is available
> or not. Instead, it assumes that *all* error codes, or even NULL,
> means that CCF isn't available.
>
> Shouldn't it be, instead, either waiting for NULL or for some
> specific error code, in order to:
> - return the error code, if CCF is available but getting
> the clock failed;
> - run the backward-compat code when CCF is not available.
Isn't that pretty much what the code is doing ? If we get a -EPROBE_DEFER
error from CCF meaning that the clock is known but not registered yet we
return it. Otherwise, if the clock is unknown to CCF, or if CCF is disabled,
we fall back.
--
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 01/10] media: omap3isp: remove unused clkdev
Hi Russell, On Mon, Mar 02, 2015 at 11:54:35PM +, Russell King - ARM Linux wrote: > (Combining replies...) > > On Tue, Mar 03, 2015 at 12:53:37AM +0200, Sakari Ailus wrote: > > Hi Laurent and Russell, > > > > On Tue, Mar 03, 2015 at 12:33:44AM +0200, Laurent Pinchart wrote: > > > Sakari, does it conflict with the omap3isp DT support ? If so, how would > > > you > > > prefer to resolve the conflict ? Russell, would it be fine to merge this > > > through Mauro's tree ? > > As other changes will depend on this, I'd prefer not to. The whole > "make clk_get() return a unique struct clk" wasn't well tested, and > several places broke - and currently clk_add_alias() is broken as a > result of that. > > I'm trying to get to the longer term solution, where clkdev internally > uses a struct clk_hw pointer rather than a struct clk pointer, and I > want to clean stuff up first. > > If omap3isp needs to keep this code, then so be it - I'll come up with > a different patch improving its use of clkdev instead. I discussed this with Laurent and the two options we thought are - You provide a stable branch on which I can rebase the patches, in order to avoid a merge conflict or - We ignore the conflict and let Stephen Rothwell handle it. The conflict itself is relatively simple to resolve. -- 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: [PATCH v4 2/2] V4L: add CCF support to the v4l2_clk API
Em Wed, 04 Mar 2015 00:56:18 +0200
Laurent Pinchart escreveu:
> Hi Mauro,
>
> On Tuesday 03 March 2015 13:40:50 Mauro Carvalho Chehab wrote:
> > Em Mon, 02 Mar 2015 20:52:41 + Laurent Pinchart escreveu:
> > > On Mon Mar 02 2015 18:55:23 GMT+0200 (EET), Mauro Carvalho Chehab wrote:
> > >> Em Sun, 1 Feb 2015 12:12:33 +0100 (CET) Guennadi Liakhovetski escreveu:
> > >>> V4L2 clocks, e.g. used by camera sensors for their master clock, do
> > >>> not have to be supplied by a different V4L2 driver, they can also be
> > >>> supplied by an independent source. In this case the standart kernel
> > >>> clock API should be used to handle such clocks. This patch adds
> > >>> support for such cases.
> > >>>
> > >>> Signed-off-by: Guennadi Liakhovetski
> > >>> Acked-by: Laurent Pinchart
> > >>> ---
> > >>>
> > >>> v4: sizeof(*clk) :)
> > >>>
> > >>> drivers/media/v4l2-core/v4l2-clk.c | 48 ++---
> > >>> include/media/v4l2-clk.h | 2 ++
> > >>> 2 files changed, 47 insertions(+), 3 deletions(-)
> > >>>
> > >>> diff --git a/drivers/media/v4l2-core/v4l2-clk.c
> > >>> b/drivers/media/v4l2-core/v4l2-clk.c index 3ff0b00..9f8cb20 100644
> > >>> --- a/drivers/media/v4l2-core/v4l2-clk.c
> > >>> +++ b/drivers/media/v4l2-core/v4l2-clk.c
>
> [snip]
>
> > >>> @@ -37,6 +38,21 @@ static struct v4l2_clk *v4l2_clk_find(const char
> > >>> *dev_id)
> > >>> struct v4l2_clk *v4l2_clk_get(struct device *dev, const char *id)
> > >>> {
> > >>> struct v4l2_clk *clk;
> > >>>
> > >>> + struct clk *ccf_clk = clk_get(dev, id);
> > >>> +
> > >>> + if (PTR_ERR(ccf_clk) == -EPROBE_DEFER)
> > >>> + return ERR_PTR(-EPROBE_DEFER);
> > >>
> > >> Why not do just:
> > >> return ccf_clk;
> > >
> > > I find the explicit error slightly more readable, but that's a matter of
> > > taste.
> >
> > Well, return(ccf_clk) will likely produce a smaller instruction code
> > than return (long).
>
> Not if the compiler is smart :-)
>
> > >>> +
> > >>> + if (!IS_ERR_OR_NULL(ccf_clk)) {
> > >>> + clk = kzalloc(sizeof(*clk), GFP_KERNEL);
> > >>> + if (!clk) {
> > >>> + clk_put(ccf_clk);
> > >>> + return ERR_PTR(-ENOMEM);
> > >>> + }
> > >>> + clk->clk = ccf_clk;
> > >>> +
> > >>> + return clk;
> > >>> + }
> > >>
> > >> The error condition here looks a little weird to me. I mean, if the
> > >> CCF clock returns an error, shouldn't it fail instead of silently
> > >> run some logic to find another clock source? Isn't it risky on getting
> > >> a wrong value?
> > >
> > > The idea is that, in the long term, everything should use CCF directly.
> > > However, we have clock providers on platforms where CCF isn't avalaible.
> > > V4L2 clock has been introduced as a single API usable by V4L2 clock
> > > users allowing them to retrieve and use clocks regardless of whether the
> > > provider uses CCF or not. Internally it first tries CCF, and then falls
> > > back to the non-CCF implementation in case of failure.
> >
> > Yeah, I got that the non-CCF is a fallback code, to be used on
> > platforms that CCF isn't available.
> >
> > However, the above code doesn't seem to look if CCF is available
> > or not. Instead, it assumes that *all* error codes, or even NULL,
> > means that CCF isn't available.
> >
> > Shouldn't it be, instead, either waiting for NULL or for some
> > specific error code, in order to:
> > - return the error code, if CCF is available but getting
> > the clock failed;
> > - run the backward-compat code when CCF is not available.
>
> Isn't that pretty much what the code is doing ? If we get a -EPROBE_DEFER
> error from CCF meaning that the clock is known but not registered yet we
> return it. Otherwise, if the clock is unknown to CCF, or if CCF is disabled,
> we fall back.
I didn't check the CCF code, but couldn't it return error codes like
ENOMEM? What are all the error codes it can return ATM? What, among
them, can happen when CCF is available?
Also, as the CCF code can be changed, if the intent behavior is to only
allow EPROBE_DEFER or NULL, if the there is support for CCF, then you
need to have an explicit comment there to avoid that any newer patches
to add different error codes.
IMHO, it seems a way better to define a single error code to be
returned when the platform doesn't support CCF (like -ENOTSUPP),
and calling the fallback code only in this case. Something like:
if (PTR_ERR(ccf_clk) != -ENOTSUPP)
return ccf_clk;
/* CCF is not supported. Fall back to the old way */
k = kzalloc(sizeof(*clk), GFP_KERNEL);
if (!clk) {
clk_put(ccf_clk);
return ERR_PTR(-ENOMEM);
}
clk->clk = ccf_clk;
return clk;
Regards,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@v
Re: [PATCH v4 2/2] V4L: add CCF support to the v4l2_clk API
Hi Mauro,
On Tuesday 03 March 2015 20:21:29 Mauro Carvalho Chehab wrote:
> Em Wed, 04 Mar 2015 00:56:18 +0200 Laurent Pinchart escreveu:
> > On Tuesday 03 March 2015 13:40:50 Mauro Carvalho Chehab wrote:
> >> Em Mon, 02 Mar 2015 20:52:41 + Laurent Pinchart escreveu:
> >>> On Mon Mar 02 2015 18:55:23 GMT+0200 (EET), Mauro Carvalho Chehab wrote:
> Em Sun, 1 Feb 2015 12:12:33 +0100 (CET) Guennadi Liakhovetski escreveu:
> > V4L2 clocks, e.g. used by camera sensors for their master clock, do
> > not have to be supplied by a different V4L2 driver, they can also be
> > supplied by an independent source. In this case the standart kernel
> > clock API should be used to handle such clocks. This patch adds
> > support for such cases.
> >
> > Signed-off-by: Guennadi Liakhovetski
> > Acked-by: Laurent Pinchart
> > ---
> >
> > v4: sizeof(*clk) :)
> >
> > drivers/media/v4l2-core/v4l2-clk.c | 48 ---
> > include/media/v4l2-clk.h | 2 ++
> > 2 files changed, 47 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/media/v4l2-core/v4l2-clk.c
> > b/drivers/media/v4l2-core/v4l2-clk.c index 3ff0b00..9f8cb20 100644
> > --- a/drivers/media/v4l2-core/v4l2-clk.c
> > +++ b/drivers/media/v4l2-core/v4l2-clk.c
> >
> > [snip]
> >
> > @@ -37,6 +38,21 @@ static struct v4l2_clk *v4l2_clk_find(const char
> > *dev_id)
> > struct v4l2_clk *v4l2_clk_get(struct device *dev, const char *id)
> > {
> > struct v4l2_clk *clk;
> > + struct clk *ccf_clk = clk_get(dev, id);
> > +
> > + if (PTR_ERR(ccf_clk) == -EPROBE_DEFER)
> > + return ERR_PTR(-EPROBE_DEFER);
>
> Why not do just:
> return ccf_clk;
> >>>
> >>> I find the explicit error slightly more readable, but that's a matter
> >>> of taste.
> >>
> >> Well, return(ccf_clk) will likely produce a smaller instruction code
> >> than return (long).
> >
> > Not if the compiler is smart :-)
> >
> > +
> > + if (!IS_ERR_OR_NULL(ccf_clk)) {
> > + clk = kzalloc(sizeof(*clk), GFP_KERNEL);
> > + if (!clk) {
> > + clk_put(ccf_clk);
> > + return ERR_PTR(-ENOMEM);
> > + }
> > + clk->clk = ccf_clk;
> > +
> > + return clk;
> > + }
>
> The error condition here looks a little weird to me. I mean, if the
> CCF clock returns an error, shouldn't it fail instead of silently
> run some logic to find another clock source? Isn't it risky on
> getting a wrong value?
> >>>
> >>> The idea is that, in the long term, everything should use CCF
> >>> directly. However, we have clock providers on platforms where CCF
> >>> isn't avalaible. V4L2 clock has been introduced as a single API
> >>> usable by V4L2 clock users allowing them to retrieve and use clocks
> >>> regardless of whether the provider uses CCF or not. Internally it
> >>> first tries CCF, and then falls back to the non-CCF implementation in
> >>> case of failure.
> >>
> >> Yeah, I got that the non-CCF is a fallback code, to be used on
> >> platforms that CCF isn't available.
> >>
> >> However, the above code doesn't seem to look if CCF is available
> >> or not. Instead, it assumes that *all* error codes, or even NULL,
> >> means that CCF isn't available.
> >>
> >> Shouldn't it be, instead, either waiting for NULL or for some
> >> specific error code, in order to:
> >>
> >> - return the error code, if CCF is available but getting
> >> the clock failed;
> >>
> >> - run the backward-compat code when CCF is not available.
> >
> > Isn't that pretty much what the code is doing ? If we get a -EPROBE_DEFER
> > error from CCF meaning that the clock is known but not registered yet we
> > return it. Otherwise, if the clock is unknown to CCF, or if CCF is
> > disabled, we fall back.
>
> I didn't check the CCF code, but couldn't it return error codes like
> ENOMEM? What are all the error codes it can return ATM? What, among
> them, can happen when CCF is available?
>
> Also, as the CCF code can be changed, if the intent behavior is to only
> allow EPROBE_DEFER or NULL, if the there is support for CCF, then you
> need to have an explicit comment there to avoid that any newer patches
> to add different error codes.
>
> IMHO, it seems a way better to define a single error code to be
> returned when the platform doesn't support CCF (like -ENOTSUPP),
But that's not how CCF works :-)
Regardless of that, note that the clk_get() call is part of the Linux clock
API, of which CCF is one implementation. clk_get() is implemented by custom
architecture code on platforms where CCF isn't used.
The idea of this patch is to
- return the platform clock if available (clk_get() returns a non-NULL, non-
error pointer)
- defer probing if the platform clock req
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: Wed Mar 4 04:00:21 CET 2015 git branch: test git hash: 269bd1324fbfaa52832bb3efe9f5105c9146a33a gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-44-g40791b9 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:3.18.0-5.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: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: ERRORS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: WARNINGS linux-3.1.10-i686: WARNINGS linux-3.2.37-i686: WARNINGS linux-3.3.8-i686: WARNINGS linux-3.4.27-i686: WARNINGS linux-3.5.7-i686: WARNINGS linux-3.6.11-i686: WARNINGS linux-3.7.4-i686: WARNINGS linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: WARNINGS linux-3.11.1-i686: WARNINGS linux-3.12.23-i686: WARNINGS linux-3.13.11-i686: ERRORS linux-3.14.9-i686: ERRORS linux-3.15.2-i686: ERRORS linux-3.16.7-i686: ERRORS linux-3.17.8-i686: WARNINGS linux-3.18.7-i686: WARNINGS linux-3.19-i686: WARNINGS linux-4.0-rc1-i686: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: WARNINGS linux-3.1.10-x86_64: WARNINGS linux-3.2.37-x86_64: WARNINGS linux-3.3.8-x86_64: WARNINGS linux-3.4.27-x86_64: WARNINGS linux-3.5.7-x86_64: WARNINGS linux-3.6.11-x86_64: WARNINGS linux-3.7.4-x86_64: WARNINGS linux-3.8-x86_64: WARNINGS linux-3.9.2-x86_64: WARNINGS linux-3.10.1-x86_64: WARNINGS linux-3.11.1-x86_64: WARNINGS linux-3.12.23-x86_64: WARNINGS linux-3.13.11-x86_64: ERRORS linux-3.14.9-x86_64: ERRORS linux-3.15.2-x86_64: ERRORS linux-3.16.7-x86_64: ERRORS linux-3.17.8-x86_64: WARNINGS linux-3.18.7-x86_64: WARNINGS linux-3.19-x86_64: WARNINGS linux-4.0-rc1-x86_64: WARNINGS apps: OK spec-git: OK sparse: ERRORS ABI WARNING: change for mips smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.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: [PATCHv3] [media] saa7164: use an MSI interrupt when available
On 02/28/2015 04:14 PM, Brendan McGrath wrote: Enhances driver to use an MSI interrupt when available. Adds the module option 'enable_msi' (type bool) which by default is enabled. Can be set to 'N' to disable. Fixes (or can reduce the occurrence of) a crash which is most commonly reported when multiple saa7164 chips are in use. A reported example can be found here: http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/83948 Reviewed-by: Steven Toth Signed-off-by: Brendan McGrath I wanted to report that I have been running this patch for about a week now and I have had no instances of the zero free sequences issue. Thank you very much! David -- 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
[GIT PULL]: dma-buf fixes for 4.0
Hi Linus, May I please request you to pull a couple of fixes in dma-buf for 4.0-rc3? The following changes since commit b942c653ae265abbd31032f3b4f5f857e5c7c723: Merge tag 'trace-sh-3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace (2015-01-22 06:26:07 +1200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sumits/dma-buf.git tags/dma-buf-for-4.0-rc3 for you to fetch changes up to 4eb2440ed60fb5793f7aa6da89b3d517cc59de43: reservation: Remove shadowing local variable 'ret' (2015-01-22 16:29:31 +0530) dma-buf pull request for 4.0-rc3 - minor timeout & other fixes on reservation/fence Jammy Zhou (2): reservation: wait only with non-zero timeout specified (v3) dma-buf/fence: don't wait when specified timeout is zero Michel Dänzer (1): reservation: Remove shadowing local variable 'ret' drivers/dma-buf/fence.c | 3 +++ drivers/dma-buf/reservation.c | 5 +++-- 2 files changed, 6 insertions(+), 2 deletions(-) Thanks, and Best regards, Sumit. PS: I am not submitting the cleanup that I submitted in my earlier pull request that you had to reject due to my stupid copy-paste error; that one patch and it's fix is in for-next, but it's not, strictly speaking, a "fix" to qualify for -rc3, hence I'll wait for the next merge-window to submit it. -- 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
