Re: [PATCH v3 0/5] Signalling last decoded frame by V4L2_BUF_FLAG_LAST and -EPIPE
Hi, On Tue, Apr 7, 2015 at 11:44 PM, Kamil Debski k.deb...@samsung.com wrote: Hi, From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Tuesday, March 17, 2015 5:09 PM On 03/17/2015 11:46 AM, Philipp Zabel wrote: Hi, Am Freitag, den 06.03.2015, 11:18 +0100 schrieb Philipp Zabel: At the V4L2 codec API session during ELC-E 2014, we agreed that for the decoder draining flow, after a V4L2_DEC_CMD_STOP decoder command was issued, the last decoded buffer should get dequeued with a V4L2_BUF_FLAG_LAST set. After that, poll should immediately return and all following VIDIOC_DQBUF should return -EPIPE until the stream is stopped or decoding continued via V4L2_DEC_CMD_START. (or STREAMOFF/STREAMON). Changes since v2: - Made V4L2_BUF_FLAG_LAST known to trace events regards Philipp Peter Seiderer (1): [media] videodev2: Add V4L2_BUF_FLAG_LAST Philipp Zabel (4): [media] videobuf2: return -EPIPE from DQBUF after the last buffer [media] coda: Set last buffer flag and fix EOS event [media] s5p-mfc: Set last buffer flag [media] DocBooc: mention mem2mem codecs for encoder/decoder commands Documentation/DocBook/media/v4l/io.xml | 10 .../DocBook/media/v4l/vidioc-decoder-cmd.xml | 6 - .../DocBook/media/v4l/vidioc-encoder-cmd.xml | 5 +++- Documentation/DocBook/media/v4l/vidioc-qbuf.xml| 8 +++ drivers/media/platform/coda/coda-bit.c | 4 ++-- drivers/media/platform/coda/coda-common.c | 27 +-- --- drivers/media/platform/coda/coda.h | 3 +++ drivers/media/platform/s5p-mfc/s5p_mfc.c | 1 + drivers/media/v4l2-core/v4l2-mem2mem.c | 10 +++- drivers/media/v4l2-core/videobuf2-core.c | 18 ++- include/media/videobuf2-core.h | 10 include/trace/events/v4l2.h| 3 ++- include/uapi/linux/videodev2.h | 2 ++ 13 files changed, 84 insertions(+), 23 deletions(-) are there any further changes that I should make to this series? I'd like to see some Acks, esp. from Kamil and Pawel. I'll take another look as well, probably on Friday. The patches look good to me, the 4th version is already queued in my tree. However I would like to see your opinion. Especially from you Pawel :) Sorry for the delay, I've been very busy lately, but I really need to take a look at them. I'll do my best to review this weekend. Putting on my calendar. -- Regards, Pawel -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] media: Correctly notify about the failed pipeline validation
Em Thu, 12 Feb 2015 15:43:11 +0200
Sakari Ailus sakari.ai...@linux.intel.com escreveu:
On the place of the source entity name, the sink entity name was printed.
Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com
---
drivers/media/media-entity.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index defe4ac..d894481 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -283,9 +283,9 @@ __must_check int media_entity_pipeline_start(struct
media_entity *entity,
if (ret 0 ret != -ENOIOCTLCMD) {
dev_dbg(entity-parent-dev,
link validation failed for \%s\:%u
- \%s\:%u, error %d\n,
- entity-name, link-source-index,
- link-sink-entity-name,
- link-sink-index, ret);
+ link-source-entity-name,
+ link-source-index,
+ entity-name, link-sink-index, ret);
This should likely be reviewed by Laurent, but the above code
seems weird to me...
1) Why should it print the link source, instead of the sink?
I suspect that the code here should take into account the chosen
pad:
struct media_pad *pad = link-sink-entity == entity
? link-sink : link-source;
2) Assuming that your patch is right, why are you printing the
link-sink-index, instead of link-source-index?
Regards,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] media: Correctly notify about the failed pipeline validation
Hi Mauro,
Mauro Carvalho Chehab wrote:
Em Thu, 12 Feb 2015 15:43:11 +0200
Sakari Ailus sakari.ai...@linux.intel.com escreveu:
On the place of the source entity name, the sink entity name was printed.
Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com
---
drivers/media/media-entity.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index defe4ac..d894481 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -283,9 +283,9 @@ __must_check int media_entity_pipeline_start(struct
media_entity *entity,
if (ret 0 ret != -ENOIOCTLCMD) {
dev_dbg(entity-parent-dev,
link validation failed for \%s\:%u
- \%s\:%u, error %d\n,
-entity-name, link-source-index,
-link-sink-entity-name,
-link-sink-index, ret);
+link-source-entity-name,
+link-source-index,
+entity-name, link-sink-index, ret);
This should likely be reviewed by Laurent, but the above code
seems weird to me...
1) Why should it print the link source, instead of the sink?
I suspect that the code here should take into account the chosen
pad:
struct media_pad *pad = link-sink-entity == entity
? link-sink : link-source;
Link validation is only performed on sink pads. This is checked a few
lines above this, so the pad here is always the sink pad. Instead of
link-sink-index I could have used pad-index but the pad and thus the
integer value is the same.
2) Assuming that your patch is right, why are you printing the
link-sink-index, instead of link-source-index?
The source pad index is prited as well. The end result is, after the patch:
source entity:source pad - sink entity:sink pad
Before it was:
sink entity:source pad - sink entity:sink pad
Which indeed was wrong.
--
Regards,
Sakari Ailus
sakari.ai...@linux.intel.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: [RFC 00/12] TC358743 async subdev and dt support
Hi Philipp, Hans forwarded this patch series to me now, since I haven't received if for some reason. I will prioritize upstreaming of the driver the next couple of days and create a new RFC. I will also go through your patches and give you feedback! Regards, Mats On 03/30/2015 01:10 PM, Philipp Zabel wrote: Hi Mats, did you have time to work on the TC358743 driver some more in the meanwhile? These are the changes I have made locally to v1 to get it to work on i.MX6. regards Philipp Mats Randgaard (1): [media] Driver for Toshiba TC358743 CSI-2 to HDMI bridge Philipp Zabel (11): [media] tc358743: register v4l2 asynchronous subdevice [media] tc358743: support probe from device tree [media] tc358743: fix set_pll to enable PLL with default frequency [media] tc358743: fix lane number calculation to include blanking [media] tc358743: split set_csi into set_csi and start_csi [media] tc358743: also set TCLK_TRAILCNT and TCLK_POSTCNT [media] tc358743: parse MIPI CSI-2 endpoint, support noncontinuous clock [media] tc358743: add direct interrupt handling [media] tc358743: detect chip by ChipID instead of IntMask [media] tc358743: don't return E2BIG from G_EDID [media] tc358743: allow event subscription MAINTAINERS|6 + drivers/media/i2c/Kconfig | 12 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/tc358743.c | 1979 drivers/media/i2c/tc358743_regs.h | 670 include/media/tc358743.h | 89 ++ include/uapi/linux/v4l2-controls.h |4 + 7 files changed, 2761 insertions(+) create mode 100644 drivers/media/i2c/tc358743.c create mode 100644 drivers/media/i2c/tc358743_regs.h create mode 100644 include/media/tc358743.h -- 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 01/12] DT: leds: Improve description of flash LEDs related properties
Hi Sylwester, On 04/08/2015 12:03 PM, Sylwester Nawrocki wrote: Hello, On 31/03/15 15:52, Jacek Anaszewski wrote: Description of flash LEDs related properties was not precise regarding the state of corresponding settings in case a property is missing. Add relevant statements. Removed is also the requirement making the flash-max-microamp property obligatory for flash LEDs. It was inconsistent as the property is defined as optional. Devices which require the property will have to assert this in their DT bindings. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Bryan Wu coolo...@gmail.com Cc: Richard Purdie rpur...@rpsys.net Cc: Pavel Machek pa...@ucw.cz Cc: Sakari Ailus sakari.ai...@linux.intel.com Cc: devicet...@vger.kernel.org --- Documentation/devicetree/bindings/leds/common.txt | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt index 747c538..21a25e4 100644 --- a/Documentation/devicetree/bindings/leds/common.txt +++ b/Documentation/devicetree/bindings/leds/common.txt @@ -29,13 +29,15 @@ Optional properties for child nodes: ide-disk - LED indicates disk activity timer - LED flashes at a fixed, configurable rate -- max-microamp : maximum intensity in microamperes of the LED -(torch LED for flash devices) -- flash-max-microamp : maximum intensity in microamperes of the - flash LED; it is mandatory if the LED should - support the flash mode -- flash-timeout-us : timeout in microseconds after which the flash - LED is turned off +- max-microamp : Maximum intensity in microamperes of the LED +(torch LED for flash devices). If omitted this will default +to the maximum current allowed by the device. +- flash-max-microamp : Maximum intensity in microamperes of the flash LED. + If omitted this will default to the maximum + current allowed by the device. +- flash-timeout-us : Timeout in microseconds after which the flash + LED is turned off. If omitted this will default to the +maximum timeout allowed by the device. Sorry about late comments on that, but since we can still change these properties and it seems we're going to do that, I'd like throw in my few preferences on the colour of this bike... IMO max-microamp is a poor property name, how about: s/max-microamp/led-max-current-ua, s/flash-max-microamp/flash-max-current-ua, so we have more consistent set of properties like: led-max-current-ua flash-max-current-ua flash-timeout-us The -microamp' suffix is consistent with regulator bindings. Please refer to [1]. Also expressing light intensity in micro-amperes seems technically wrong. I would propose to substitute word intensity in microamperes with LED supply current in microamperes. OK, I will address this in the next version of the patch. I also think we should require the maximum current properties and the driver should warn if they are missing and limit current to some potentially safe value, e.g. small fraction of the maximum current. TBD. Also from the description it should be clear whether the current limits refer to capabilities of a LED or the desired settings we want to be applied at the LED driver device. We could, for example, add a sentence after the above 3 properties: Required properties for Flash LEDs: - led-max-current-ua - flash-max-current-ua - flash-timeout-us These properties determine a LED driver IC settings required for safe operation. Or something along these lines. OK. [1] http://www.spinics.net/lists/linux-leds/msg02674.html -- Best Regards, Jacek Anaszewski -- 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 06/12] of: Add Skyworks Solutions, Inc. vendor prefix
On Tue, Mar 31, 2015 at 03:52:42PM +0200, Jacek Anaszewski wrote: Use skyworks as the vendor prefix for the Skyworks Solutions, Inc. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: devicet...@vger.kernel.org --- .../devicetree/bindings/vendor-prefixes.txt|1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 42b3dab..4cd18bb 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -163,6 +163,7 @@ ricoh Ricoh Co. Ltd. rockchip Fuzhou Rockchip Electronics Co., Ltd samsung Samsung Semiconductor sandisk Sandisk Corporation +skyworks Skyworks Solutions, Inc. Please maintain the alphabetic order. With that fixed, Acked-by: Sakari Ailus sakari.ai...@linux.intel.com sbs Smart Battery System schindlerSchindler seagate Seagate Technology PLC -- 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 01/12] DT: leds: Improve description of flash LEDs related properties
Hi Sakari, On 04/08/2015 11:11 AM, Sakari Ailus wrote: Hi Jacek, On Wed, Apr 08, 2015 at 10:54:52AM +0200, Jacek Anaszewski wrote: Hi Sakari, On 04/03/2015 02:09 PM, Sakari Ailus wrote: Hi Jacek, On Tue, Mar 31, 2015 at 03:52:37PM +0200, Jacek Anaszewski wrote: Description of flash LEDs related properties was not precise regarding the state of corresponding settings in case a property is missing. Add relevant statements. Removed is also the requirement making the flash-max-microamp property obligatory for flash LEDs. It was inconsistent as the property is defined as optional. Devices which require the property will have to assert this in their DT bindings. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Bryan Wu coolo...@gmail.com Cc: Richard Purdie rpur...@rpsys.net Cc: Pavel Machek pa...@ucw.cz Cc: Sakari Ailus sakari.ai...@linux.intel.com Cc: devicet...@vger.kernel.org --- Documentation/devicetree/bindings/leds/common.txt | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt index 747c538..21a25e4 100644 --- a/Documentation/devicetree/bindings/leds/common.txt +++ b/Documentation/devicetree/bindings/leds/common.txt @@ -29,13 +29,15 @@ Optional properties for child nodes: ide-disk - LED indicates disk activity timer - LED flashes at a fixed, configurable rate -- max-microamp : maximum intensity in microamperes of the LED -(torch LED for flash devices) -- flash-max-microamp : maximum intensity in microamperes of the - flash LED; it is mandatory if the LED should - support the flash mode -- flash-timeout-us : timeout in microseconds after which the flash - LED is turned off +- max-microamp : Maximum intensity in microamperes of the LED +(torch LED for flash devices). If omitted this will default +to the maximum current allowed by the device. +- flash-max-microamp : Maximum intensity in microamperes of the flash LED. + If omitted this will default to the maximum + current allowed by the device. +- flash-timeout-us : Timeout in microseconds after which the flash + LED is turned off. If omitted this will default to the +maximum timeout allowed by the device. Examples: Pavel pointed out that the brightness between maximum current and the maximum *allowed* another current might not be noticeable, leading a potential spelling error to cause the LED being run at too high current. I think that a board designed so that it can be damaged because of software bugs should be considered not eligible for commercial use. Any self-esteeming manufacturer will not connect a LED to the output that can produce the current greater than the LED's absolute maximum current. The maximum current *is* used to prevent potential hardware damage. What hardware are we talking about - LED controller or the discrete LED component attached to the LED controller's current output? The maximum current the LED controller can produce is fixed or depends on external components like resistors. This is at least the case for max77693 and aat1290 device I've been working with. If a LED is rated to max 1A and it will be connected to the output capable of producing 1.2A then it is likely that it will be damaged. I was thinking about this kind of hardware damage. How vendors can protect from it if they connect incompatible LED to the current output? There might be boards that provide sockets for connecting external LEDs though. Such arrangements indeed justify the need for making the properties required. This is how mobile phones typically are, probably also the one you're using. :-) I don't believe there's really a difference between vendors in this respect. We still lack a proper way to model the temperature of the flash LED, so what we have now is a bit incomplete, but at least it prevents causing damage unintentionally. Are you thinking about flash faults? The DT properties could be useful for devices like aat1290 device I was writing a driver for, which has the maximum current and timeout values depending on corresponding capacitor and resistor values respectively. Such devices should make the properties required in their bindings. The three drivers I've looked also require these properties, which I think is in the line with the above. How about either dropping the patch, or changing maximum to minimum and will to should? The drivers could also behave this way instead of requiring the properties, but I don't think there's anything wrong with requiring the properties either. As I mentioned in the previous message in this subject, the max-microamp property refers also to non-flash LEDs. Since existing LED class
Re: [PATCH v4 01/12] DT: leds: Improve description of flash LEDs related properties
Hi Jacek, On Wed, Apr 08, 2015 at 12:23:23PM +0200, Jacek Anaszewski wrote: Hi Sakari, On 04/08/2015 11:11 AM, Sakari Ailus wrote: Hi Jacek, On Wed, Apr 08, 2015 at 10:54:52AM +0200, Jacek Anaszewski wrote: Hi Sakari, On 04/03/2015 02:09 PM, Sakari Ailus wrote: Hi Jacek, On Tue, Mar 31, 2015 at 03:52:37PM +0200, Jacek Anaszewski wrote: Description of flash LEDs related properties was not precise regarding the state of corresponding settings in case a property is missing. Add relevant statements. Removed is also the requirement making the flash-max-microamp property obligatory for flash LEDs. It was inconsistent as the property is defined as optional. Devices which require the property will have to assert this in their DT bindings. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Bryan Wu coolo...@gmail.com Cc: Richard Purdie rpur...@rpsys.net Cc: Pavel Machek pa...@ucw.cz Cc: Sakari Ailus sakari.ai...@linux.intel.com Cc: devicet...@vger.kernel.org --- Documentation/devicetree/bindings/leds/common.txt | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt index 747c538..21a25e4 100644 --- a/Documentation/devicetree/bindings/leds/common.txt +++ b/Documentation/devicetree/bindings/leds/common.txt @@ -29,13 +29,15 @@ Optional properties for child nodes: ide-disk - LED indicates disk activity timer - LED flashes at a fixed, configurable rate -- max-microamp : maximum intensity in microamperes of the LED - (torch LED for flash devices) -- flash-max-microamp : maximum intensity in microamperes of the - flash LED; it is mandatory if the LED should -support the flash mode -- flash-timeout-us : timeout in microseconds after which the flash - LED is turned off +- max-microamp : Maximum intensity in microamperes of the LED + (torch LED for flash devices). If omitted this will default + to the maximum current allowed by the device. +- flash-max-microamp : Maximum intensity in microamperes of the flash LED. +If omitted this will default to the maximum +current allowed by the device. +- flash-timeout-us : Timeout in microseconds after which the flash + LED is turned off. If omitted this will default to the + maximum timeout allowed by the device. Examples: Pavel pointed out that the brightness between maximum current and the maximum *allowed* another current might not be noticeable, leading a potential spelling error to cause the LED being run at too high current. I think that a board designed so that it can be damaged because of software bugs should be considered not eligible for commercial use. Any self-esteeming manufacturer will not connect a LED to the output that can produce the current greater than the LED's absolute maximum current. The maximum current *is* used to prevent potential hardware damage. What hardware are we talking about - LED controller or the discrete LED component attached to the LED controller's current output? Generally the LED itself, not the controller. Most controllers have overheating protection while the LEDs do not. The maximum current the LED controller can produce is fixed or depends on external components like resistors. On some controllers perhaps, but not on most of them. This is at least the case for max77693 and aat1290 device I've been working with. If a LED is rated to max 1A and it will be connected to the output capable of producing 1.2A then it is likely that it will be damaged. I was thinking about this kind of hardware damage. This is the very reason why the maximum current limit is there: to prevent hardware damage. If the LED could safely be used at the controller's maximum current, there would be no need for the maximum current property (torch/flash). How vendors can protect from it if they connect incompatible LED to the current output? There might be boards that provide sockets for connecting external LEDs though. Such arrangements indeed justify the need for making the properties required. Pluggable hardware is a completely different matter. If used with DT overlays, the overlay should contain the limits as well. This is how mobile phones typically are, probably also the one you're using. :-) I don't believe there's really a difference between vendors in this respect. We still lack a proper way to model the temperature of the flash LED, so what we have now is a bit incomplete, but at least it prevents causing damage unintentionally. Are you thinking about flash faults? The question is: when if it safe to strobe again after a strobe has ended? -- Kind regards, Sakari Ailus
Re: [PATCH] [media] dmxdev: fix possible race conditions in dvb_dmxdev_buffer_read
Hi,
Em Tue, 30 Dec 2014 12:05:34 +0900
Jaedon Shin jaedon.s...@gmail.com escreveu:
This patch splits the dvb_dmxdev_buffer_read into dvb_dvr_read and
dvb_demux_read that fixes to unlock mutex before sleeping.
There are race conditions executing the DMX_ADD_PID and the DMX_REMOVE_PID
in the dvb_demux_do_ioctl when dvb_demux_read is waiting for data.
Signed-off-by: Jaedon Shin jaedon.s...@gmail.com
---
drivers/media/dvb-core/dmxdev.c | 94
-
1 file changed, 75 insertions(+), 19 deletions(-)
diff --git a/drivers/media/dvb-core/dmxdev.c b/drivers/media/dvb-core/dmxdev.c
index abff803..c2564b0 100644
--- a/drivers/media/dvb-core/dmxdev.c
+++ b/drivers/media/dvb-core/dmxdev.c
@@ -57,10 +57,11 @@ static int dvb_dmxdev_buffer_write(struct dvb_ringbuffer
*buf,
return dvb_ringbuffer_write(buf, src, len);
}
-static ssize_t dvb_dmxdev_buffer_read(struct dvb_ringbuffer *src,
+static ssize_t dvb_dmxdev_buffer_read(struct dmxdev_filter *dmxdevfilter,
int non_blocking, char __user *buf,
size_t count, loff_t *ppos)
{
+ struct dvb_ringbuffer *src = dmxdevfilter-buffer;
size_t todo;
ssize_t avail;
ssize_t ret = 0;
@@ -75,16 +76,21 @@ static ssize_t dvb_dmxdev_buffer_read(struct
dvb_ringbuffer *src,
}
for (todo = count; todo 0; todo -= ret) {
- if (non_blocking dvb_ringbuffer_empty(src)) {
- ret = -EWOULDBLOCK;
- break;
- }
+ if (dvb_ringbuffer_empty(src)) {
+ mutex_unlock(dmxdevfilter-mutex);
- ret = wait_event_interruptible(src-queue,
-!dvb_ringbuffer_empty(src) ||
-(src-error != 0));
- if (ret 0)
- break;
+ if (non_blocking)
+ return -EWOULDBLOCK;
+
+ ret = wait_event_interruptible(src-queue,
+ !dvb_ringbuffer_empty(src) ||
+ (src-error != 0));
+ if (ret 0)
+ return ret;
+
+ if (mutex_lock_interruptible(dmxdevfilter-mutex))
+ return -ERESTARTSYS;
+ }
if (src-error) {
ret = src-error;
@@ -242,13 +248,63 @@ static ssize_t dvb_dvr_read(struct file *file, char
__user *buf, size_t count,
{
struct dvb_device *dvbdev = file-private_data;
struct dmxdev *dmxdev = dvbdev-priv;
+ struct dvb_ringbuffer *src = dmxdev-dvr_buffer;
+ size_t todo;
+ ssize_t avail;
+ ssize_t ret = 0;
- if (dmxdev-exit)
+ if (mutex_lock_interruptible(dmxdev-mutex))
+ return -ERESTARTSYS;
+
+ if (dmxdev-exit) {
+ mutex_unlock(dmxdev-mutex);
return -ENODEV;
+ }
+
+ if (src-error) {
+ ret = src-error;
+ dvb_ringbuffer_flush(src);
+ mutex_unlock(dmxdev-mutex);
+ return ret;
+ }
+
+ for (todo = count; todo 0; todo -= ret) {
+ if (dvb_ringbuffer_empty(src)) {
+ mutex_unlock(dmxdev-mutex);
- return dvb_dmxdev_buffer_read(dmxdev-dvr_buffer,
- file-f_flags O_NONBLOCK,
- buf, count, ppos);
+ if (file-f_flags O_NONBLOCK)
+ return -EWOULDBLOCK;
+
+ ret = wait_event_interruptible(src-queue,
+ !dvb_ringbuffer_empty(src) ||
+ (src-error != 0));
+ if (ret 0)
+ return ret;
+
+ if (mutex_lock_interruptible(dmxdev-mutex))
+ return -ERESTARTSYS;
+ }
Hmm... you're replicating what's there at dvb_dmxdev_buffer_read()
with a few additions bellow.
Instead, please do it in a way that we'll have just one copy of the
code. The DVB ringbuf logic is already complex enough without code
duplication.
This would also make easier for reviewers to check the changes at
the logic.
+
+ if (src-error) {
+ ret = src-error;
+ dvb_ringbuffer_flush(src);
+ break;
+ }
+
+ avail = dvb_ringbuffer_avail(src);
+ if (avail todo)
+ avail = todo;
+
+ ret = dvb_ringbuffer_read_user(src, buf, avail);
+ if (ret 0)
+ break;
+
+ buf += ret;
+ }
+
+ mutex_unlock(dmxdev-mutex);
+
+ return (count - todo) ? (count - todo) :
Re: OMAP3 ISP previewer Y10 to UYVY conversion
Hi Chris, On Tuesday 07 April 2015 11:45:10 Chris Whittenburg wrote: On Tue, Apr 7, 2015 at 10:51 AM, Laurent Pinchart wrote: I suspect the RGB2RGB conversion matrix to be wrong. The default setting is supposed to handle fluorescent lighting. You could try setting the RGB2RGB matrix to the identity matrix and see if this helps. See http://git.ideasonboard.org/omap3-isp-live.git/blob/HEAD:/isp/controls.c#l 184 for sample code. Another matrix that could be worth being reprogrammed is the RGB2YUV matrix, which also defaults to fluorescent lighting. Sample code to reprogram it is available in the same location. Thanks Laurent... Just to verify, the conversion matrix still plays a role even though the input format is Y10? Yes it does. The preview engine first converts Y10 to RGB by duplicating the Y value for all three channels, then feeds it through the RGB2RGB matrix, the gamma table, and the RGB2YUV matrix. -- 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 v4 01/12] DT: leds: Improve description of flash LEDs related properties
On Wed 2015-04-08 12:03:27, Sylwester Nawrocki wrote: Hello, On 31/03/15 15:52, Jacek Anaszewski wrote: Description of flash LEDs related properties was not precise regarding the state of corresponding settings in case a property is missing. Add relevant statements. Removed is also the requirement making the flash-max-microamp property obligatory for flash LEDs. It was inconsistent as the property is defined as optional. Devices which require the property will have to assert this in their DT bindings. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Bryan Wu coolo...@gmail.com Cc: Richard Purdie rpur...@rpsys.net Cc: Pavel Machek pa...@ucw.cz Cc: Sakari Ailus sakari.ai...@linux.intel.com Cc: devicet...@vger.kernel.org --- Documentation/devicetree/bindings/leds/common.txt | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt index 747c538..21a25e4 100644 --- a/Documentation/devicetree/bindings/leds/common.txt +++ b/Documentation/devicetree/bindings/leds/common.txt @@ -29,13 +29,15 @@ Optional properties for child nodes: ide-disk - LED indicates disk activity timer - LED flashes at a fixed, configurable rate -- max-microamp : maximum intensity in microamperes of the LED -(torch LED for flash devices) -- flash-max-microamp : maximum intensity in microamperes of the - flash LED; it is mandatory if the LED should - support the flash mode -- flash-timeout-us : timeout in microseconds after which the flash - LED is turned off +- max-microamp : Maximum intensity in microamperes of the LED +(torch LED for flash devices). If omitted this will default +to the maximum current allowed by the device. +- flash-max-microamp : Maximum intensity in microamperes of the flash LED. + If omitted this will default to the maximum + current allowed by the device. +- flash-timeout-us : Timeout in microseconds after which the flash + LED is turned off. If omitted this will default to the +maximum timeout allowed by the device. Sorry about late comments on that, but since we can still change these properties and it seems we're going to do that, I'd like throw in my few preferences on the colour of this bike... Lets not paint bikes here. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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] rc: img-ir: Add and enable sys clock for IR
Em Tue, 3 Feb 2015 17:30:29 +
Sifan Naeem sifan.na...@imgtec.com escreveu:
Gets a handle to the system clock, already described in the binding
document, and calls the appropriate common clock
framework functions to mark it prepared/enabled, the common clock
framework initially enables the clock and doesn't disable it at least
until the device/driver is removed.
The system clock to IR is needed for the driver to communicate with the
IR hardware via MMIO accesses on the system bus, so it must not be
disabled during use or the driver will malfunction.
Hmm... patchwork has two versions of this patch, but I have only one on
my e-mail.
Could you please check if I applied the right one? If not, please
send me an email with a fixup patch.
Thanks!
Mauro
Signed-off-by: Sifan Naeem sifan.na...@imgtec.com
---
drivers/media/rc/img-ir/img-ir-core.c | 13 +
drivers/media/rc/img-ir/img-ir.h |2 ++
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/media/rc/img-ir/img-ir-core.c
b/drivers/media/rc/img-ir/img-ir-core.c
index 77c78de..783dd21 100644
--- a/drivers/media/rc/img-ir/img-ir-core.c
+++ b/drivers/media/rc/img-ir/img-ir-core.c
@@ -60,6 +60,8 @@ static void img_ir_setup(struct img_ir_priv *priv)
if (!IS_ERR(priv-clk))
clk_prepare_enable(priv-clk);
+ if (!IS_ERR(priv-sys_clk))
+ clk_prepare_enable(priv-sys_clk);
}
static void img_ir_ident(struct img_ir_priv *priv)
@@ -110,10 +112,11 @@ static int img_ir_probe(struct platform_device *pdev)
priv-clk = devm_clk_get(pdev-dev, core);
if (IS_ERR(priv-clk))
dev_warn(pdev-dev, cannot get core clock resource\n);
- /*
- * The driver doesn't need to know about the system (sys) or power
- * modulation (mod) clocks yet
- */
+
+ /* Get sys clock */
+ priv-sys_clk = devm_clk_get(pdev-dev, sys);
+ if (IS_ERR(priv-sys_clk))
+ dev_warn(pdev-dev, cannot get sys clock resource\n);
/* Set up raw hw decoder */
error = img_ir_probe_raw(priv);
@@ -152,6 +155,8 @@ static int img_ir_remove(struct platform_device *pdev)
if (!IS_ERR(priv-clk))
clk_disable_unprepare(priv-clk);
+ if (!IS_ERR(priv-sys_clk))
+ clk_disable_unprepare(priv-sys_clk);
return 0;
}
diff --git a/drivers/media/rc/img-ir/img-ir.h
b/drivers/media/rc/img-ir/img-ir.h
index 2ddf560..f1387c0 100644
--- a/drivers/media/rc/img-ir/img-ir.h
+++ b/drivers/media/rc/img-ir/img-ir.h
@@ -138,6 +138,7 @@ struct clk;
* @dev: Platform device.
* @irq: IRQ number.
* @clk: Input clock.
+ * @sys_clk: System clock.
* @reg_base:Iomem base address of IR register block.
* @lock:Protects IR registers and variables in this struct.
* @raw: Driver data for raw decoder.
@@ -147,6 +148,7 @@ struct img_ir_priv {
struct device *dev;
int irq;
struct clk *clk;
+ struct clk *sys_clk;
void __iomem*reg_base;
spinlock_t lock;
--
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 01/12] DT: leds: Improve description of flash LEDs related properties
Hello, On 31/03/15 15:52, Jacek Anaszewski wrote: Description of flash LEDs related properties was not precise regarding the state of corresponding settings in case a property is missing. Add relevant statements. Removed is also the requirement making the flash-max-microamp property obligatory for flash LEDs. It was inconsistent as the property is defined as optional. Devices which require the property will have to assert this in their DT bindings. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Bryan Wu coolo...@gmail.com Cc: Richard Purdie rpur...@rpsys.net Cc: Pavel Machek pa...@ucw.cz Cc: Sakari Ailus sakari.ai...@linux.intel.com Cc: devicet...@vger.kernel.org --- Documentation/devicetree/bindings/leds/common.txt | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt index 747c538..21a25e4 100644 --- a/Documentation/devicetree/bindings/leds/common.txt +++ b/Documentation/devicetree/bindings/leds/common.txt @@ -29,13 +29,15 @@ Optional properties for child nodes: ide-disk - LED indicates disk activity timer - LED flashes at a fixed, configurable rate -- max-microamp : maximum intensity in microamperes of the LED - (torch LED for flash devices) -- flash-max-microamp : maximum intensity in microamperes of the - flash LED; it is mandatory if the LED should -support the flash mode -- flash-timeout-us : timeout in microseconds after which the flash - LED is turned off +- max-microamp : Maximum intensity in microamperes of the LED + (torch LED for flash devices). If omitted this will default + to the maximum current allowed by the device. +- flash-max-microamp : Maximum intensity in microamperes of the flash LED. +If omitted this will default to the maximum +current allowed by the device. +- flash-timeout-us : Timeout in microseconds after which the flash + LED is turned off. If omitted this will default to the + maximum timeout allowed by the device. Sorry about late comments on that, but since we can still change these properties and it seems we're going to do that, I'd like throw in my few preferences on the colour of this bike... IMO max-microamp is a poor property name, how about: s/max-microamp/led-max-current-ua, s/flash-max-microamp/flash-max-current-ua, so we have more consistent set of properties like: led-max-current-ua flash-max-current-ua flash-timeout-us Also expressing light intensity in micro-amperes seems technically wrong. I would propose to substitute word intensity in microamperes with LED supply current in microamperes. I also think we should require the maximum current properties and the driver should warn if they are missing and limit current to some potentially safe value, e.g. small fraction of the maximum current. Also from the description it should be clear whether the current limits refer to capabilities of a LED or the desired settings we want to be applied at the LED driver device. We could, for example, add a sentence after the above 3 properties: Required properties for Flash LEDs: - led-max-current-ua - flash-max-current-ua - flash-timeout-us These properties determine a LED driver IC settings required for safe operation. Or something along these lines. -- 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 v3 0/5] Signalling last decoded frame by V4L2_BUF_FLAG_LAST and -EPIPE
On 04/07/15 16:44, Kamil Debski wrote: Hi, From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Tuesday, March 17, 2015 5:09 PM On 03/17/2015 11:46 AM, Philipp Zabel wrote: Hi, Am Freitag, den 06.03.2015, 11:18 +0100 schrieb Philipp Zabel: At the V4L2 codec API session during ELC-E 2014, we agreed that for the decoder draining flow, after a V4L2_DEC_CMD_STOP decoder command was issued, the last decoded buffer should get dequeued with a V4L2_BUF_FLAG_LAST set. After that, poll should immediately return and all following VIDIOC_DQBUF should return -EPIPE until the stream is stopped or decoding continued via V4L2_DEC_CMD_START. (or STREAMOFF/STREAMON). Changes since v2: - Made V4L2_BUF_FLAG_LAST known to trace events regards Philipp Peter Seiderer (1): [media] videodev2: Add V4L2_BUF_FLAG_LAST Philipp Zabel (4): [media] videobuf2: return -EPIPE from DQBUF after the last buffer [media] coda: Set last buffer flag and fix EOS event [media] s5p-mfc: Set last buffer flag [media] DocBooc: mention mem2mem codecs for encoder/decoder commands Documentation/DocBook/media/v4l/io.xml | 10 .../DocBook/media/v4l/vidioc-decoder-cmd.xml | 6 - .../DocBook/media/v4l/vidioc-encoder-cmd.xml | 5 +++- Documentation/DocBook/media/v4l/vidioc-qbuf.xml| 8 +++ drivers/media/platform/coda/coda-bit.c | 4 ++-- drivers/media/platform/coda/coda-common.c | 27 +-- --- drivers/media/platform/coda/coda.h | 3 +++ drivers/media/platform/s5p-mfc/s5p_mfc.c | 1 + drivers/media/v4l2-core/v4l2-mem2mem.c | 10 +++- drivers/media/v4l2-core/videobuf2-core.c | 18 ++- include/media/videobuf2-core.h | 10 include/trace/events/v4l2.h| 3 ++- include/uapi/linux/videodev2.h | 2 ++ 13 files changed, 84 insertions(+), 23 deletions(-) are there any further changes that I should make to this series? I'd like to see some Acks, esp. from Kamil and Pawel. I'll take another look as well, probably on Friday. The patches look good to me, the 4th version is already queued in my tree. However I would like to see your opinion. Especially from you Pawel :) It's unlikely I will have time this week for a review, but I've tentatively scheduled it for Monday. 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 4.1] mem2mem changes for 4.1
The following changes since commit c8c7c44b7cf5ef7163e4bd6aedbdeb6f6031ee3e: [media] s5p-jpeg: Remove some unused functions (2015-04-07 08:15:15 -0300) are available in the git repository at: git://linuxtv.org/kdebski/media_tree_2.git for-4.1-v2 for you to fetch changes up to 8dae02ffa32db8193513ee0a3c6dcd277e653954: coda: Add tracing support (2015-04-08 11:54:12 +0200) Kamil Debski (4): vb2: split the io_flags member of vb2_queue into a bit field vb2: add allow_zero_bytesused flag to the vb2_queue struct coda: set allow_zero_bytesused flag for vb2_queue_init s5p-mfc: set allow_zero_bytesused flag for vb2_queue_init Peter Seiderer (2): coda: check kasprintf return value in coda_open coda: fix double call to debugfs_remove Philipp Zabel (16): v4l2-mem2mem: no need to initialize b in v4l2_m2m_next_buf and v4l2_m2m_buf_remove gpu: ipu-v3: Add missing IDMAC channel names gpu: ipu-v3: Add mem2mem image conversion support to IC gpu: ipu-v3: Register scaler platform device coda: bitrate can only be set in kbps steps coda: bitstream payload is unsigned coda: use strlcpy instead of snprintf coda: allocate per-context buffers from REQBUFS coda: allocate bitstream buffer from REQBUFS, size depends on the format coda: move parameter buffer in together with context buffer allocation coda: remove duplicate error messages for buffer allocations coda: fail to start streaming if userspace set invalid formats coda: call SEQ_END when the first queue is stopped coda: fix fill bitstream errors in nonstreaming case coda: drop dma_sync_single_for_device in coda_bitstream_queue coda: Add tracing support Sascha Hauer (2): imx-ipu: Add ipu media common code imx-ipu: Add i.MX IPUv3 scaler driver drivers/gpu/ipu-v3/ipu-common.c |2 + drivers/gpu/ipu-v3/ipu-ic.c | 787 +++- drivers/media/platform/Kconfig |2 + drivers/media/platform/Makefile |1 + drivers/media/platform/coda/Makefile|2 + drivers/media/platform/coda/coda-bit.c | 205 +-- drivers/media/platform/coda/coda-common.c | 113 ++-- drivers/media/platform/coda/coda-jpeg.c |1 + drivers/media/platform/coda/coda.h | 18 +- drivers/media/platform/coda/trace.h | 203 +++ drivers/media/platform/imx/Kconfig | 11 + drivers/media/platform/imx/Makefile |2 + drivers/media/platform/imx/imx-ipu-scaler.c | 869 +++ drivers/media/platform/imx/imx-ipu.c| 313 ++ drivers/media/platform/imx/imx-ipu.h| 36 ++ drivers/media/platform/s5p-mfc/s5p_mfc.c|7 + drivers/media/v4l2-core/v4l2-mem2mem.c |4 +- drivers/media/v4l2-core/videobuf2-core.c| 56 +- include/media/videobuf2-core.h | 20 +- include/video/imx-ipu-v3.h | 49 +- 20 files changed, 2535 insertions(+), 166 deletions(-) create mode 100644 drivers/media/platform/coda/trace.h create mode 100644 drivers/media/platform/imx/Kconfig create mode 100644 drivers/media/platform/imx/Makefile create mode 100644 drivers/media/platform/imx/imx-ipu-scaler.c create mode 100644 drivers/media/platform/imx/imx-ipu.c create mode 100644 drivers/media/platform/imx/imx-ipu.h -- 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: cxd2099: move pre-init values out of init()
Em Sun, 8 Feb 2015 20:55:36 +
luisbg l...@debethencourt.com escreveu:
Improve code readability by moving out all pre-init values from the init
function.
Signed-off-by: Luis de Bethencourt luis...@samsung.com
---
drivers/staging/media/cxd2099/cxd2099.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/cxd2099/cxd2099.c
b/drivers/staging/media/cxd2099/cxd2099.c
index 657ea48..bafe36f 100644
--- a/drivers/staging/media/cxd2099/cxd2099.c
+++ b/drivers/staging/media/cxd2099/cxd2099.c
@@ -300,7 +300,6 @@ static int init(struct cxd *ci)
int status;
mutex_lock(ci-lock);
- ci-mode = -1;
do {
status = write_reg(ci, 0x00, 0x00);
if (status 0)
@@ -420,7 +419,6 @@ static int init(struct cxd *ci)
status = write_regm(ci, 0x09, 0x08, 0x08);
if (status 0)
break;
- ci-cammode = -1;
cam_mode(ci, 0);
} while (0);
mutex_unlock(ci-lock);
@@ -711,6 +709,8 @@ struct dvb_ca_en50221 *cxd2099_attach(struct cxd2099_cfg
*cfg,
ci-en = en_templ;
ci-en.data = ci;
+ ci-mode = -1;
+ ci-cammode = -1;
This actually changes the logic, as, cammode is == -1 only if the
do {} while loop succeeds.
Also, calling cam_mode(ci, 0) will change cammode to 0. Btw, for
it to work, ci-mode should be initialized earlier.
So, this patch looks very wrong on my eyes, except if you found
a real bug on it.
Have you tested it on a real device? What bug does it fix?
Regards,
Mauro
init(ci);
dev_info(i2c-dev, Attached CXD2099AR at %02x\n, ci-cfg.adr);
return ci-en;
--
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 01/12] DT: leds: Improve description of flash LEDs related properties
Hi! I think that a board designed so that it can be damaged because of software bugs should be considered not eligible for commercial use. Hello? It is 2015. Yes, that was nice rule... in 1995 or so :-). As I mentioned in the previous message in this subject, the max-microamp property refers also to non-flash LEDs. Since existing LED class devices does not require them, then it should be left optional and default to max. It would however be inconsistent with flash LEDs related properties. For non-flash LEDs and backward compatibility, I guess you are right. Inconsistency is fine in this case... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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
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 8 Apr 09:01:40 CEST 2015 git branch: test git hash: c8c7c44b7cf5ef7163e4bd6aedbdeb6f6031ee3e 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.19.0-1.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: WARNINGS linux-git-m32r: OK linux-git-mips: ERRORS linux-git-powerpc64: OK linux-git-sh: ERRORS 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: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16.7-i686: WARNINGS 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: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16.7-x86_64: OK linux-3.17.8-x86_64: OK linux-3.18.7-x86_64: OK linux-3.19-x86_64: OK linux-4.0-rc1-x86_64: OK apps: OK spec-git: OK ABI WARNING: change for arm-at91 ABI WARNING: change for arm-davinci ABI WARNING: change for arm-exynos ABI WARNING: change for arm-mx ABI WARNING: change for arm-omap ABI WARNING: change for arm-omap1 ABI WARNING: change for arm-pxa ABI WARNING: change for blackfin ABI WARNING: change for i686 ABI WARNING: change for m32r ABI WARNING: change for mips ABI WARNING: change for powerpc64 ABI WARNING: change for sh ABI WARNING: change for x86_64 sparse: WARNINGS 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: [PATCH v4 01/12] DT: leds: Improve description of flash LEDs related properties
Hi Bryan, Bryan Wu wrote: On Fri, Apr 3, 2015 at 1:37 PM, Pavel Machek pa...@ucw.cz wrote: Hi! +- flash-timeout-us : Timeout in microseconds after which the flash + LED is turned off. If omitted this will default to the +maximum timeout allowed by the device. Examples: Pavel pointed out that the brightness between maximum current and the maximum *allowed* another current might not be noticeable,leading a potential spelling error to cause the LED being run at too high current. Where did he point this out? Do you think about the current version of the leds/common.txt documentation or there was some other message, that I don't see? Date: Thu, 2 Apr 2015 22:30:44 +0200 From: Pavel Machek pa...@ucw.cz To: Sakari Ailus sakari.ai...@iki.fi Subject: Re: [PATCHv3] media: i2c/adp1653: devicetree support for adp1653 Besides, I can't understand your point. Could you express it in other words, please? Typo in device tree would cause hardware damage. But idea. Make the properties mandatory. Pavel I don't quite follow there. I think Pavel acked this patch right? So what's left to hold here? LED flash controllers are capable of providing more current than the LEDs attached to them can withstand without hardware damage. This is the reason the maximum current limits lower than the LED controller maximums are there. Pavel, quite rightly so in my opinion, is suggesting these properties are made mandatory. A typo in the DT source could cause the controller maximum current used instead of LED maximum which is often lower. That kind of a problem would easily go unnoticed since there isn't necessarily any perceivable change in the functionality of the board. You'd only notice later on, when the LEDs stop working. -- Regards, Sakari Ailus sakari.ai...@linux.intel.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: [PATCH v4 01/12] DT: leds: Improve description of flash LEDs related properties
On Tue 2015-04-07 18:20:08, Bryan Wu wrote: On Fri, Apr 3, 2015 at 1:37 PM, Pavel Machek pa...@ucw.cz wrote: Hi! +- flash-timeout-us : Timeout in microseconds after which the flash + LED is turned off. If omitted this will default to the +maximum timeout allowed by the device. Examples: Pavel pointed out that the brightness between maximum current and the maximum *allowed* another current might not be noticeable,leading a potential spelling error to cause the LED being run at too high current. Where did he point this out? Do you think about the current version of the leds/common.txt documentation or there was some other message, that I don't see? Date: Thu, 2 Apr 2015 22:30:44 +0200 From: Pavel Machek pa...@ucw.cz To: Sakari Ailus sakari.ai...@iki.fi Subject: Re: [PATCHv3] media: i2c/adp1653: devicetree support for adp1653 Besides, I can't understand your point. Could you express it in other words, please? Typo in device tree would cause hardware damage. But idea. Make the properties mandatory. Pavel I don't quite follow there. I think Pavel acked this patch right? So what's left to hold here? Yeah. Then I realized that patch is wrong/dangerous. Sorry about that. Try to forget about my ACK if you can ;-). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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 v4 01/12] DT: leds: Improve description of flash LEDs related properties
Hi Sakari, On 04/03/2015 02:09 PM, Sakari Ailus wrote: Hi Jacek, On Tue, Mar 31, 2015 at 03:52:37PM +0200, Jacek Anaszewski wrote: Description of flash LEDs related properties was not precise regarding the state of corresponding settings in case a property is missing. Add relevant statements. Removed is also the requirement making the flash-max-microamp property obligatory for flash LEDs. It was inconsistent as the property is defined as optional. Devices which require the property will have to assert this in their DT bindings. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Bryan Wu coolo...@gmail.com Cc: Richard Purdie rpur...@rpsys.net Cc: Pavel Machek pa...@ucw.cz Cc: Sakari Ailus sakari.ai...@linux.intel.com Cc: devicet...@vger.kernel.org --- Documentation/devicetree/bindings/leds/common.txt | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt index 747c538..21a25e4 100644 --- a/Documentation/devicetree/bindings/leds/common.txt +++ b/Documentation/devicetree/bindings/leds/common.txt @@ -29,13 +29,15 @@ Optional properties for child nodes: ide-disk - LED indicates disk activity timer - LED flashes at a fixed, configurable rate -- max-microamp : maximum intensity in microamperes of the LED -(torch LED for flash devices) -- flash-max-microamp : maximum intensity in microamperes of the - flash LED; it is mandatory if the LED should - support the flash mode -- flash-timeout-us : timeout in microseconds after which the flash - LED is turned off +- max-microamp : Maximum intensity in microamperes of the LED +(torch LED for flash devices). If omitted this will default +to the maximum current allowed by the device. +- flash-max-microamp : Maximum intensity in microamperes of the flash LED. + If omitted this will default to the maximum + current allowed by the device. +- flash-timeout-us : Timeout in microseconds after which the flash + LED is turned off. If omitted this will default to the +maximum timeout allowed by the device. Examples: Pavel pointed out that the brightness between maximum current and the maximum *allowed* another current might not be noticeable, leading a potential spelling error to cause the LED being run at too high current. I think that a board designed so that it can be damaged because of software bugs should be considered not eligible for commercial use. Any self-esteeming manufacturer will not connect a LED to the output that can produce the current greater than the LED's absolute maximum current. The DT properties could be useful for devices like aat1290 device I was writing a driver for, which has the maximum current and timeout values depending on corresponding capacitor and resistor values respectively. Such devices should make the properties required in their bindings. The three drivers I've looked also require these properties, which I think is in the line with the above. How about either dropping the patch, or changing maximum to minimum and will to should? The drivers could also behave this way instead of requiring the properties, but I don't think there's anything wrong with requiring the properties either. As I mentioned in the previous message in this subject, the max-microamp property refers also to non-flash LEDs. Since existing LED class devices does not require them, then it should be left optional and default to max. It would however be inconsistent with flash LEDs related properties. I think this is worth considering now as we can't change this later without breaking something. -- Best Regards, Jacek Anaszewski -- 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 01/12] DT: leds: Improve description of flash LEDs related properties
Hi Jacek, On Wed, Apr 08, 2015 at 10:54:52AM +0200, Jacek Anaszewski wrote: Hi Sakari, On 04/03/2015 02:09 PM, Sakari Ailus wrote: Hi Jacek, On Tue, Mar 31, 2015 at 03:52:37PM +0200, Jacek Anaszewski wrote: Description of flash LEDs related properties was not precise regarding the state of corresponding settings in case a property is missing. Add relevant statements. Removed is also the requirement making the flash-max-microamp property obligatory for flash LEDs. It was inconsistent as the property is defined as optional. Devices which require the property will have to assert this in their DT bindings. Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Bryan Wu coolo...@gmail.com Cc: Richard Purdie rpur...@rpsys.net Cc: Pavel Machek pa...@ucw.cz Cc: Sakari Ailus sakari.ai...@linux.intel.com Cc: devicet...@vger.kernel.org --- Documentation/devicetree/bindings/leds/common.txt | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/Documentation/devicetree/bindings/leds/common.txt b/Documentation/devicetree/bindings/leds/common.txt index 747c538..21a25e4 100644 --- a/Documentation/devicetree/bindings/leds/common.txt +++ b/Documentation/devicetree/bindings/leds/common.txt @@ -29,13 +29,15 @@ Optional properties for child nodes: ide-disk - LED indicates disk activity timer - LED flashes at a fixed, configurable rate -- max-microamp : maximum intensity in microamperes of the LED -(torch LED for flash devices) -- flash-max-microamp : maximum intensity in microamperes of the - flash LED; it is mandatory if the LED should - support the flash mode -- flash-timeout-us : timeout in microseconds after which the flash - LED is turned off +- max-microamp : Maximum intensity in microamperes of the LED +(torch LED for flash devices). If omitted this will default +to the maximum current allowed by the device. +- flash-max-microamp : Maximum intensity in microamperes of the flash LED. + If omitted this will default to the maximum + current allowed by the device. +- flash-timeout-us : Timeout in microseconds after which the flash + LED is turned off. If omitted this will default to the +maximum timeout allowed by the device. Examples: Pavel pointed out that the brightness between maximum current and the maximum *allowed* another current might not be noticeable, leading a potential spelling error to cause the LED being run at too high current. I think that a board designed so that it can be damaged because of software bugs should be considered not eligible for commercial use. Any self-esteeming manufacturer will not connect a LED to the output that can produce the current greater than the LED's absolute maximum current. The maximum current *is* used to prevent potential hardware damage. This is how mobile phones typically are, probably also the one you're using. :-) I don't believe there's really a difference between vendors in this respect. We still lack a proper way to model the temperature of the flash LED, so what we have now is a bit incomplete, but at least it prevents causing damage unintentionally. The DT properties could be useful for devices like aat1290 device I was writing a driver for, which has the maximum current and timeout values depending on corresponding capacitor and resistor values respectively. Such devices should make the properties required in their bindings. The three drivers I've looked also require these properties, which I think is in the line with the above. How about either dropping the patch, or changing maximum to minimum and will to should? The drivers could also behave this way instead of requiring the properties, but I don't think there's anything wrong with requiring the properties either. As I mentioned in the previous message in this subject, the max-microamp property refers also to non-flash LEDs. Since existing LED class devices does not require them, then it should be left optional and default to max. It would however be inconsistent with flash LEDs related properties. I do agree with Pavel here, these should be mandatory (at least for new drivers) OR default to minimum. -- 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] CONFIG_VIDEO_DEV needs to be enabled by MEDIA_DIGITAL_TV_SUPPORT also
Em Sun, 15 Feb 2015 22:13:13 + David Howells dhowe...@redhat.com escreveu: CONFIG_VIDEO_DEV needs to be enabled by MEDIA_DIGITAL_TV_SUPPORT so that DVB TV receiver drivers can be enabled. Actually, no. VIDEO_DEV enables the V4L2 core, with is not needed by pure DVB devices. Ok, some drivers are hybrid, and there's no way to enable just the DVB part of the driver. So, for those specific drivers, both analog and digital support should be enabled. This is actually a driver issue, as the driver was written originally for analog, and then extended to support digital, without making the analog part optional. I fixed this on a few drivers (like em28xx). It is not that hard to split the driver, but it requires some care and careful tests to avoiding breaking the driver, as sometimes the register init for the device mixes analog and digital init at the same part of the driver. Regards, Mauro Signed-off-by: David Howells dhowe...@redhat.com --- drivers/media/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig index 49cd308..52d4a20 100644 --- a/drivers/media/Kconfig +++ b/drivers/media/Kconfig @@ -102,7 +102,7 @@ config MEDIA_CONTROLLER config VIDEO_DEV tristate depends on MEDIA_SUPPORT - depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || MEDIA_RADIO_SUPPORT || MEDIA_SDR_SUPPORT + depends on MEDIA_CAMERA_SUPPORT || MEDIA_ANALOG_TV_SUPPORT || MEDIA_DIGITAL_TV_SUPPORT || MEDIA_RADIO_SUPPORT || MEDIA_SDR_SUPPORT default y config VIDEO_V4L2_SUBDEV_API -- 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] v4l: vb2-memops: use vma slab when vma allocation
Mauro,
Please revert this patch: vm_area_cachep is not exported, so you cannot use this
in a module.
Cho KyongHo, if you believe that vm_area_cachep should be exported so it can be
used here, then please make a patch for that.
For the time being though, this patch should be reverted.
This patch slipped through the cracks and I clearly never reviewed it, and I
only
noticed the problem after I compiled the media_tree git repo after this patch
was merged.
Regards,
Hans
On 02/05/2015 06:52 AM, Cho KyongHo wrote:
The slab for vm_area_struct which is vm_area_cachep is already prepared
for the general use. Instead of kmalloc() for the vma copy for userptr,
allocation from vm_area_cachep is more beneficial.
CC: Mauro Carvalho Chehab mche...@osg.samsung.com
CC: Hans Verkuil hans.verk...@cisco.com
CC: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Cho KyongHo pullip@samsung.com
---
drivers/media/v4l2-core/videobuf2-memops.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-memops.c
b/drivers/media/v4l2-core/videobuf2-memops.c
index 81c1ad8..dd06efa 100644
--- a/drivers/media/v4l2-core/videobuf2-memops.c
+++ b/drivers/media/v4l2-core/videobuf2-memops.c
@@ -37,7 +37,7 @@ struct vm_area_struct *vb2_get_vma(struct vm_area_struct
*vma)
{
struct vm_area_struct *vma_copy;
- vma_copy = kmalloc(sizeof(*vma_copy), GFP_KERNEL);
+ vma_copy = kmem_cache_alloc(vm_area_cachep, GFP_KERNEL);
if (vma_copy == NULL)
return NULL;
@@ -75,7 +75,7 @@ void vb2_put_vma(struct vm_area_struct *vma)
if (vma-vm_file)
fput(vma-vm_file);
- kfree(vma);
+ kmem_cache_free(vm_area_cachep, vma);
}
EXPORT_SYMBOL_GPL(vb2_put_vma);
--
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 01/12] DT: leds: Improve description of flash LEDs related properties
Hi Jacek, On 08/04/15 13:58, Jacek Anaszewski wrote: --- a/Documentation/devicetree/bindings/leds/common.txt +++ b/Documentation/devicetree/bindings/leds/common.txt @@ -29,13 +29,15 @@ Optional properties for child nodes: ide-disk - LED indicates disk activity timer - LED flashes at a fixed, configurable rate -- max-microamp : maximum intensity in microamperes of the LED - (torch LED for flash devices) -- flash-max-microamp : maximum intensity in microamperes of the - flash LED; it is mandatory if the LED should - support the flash mode -- flash-timeout-us : timeout in microseconds after which the flash - LED is turned off +- max-microamp : Maximum intensity in microamperes of the LED + (torch LED for flash devices). If omitted this will default + to the maximum current allowed by the device. +- flash-max-microamp : Maximum intensity in microamperes of the flash LED. + If omitted this will default to the maximum + current allowed by the device. +- flash-timeout-us : Timeout in microseconds after which the flash + LED is turned off. If omitted this will default to the + maximum timeout allowed by the device. Sorry about late comments on that, but since we can still change these properties and it seems we're going to do that, I'd like throw in my few preferences on the colour of this bike... IMO max-microamp is a poor property name, how about: s/max-microamp/led-max-current-ua, s/flash-max-microamp/flash-max-current-ua, so we have more consistent set of properties like: led-max-current-ua flash-max-current-ua flash-timeout-us The -microamp' suffix is consistent with regulator bindings. Please refer to [1]. OK, in a perfect world we would have clean and consistent notation of units. If it's acked let's leave it, I didn't know it was, sorry about that. When I read yesterday Documentation/devicetree/bindings/leds/common.txt the set of new properties looked rather sloppy, especially max-microamp looked incomplete to me, as if the subject was missing. Anyway, I'll just get used to it, let's complete this whole Flash/LED integration story. -- 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
[PATCH 2/2] v4l2-dv-timings: fix rounding in hblank and hsync calculation
Changed the rounding calculation for hblank and hsync to match it to equations in standards. Currently hblank and hsync are rounded down. hblank needs to be rounded to nearest multiple of twice the cell granularity. hsync needs to be rounded to nearest multiple of cell granularity. Cc: Hans Verkuil hans.verk...@cisco.com Cc: Martin Bugge marbu...@cisco.com Signed-off-by: Prashant Laddha prlad...@cisco.com --- drivers/media/v4l2-core/v4l2-dv-timings.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/media/v4l2-core/v4l2-dv-timings.c b/drivers/media/v4l2-core/v4l2-dv-timings.c index 5e114ee..4b8ec4e 100644 --- a/drivers/media/v4l2-core/v4l2-dv-timings.c +++ b/drivers/media/v4l2-core/v4l2-dv-timings.c @@ -570,14 +570,15 @@ bool v4l2_detect_gtf(unsigned frame_height, (hfreq * (100 - GTF_S_C_PRIME) + GTF_S_M_PRIME * 1000) / 2) / (hfreq * (100 - GTF_S_C_PRIME) + GTF_S_M_PRIME * 1000); - h_blank = h_blank - h_blank % (2 * GTF_CELL_GRAN); + h_blank = ((h_blank + GTF_CELL_GRAN) / (2 * GTF_CELL_GRAN)) * + (2 * GTF_CELL_GRAN); frame_width = image_width + h_blank; pix_clk = (image_width + h_blank) * hfreq; pix_clk = pix_clk / GTF_PXL_CLK_GRAN * GTF_PXL_CLK_GRAN; hsync = (frame_width * 8 + 50) / 100; - hsync = hsync - hsync % GTF_CELL_GRAN; + hsync = ((hsync + GTF_CELL_GRAN / 2) / GTF_CELL_GRAN) * GTF_CELL_GRAN; h_fp = h_blank / 2 - hsync; -- 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
Wonga Loans
Wonga Loans Wonga Express Loan Promtion.pdf Description: Adobe PDF document
[PATCH] Add support for interlaced format in detect cvt/gtf
Extended detect_cvt/gtf API to indicate the scan type (interlaced
or progressive). In case of interlaced, the vertical front and back
porch and vsync values for both (odd,even) fields are considered to
derive image height. Populated vsync, verical front, back porch
values in bt timing structure for even and odd fields and updated
the flags appropriately.
Cc: Hans Verkuil hans.verk...@cisco.com
Cc: Martin Bugge marbu...@cisco.com
Cc: Mats Randgaard matra...@cisco.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Prashant Laddha prlad...@cisco.com
---
drivers/media/i2c/adv7604.c | 4 +++
drivers/media/i2c/adv7842.c | 8 --
drivers/media/platform/vivid/vivid-vid-cap.c | 5 ++--
drivers/media/v4l2-core/v4l2-dv-timings.c| 39
include/media/v4l2-dv-timings.h | 6 +++--
5 files changed, 51 insertions(+), 11 deletions(-)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 1e58537..bdc1d6d 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -1304,11 +1304,15 @@ static int stdi2dv_timings(struct v4l2_subdev *sd,
if (v4l2_detect_cvt(stdi-lcf + 1, hfreq, stdi-lcvs,
(stdi-hs_pol == '+' ? V4L2_DV_HSYNC_POS_POL : 0) |
(stdi-vs_pol == '+' ? V4L2_DV_VSYNC_POS_POL : 0),
+ stdi-interlaced ? V4L2_DV_INTERLACED :
+ V4L2_DV_PROGRESSIVE,
timings))
return 0;
if (v4l2_detect_gtf(stdi-lcf + 1, hfreq, stdi-lcvs,
(stdi-hs_pol == '+' ? V4L2_DV_HSYNC_POS_POL : 0) |
(stdi-vs_pol == '+' ? V4L2_DV_VSYNC_POS_POL : 0),
+ stdi-interlaced ? V4L2_DV_INTERLACED :
+ V4L2_DV_PROGRESSIVE,
state-aspect_ratio, timings))
return 0;
diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c
index 7c215ee..b93ad27 100644
--- a/drivers/media/i2c/adv7842.c
+++ b/drivers/media/i2c/adv7842.c
@@ -1333,12 +1333,16 @@ static int stdi2dv_timings(struct v4l2_subdev *sd,
if (v4l2_detect_cvt(stdi-lcf + 1, hfreq, stdi-lcvs,
(stdi-hs_pol == '+' ? V4L2_DV_HSYNC_POS_POL : 0) |
(stdi-vs_pol == '+' ? V4L2_DV_VSYNC_POS_POL : 0),
- timings))
+ stdi-interlaced ? V4L2_DV_INTERLACED :
+ V4L2_DV_PROGRESSIVE,
+ timings))
return 0;
if (v4l2_detect_gtf(stdi-lcf + 1, hfreq, stdi-lcvs,
(stdi-hs_pol == '+' ? V4L2_DV_HSYNC_POS_POL : 0) |
(stdi-vs_pol == '+' ? V4L2_DV_VSYNC_POS_POL : 0),
- state-aspect_ratio, timings))
+ stdi-interlaced ? V4L2_DV_INTERLACED :
+ V4L2_DV_PROGRESSIVE,
+ state-aspect_ratio, timings))
return 0;
v4l2_dbg(2, debug, sd,
diff --git a/drivers/media/platform/vivid/vivid-vid-cap.c
b/drivers/media/platform/vivid/vivid-vid-cap.c
index ede168a..5e2b712 100644
--- a/drivers/media/platform/vivid/vivid-vid-cap.c
+++ b/drivers/media/platform/vivid/vivid-vid-cap.c
@@ -1620,7 +1620,7 @@ static bool valid_cvt_gtf_timings(struct v4l2_dv_timings
*timings)
if (bt-standards == 0 || (bt-standards V4L2_DV_BT_STD_CVT)) {
if (v4l2_detect_cvt(total_v_lines, h_freq, bt-vsync,
- bt-polarities, timings))
+ bt-polarities, bt-interlaced, timings))
return true;
}
@@ -1631,7 +1631,8 @@ static bool valid_cvt_gtf_timings(struct v4l2_dv_timings
*timings)
aspect_ratio.numerator,
aspect_ratio.denominator);
if (v4l2_detect_gtf(total_v_lines, h_freq, bt-vsync,
- bt-polarities, aspect_ratio, timings))
+ bt-polarities, bt-interlaced,
+ aspect_ratio, timings))
return true;
}
return false;
diff --git a/drivers/media/v4l2-core/v4l2-dv-timings.c
b/drivers/media/v4l2-core/v4l2-dv-timings.c
index b1d8dbb..80e4722 100644
--- a/drivers/media/v4l2-core/v4l2-dv-timings.c
+++ b/drivers/media/v4l2-core/v4l2-dv-timings.c
@@ -335,6 +335,7 @@ EXPORT_SYMBOL_GPL(v4l2_print_dv_timings);
* @vsync - the height of the vertical sync in lines.
* @polarities - the horizontal and vertical polarities (same as struct
* v4l2_bt_timings polarities).
+ * @scan - V4L2_DV_INTERLACED or V4L2_DV_PROGRESSIVE
* @fmt - the resulting timings.
*
* This function will attempt to detect if the given
support for interlaced format in detect cvt/gtf
While I was working with Hans on adding cvt/gtf modeline calculations in v4l2 utils, we thought that it would be nice to extend the detect cvt/gtf functionality in v4l2-dv-timings to handle interlaced format. Please find the patch for the same. Regards, Prashant -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] media: Correctly notify about the failed pipeline validation
Hello Sakari,
Thank you for the patch.
On Thursday 12 February 2015 15:43:11 Sakari Ailus wrote:
On the place of the source entity name, the sink entity name was printed.
Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
and applied to my tree. It's a bit late for v4.1, can it wait for v4.2 ?
---
drivers/media/media-entity.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index defe4ac..d894481 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -283,9 +283,9 @@ __must_check int media_entity_pipeline_start(struct
media_entity *entity, if (ret 0 ret != -ENOIOCTLCMD) {
dev_dbg(entity-parent-dev,
link validation failed for \%s\:%u
- \%s\:%u, error
%d\n,
- entity-name, link-source-index,
- link-sink-entity-name,
- link-sink-index, ret);
+ link-source-entity-name,
+ link-source-index,
+ entity-name, link-sink-index, ret);
goto error;
}
}
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] v4l2-dv-timings: fix rounding error in vsync_bp calculation
Changed the rounding offsets used in vsync_bp calculation in cvt and
gtf timings. The results for vsync_bp should now match with results
from timing generator spreadsheets for cvt and gtf standards.
In the vsync_bp calculation for cvt, always round down the value of
(CVT_MIN_VSYNC_BP / h_period_est) and then add 1. It thus, reflects
the equation used in timing generator spreadsheet. Using 199 as
rounding offset, could pontentially lead to bumping up the vsync_bp
value by extra 1.
In the vsync_bp calculations for gtf, instead of round up or round
down, round the (CVT_MIN_VSYNC_BP / h_period_est) to the nearest
integer.
Cc: Hans Verkuil hans.verk...@cisco.com
Cc: Martin Bugge marbu...@cisco.com
Thanks to Martin Bugge marbu...@cisco.com for validating with
standards and suggestions on equations.
Signed-off-by: Prashant Laddha prlad...@cisco.com
---
drivers/media/v4l2-core/v4l2-dv-timings.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-dv-timings.c
b/drivers/media/v4l2-core/v4l2-dv-timings.c
index 80e4722..5e114ee 100644
--- a/drivers/media/v4l2-core/v4l2-dv-timings.c
+++ b/drivers/media/v4l2-core/v4l2-dv-timings.c
@@ -367,14 +367,14 @@ bool v4l2_detect_cvt(unsigned frame_height, unsigned
hfreq, unsigned vsync,
/* Vertical */
if (reduced_blanking) {
v_fp = CVT_RB_V_FPORCH;
- v_bp = (CVT_RB_MIN_V_BLANK * hfreq + 199) / 100;
+ v_bp = (CVT_RB_MIN_V_BLANK * hfreq) / 100 + 1;
v_bp -= vsync + v_fp;
if (v_bp CVT_RB_MIN_V_BPORCH)
v_bp = CVT_RB_MIN_V_BPORCH;
} else {
v_fp = CVT_MIN_V_PORCH_RND;
- v_bp = (CVT_MIN_VSYNC_BP * hfreq + 199) / 100 - vsync;
+ v_bp = (CVT_MIN_VSYNC_BP * hfreq) / 100 + 1 - vsync;
if (v_bp CVT_MIN_V_BPORCH)
v_bp = CVT_MIN_V_BPORCH;
@@ -543,7 +543,7 @@ bool v4l2_detect_gtf(unsigned frame_height,
/* Vertical */
v_fp = GTF_V_FP;
- v_bp = (GTF_MIN_VSYNC_BP * hfreq + 99) / 100 - vsync;
+ v_bp = (GTF_MIN_VSYNC_BP * hfreq + 50) / 100 - vsync;
if (scan == V4L2_DV_INTERLACED)
image_height = (frame_height - 2 * v_fp - 2 * vsync - 2 * v_bp)
--
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
fix for rounding errors in cvt/gtf calculation
While I was testing cvt / gtf timings against the timings given by standards timing generator spreadsheets, there were differences in results for some of the formats. Those differences could be traced back to the rounding used to compute some of the intermediate values. Following two patches fixes two such rounding errors. [PATCH 1/2] v4l2-dv-timings: fix rounding error in vsync_bp [PATCH 2/2] v4l2-dv-timings: fix rounding in hblank and hsync Please review and share your comments. Regards, Prashant -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] media: Correctly notify about the failed pipeline validation
Hi Laurent, Laurent Pinchart wrote: Hello Sakari, Thank you for the patch. On Thursday 12 February 2015 15:43:11 Sakari Ailus wrote: On the place of the source entity name, the sink entity name was printed. Signed-off-by: Sakari Ailus sakari.ai...@linux.intel.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com and applied to my tree. It's a bit late for v4.1, can it wait for v4.2 ? Thanks! v4.2 is fine. This is just a bug fix in a debug print. I wouldn't bother with stable or v4.1. -- Sakari Ailus sakari.ai...@linux.intel.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: [PATCH] rc: img-ir: Add and enable sys clock for IR
Hi Mauro,
I sent you a v2 of this patch on 4th February:
From: Sifan Naeem
Sent: 04 February 2015 16:48
To: James Hogan; mche...@osg.samsung.com
Cc: linux-ker...@vger.kernel.org; linux-media@vger.kernel.org; Sifan Naeem
Subject: [PATCH v2] rc: img-ir: Add and enable sys clock for img-ir
Unfortunately, while trying to improve the commit message in v2 I had changed
the last word of the patch name from IR to img-ir.
Do you want me to do a diff between the 2 patches and send you a new patch?
Sifan
-Original Message-
From: Mauro Carvalho Chehab [mailto:mche...@osg.samsung.com]
Sent: 08 April 2015 12:32
To: Sifan Naeem
Cc: James Hogan; linux-ker...@vger.kernel.org; linux-
me...@vger.kernel.org
Subject: Re: [PATCH] rc: img-ir: Add and enable sys clock for IR
Em Tue, 3 Feb 2015 17:30:29 +
Sifan Naeem sifan.na...@imgtec.com escreveu:
Gets a handle to the system clock, already described in the binding
document, and calls the appropriate common clock framework functions
to mark it prepared/enabled, the common clock framework initially
enables the clock and doesn't disable it at least until the
device/driver is removed.
The system clock to IR is needed for the driver to communicate with
the IR hardware via MMIO accesses on the system bus, so it must not be
disabled during use or the driver will malfunction.
Hmm... patchwork has two versions of this patch, but I have only one on my
e-mail.
Could you please check if I applied the right one? If not, please send me an
email with a fixup patch.
Thanks!
Mauro
Signed-off-by: Sifan Naeem sifan.na...@imgtec.com
---
drivers/media/rc/img-ir/img-ir-core.c | 13 +
drivers/media/rc/img-ir/img-ir.h |2 ++
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/media/rc/img-ir/img-ir-core.c
b/drivers/media/rc/img-ir/img-ir-core.c
index 77c78de..783dd21 100644
--- a/drivers/media/rc/img-ir/img-ir-core.c
+++ b/drivers/media/rc/img-ir/img-ir-core.c
@@ -60,6 +60,8 @@ static void img_ir_setup(struct img_ir_priv *priv)
if (!IS_ERR(priv-clk))
clk_prepare_enable(priv-clk);
+ if (!IS_ERR(priv-sys_clk))
+ clk_prepare_enable(priv-sys_clk);
}
static void img_ir_ident(struct img_ir_priv *priv) @@ -110,10 +112,11
@@ static int img_ir_probe(struct platform_device *pdev)
priv-clk = devm_clk_get(pdev-dev, core);
if (IS_ERR(priv-clk))
dev_warn(pdev-dev, cannot get core clock resource\n);
- /*
-* The driver doesn't need to know about the system (sys) or
power
-* modulation (mod) clocks yet
-*/
+
+ /* Get sys clock */
+ priv-sys_clk = devm_clk_get(pdev-dev, sys);
+ if (IS_ERR(priv-sys_clk))
+ dev_warn(pdev-dev, cannot get sys clock resource\n);
/* Set up raw hw decoder */
error = img_ir_probe_raw(priv);
@@ -152,6 +155,8 @@ static int img_ir_remove(struct platform_device
*pdev)
if (!IS_ERR(priv-clk))
clk_disable_unprepare(priv-clk);
+ if (!IS_ERR(priv-sys_clk))
+ clk_disable_unprepare(priv-sys_clk);
return 0;
}
diff --git a/drivers/media/rc/img-ir/img-ir.h
b/drivers/media/rc/img-ir/img-ir.h
index 2ddf560..f1387c0 100644
--- a/drivers/media/rc/img-ir/img-ir.h
+++ b/drivers/media/rc/img-ir/img-ir.h
@@ -138,6 +138,7 @@ struct clk;
* @dev: Platform device.
* @irq: IRQ number.
* @clk: Input clock.
+ * @sys_clk: System clock.
* @reg_base: Iomem base address of IR register block.
* @lock: Protects IR registers and variables in this struct.
* @raw: Driver data for raw decoder.
@@ -147,6 +148,7 @@ struct img_ir_priv {
struct device *dev;
int irq;
struct clk *clk;
+ struct clk *sys_clk;
void __iomem*reg_base;
spinlock_t lock;
--
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: cxd2099: move pre-init values out of init()
On Wed, Apr 08, 2015 at 08:09:03AM -0300, Mauro Carvalho Chehab wrote:
Em Sun, 8 Feb 2015 20:55:36 +
luisbg l...@debethencourt.com escreveu:
Improve code readability by moving out all pre-init values from the init
function.
Signed-off-by: Luis de Bethencourt luis...@samsung.com
---
drivers/staging/media/cxd2099/cxd2099.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/media/cxd2099/cxd2099.c
b/drivers/staging/media/cxd2099/cxd2099.c
index 657ea48..bafe36f 100644
--- a/drivers/staging/media/cxd2099/cxd2099.c
+++ b/drivers/staging/media/cxd2099/cxd2099.c
@@ -300,7 +300,6 @@ static int init(struct cxd *ci)
int status;
mutex_lock(ci-lock);
- ci-mode = -1;
do {
status = write_reg(ci, 0x00, 0x00);
if (status 0)
@@ -420,7 +419,6 @@ static int init(struct cxd *ci)
status = write_regm(ci, 0x09, 0x08, 0x08);
if (status 0)
break;
- ci-cammode = -1;
cam_mode(ci, 0);
} while (0);
mutex_unlock(ci-lock);
@@ -711,6 +709,8 @@ struct dvb_ca_en50221 *cxd2099_attach(struct
cxd2099_cfg *cfg,
ci-en = en_templ;
ci-en.data = ci;
+ ci-mode = -1;
+ ci-cammode = -1;
This actually changes the logic, as, cammode is == -1 only if the
do {} while loop succeeds.
Also, calling cam_mode(ci, 0) will change cammode to 0. Btw, for
it to work, ci-mode should be initialized earlier.
So, this patch looks very wrong on my eyes, except if you found
a real bug on it.
Have you tested it on a real device? What bug does it fix?
Regards,
Mauro
Apologies. You are right and this patch is completely wrong.
I submitted this while reading the code of a few drivers to learn from them.
I should've retracted it before you spent time reviewing it. Sorry for that.
Thanks,
Luis
init(ci);
dev_info(i2c-dev, Attached CXD2099AR at %02x\n, ci-cfg.adr);
return ci-en;
--
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] Misc UVC and OMAP3 ISP patches
Hi Mauro, If there's still time to get fixes merged in v4.1, please pull the following changes. The following changes since commit c8c7c44b7cf5ef7163e4bd6aedbdeb6f6031ee3e: [media] s5p-jpeg: Remove some unused functions (2015-04-07 08:15:15 -0300) are available in the git repository at: git://linuxtv.org/pinchartl/media.git v4l2/next for you to fetch changes up to 7543cd6741b602eb47560130a5c9d32fa16f62a2: uvcvideo: add support for VIDIOC_QUERY_EXT_CTRL (2015-04-08 16:42:29 +0300) Hans Verkuil (2): uvcvideo: fix cropcap v4l2-compliance failure uvcvideo: add support for VIDIOC_QUERY_EXT_CTRL Russell King (1): media: omap3isp: remove unused clkdev drivers/media/platform/omap3isp/isp.c | 24 drivers/media/platform/omap3isp/isp.h | 1 - drivers/media/usb/uvc/uvc_v4l2.c | 65 -- include/media/omap3isp.h | 6 4 files changed, 53 insertions(+), 43 deletions(-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rc: img-ir: Add and enable sys clock for IR
Em Wed, 08 Apr 2015 13:56:14 +
Sifan Naeem sifan.na...@imgtec.com escreveu:
Hi Mauro,
I sent you a v2 of this patch on 4th February:
From: Sifan Naeem
Sent: 04 February 2015 16:48
To: James Hogan; mche...@osg.samsung.com
Cc: linux-ker...@vger.kernel.org; linux-media@vger.kernel.org; Sifan Naeem
Subject: [PATCH v2] rc: img-ir: Add and enable sys clock for img-ir
Unfortunately, while trying to improve the commit message in v2 I had changed
the last word of the patch name from IR to img-ir.
Do you want me to do a diff between the 2 patches and send you a new patch?
Yes, please do that, changing the patch name/description to reflect
what changed since v1.
Regards,
Mauro
Sifan
-Original Message-
From: Mauro Carvalho Chehab [mailto:mche...@osg.samsung.com]
Sent: 08 April 2015 12:32
To: Sifan Naeem
Cc: James Hogan; linux-ker...@vger.kernel.org; linux-
me...@vger.kernel.org
Subject: Re: [PATCH] rc: img-ir: Add and enable sys clock for IR
Em Tue, 3 Feb 2015 17:30:29 +
Sifan Naeem sifan.na...@imgtec.com escreveu:
Gets a handle to the system clock, already described in the binding
document, and calls the appropriate common clock framework functions
to mark it prepared/enabled, the common clock framework initially
enables the clock and doesn't disable it at least until the
device/driver is removed.
The system clock to IR is needed for the driver to communicate with
the IR hardware via MMIO accesses on the system bus, so it must not be
disabled during use or the driver will malfunction.
Hmm... patchwork has two versions of this patch, but I have only one on my
e-mail.
Could you please check if I applied the right one? If not, please send me an
email with a fixup patch.
Thanks!
Mauro
Signed-off-by: Sifan Naeem sifan.na...@imgtec.com
---
drivers/media/rc/img-ir/img-ir-core.c | 13 +
drivers/media/rc/img-ir/img-ir.h |2 ++
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/media/rc/img-ir/img-ir-core.c
b/drivers/media/rc/img-ir/img-ir-core.c
index 77c78de..783dd21 100644
--- a/drivers/media/rc/img-ir/img-ir-core.c
+++ b/drivers/media/rc/img-ir/img-ir-core.c
@@ -60,6 +60,8 @@ static void img_ir_setup(struct img_ir_priv *priv)
if (!IS_ERR(priv-clk))
clk_prepare_enable(priv-clk);
+ if (!IS_ERR(priv-sys_clk))
+ clk_prepare_enable(priv-sys_clk);
}
static void img_ir_ident(struct img_ir_priv *priv) @@ -110,10 +112,11
@@ static int img_ir_probe(struct platform_device *pdev)
priv-clk = devm_clk_get(pdev-dev, core);
if (IS_ERR(priv-clk))
dev_warn(pdev-dev, cannot get core clock resource\n);
- /*
- * The driver doesn't need to know about the system (sys) or
power
- * modulation (mod) clocks yet
- */
+
+ /* Get sys clock */
+ priv-sys_clk = devm_clk_get(pdev-dev, sys);
+ if (IS_ERR(priv-sys_clk))
+ dev_warn(pdev-dev, cannot get sys clock resource\n);
/* Set up raw hw decoder */
error = img_ir_probe_raw(priv);
@@ -152,6 +155,8 @@ static int img_ir_remove(struct platform_device
*pdev)
if (!IS_ERR(priv-clk))
clk_disable_unprepare(priv-clk);
+ if (!IS_ERR(priv-sys_clk))
+ clk_disable_unprepare(priv-sys_clk);
return 0;
}
diff --git a/drivers/media/rc/img-ir/img-ir.h
b/drivers/media/rc/img-ir/img-ir.h
index 2ddf560..f1387c0 100644
--- a/drivers/media/rc/img-ir/img-ir.h
+++ b/drivers/media/rc/img-ir/img-ir.h
@@ -138,6 +138,7 @@ struct clk;
* @dev: Platform device.
* @irq: IRQ number.
* @clk: Input clock.
+ * @sys_clk: System clock.
* @reg_base:Iomem base address of IR register block.
* @lock:Protects IR registers and variables in this
struct.
* @raw: Driver data for raw decoder.
@@ -147,6 +148,7 @@ struct img_ir_priv {
struct device *dev;
int irq;
struct clk *clk;
+ struct clk *sys_clk;
void __iomem*reg_base;
spinlock_t lock;
--
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: [PATCHv4] [media] saa7164: use an MSI interrupt when available
Hi Brendan,
The idea is good,
Some comments bellow.
Em Sat, 14 Mar 2015 14:27:39 +1100
Brendan McGrath red...@redmandi.dyndns.org escreveu:
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 both digital tuners of the saa7164 chip is in use. A reported
example can
be found here:
http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/83948
Reviewed-by: Steven Toth st...@kernellabs.com
Signed-off-by: Brendan McGrath red...@redmandi.dyndns.org
---
Changes since v3:
- fixes a conflict with a commit (3f845f3c4cf4) made to the media_tree
after v3 was created (only the unified context has been changed)
- corrected comments to reflect that the reported incident occured more
commonly when multiple tuners were in use (not multiple saa7164 chips as
previously stated)
drivers/media/pci/saa7164/saa7164-core.c | 40
++--
drivers/media/pci/saa7164/saa7164.h | 1 +
2 files changed, 39 insertions(+), 2 deletions(-)
diff --git a/drivers/media/pci/saa7164/saa7164-core.c
b/drivers/media/pci/saa7164/saa7164-core.c
index 9cf3c6c..7635598 100644
--- a/drivers/media/pci/saa7164/saa7164-core.c
+++ b/drivers/media/pci/saa7164/saa7164-core.c
@@ -85,6 +85,11 @@ module_param(guard_checking, int, 0644);
MODULE_PARM_DESC(guard_checking,
enable dma sanity checking for buffer overruns);
+static bool enable_msi = true;
+module_param(enable_msi, bool, 0444);
+MODULE_PARM_DESC(enable_msi,
+ enable the use of an msi interrupt if available);
+
static unsigned int saa7164_devcount;
static DEFINE_MUTEX(devlist);
@@ -1230,8 +1235,34 @@ static int saa7164_initdev(struct pci_dev *pci_dev,
goto fail_irq;
}
- err = request_irq(pci_dev-irq, saa7164_irq,
- IRQF_SHARED, dev-name, dev);
+ /* irq bit */
+ if (enable_msi)
+ err = pci_enable_msi(pci_dev);
It is worth printing a warning about that.
+
+ if (!err enable_msi) {
+ /* no error - so request an msi interrupt */
+ err = request_irq(pci_dev-irq, saa7164_irq, 0,
+ dev-name, dev);
+
+ if (err) {
+ /* fall back to legacy interrupt */
+ printk(KERN_ERR %s() Failed to get an MSI interrupt.
+ Falling back to a shared IRQ\n, __func__);
+ pci_disable_msi(pci_dev);
+ } else {
+ dev-msi = true;
+ }
+ }
It would be better to join this if with the next one, in order
to make clear that both belong to the enable_msi logic. Something like:
static bool saa7164_enable_msi(struct device *pci_dev)
{
if (!enable_msi)
return false;
err = pci_enable_msi(pci_dev);
if (err) {
printf(KERN_ERR %s() Failed to enable MSI
Falling back to a shared IRQ\n, __func__);
return false;
}
err = request_irq(pci_dev-irq, saa7164_irq, 0,
dev-name, dev);
if (err) {
printk(KERN_ERR %s() Failed to get an MSI interrupt.
Falling back to a shared IRQ\n, __func__);
pci_disable_msi(pci_dev);
return false;
}
return true;
}
Then, at the probe function, you could simply do:
if (saa7164_enable_msi(pci_dev)) {
dev-msi = true;
} else {
/* SOME_FALLBACK_CODE */
}
The probe function is already complex enough. Breaking it into small
inlined functions makes easier to review. The removal of the if's
is an extra bonus, as the code size will likely be a little bit smaller.
+
+ if ((!enable_msi) || err) {
+ dev-msi = false;
No need, as dev was initialized with kzalloc(), with zeroes all fields.
Also, you can simplify the if clause to:
if (!dev-msi) {
That makes clearer that the code below is to be used when MSI is not
enabled or not initialized properly.
+ /* if we have an error (i.e. we don't have an interrupt)
+ or msi is not enabled - fallback to shared interrupt */
+
+ err = request_irq(pci_dev-irq, saa7164_irq,
+ IRQF_SHARED, dev-name, dev);
+ }
+
if (err 0) {
printk(KERN_ERR %s: can't get IRQ %d\n, dev-name,
pci_dev-irq);
@@ -1439,6 +1470,11 @@ static void saa7164_finidev(struct pci_dev *pci_dev)
/* unregister stuff */
free_irq(pci_dev-irq, dev);
+ if (dev-msi) {
+ pci_disable_msi(pci_dev);
+ dev-msi = false;
+ }
+
Re: [PATCH v3 3/4] v4l: of: Parse variable length properties --- link-frequencies
Hi Laurent,
On Tue, Apr 07, 2015 at 01:02:31PM +0300, Laurent Pinchart wrote:
Hello Sakari,
Thank you for the patch.
Thanks for the review!
On Tuesday 07 April 2015 01:57:31 Sakari Ailus wrote:
+/*
+ * v4l2_of_free_endpoint() - release resources acquired by
+ * v4l2_of_alloc_parse_endpoint()
I would say free the endpoint allocated by v4l2_of_alloc_parse_endpoint().
+ * @endpoint - the endpoint the resources of which are to be released
+ *
+ * It is safe to call this function with NULL argument or on and
s/and/an/
Fixed both.
+ * endpoint the parsing of which failed.
+ */
+void v4l2_of_free_endpoint(struct v4l2_of_endpoint *endpoint)
+{
+ if (IS_ERR_OR_NULL(endpoint))
+ return;
+
+ kfree(endpoint-link_frequencies);
+ kfree(endpoint);
+}
+EXPORT_SYMBOL(v4l2_of_free_endpoint);
+
+/**
+ * v4l2_of_alloc_parse_endpoint() - parse all endpoint node properties
+ * @node: pointer to endpoint device_node
+ *
+ * All properties are optional. If none are found, we don't set any flags.
+ * This means the port has a static configuration and no properties have
+ * to be specified explicitly.
+ * If any properties that identify the bus as parallel are found and
+ * slave-mode isn't set, we set V4L2_MBUS_MASTER. Similarly, if we
recognise
+ * the bus as serial CSI-2 and clock-noncontinuous isn't set, we set the
+ * V4L2_MBUS_CSI2_CONTINUOUS_CLOCK flag.
+ * The caller should hold a reference to @node.
+ *
+ * v4l2_of_alloc_parse_endpoint() has two important differences to
+ * v4l2_of_parse_endpoint():
+ *
+ * 1. It also parses variable size data and
+ *
+ * 2. The memory resources it has acquired to store the variable size
+ *data must be released using v4l2_of_free_endpoint() when no longer
+ *needed.
I would s/resources it has acquired/it has allocated/ and s/released/freed/.
Fixed.
Apart from that,
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Thanks!
--
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
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Thu Apr 9 04:00:17 CEST 2015 git branch: test git hash: b6100f10bdc2019a65297d2597c388de2f7dd653 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.19.0-1.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: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: ERRORS linux-2.6.33.7-i686: ERRORS linux-2.6.34.7-i686: ERRORS linux-2.6.35.9-i686: ERRORS linux-2.6.36.4-i686: ERRORS linux-2.6.37.6-i686: ERRORS linux-2.6.38.8-i686: ERRORS linux-2.6.39.4-i686: ERRORS linux-3.0.60-i686: ERRORS linux-3.1.10-i686: ERRORS linux-3.2.37-i686: ERRORS linux-3.3.8-i686: ERRORS linux-3.4.27-i686: ERRORS linux-3.5.7-i686: ERRORS linux-3.6.11-i686: ERRORS linux-3.7.4-i686: ERRORS linux-3.8-i686: ERRORS linux-3.9.2-i686: ERRORS linux-3.10.1-i686: ERRORS linux-3.11.1-i686: ERRORS linux-3.12.23-i686: ERRORS 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: ERRORS linux-3.18.7-i686: ERRORS linux-3.19-i686: ERRORS linux-4.0-rc1-i686: ERRORS linux-2.6.32.27-x86_64: ERRORS linux-2.6.33.7-x86_64: ERRORS linux-2.6.34.7-x86_64: ERRORS linux-2.6.35.9-x86_64: ERRORS linux-2.6.36.4-x86_64: ERRORS linux-2.6.37.6-x86_64: ERRORS linux-2.6.38.8-x86_64: ERRORS linux-2.6.39.4-x86_64: ERRORS linux-3.0.60-x86_64: ERRORS linux-3.1.10-x86_64: ERRORS linux-3.2.37-x86_64: ERRORS linux-3.3.8-x86_64: ERRORS linux-3.4.27-x86_64: ERRORS linux-3.5.7-x86_64: ERRORS linux-3.6.11-x86_64: ERRORS linux-3.7.4-x86_64: ERRORS linux-3.8-x86_64: ERRORS linux-3.9.2-x86_64: ERRORS linux-3.10.1-x86_64: ERRORS linux-3.11.1-x86_64: ERRORS linux-3.12.23-x86_64: ERRORS 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: ERRORS linux-3.18.7-x86_64: ERRORS linux-3.19-x86_64: ERRORS linux-4.0-rc1-x86_64: ERRORS apps: OK spec-git: OK sparse: ERRORS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/4] v4l: of: Instead of zeroing bus_type and bus field separately, unify this
On Tue, Apr 07, 2015 at 12:47:56PM +0300, Laurent Pinchart wrote: Hello Sakari, Thank you for the patch. On Tuesday 07 April 2015 01:57:30 Sakari Ailus wrote: Clean the entire struct starting from bus_type. As more fields are added, no changes will be needed in the function to reset their value explicitly. I would s/Clean/Clear/ or s/Clean/Zero/. Same for the comment in the code. Apart from that, I'll use zero. It's clearer. :-) Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Thanks!! -- 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 v3 1/4] v4l: of: Remove the head field in struct v4l2_of_endpoint
Hi Laurent, On Tue, Apr 07, 2015 at 01:11:34PM +0300, Laurent Pinchart wrote: Hi Sakari, Thank you for the patch. On Tuesday 07 April 2015 01:57:29 Sakari Ailus wrote: The field is unused. Remove it. Do you know what the field was added for in the first place ? Frankly I have to admit I have no idea. It's part of the original patch which adds V4L2 OF support: --- commit 99fd133f907afdb430942d8d2ae53faa438adfe8 Author: Guennadi Liakhovetski g.liakhovet...@gmx.de Date: Wed Sep 26 05:24:03 2012 -0300 [media] Add a V4L2 OF parser Add a V4L2 OF parser, implementing bindings documented in Documentation/devicetree/bindings/media/video-interfaces.txt. [s.nawro...@samsung.com: various corrections and improvements since the initial version] Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com --- It looks like the intent has been that the field is used in order to keep a list of structs of this kind, but no-one is using it for that purpose at the moment. -- 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] [media] v4l: vb2-memops: use vma slab when vma allocation
Hans,
I didn't notice that vb2_put_vma is exported because I don't build modules.
I am sorry about bothering you.
Mauro,
I think it is better to drop my patch out from your tree
because I don't think it is not worth to export vm_area_cache_p to use it
in vb2_put_vma.
Regards,
KyongHo
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Thursday, April 09, 2015 1:01 AM
Mauro,
Please revert this patch: vm_area_cachep is not exported, so you cannot use
this in a module.
Cho KyongHo, if you believe that vm_area_cachep should be exported so it can
be used here, then please make a patch for that.
For the time being though, this patch should be reverted.
This patch slipped through the cracks and I clearly never reviewed it, and I
only noticed the problem after I compiled the media_tree git repo after this
patch was merged.
Regards,
Hans
On 02/05/2015 06:52 AM, Cho KyongHo wrote:
The slab for vm_area_struct which is vm_area_cachep is already
prepared for the general use. Instead of kmalloc() for the vma copy
for userptr, allocation from vm_area_cachep is more beneficial.
CC: Mauro Carvalho Chehab mche...@osg.samsung.com
CC: Hans Verkuil hans.verk...@cisco.com
CC: Laurent Pinchart laurent.pinch...@ideasonboard.com
Signed-off-by: Cho KyongHo pullip@samsung.com
---
drivers/media/v4l2-core/videobuf2-memops.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/v4l2-core/videobuf2-memops.c
b/drivers/media/v4l2-core/videobuf2-memops.c
index 81c1ad8..dd06efa 100644
--- a/drivers/media/v4l2-core/videobuf2-memops.c
+++ b/drivers/media/v4l2-core/videobuf2-memops.c
@@ -37,7 +37,7 @@ struct vm_area_struct *vb2_get_vma(struct
vm_area_struct *vma) {
struct vm_area_struct *vma_copy;
- vma_copy = kmalloc(sizeof(*vma_copy), GFP_KERNEL);
+ vma_copy = kmem_cache_alloc(vm_area_cachep, GFP_KERNEL);
if (vma_copy == NULL)
return NULL;
@@ -75,7 +75,7 @@ void vb2_put_vma(struct vm_area_struct *vma)
if (vma-vm_file)
fput(vma-vm_file);
- kfree(vma);
+ kmem_cache_free(vm_area_cachep, vma);
}
EXPORT_SYMBOL_GPL(vb2_put_vma);
--
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 4/4] smiapp: Use v4l2_of_alloc_parse_endpoint()
Hi Laurent,
On Tue, Apr 07, 2015 at 01:10:20PM +0300, Laurent Pinchart wrote:
@@ -3022,34 +3026,30 @@ static struct smiapp_platform_data
*smiapp_get_pdata(struct device *dev) dev_dbg(dev, reset %d, nvm %d, clk
%d, csi %d\n, pdata-xshutdown, pdata-nvm_size, pdata-ext_clk,
pdata-csi_signalling_mode);
- rval = of_get_property(ep, link-frequencies, asize) ? 0 : -ENOENT;
- if (rval) {
- dev_warn(dev, can't get link-frequencies array size\n);
+ if (!bus_cfg-nr_of_link_frequencies) {
Now that I see it being used, nr_of_link_frequencies feels a bit long.
num_link_freqs could be an alternative. I'll let you decide. But for this
patch,
It's long, I agree, but still used in only a small number of places in
drivers. I'd prefer to keep it as-is also as the name matches the name of
the property.
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Thanks.
--
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
