Re: v4l2: Adding support for multiple MIPI CSI-2 virtual channels

[Ajay kumar]

Hi Everyone,

On Fri, Feb 17, 2017 at 7:27 PM, Thomas Axelsson
 wrote:
> Hi,
>
> I have a v4l2_subdev that provides multiple MIPI CSI-2 Virtual Channels. I 
> want to configure each virtual channel individually (e.g. set_fmt), but the 
> v4l2 interface does not seem to have a clear way to access configuration on a 
> virtual channel level, but only the v4l2_subdev as a whole. Using one 
> v4l2_subdev for multiple virtual channels by extending the "reg" tag to be an 
> array looks like the correct way to do it, based on the mipi-dsi-bus.txt 
> document and current device tree endpoint structure.
>
> However, I cannot figure out how to extend e.g. set_fmt/get_fmt subdev ioctls 
> to specify which virtual channel the call applies to. Does anyone have any 
> advice on how to handle this case?
This would be helpful for my project as well since even I need to
support multiple streams using Virtual Channels.
Can anyone point out to some V4L2 driver, if this kind of support is
already implemented?

Thanks.
>
> Previous thread: "Device Tree formatting for multiple virtual channels in 
> ti-vpe/cal driver?"
>
>
> Best Regards,
> Thomas Axelsson
>
> PS. First e-mail seems to have gotten caught in the spam filter. I apologize 
> if this is a duplicate.

Re: [PATCH] media: staging: bcm2048: use unsigned int instead of unsigned

[Greg KH]

On Mon, Feb 20, 2017 at 05:08:56PM -0700, David Cako wrote:
> Signed-off-by: David Cako 
> ---
>  drivers/staging/media/bcm2048/radio-bcm2048.c | 44 
> +--
>  1 file changed, 22 insertions(+), 22 deletions(-)

We can't take patches without any changelog text, sorry.  And always
test-build your patches, this is a known tricky one, you have to ignore
checkpatch, it is wrong.

sorry,

greg k-h

cron job: media_tree daily build: WARNINGS

[Hans Verkuil]

This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:   Tue Feb 21 05:00:28 CET 2017
media-tree git hash:9eeb0ed0f30938f31a3d9135a88b9502192c18dd
media_build git hash:   785cdf7f0798964681b33aad44fc2ff4d734733d
v4l-utils git hash: 1edd6920bed585d0ea70a2d400182ba17ee2e7fc
gcc version:i686-linux-gcc (GCC) 6.2.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.9.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: WARNINGS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.38.8-i686: WARNINGS
linux-2.6.39.4-i686: WARNINGS
linux-3.0.60-i686: WARNINGS
linux-3.1.10-i686: WARNINGS
linux-3.2.37-i686: WARNINGS
linux-3.3.8-i686: WARNINGS
linux-3.4.27-i686: WARNINGS
linux-3.5.7-i686: WARNINGS
linux-3.6.11-i686: WARNINGS
linux-3.7.4-i686: WARNINGS
linux-3.8-i686: WARNINGS
linux-3.9.2-i686: WARNINGS
linux-3.10.1-i686: WARNINGS
linux-3.11.1-i686: WARNINGS
linux-3.12.67-i686: WARNINGS
linux-3.13.11-i686: WARNINGS
linux-3.14.9-i686: WARNINGS
linux-3.15.2-i686: WARNINGS
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.9-i686: WARNINGS
linux-4.1.33-i686: WARNINGS
linux-4.2.8-i686: WARNINGS
linux-4.3.6-i686: WARNINGS
linux-4.4.22-i686: WARNINGS
linux-4.5.7-i686: WARNINGS
linux-4.6.7-i686: WARNINGS
linux-4.7.5-i686: WARNINGS
linux-4.8-i686: OK
linux-4.9-i686: OK
linux-4.10-rc3-i686: OK
linux-2.6.36.4-x86_64: WARNINGS
linux-2.6.37.6-x86_64: WARNINGS
linux-2.6.38.8-x86_64: WARNINGS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.60-x86_64: WARNINGS
linux-3.1.10-x86_64: WARNINGS
linux-3.2.37-x86_64: WARNINGS
linux-3.3.8-x86_64: WARNINGS
linux-3.4.27-x86_64: WARNINGS
linux-3.5.7-x86_64: WARNINGS
linux-3.6.11-x86_64: WARNINGS
linux-3.7.4-x86_64: WARNINGS
linux-3.8-x86_64: WARNINGS
linux-3.9.2-x86_64: WARNINGS
linux-3.10.1-x86_64: WARNINGS
linux-3.11.1-x86_64: WARNINGS
linux-3.12.67-x86_64: WARNINGS
linux-3.13.11-x86_64: WARNINGS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16.7-x86_64: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.7-x86_64: WARNINGS
linux-3.19-x86_64: WARNINGS
linux-4.0.9-x86_64: WARNINGS
linux-4.1.33-x86_64: WARNINGS
linux-4.2.8-x86_64: WARNINGS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.22-x86_64: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-x86_64: WARNINGS
linux-4.8-x86_64: OK
linux-4.9-x86_64: OK
linux-4.10-rc3-x86_64: OK
apps: WARNINGS
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html

[PATCH 2/2] media: pci: saa7164: remove dead code

[Gustavo A. R. Silva]

Remove dead code. The following line of code is never reached:
return SAA_OK;

Addresses-Coverity-ID: 114283
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/media/pci/saa7164/saa7164-cmd.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/media/pci/saa7164/saa7164-cmd.c 
b/drivers/media/pci/saa7164/saa7164-cmd.c
index 169c90a..fb19498 100644
--- a/drivers/media/pci/saa7164/saa7164-cmd.c
+++ b/drivers/media/pci/saa7164/saa7164-cmd.c
@@ -181,8 +181,6 @@ static int saa7164_cmd_dequeue(struct saa7164_dev *dev)
wake_up(q);
return SAA_OK;
}
-
-   return SAA_OK;
 }
 
 static int saa7164_cmd_set(struct saa7164_dev *dev, struct tmComResInfo *msg,
-- 
2.5.0

[PATCH 1/2] media: pci: saa7164: remove unnecessary code

[Gustavo A. R. Silva]

Remove unnecessary variable 'loop'.

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/media/pci/saa7164/saa7164-cmd.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/media/pci/saa7164/saa7164-cmd.c 
b/drivers/media/pci/saa7164/saa7164-cmd.c
index 45951b3..169c90a 100644
--- a/drivers/media/pci/saa7164/saa7164-cmd.c
+++ b/drivers/media/pci/saa7164/saa7164-cmd.c
@@ -134,14 +134,13 @@ int saa7164_irq_dequeue(struct saa7164_dev *dev)
  * -bus/c running buffer. */
 static int saa7164_cmd_dequeue(struct saa7164_dev *dev)
 {
-   int loop = 1;
int ret;
u32 timeout;
wait_queue_head_t *q = NULL;
u8 tmp[512];
dprintk(DBGLVL_CMD, "%s()\n", __func__);
 
-   while (loop) {
+   while (true) {
 
struct tmComResInfo tRsp = { 0, 0, 0, 0, 0, 0 };
ret = saa7164_bus_get(dev, , NULL, 1);
-- 
2.5.0

Re: [PATCH] media: staging: bcm2048: use unsigned int instead of unsigned

[kbuild test robot]

Hi David,

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.10 next-20170220]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/David-Cako/media-staging-bcm2048-use-unsigned-int-instead-of-unsigned/20170221-082741
base:   git://linuxtv.org/media_tree.git master
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/staging/media/bcm2048/radio-bcm2048.c: In function 
'bcm2048_power_state_write':
>> drivers/staging/media/bcm2048/radio-bcm2048.c:2023:50: error: two or more 
>> data types in declaration specifiers
DEFINE_SYSFS_PROPERTY(power_state, unsigned int, int, "%u", 0)
 ^
   drivers/staging/media/bcm2048/radio-bcm2048.c:1943:2: note: in definition of 
macro 'property_write'
 type value;   \
 ^~~~
   drivers/staging/media/bcm2048/radio-bcm2048.c:2023:1: note: in expansion of 
macro 'DEFINE_SYSFS_PROPERTY'
DEFINE_SYSFS_PROPERTY(power_state, unsigned int, int, "%u", 0)
^
   drivers/staging/media/bcm2048/radio-bcm2048.c: In function 
'bcm2048_mute_write':
   drivers/staging/media/bcm2048/radio-bcm2048.c:2024:43: error: two or more 
data types in declaration specifiers
DEFINE_SYSFS_PROPERTY(mute, unsigned int, int, "%u", 0)
  ^
   drivers/staging/media/bcm2048/radio-bcm2048.c:1943:2: note: in definition of 
macro 'property_write'
 type value;   \
 ^~~~
   drivers/staging/media/bcm2048/radio-bcm2048.c:2024:1: note: in expansion of 
macro 'DEFINE_SYSFS_PROPERTY'
DEFINE_SYSFS_PROPERTY(mute, unsigned int, int, "%u", 0)
^
   drivers/staging/media/bcm2048/radio-bcm2048.c: In function 
'bcm2048_audio_route_write':
   drivers/staging/media/bcm2048/radio-bcm2048.c:2025:50: error: two or more 
data types in declaration specifiers
DEFINE_SYSFS_PROPERTY(audio_route, unsigned int, int, "%u", 0)
 ^
   drivers/staging/media/bcm2048/radio-bcm2048.c:1943:2: note: in definition of 
macro 'property_write'
 type value;   \
 ^~~~
   drivers/staging/media/bcm2048/radio-bcm2048.c:2025:1: note: in expansion of 
macro 'DEFINE_SYSFS_PROPERTY'
DEFINE_SYSFS_PROPERTY(audio_route, unsigned int, int, "%u", 0)
^
   drivers/staging/media/bcm2048/radio-bcm2048.c: In function 
'bcm2048_dac_output_write':
   drivers/staging/media/bcm2048/radio-bcm2048.c:2026:49: error: two or more 
data types in declaration specifiers
DEFINE_SYSFS_PROPERTY(dac_output, unsigned int, int, "%u", 0)
^
   drivers/staging/media/bcm2048/radio-bcm2048.c:1943:2: note: in definition of 
macro 'property_write'
 type value;   \
 ^~~~
   drivers/staging/media/bcm2048/radio-bcm2048.c:2026:1: note: in expansion of 
macro 'DEFINE_SYSFS_PROPERTY'
DEFINE_SYSFS_PROPERTY(dac_output, unsigned int, int, "%u", 0)
^
   drivers/staging/media/bcm2048/radio-bcm2048.c: In function 
'bcm2048_fm_hi_lo_injection_write':
   drivers/staging/media/bcm2048/radio-bcm2048.c:2028:57: error: two or more 
data types in declaration specifiers
DEFINE_SYSFS_PROPERTY(fm_hi_lo_injection, unsigned int, int, "%u", 0)
^
   drivers/staging/media/bcm2048/radio-bcm2048.c:1943:2: note: in definition of 
macro 'property_write'
 type value;   \
 ^~~~
   drivers/staging/media/bcm2048/radio-bcm2048.c:2028:1: note: in expansion of 
macro 'DEFINE_SYSFS_PROPERTY'
DEFINE_SYSFS_PROPERTY(fm_hi_lo_injection, unsigned int, int, "%u", 0)
^
   drivers/staging/media/bcm2048/radio-bcm2048.c: In function 
'bcm2048_fm_frequency_write':
   drivers/staging/media/bcm2048/radio-bcm2048.c:2029:51: error: two or more 
data types in declaration specifiers
DEFINE_SYSFS_PROPERTY(fm_frequency, unsigned int, int, "%u", 0)
  ^
   drivers/staging/media/bcm2048/radio-bcm2048.c:1943:2: note: in definition of 
macro 'property_write'
 type value;   \
 ^~~~
   drivers/staging/media/bcm2048/radio-bcm2048.c:2029:1: note: in expansion of 
macro 'DEFINE_SYSFS_PROPERTY'
DEFINE_SYSFS_PROPERTY(fm_frequency, unsigned int, int, "%u", 0)
^
   drivers/staging/media/bcm2048/radio-bcm2048.c: In function 
'bcm2048_fm_af_frequency_write':
   drivers/staging/media/bcm2048/radio-bcm2048.c:2030:54: error: two or more 
data types in declaration specifiers
  

[PATCH] fix unsigned int argument

[David Cako]

Sorry, left the old "int" argument in previous patch.

Signed-off-by: David Cako 
---
 drivers/staging/media/bcm2048/radio-bcm2048.c | 44 +--
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c 
b/drivers/staging/media/bcm2048/radio-bcm2048.c
index b1923a3..a41d971 100644
--- a/drivers/staging/media/bcm2048/radio-bcm2048.c
+++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
@@ -2020,27 +2020,27 @@ static ssize_t bcm2048_##prop##_read(struct device 
*dev,\
return count;   \
 }
 
-DEFINE_SYSFS_PROPERTY(power_state, unsigned int, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(mute, unsigned int, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(audio_route, unsigned int, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(dac_output, unsigned int, int, "%u", 0)
-
-DEFINE_SYSFS_PROPERTY(fm_hi_lo_injection, unsigned int, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(fm_frequency, unsigned int, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(fm_af_frequency, unsigned int, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(fm_deemphasis, unsigned int, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(fm_rds_mask, unsigned int, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(fm_best_tune_mode, unsigned int, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(fm_search_rssi_threshold, unsigned int, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(fm_search_mode_direction, unsigned int, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(fm_search_tune_mode, unsigned int, int, "%u", value > 3)
-
-DEFINE_SYSFS_PROPERTY(rds, unsigned int, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(rds_b_block_mask, unsigned int, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(rds_b_block_match, unsigned int, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(rds_pi_mask, unsigned int, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(rds_pi_match, unsigned int, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(rds_wline, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(power_state, unsigned int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(mute, unsigned int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(audio_route, unsigned int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(dac_output, unsigned int, "%u", 0)
+
+DEFINE_SYSFS_PROPERTY(fm_hi_lo_injection, unsigned int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(fm_frequency, unsigned int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(fm_af_frequency, unsigned int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(fm_deemphasis, unsigned int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(fm_rds_mask, unsigned int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(fm_best_tune_mode, unsigned int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(fm_search_rssi_threshold, unsigned int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(fm_search_mode_direction, unsigned int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(fm_search_tune_mode, unsigned int, "%u", value > 3)
+
+DEFINE_SYSFS_PROPERTY(rds, unsigned int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(rds_b_block_mask, unsigned int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(rds_b_block_match, unsigned int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(rds_pi_mask, unsigned int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(rds_pi_match, unsigned int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(rds_wline, unsigned int, "%u", 0)
 property_read(rds_pi, unsigned int, "%x")
 property_str_read(rds_rt, (BCM2048_MAX_RDS_RT + 1))
 property_str_read(rds_ps, (BCM2048_MAX_RDS_PS + 1))
@@ -2052,7 +2052,7 @@ property_read(region_bottom_frequency, unsigned int, "%u")
 property_read(region_top_frequency, unsigned int, "%u")
 property_signed_read(fm_carrier_error, int, "%d")
 property_signed_read(fm_rssi, int, "%d")
-DEFINE_SYSFS_PROPERTY(region, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(region, unsigned int, "%u", 0)
 
 static struct device_attribute attrs[] = {
__ATTR(power_state, 0644, bcm2048_power_state_read,
-- 
2.7.4

Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates

[Steve Longerbeam]

On 02/20/2017 04:13 PM, Russell King - ARM Linux wrote:

On Tue, Feb 21, 2017 at 12:04:10AM +0200, Sakari Ailus wrote:

On Wed, Feb 15, 2017 at 06:19:31PM -0800, Steve Longerbeam wrote:

From: Russell King 

Setting and getting frame rates is part of the negotiation mechanism
between subdevs.  The lack of support means that a frame rate at the
sensor can't be negotiated through the subdev path.


Just wondering --- what do you need this for?


The v4l2 documentation contradicts the media-ctl implementation.

While v4l2 documentation says:

  These ioctls are used to get and set the frame interval at specific
  subdev pads in the image pipeline. The frame interval only makes sense
  for sub-devices that can control the frame period on their own. This
  includes, for instance, image sensors and TV tuners. Sub-devices that
  don't support frame intervals must not implement these ioctls.

However, when trying to configure the pipeline using media-ctl, eg:

media-ctl -d /dev/media1 --set-v4l2 '"imx219 pixel 
0-0010":0[crop:(0,0)/3264x2464]'
media-ctl -d /dev/media1 --set-v4l2 '"imx219 
0-0010":1[fmt:SRGGB10/3264x2464@1/30]'
media-ctl -d /dev/media1 --set-v4l2 '"imx219 0-0010":0[fmt:SRGGB8/816x616@1/30]'
media-ctl -d /dev/media1 --set-v4l2 
'"imx6-mipi-csi2":1[fmt:SRGGB8/816x616@1/30]'
Unable to setup formats: Inappropriate ioctl for device (25)
media-ctl -d /dev/media1 --set-v4l2 '"ipu1_csi0_mux":2[fmt:SRGGB8/816x616@1/30]'
media-ctl -d /dev/media1 --set-v4l2 '"ipu1_csi0":2[fmt:SRGGB8/816x616@1/30]'

The problem there is that the format setting for the csi2 does not get
propagated forward:

$ strace media-ctl -d /dev/media1 --set-v4l2 
'"imx6-mipi-csi2":1[fmt:SRGGB8/816x616@1/30]'
...
open("/dev/v4l-subdev16", O_RDWR)   = 3
ioctl(3, VIDIOC_SUBDEV_S_FMT, 0xbec16244) = 0
ioctl(3, VIDIOC_SUBDEV_S_FRAME_INTERVAL, 0xbec162a4) = -1 ENOTTY (Inappropriate
ioctl for device)
fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 2), ...}) = 0
write(1, "Unable to setup formats: Inappro"..., 61) = 61
Unable to setup formats: Inappropriate ioctl for device (25)
close(3)= 0
exit_group(1)   = ?
+++ exited with 1 +++

because media-ctl exits as soon as it encouters the error while trying
to set the frame rate.

This makes implementing setup of the media pipeline in shell scripts
unnecessarily difficult - as you need to then know whether an entity
is likely not to support the VIDIOC_SUBDEV_S_FRAME_INTERVAL call,
and either avoid specifying a frame rate:

$ strace media-ctl -d /dev/media1 --set-v4l2 
'"imx6-mipi-csi2":1[fmt:SRGGB8/816x616]'
...
open("/dev/v4l-subdev16", O_RDWR)   = 3
ioctl(3, VIDIOC_SUBDEV_S_FMT, 0xbeb1a254) = 0
open("/dev/v4l-subdev0", O_RDWR)= 4
ioctl(4, VIDIOC_SUBDEV_S_FMT, 0xbeb1a254) = 0
close(4)= 0
close(3)= 0
exit_group(0)   = ?
+++ exited with 0 +++

or manually setting the format on the sink.

Allowing the S_FRAME_INTERVAL call seems to me to be more in keeping
with the negotiation mechanism that is implemented in subdevs, and
IMHO should be implemented inside the kernel as a pad operation along
with the format negotiation, especially so as frame skipping is
defined as scaling, in just the same way as the frame size is also
scaling:

   -  ``MEDIA_ENT_F_PROC_VIDEO_SCALER``

   -  Video scaler. An entity capable of video scaling must have
  at least one sink pad and one source pad, and scale the
  video frame(s) received on its sink pad(s) to a different
  resolution output on its source pad(s). The range of
  supported scaling ratios is entity-specific and can differ
  between the horizontal and vertical directions (in particular
  scaling can be supported in one direction only). Binning and
  skipping are considered as scaling.

Although, this is vague, as it doesn't define what it means by "skipping",
whether that's skipping pixels (iow, sub-sampling) or whether that's
frame skipping.

Then there's the issue where, if you have this setup:

 camera --> csi2 receiver --> csi --> capture

and the "csi" subdev can skip frames, you need to know (a) at the CSI
sink pad what the frame rate is of the source (b) what the desired
source pad frame rate is, so you can configure the frame skipping.
So, does the csi subdev have to walk back through the media graph
looking for the frame rate?  Does the capture device have to walk back
through the media graph looking for some subdev to tell it what the
frame rate is - the capture device certainly can't go straight to the
sensor to get an answer to that question, because that bypasses the
effect of the CSI frame skipping (which will lower the frame rate.)

IMHO, frame rate is just another format property, just like the
resolution and data format itself, and v4l2 should be treating it no
differently.



I agree, frame 

Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates

[Russell King - ARM Linux]

On Tue, Feb 21, 2017 at 12:04:10AM +0200, Sakari Ailus wrote:
> On Wed, Feb 15, 2017 at 06:19:31PM -0800, Steve Longerbeam wrote:
> > From: Russell King 
> > 
> > Setting and getting frame rates is part of the negotiation mechanism
> > between subdevs.  The lack of support means that a frame rate at the
> > sensor can't be negotiated through the subdev path.
> 
> Just wondering --- what do you need this for?

The v4l2 documentation contradicts the media-ctl implementation.

While v4l2 documentation says:

  These ioctls are used to get and set the frame interval at specific
  subdev pads in the image pipeline. The frame interval only makes sense
  for sub-devices that can control the frame period on their own. This
  includes, for instance, image sensors and TV tuners. Sub-devices that
  don't support frame intervals must not implement these ioctls.

However, when trying to configure the pipeline using media-ctl, eg:

media-ctl -d /dev/media1 --set-v4l2 '"imx219 pixel 
0-0010":0[crop:(0,0)/3264x2464]'
media-ctl -d /dev/media1 --set-v4l2 '"imx219 
0-0010":1[fmt:SRGGB10/3264x2464@1/30]'
media-ctl -d /dev/media1 --set-v4l2 '"imx219 0-0010":0[fmt:SRGGB8/816x616@1/30]'
media-ctl -d /dev/media1 --set-v4l2 
'"imx6-mipi-csi2":1[fmt:SRGGB8/816x616@1/30]'
Unable to setup formats: Inappropriate ioctl for device (25)
media-ctl -d /dev/media1 --set-v4l2 '"ipu1_csi0_mux":2[fmt:SRGGB8/816x616@1/30]'
media-ctl -d /dev/media1 --set-v4l2 '"ipu1_csi0":2[fmt:SRGGB8/816x616@1/30]'

The problem there is that the format setting for the csi2 does not get
propagated forward:

$ strace media-ctl -d /dev/media1 --set-v4l2 
'"imx6-mipi-csi2":1[fmt:SRGGB8/816x616@1/30]'
...
open("/dev/v4l-subdev16", O_RDWR)   = 3
ioctl(3, VIDIOC_SUBDEV_S_FMT, 0xbec16244) = 0
ioctl(3, VIDIOC_SUBDEV_S_FRAME_INTERVAL, 0xbec162a4) = -1 ENOTTY (Inappropriate
ioctl for device)
fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 2), ...}) = 0
write(1, "Unable to setup formats: Inappro"..., 61) = 61
Unable to setup formats: Inappropriate ioctl for device (25)
close(3)= 0
exit_group(1)   = ?
+++ exited with 1 +++

because media-ctl exits as soon as it encouters the error while trying
to set the frame rate.

This makes implementing setup of the media pipeline in shell scripts
unnecessarily difficult - as you need to then know whether an entity
is likely not to support the VIDIOC_SUBDEV_S_FRAME_INTERVAL call,
and either avoid specifying a frame rate:

$ strace media-ctl -d /dev/media1 --set-v4l2 
'"imx6-mipi-csi2":1[fmt:SRGGB8/816x616]'
...
open("/dev/v4l-subdev16", O_RDWR)   = 3
ioctl(3, VIDIOC_SUBDEV_S_FMT, 0xbeb1a254) = 0
open("/dev/v4l-subdev0", O_RDWR)= 4
ioctl(4, VIDIOC_SUBDEV_S_FMT, 0xbeb1a254) = 0
close(4)= 0
close(3)= 0
exit_group(0)   = ?
+++ exited with 0 +++

or manually setting the format on the sink.

Allowing the S_FRAME_INTERVAL call seems to me to be more in keeping
with the negotiation mechanism that is implemented in subdevs, and
IMHO should be implemented inside the kernel as a pad operation along
with the format negotiation, especially so as frame skipping is
defined as scaling, in just the same way as the frame size is also
scaling:

   -  ``MEDIA_ENT_F_PROC_VIDEO_SCALER``

   -  Video scaler. An entity capable of video scaling must have
  at least one sink pad and one source pad, and scale the
  video frame(s) received on its sink pad(s) to a different
  resolution output on its source pad(s). The range of
  supported scaling ratios is entity-specific and can differ
  between the horizontal and vertical directions (in particular
  scaling can be supported in one direction only). Binning and
  skipping are considered as scaling.

Although, this is vague, as it doesn't define what it means by "skipping",
whether that's skipping pixels (iow, sub-sampling) or whether that's
frame skipping.

Then there's the issue where, if you have this setup:

 camera --> csi2 receiver --> csi --> capture

and the "csi" subdev can skip frames, you need to know (a) at the CSI
sink pad what the frame rate is of the source (b) what the desired
source pad frame rate is, so you can configure the frame skipping.
So, does the csi subdev have to walk back through the media graph
looking for the frame rate?  Does the capture device have to walk back
through the media graph looking for some subdev to tell it what the
frame rate is - the capture device certainly can't go straight to the
sensor to get an answer to that question, because that bypasses the
effect of the CSI frame skipping (which will lower the frame rate.)

IMHO, frame rate is just another format property, just like the
resolution and data format itself, and v4l2 should be treating it no
differently.

In any case, the documentation vs media-ctl create 

[PATCH] media: staging: bcm2048: use unsigned int instead of unsigned

[David Cako]

Signed-off-by: David Cako 
---
 drivers/staging/media/bcm2048/radio-bcm2048.c | 44 +--
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/drivers/staging/media/bcm2048/radio-bcm2048.c 
b/drivers/staging/media/bcm2048/radio-bcm2048.c
index 37bd439..b1923a3 100644
--- a/drivers/staging/media/bcm2048/radio-bcm2048.c
+++ b/drivers/staging/media/bcm2048/radio-bcm2048.c
@@ -2020,27 +2020,27 @@ static ssize_t bcm2048_##prop##_read(struct device 
*dev,\
return count;   \
 }
 
-DEFINE_SYSFS_PROPERTY(power_state, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(mute, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(audio_route, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(dac_output, unsigned, int, "%u", 0)
-
-DEFINE_SYSFS_PROPERTY(fm_hi_lo_injection, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(fm_frequency, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(fm_af_frequency, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(fm_deemphasis, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(fm_rds_mask, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(fm_best_tune_mode, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(fm_search_rssi_threshold, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(fm_search_mode_direction, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(fm_search_tune_mode, unsigned, int, "%u", value > 3)
-
-DEFINE_SYSFS_PROPERTY(rds, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(rds_b_block_mask, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(rds_b_block_match, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(rds_pi_mask, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(rds_pi_match, unsigned, int, "%u", 0)
-DEFINE_SYSFS_PROPERTY(rds_wline, unsigned, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(power_state, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(mute, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(audio_route, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(dac_output, unsigned int, int, "%u", 0)
+
+DEFINE_SYSFS_PROPERTY(fm_hi_lo_injection, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(fm_frequency, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(fm_af_frequency, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(fm_deemphasis, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(fm_rds_mask, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(fm_best_tune_mode, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(fm_search_rssi_threshold, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(fm_search_mode_direction, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(fm_search_tune_mode, unsigned int, int, "%u", value > 3)
+
+DEFINE_SYSFS_PROPERTY(rds, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(rds_b_block_mask, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(rds_b_block_match, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(rds_pi_mask, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(rds_pi_match, unsigned int, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(rds_wline, unsigned int, int, "%u", 0)
 property_read(rds_pi, unsigned int, "%x")
 property_str_read(rds_rt, (BCM2048_MAX_RDS_RT + 1))
 property_str_read(rds_ps, (BCM2048_MAX_RDS_PS + 1))
@@ -2052,7 +2052,7 @@ property_read(region_bottom_frequency, unsigned int, "%u")
 property_read(region_top_frequency, unsigned int, "%u")
 property_signed_read(fm_carrier_error, int, "%d")
 property_signed_read(fm_rssi, int, "%d")
-DEFINE_SYSFS_PROPERTY(region, unsigned, int, "%u", 0)
+DEFINE_SYSFS_PROPERTY(region, unsigned int, int, "%u", 0)
 
 static struct device_attribute attrs[] = {
__ATTR(power_state, 0644, bcm2048_power_state_read,
-- 
2.7.4

Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates

[Steve Longerbeam]

On 02/20/2017 02:56 PM, Steve Longerbeam wrote:



On 02/20/2017 02:04 PM, Sakari Ailus wrote:

Hi Steve,

On Wed, Feb 15, 2017 at 06:19:31PM -0800, Steve Longerbeam wrote:

From: Russell King 

Setting and getting frame rates is part of the negotiation mechanism
between subdevs.  The lack of support means that a frame rate at the
sensor can't be negotiated through the subdev path.


Just wondering --- what do you need this for?



Hi Sakari,

i.MX does need the ability to negotiate the frame rates in the
pipelines. The CSI has the ability to skip frames at the output,
which is something Philipp added to the CSI subdev. That affects
frame interval at the CSI output.

But as Russell pointed out, the lack of [gs]_frame_interval op
causes media-ctl to fail:

media-ctl -v -d /dev/media1 --set-v4l2
'"imx6-mipi-csi2":1[fmt:SGBRG8/512x512@1/30]'

Opening media device /dev/media1
Enumerating entities
Found 29 entities
Enumerating pads and links
Setting up format SGBRG8 512x512 on pad imx6-mipi-csi2/1
Format set: SGBRG8 512x512
Setting up frame interval 1/30 on entity imx6-mipi-csi2
Unable to set frame interval: Inappropriate ioctl for device (-25)Unable
to setup formats: Inappropriate ioctl for device (25)


So i.MX needs to implement this op in every subdev in the
pipeline, otherwise it's not possible to configure the
pipeline with media-ctl.




Hi Russell,

But Sakari brings up a good point. The mipi csi-2 receiver doesn't
have any control over frame rate, so why do you even need to
give it this information via media-ctl?

Steve

Re: [PATCH v2 0/3] r8a7793 Gose video input support

[Laurent Pinchart]

Hi Ulrich,

On Thursday 20 Oct 2016 10:49:11 Simon Horman wrote:
> On Tue, Oct 18, 2016 at 05:02:20PM +0200, Ulrich Hecht wrote:
> > Hi!
> > 
> > This is a by-the-datasheet implementation of analog and digital video
> > input on the Gose board.
> > 
> > I have tried to address all concerns raised by reviewers, with the
> > exception of the composite input patch, which has been left as is for
> > now.
> > 
> > CU
> > Uli
> > 
> > 
> > Changes since v1:
> > - r8a7793.dtsi: added VIN2
> > - modeled HDMI decoder input/output and connector
> > - added "renesas,rcar-gen2-vin" compat strings
> > - removed unnecessary "remote" node and aliases
> > - set ADV7612 interrupt to GP4_2
> > 
> > Ulrich Hecht (3):
> >   ARM: dts: r8a7793: Enable VIN0-VIN2
> 
> I have queued up the above patch with Laurent and Geert's tags.
> 
> >   ARM: dts: gose: add HDMI input
> >   ARM: dts: gose: add composite video input
> 
> Please address the review of the above two patches and repost.

Could you please do so ? Feedback on 2/3 should be easy to handle. For 3/3, 
you might need to ping the DT maintainers.

> >  arch/arm/boot/dts/r8a7793-gose.dts | 100 +++
> >  arch/arm/boot/dts/r8a7793.dtsi |  27 ++
> >  2 files changed, 127 insertions(+)

-- 
Regards,

Laurent Pinchart

[PATCH] rtl8188eu: style: spaces to tabs

[David Cako]

---
 drivers/staging/rtl8188eu/core/rtw_recv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_recv.c 
b/drivers/staging/rtl8188eu/core/rtw_recv.c
index f2021fe..8c715af 100644
--- a/drivers/staging/rtl8188eu/core/rtw_recv.c
+++ b/drivers/staging/rtl8188eu/core/rtw_recv.c
@@ -32,11 +32,11 @@ static u8 SNAP_ETH_TYPE_APPLETALK_AARP[2] = {0x80, 0xf3};
 
 /* Bridge-Tunnel header (for EtherTypes ETH_P_AARP and ETH_P_IPX) */
 static u8 rtw_bridge_tunnel_header[] = {
-   0xaa, 0xaa, 0x03, 0x00, 0x00, 0xf8
+   0xaa, 0xaa, 0x03, 0x00, 0x00, 0xf8
 };
 
 static u8 rtw_rfc1042_header[] = {
-   0xaa, 0xaa, 0x03, 0x00, 0x00, 0x00
+   0xaa, 0xaa, 0x03, 0x00, 0x00, 0x00
 };
 
 static void rtw_signal_stat_timer_hdl(unsigned long data);
-- 
2.7.4

Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates

[Steve Longerbeam]

On 02/20/2017 02:04 PM, Sakari Ailus wrote:

Hi Steve,

On Wed, Feb 15, 2017 at 06:19:31PM -0800, Steve Longerbeam wrote:

From: Russell King 

Setting and getting frame rates is part of the negotiation mechanism
between subdevs.  The lack of support means that a frame rate at the
sensor can't be negotiated through the subdev path.


Just wondering --- what do you need this for?



Hi Sakari,

i.MX does need the ability to negotiate the frame rates in the
pipelines. The CSI has the ability to skip frames at the output,
which is something Philipp added to the CSI subdev. That affects
frame interval at the CSI output.

But as Russell pointed out, the lack of [gs]_frame_interval op
causes media-ctl to fail:

media-ctl -v -d /dev/media1 --set-v4l2 
'"imx6-mipi-csi2":1[fmt:SGBRG8/512x512@1/30]'


Opening media device /dev/media1
Enumerating entities
Found 29 entities
Enumerating pads and links
Setting up format SGBRG8 512x512 on pad imx6-mipi-csi2/1
Format set: SGBRG8 512x512
Setting up frame interval 1/30 on entity imx6-mipi-csi2
Unable to set frame interval: Inappropriate ioctl for device (-25)Unable 
to setup formats: Inappropriate ioctl for device (25)



So i.MX needs to implement this op in every subdev in the
pipeline, otherwise it's not possible to configure the
pipeline with media-ctl.


Steve

Re: [PATCH v3 1/2] v4l: Add camera voice coil lens control class, current control

[Pavel Machek]

Hi!

> > > > I wonder... should we somehow expose the range of diopters to
> > > > userspace? I believe userland camera application will need that
> > > > information.
> > > 
> > > It'd certainly be useful to be able to provide more information.
> > > 
> > > The question is: where to store it, and how? It depends on the voice
> > > coil, the spring constant, the lens and the distance of the lens from
> > > the sensor --- at least. Probably the sensor size as well.
> > > 
> > > On voice coil lenses it is also somewhat inexact.
> > 
> > I was thinking read-only attribute providing minimum and maximum
> > diopters in case there's linear relationship as on N900.
> > 
> > +#define V4L2_CID_VOICE_DIOPTERS_AT_REST (V4L2_CID_VOICE_COIL_CLASS_BASE + 
> > 2)
> > +#define V4L2_CID_VOICE_DIOPTERS_AT_MAX (V4L2_CID_VOICE_COIL_CLASS_BASE + 3)
> 
> Where do you store that information and how? Should the user be also told
> how the applied current affects the value?

The information would come from device tree.

User already knows minimum and maximum, so if he knows there's linear
relationship, he has complete picture. I'm not sure if there are some
voice coils with anything else then linear relationship. I guess we
could do

+#define V4L2_CID_VOICE_CURRENT_TO_DIOPTERS (V4L2_CID_VOICE_COIL_CLASS_BASE + 4)
#define ..._LINEAR 1

...

> I also wonder whether that's the best way to provide the information to the
> user --- we have things such as devices that are a part of a camera module
> and telling the user on which side of the device the camera is located.
> 
> We've been planning to have a property API for this to provide the user with
> a tree of key-value pairs, with details unsettled as of yet, so it's
> certainly nothing that could be used yet.

You know the design better than I do. I believe read-only properties
would be easy enough for this.

> Do you have a user application that could make use of such information?

fcam-dev,
yes. https://gitlab.com/pavelm/fcam-devhttps://gitlab.com/pavelm/fcam-dev

I don't promise to make neccessary modifications -- currently it
hardcodes 0 and 20 diopters -- but it allows manual or automatic
focus; in both modes it is good to tell user where he is focusing, and
it is pretty much mandatory in the manual mode.

Best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v3 1/2] v4l: Add camera voice coil lens control class, current control

[Sakari Ailus]

Hi Pavel,

On Wed, Feb 15, 2017 at 09:09:09AM +0100, Pavel Machek wrote:
> Hi!
> 
> > On 02/15/17 00:47, Pavel Machek wrote:
> > > On Tue 2017-02-14 14:20:22, Sakari Ailus wrote:
> > >> Add a V4L2 control class for voice coil lens driver devices. These are
> > >> simple devices that are used to move a camera lens from its resting
> > >> position.
> > >>
> > >> Signed-off-by: Sakari Ailus 
> > > 
> > > Looks good to me.
> > > 
> > > I wonder... should we somehow expose the range of diopters to
> > > userspace? I believe userland camera application will need that
> > > information.
> > 
> > It'd certainly be useful to be able to provide more information.
> > 
> > The question is: where to store it, and how? It depends on the voice
> > coil, the spring constant, the lens and the distance of the lens from
> > the sensor --- at least. Probably the sensor size as well.
> > 
> > On voice coil lenses it is also somewhat inexact.
> 
> I was thinking read-only attribute providing minimum and maximum
> diopters in case there's linear relationship as on N900.
> 
> +#define V4L2_CID_VOICE_DIOPTERS_AT_REST (V4L2_CID_VOICE_COIL_CLASS_BASE + 2)
> +#define V4L2_CID_VOICE_DIOPTERS_AT_MAX (V4L2_CID_VOICE_COIL_CLASS_BASE + 3)

Where do you store that information and how? Should the user be also told
how the applied current affects the value?

I also wonder whether that's the best way to provide the information to the
user --- we have things such as devices that are a part of a camera module
and telling the user on which side of the device the camera is located.

We've been planning to have a property API for this to provide the user with
a tree of key-value pairs, with details unsettled as of yet, so it's
certainly nothing that could be used yet.

Do you have a user application that could make use of such information?

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates

[Sakari Ailus]

Hi Steve,

On Wed, Feb 15, 2017 at 06:19:31PM -0800, Steve Longerbeam wrote:
> From: Russell King 
> 
> Setting and getting frame rates is part of the negotiation mechanism
> between subdevs.  The lack of support means that a frame rate at the
> sensor can't be negotiated through the subdev path.

Just wondering --- what do you need this for?

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH] [media] et8ek8: Export OF device ID as module aliases

[Sakari Ailus]

On Mon, Feb 20, 2017 at 05:16:16PM -0300, Javier Martinez Canillas wrote:
> The I2C core always reports a MODALIAS of the form i2c: even if the
> device was registered via OF, this means that exporting the OF device ID
> table device aliases in the module is not needed. But in order to change
> how the core reports modaliases to user-space, it's better to export it.
> 
> Before this patch:
> 
> $ modinfo drivers/media/i2c/et8ek8/et8ek8.ko | grep alias
> alias:  i2c:et8ek8
> 
> After this patch:
> 
> $ modinfo drivers/media/i2c/et8ek8/et8ek8.ko | grep alias
> alias:  i2c:et8ek8
> alias:  of:N*T*Ctoshiba,et8ek8C*
> alias:  of:N*T*Ctoshiba,et8ek8
> 
> Signed-off-by: Javier Martinez Canillas 

Thanks!

Applied to my tree (for-v4.12 branch).

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH 0/6] Media controller and omap3isp cleanups

[Hans Verkuil]

Acked-by: Hans Verkuil 

Thanks!

Hans

On 02/20/2017 07:22 AM, Sakari Ailus wrote:
> Hi all,
> 
> These patches prepare for media device refcounting but do not begin those
> changes yet. They're worthwhile on their own merits.
> 

[PATCH v1 1/2] ir-ctl: use strndup instead of strndupa (fixes musl compile)

[Peter Seiderer]

Fixes buildroot musl compile (see [1], [2]):

  ir-ctl.c:(.text+0xb06): undefined reference to `strndupa'

[1] 
http://autobuild.buildroot.net/results/b8b96c7bbf2147dacac62485cbfdbcfd758271a5
[2] http://lists.busybox.net/pipermail/buildroot/2017-February/184048.html

Signed-off-by: Peter Seiderer 
---
 utils/ir-ctl/ir-ctl.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/utils/ir-ctl/ir-ctl.c b/utils/ir-ctl/ir-ctl.c
index bc58cee0..f938b429 100644
--- a/utils/ir-ctl/ir-ctl.c
+++ b/utils/ir-ctl/ir-ctl.c
@@ -344,12 +344,14 @@ static struct file *read_scancode(const char *name)
return NULL;
}
 
-   pstr = strndupa(name, p - name);
+   pstr = strndup(name, p - name);
 
if (!protocol_match(pstr, )) {
fprintf(stderr, _("error: protocol '%s' not found\n"), pstr);
+   free(pstr);
return NULL;
}
+   free(pstr);
 
if (!strtoscancode(p + 1, )) {
fprintf(stderr, _("error: invalid scancode '%s'\n"), p + 1);
-- 
2.11.0

[PATCH v1 2/2] ir-ctl: add optional copy of TEMP_FAILURE_RETRY macro (fix musl compile)

[Peter Seiderer]

Fixes buildroot musl compile (see [1], [2]):

  ir-ctl.c:(.text+0xe01): undefined reference to `TEMP_FAILURE_RETRY'

[1] 
http://autobuild.buildroot.net/results/b8b96c7bbf2147dacac62485cbfdbcfd758271a5
[2] http://lists.busybox.net/pipermail/buildroot/2017-February/184048.html

Signed-off-by: Peter Seiderer 
---
 utils/ir-ctl/ir-ctl.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/utils/ir-ctl/ir-ctl.c b/utils/ir-ctl/ir-ctl.c
index f938b429..e9da7778 100644
--- a/utils/ir-ctl/ir-ctl.c
+++ b/utils/ir-ctl/ir-ctl.c
@@ -44,6 +44,15 @@
 
 # define N_(string) string
 
+/* taken from glibc unistd.h */
+#ifndef TEMP_FAILURE_RETRY
+#define TEMP_FAILURE_RETRY(expression) \
+  (__extension__  \
+({ long int __result; \
+   do __result = (long int) (expression); \
+   while (__result == -1L && errno == EINTR); \
+   __result; }))
+#endif
 
 /* See drivers/media/rc/ir-lirc-codec.c line 23 */
 #define LIRCBUF_SIZE   512
-- 
2.11.0

[PATCH] cec rst: document the error codes

[Hans Verkuil]

Document all the various error codes returned by the CEC ioctls.

These were never documented, instead the documentation relied on a reference
to the generic error codes, but that's not sufficient.

Signed-off-by: Hans Verkuil 
---
diff --git a/Documentation/media/uapi/cec/cec-ioc-adap-g-log-addrs.rst 
b/Documentation/media/uapi/cec/cec-ioc-adap-g-log-addrs.rst
index b878637..3faf9c5 100644
--- a/Documentation/media/uapi/cec/cec-ioc-adap-g-log-addrs.rst
+++ b/Documentation/media/uapi/cec/cec-ioc-adap-g-log-addrs.rst
@@ -356,3 +356,16 @@ On success 0 is returned, on error -1 and the ``errno`` 
variable is set
 appropriately. The generic error codes are described at the
 :ref:`Generic Error Codes ` chapter.
 
+The :ref:`ioctl CEC_ADAP_S_LOG_ADDRS ` can return the 
following
+error codes:
+
+ENOTTY
+The ``CEC_CAP_LOG_ADDRS`` capability wasn't set, so this ioctl is not 
supported.
+
+EBUSY
+The CEC adapter is currently configuring itself, or it is already 
configured and
+``num_log_addrs`` is non-zero, or another filehandle is in exclusive 
follower or
+initiator mode, or the filehandle is in mode ``CEC_MODE_NO_INITIATOR``.
+
+EINVAL
+The contents of struct :c:type:`cec_log_addrs` is invalid.
diff --git a/Documentation/media/uapi/cec/cec-ioc-adap-g-phys-addr.rst 
b/Documentation/media/uapi/cec/cec-ioc-adap-g-phys-addr.rst
index 3357deb..8dfd84d 100644
--- a/Documentation/media/uapi/cec/cec-ioc-adap-g-phys-addr.rst
+++ b/Documentation/media/uapi/cec/cec-ioc-adap-g-phys-addr.rst
@@ -83,3 +83,16 @@ Return Value
 On success 0 is returned, on error -1 and the ``errno`` variable is set
 appropriately. The generic error codes are described at the
 :ref:`Generic Error Codes ` chapter.
+
+The :ref:`ioctl CEC_ADAP_S_PHYS_ADDR ` can return the 
following
+error codes:
+
+ENOTTY
+The ``CEC_CAP_PHYS_ADDR`` capability wasn't set, so this ioctl is not 
supported.
+
+EBUSY
+Another filehandle is in exclusive follower or initiator mode, or the 
filehandle
+is in mode ``CEC_MODE_NO_INITIATOR``.
+
+EINVAL
+The physical address is malformed.
diff --git a/Documentation/media/uapi/cec/cec-ioc-dqevent.rst 
b/Documentation/media/uapi/cec/cec-ioc-dqevent.rst
index e256c66..728364e 100644
--- a/Documentation/media/uapi/cec/cec-ioc-dqevent.rst
+++ b/Documentation/media/uapi/cec/cec-ioc-dqevent.rst
@@ -179,3 +179,14 @@ Return Value
 On success 0 is returned, on error -1 and the ``errno`` variable is set
 appropriately. The generic error codes are described at the
 :ref:`Generic Error Codes ` chapter.
+
+The :ref:`ioctl CEC_DQEVENT ` can return the following
+error codes:
+
+EAGAIN
+This is returned when the filehandle is in non-blocking mode and there
+are no pending events.
+
+ERESTARTSYS
+An interrupt (e.g. Ctrl-C) arrived while in blocking mode waiting for
+events to arrive.
diff --git a/Documentation/media/uapi/cec/cec-ioc-g-mode.rst 
b/Documentation/media/uapi/cec/cec-ioc-g-mode.rst
index 4f5818b..67fba88 100644
--- a/Documentation/media/uapi/cec/cec-ioc-g-mode.rst
+++ b/Documentation/media/uapi/cec/cec-ioc-g-mode.rst
@@ -254,3 +254,15 @@ Return Value
 On success 0 is returned, on error -1 and the ``errno`` variable is set
 appropriately. The generic error codes are described at the
 :ref:`Generic Error Codes ` chapter.
+
+The :ref:`ioctl CEC_S_MODE ` can return the following
+error codes:
+
+EINVAL
+The requested mode is invalid.
+
+EPERM
+Monitor mode is requested without having root permissions
+
+EBUSY
+Someone else is already an exclusive follower or initiator.
diff --git a/Documentation/media/uapi/cec/cec-ioc-receive.rst 
b/Documentation/media/uapi/cec/cec-ioc-receive.rst
index bdf015b..30cbcc9 100644
--- a/Documentation/media/uapi/cec/cec-ioc-receive.rst
+++ b/Documentation/media/uapi/cec/cec-ioc-receive.rst
@@ -294,3 +294,35 @@ Return Value
 On success 0 is returned, on error -1 and the ``errno`` variable is set
 appropriately. The generic error codes are described at the
 :ref:`Generic Error Codes ` chapter.
+
+The :ref:`ioctl CEC_RECEIVE ` can return the following
+error codes:
+
+EAGAIN
+No messages are in the receive queue, and the filehandle is in 
non-blocking mode.
+
+ETIMEDOUT
+The ``timeout`` was reached while waiting for a message.
+
+ERESTARTSYS
+The wait for a message was interrupted (e.g. by Ctrl-C).
+
+The :ref:`ioctl CEC_TRANSMIT ` can return the following
+error codes:
+
+ENOTTY
+The ``CEC_CAP_TRANSMIT`` capability wasn't set, so this ioctl is not 
supported.
+
+ENONET
+The CEC adapter is not configured.
+
+EBUSY
+Another filehandle is in exclusive follower or initiator mode, or the 
filehandle
+is in mode ``CEC_MODE_NO_INITIATOR``. This is also returned if the transmit
+queue is full.
+
+EINVAL
+The contents of struct :c:type:`cec_msg` is invalid.
+
+ERESTARTSYS
+The wait for a successful transmit was interrupted (e.g. by Ctrl-C).

[PATCH] cec: log reason for returning -EINVAL

[Hans Verkuil]

When validating the struct cec_s_log_addrs input a debug message is printed
for all except two of the 'return -EINVAL' paths.

Also log the reason for the missing two paths.

Signed-off-by: Hans Verkuil 
---
diff --git a/drivers/media/cec/cec-adap.c b/drivers/media/cec/cec-adap.c
index ebb5e391..72f9bba 100644
--- a/drivers/media/cec/cec-adap.c
+++ b/drivers/media/cec/cec-adap.c
@@ -1436,12 +1436,16 @@ int __cec_s_log_addrs(struct cec_adapter *adap,
 * within the correct range.
 */
if (log_addrs->vendor_id != CEC_VENDOR_ID_NONE &&
-   (log_addrs->vendor_id & 0xff00) != 0)
+   (log_addrs->vendor_id & 0xff00) != 0) {
+   dprintk(1, "invalid vendor ID\n");
return -EINVAL;
+   }
 
if (log_addrs->cec_version != CEC_OP_CEC_VERSION_1_4 &&
-   log_addrs->cec_version != CEC_OP_CEC_VERSION_2_0)
+   log_addrs->cec_version != CEC_OP_CEC_VERSION_2_0) {
+   dprintk(1, "invalid CEC version\n");
return -EINVAL;
+   }
 
if (log_addrs->num_log_addrs > 1)
for (i = 0; i < log_addrs->num_log_addrs; i++)

[PATCH] [media] et8ek8: Export OF device ID as module aliases

[Javier Martinez Canillas]

The I2C core always reports a MODALIAS of the form i2c: even if the
device was registered via OF, this means that exporting the OF device ID
table device aliases in the module is not needed. But in order to change
how the core reports modaliases to user-space, it's better to export it.

Before this patch:

$ modinfo drivers/media/i2c/et8ek8/et8ek8.ko | grep alias
alias:  i2c:et8ek8

After this patch:

$ modinfo drivers/media/i2c/et8ek8/et8ek8.ko | grep alias
alias:  i2c:et8ek8
alias:  of:N*T*Ctoshiba,et8ek8C*
alias:  of:N*T*Ctoshiba,et8ek8

Signed-off-by: Javier Martinez Canillas 
---

 drivers/media/i2c/et8ek8/et8ek8_driver.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/i2c/et8ek8/et8ek8_driver.c 
b/drivers/media/i2c/et8ek8/et8ek8_driver.c
index bec4a563a09c..f39f5179dd95 100644
--- a/drivers/media/i2c/et8ek8/et8ek8_driver.c
+++ b/drivers/media/i2c/et8ek8/et8ek8_driver.c
@@ -1485,6 +1485,7 @@ static const struct of_device_id et8ek8_of_table[] = {
{ .compatible = "toshiba,et8ek8" },
{ },
 };
+MODULE_DEVICE_TABLE(of, et8ek8_of_table);
 
 static const struct i2c_device_id et8ek8_id_table[] = {
{ ET8EK8_NAME, 0 },
-- 
2.9.3

RE: Dead code in v4l2-mem2mem.c?

[Shaobo]

Hi Laurent,

I'd like to. It sounds interesting and useful to me. Could you give me some 
pointers about how to audit drivers?

Shaobo
-Original Message-
From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] 
Sent: 2017年2月18日 3:54
To: Shaobo 
Cc: linux-media@vger.kernel.org; mche...@kernel.org; hverk...@xs4all.nl; 
sakari.ai...@linux.intel.com; ricardo.riba...@gmail.com
Subject: Re: Dead code in v4l2-mem2mem.c?

Hi Shaobo,

On Friday 17 Feb 2017 11:42:25 Shaobo wrote:
> Hi Laurent,
> 
> Thanks a lot for your reply.
> 
> I would like to also point out the inconsistency of using 
> `v4l2_m2m_get_vq` inside drivers/media/v4l2-core/v4l2-mem2mem.c and 
> inside other files. It appears to me almost all call sites of 
> `v4l2_m2m_get_vq` in drivers/media/v4l2-core/v4l2-mem2mem.c does not 
> have NULL check afterwards while in other files (e.g., 
> drivers/media/platform/mx2_emmaprp.c) they do. I was wondering if there is 
> special assumption on this function in mem2mem.c.

I don't see any case where the function could reasonably be called with a NULL 
context other than a severe driver bug. This being said, we need to audit the 
callers to make sure that's really the case. Would you like to do so and submit 
a patch ? :-)

> -Original Message-
> From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
> Sent: 2017年2月17日 3:26
> To: Shaobo 
> Cc: linux-media@vger.kernel.org; mche...@kernel.org; 
> hverk...@xs4all.nl; sakari.ai...@linux.intel.com; 
> ricardo.riba...@gmail.com
> Subject: Re: Dead code in v4l2-mem2mem.c?
> 
> Hi Shaobo,
> 
> First of all, could you please make sure you send future mails to the 
> linux- media mailing list in plain text only (no HTML) ? The mailing 
> list server rejects HTML e-mails.
> 
> On Thursday 16 Feb 2017 16:08:25 Shaobo wrote:
> > Hi there,
> > 
> > My name is Shaobo He and I am a graduate student at University of 
> > Utah. I am applying a static analysis tool to the Linux device 
> > drivers, looking for NULL pointer dereference and accidentally found 
> > a plausible dead code location in v4l2-mem2mem.c due to undefined behavior.
> > 
> > The following is the problematic code segment,
> > 
> > static struct v4l2_m2m_queue_ctx *get_queue_ctx(struct v4l2_m2m_ctx 
> > *m2m_ctx,
> > 
> >   enum v4l2_buf_type type)
> > 
> > {
> > 
> > if (V4L2_TYPE_IS_OUTPUT(type))
> > 
> > return _ctx->out_q_ctx;
> > 
> > else
> > 
> > return _ctx->cap_q_ctx;
> > 
> > }
> > 
> > struct vb2_queue *v4l2_m2m_get_vq(struct v4l2_m2m_ctx *m2m_ctx,
> > 
> > enum v4l2_buf_type type)
> > 
> > {
> > 
> > struct v4l2_m2m_queue_ctx *q_ctx;
> > 
> > q_ctx = get_queue_ctx(m2m_ctx, type);
> > if (!q_ctx)
> > 
> > return NULL;
> > 
> > return _ctx->q;
> > 
> > }
> > 
> > `get_queue_ctx` returns a pointer value that is an addition of the 
> > base pointer address (`m2m_ctx`) to a non-zero offset. The following 
> > is the definition of struct v4l2_m2m_ctx,
> > 
> > struct v4l2_m2m_ctx {
> > 
> > /* optional cap/out vb2 queues lock */
> > struct mutex*q_lock;
> > 
> > /* internal use only */
> > struct v4l2_m2m_dev *m2m_dev;
> > 
> > struct v4l2_m2m_queue_ctx   cap_q_ctx;
> > 
> > struct v4l2_m2m_queue_ctx   out_q_ctx;
> > 
> > /* For device job queue */
> > struct list_headqueue;
> > unsigned long   job_flags;
> > wait_queue_head_t   finished;
> > 
> > void*priv;
> > 
> > };
> > 
> > There is a NULL test in a caller of `get_queue_ctx` (line 85), which 
> > appears problematic to me. I'm not sure if it is defined or feasible 
> > under the context of Linux kernel. This blog
> > (https://wdtz.org/undefined-behavior-in-binutils-causes-segfault.htm
> > l) suggests that the NULL check can be optimized away because the 
> > only case that the return value can be NULL triggers pointer 
> > overflow, which is undefined.
> > 
> > Please let me know if it makes sense or not. Thanks for your time 
> > and I am looking forward to your reply.
> 
> The NULL check is indeed wrong. I believe that the m2m_ctx argument 
> passed to the v4l2_m2m_get_vq() function should never be NULL. We will 
> however need to audit drivers to make sure that's the case. The NULL 
> check could then be removed. Alternatively we could check m2m_ctx 
> above the get_queue_ctx() call, which wouldn't require auditing 
> drivers. It's a safe option, but would likely result in an unneeded NULL 
> check.
> 
> --
> Regards,
> 
> Laurent Pinchart

--
Regards,

Laurent Pinchart

change mode on PC tuner

[Łukasz Batek]

Hello,
I've bought TT-TVStick CT2-4400 and every time when I turn on PC, I have to 
write this: dvb-fe-tool
-d DVBC/ANNEX_A because I have set on dvb-t. What should I do to set it 
permanently?

-- 
Łukasz Batek

Re: ir-keytable: infinite loops, segfaults

[Sean Young]

Hi Vincent,

Thanks for testing this.

On Fri, Feb 17, 2017 at 12:05:50AM +1100, Vincent McIntyre wrote:
> Hi again
> 
> after you kindly fixed media_build for me I applied the nec protocol
> patch and tried again.
> 
> $ sudo ir-keytable
> Found /sys/class/rc/rc0/ (/dev/input/event5) with:
> Driver imon, table rc-imon-mce
> Supported protocols: rc-6
> Enabled protocols: rc-6
> Name: iMON Remote (15c2:ffdc)
> bus: 3, vendor/product: 15c2:ffdc, version: 0x
> Repeat delay = 500 ms, repeat period = 125 ms
> Found /sys/class/rc/rc1/ (/dev/input/event11) with:
> Driver dvb_usb_cxusb, table rc-dvico-mce
> Supported protocols: nec
> Enabled protocols:
> Name: IR-receiver inside an USB DVB re
> bus: 3, vendor/product: 0fe9:db78, version: 0x827b
> Repeat delay = 500 ms, repeat period = 125 ms
> Found /sys/class/rc/rc2/ (/dev/input/event16) with:
> Driver dvb_usb_af9035, table rc-empty
> Supported protocols: nec
> Enabled protocols:
> Name: Leadtek WinFast DTV Dongle Dual
> bus: 3, vendor/product: 0413:6a05, version: 0x0200
> Repeat delay = 500 ms, repeat period = 125 ms
> 
> $ sudo ir-keytable -v --sysdev rc1
> Found device /sys/class/rc/rc0/
> Found device /sys/class/rc/rc1/
> Found device /sys/class/rc/rc2/
> Input sysfs node is /sys/class/rc/rc0/input8/
> Event sysfs node is /sys/class/rc/rc0/input8/event5/
> Parsing uevent /sys/class/rc/rc0/input8/event5/uevent
> /sys/class/rc/rc0/input8/event5/uevent uevent MAJOR=13
> /sys/class/rc/rc0/input8/event5/uevent uevent MINOR=69
> /sys/class/rc/rc0/input8/event5/uevent uevent DEVNAME=input/event5
> Parsing uevent /sys/class/rc/rc0/uevent
> /sys/class/rc/rc0/uevent uevent NAME=rc-imon-mce
> /sys/class/rc/rc0/uevent uevent DRV_NAME=imon
> input device is /dev/input/event5
> /sys/class/rc/rc0/protocols protocol rc-6 (enabled)
> Found /sys/class/rc/rc0/ (/dev/input/event5) with:
> Driver imon, table rc-imon-mce
> Supported protocols: rc-6
> Enabled protocols: rc-6
> Name: iMON Remote (15c2:ffdc)
> bus: 3, vendor/product: 15c2:ffdc, version: 0x
> Repeat delay = 500 ms, repeat period = 125 ms
> Input sysfs node is /sys/class/rc/rc1/input17/
> Event sysfs node is /sys/class/rc/rc1/input17/event11/
> Parsing uevent /sys/class/rc/rc1/input17/event11/uevent
> /sys/class/rc/rc1/input17/event11/uevent uevent MAJOR=13
> /sys/class/rc/rc1/input17/event11/uevent uevent MINOR=75
> /sys/class/rc/rc1/input17/event11/uevent uevent DEVNAME=input/event11
> Parsing uevent /sys/class/rc/rc1/uevent
> /sys/class/rc/rc1/uevent uevent NAME=rc-dvico-mce
> /sys/class/rc/rc1/uevent uevent DRV_NAME=dvb_usb_cxusb
> input device is /dev/input/event11
> /sys/class/rc/rc1/protocols protocol nec (disabled)
> Found /sys/class/rc/rc1/ (/dev/input/event11) with:
> Driver dvb_usb_cxusb, table rc-dvico-mce
> Supported protocols: nec
> Enabled protocols:
> Name: IR-receiver inside an USB DVB re
> bus: 3, vendor/product: 0fe9:db78, version: 0x827b
> Repeat delay = 500 ms, repeat period = 125 ms
> Input sysfs node is /sys/class/rc/rc2/input19/
> Event sysfs node is /sys/class/rc/rc2/input19/event16/
> Parsing uevent /sys/class/rc/rc2/input19/event16/uevent
> /sys/class/rc/rc2/input19/event16/uevent uevent MAJOR=13
> /sys/class/rc/rc2/input19/event16/uevent uevent MINOR=80
> /sys/class/rc/rc2/input19/event16/uevent uevent DEVNAME=input/event16
> Parsing uevent /sys/class/rc/rc2/uevent
> /sys/class/rc/rc2/uevent uevent NAME=rc-empty
> /sys/class/rc/rc2/uevent uevent DRV_NAME=dvb_usb_af9035
> input device is /dev/input/event16
> /sys/class/rc/rc2/protocols protocol nec (disabled)
> Found /sys/class/rc/rc2/ (/dev/input/event16) with:
> Driver dvb_usb_af9035, table rc-empty
> Supported protocols: nec
> Enabled protocols:
> Name: Leadtek WinFast DTV Dongle Dual
> bus: 3, vendor/product: 0413:6a05, version: 0x0200
> Repeat delay = 500 ms, repeat period = 125 ms
> 
> So only rc0 has any protocols enabled. Let's try to enable nec on rc1
> 
> $ sudo /usr/bin/ir-keytable -s rc1 -c
> Old keytable cleared
> $ sudo /usr/bin/ir-keytable -s rc1 -w /etc/rc_keymaps/dvico-remote
> Read dvico_mce table
> Wrote 45 keycode(s) to driver
> Invalid protocols selected
> Couldn't change the IR protocols
> $ sudo /usr/bin/ir-keytable -s rc1 -p nec -v
> Found device /sys/class/rc/rc0/
> Found device /sys/class/rc/rc1/
> Found device /sys/class/rc/rc2/
> Input sysfs node is /sys/class/rc/rc1/input17/
> Event sysfs node is /sys/class/rc/rc1/input17/event11/
> Parsing uevent /sys/class/rc/rc1/input17/event11/uevent
> /sys/class/rc/rc1/input17/event11/uevent uevent MAJOR=13
> /sys/class/rc/rc1/input17/event11/uevent uevent MINOR=75
> /sys/class/rc/rc1/input17/event11/uevent uevent DEVNAME=input/event11
> Parsing uevent /sys/class/rc/rc1/uevent
> 

Re: [PATCH] v4l-utils: fix invalid protocol in streamzap keymap

[Matthias Reichl]

On Sat, Feb 18, 2017 at 07:24:43PM +, Sean Young wrote:
> On Fri, Feb 17, 2017 at 10:19:16AM +0100, Matthias Reichl wrote:
> > ir-keytable can't load the streamzap keymap because the
> > protocol type RC5_SZ is invalid:
> > 
> > ./ir-keytable -w rc_keymaps/streamzap
> > Protocol RC5_SZ invalid
> > ...
> > 
> > Fix this by changing the protocol type to RC-5-SZ which
> > matches the kernel protocol rc-5-sz
> > 
> > Signed-off-by: Matthias Reichl 
> > ---
> >  utils/keytable/rc_keymaps/streamzap | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/utils/keytable/rc_keymaps/streamzap 
> > b/utils/keytable/rc_keymaps/streamzap
> > index 3512cd8..03d2cb8 100644
> > --- a/utils/keytable/rc_keymaps/streamzap
> > +++ b/utils/keytable/rc_keymaps/streamzap
> 
> This is file is generated by utils/keytable/gen_keytables.pl, so there is no
> use in patching it.

Ouch, I totally missed that. Thanks for pointing it out!

> Actually I think a better solution would be to be less pernickety about how
> the protocol is specified. ir-ctl also does this. How about the following
> patch.

I agree, this is a much better solution. It simplifies the protocol_map
and being more tolerant about spelling is also a benefit to the user.

> Sean
> 
> From: Sean Young 
> Subject: [PATCH] [PATCH v4l-utils] ir-keytable: be more permissive on protocol
>  name
> 
> Allowed the protocol to be specified with or without underscores or
> dashes. This also solves the problem of not being able to load
> the streamzap keymap.
> 
> ./ir-keytable -w rc_keymaps/streamzap
> Protocol RC5_SZ invalid
> 
> Reported-by: Matthias Reichl 
> Signed-off-by: Sean Young 
> ---
>  utils/keytable/keytable.c | 20 
>  1 file changed, 16 insertions(+), 4 deletions(-)
> 
> diff --git a/utils/keytable/keytable.c b/utils/keytable/keytable.c
> index a6ecc9e..a35db5b 100644
> --- a/utils/keytable/keytable.c
> +++ b/utils/keytable/keytable.c
> @@ -120,9 +120,7 @@ const struct protocol_map_entry protocol_map[] = {
>   { "other",  NULL,   SYSFS_OTHER },
>   { "lirc",   NULL,   SYSFS_LIRC  },
>   { "rc-5",   "/rc5_decoder", SYSFS_RC5   },
> - { "rc5",NULL,   SYSFS_RC5   },
>   { "rc-5x",  NULL,   SYSFS_INVALID   },
> - { "rc5x",   NULL,   SYSFS_INVALID   },
>   { "rc-5-sz",NULL,   SYSFS_RC5_SZ},
>   { "jvc","/jvc_decoder", SYSFS_JVC   },
>   { "sony",   "/sony_decoder",SYSFS_SONY  },
> @@ -134,7 +132,6 @@ const struct protocol_map_entry protocol_map[] = {
>   { "mce_kbd",NULL,   SYSFS_MCE_KBD   },
>   { "mce-kbd",NULL,   SYSFS_MCE_KBD   },
>   { "rc-6",   "/rc6_decoder", SYSFS_RC6   },
> - { "rc6",NULL,   SYSFS_RC6   },
>   { "rc-6-0", NULL,   SYSFS_INVALID   },
>   { "rc-6-6a-20", NULL,   SYSFS_INVALID   },
>   { "rc-6-6a-24", NULL,   SYSFS_INVALID   },
> @@ -145,6 +142,21 @@ const struct protocol_map_entry protocol_map[] = {
>   { NULL, NULL,   SYSFS_INVALID   },
>  };
>  
> +static bool str_like(const char *a, const char *b)
> +{
> + while (*a && *b) {
> + if (*a == '-' || *a == '_')
> + a++;
> + if (*b == '-' || *b == '_')
> + b++;
> + if (tolower(*a) != tolower(*b))
> + return false;
> + a++; b++;
> + }

A small nit: this code will fail if both strings are identical
and end with a dash or underscore. In that case we'll iterate
beyond then end of the strings.

Adding a continue after the dash/underscore increment should fix
this, then we won't increment the pointer by 2 within a loop

if (*a == '-' || *a == '_') {
a++;
continue;
}
if (*b == '-' || *b == '_') {
b++;
continue;
}

Other than that the patch looks fine to me and worked well.

> +
> + return !*a && !*b;
> +}
> +
>  static enum sysfs_protocols parse_sysfs_protocol(const char *name, bool 
> all_allowed)
>  {
>   const struct protocol_map_entry *pme;
> @@ -156,7 +168,7 @@ static enum sysfs_protocols parse_sysfs_protocol(const 
> char *name, bool all_allo
>   return ~0;
>  
>   for (pme = protocol_map; pme->name; pme++) {
> - if (!strcasecmp(name, pme->name))
> + if (str_like(name, pme->name))
>   return pme->sysfs_protocol;
>   }
>  
> -- 
> 2.9.3
> 

[PATCH 6/6] media: devnode: Rename mdev argument as devnode

[Sakari Ailus]

Historically, mdev argument name was being used on both struct
media_device and struct media_devnode. Recently most occurrences of mdev
referring to struct media_devnode were replaced by devnode, which makes
more sense. Fix the last remaining occurrence.

Fixes: 163f1e93e9950 ("[media] media-devnode: fix namespace mess")
Signed-off-by: Sakari Ailus 
Acked-by: Hans Verkuil 
---
 drivers/media/media-device.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index c51e2e5..fce91b5 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -537,9 +537,9 @@ static DEVICE_ATTR(model, S_IRUGO, show_model, NULL);
  * Registration/unregistration
  */
 
-static void media_device_release(struct media_devnode *mdev)
+static void media_device_release(struct media_devnode *devnode)
 {
-   dev_dbg(mdev->parent, "Media device released\n");
+   dev_dbg(devnode->parent, "Media device released\n");
 }
 
 /**
-- 
2.1.4

[PATCH 1/6] omap3isp: Don't rely on devm for memory resource management

[Sakari Ailus]

devm functions are fine for managing resources that are directly related
to the device at hand and that have no other dependencies. However, a
process holding a file handle to a device created by a driver for a device
may result in the file handle left behind after the device is long gone.
This will result in accessing released (and potentially reallocated)
memory.

Instead, manage the memory resources in the driver. Releasing the
resources can be later on bound to e.g. by releasing a reference.

Signed-off-by: Sakari Ailus 
---
 drivers/media/platform/omap3isp/isp.c | 18 --
 drivers/media/platform/omap3isp/isph3a_aewb.c | 24 +---
 drivers/media/platform/omap3isp/isph3a_af.c   | 24 +---
 drivers/media/platform/omap3isp/isphist.c | 11 +++
 drivers/media/platform/omap3isp/ispstat.c |  2 ++
 5 files changed, 55 insertions(+), 24 deletions(-)

diff --git a/drivers/media/platform/omap3isp/isp.c 
b/drivers/media/platform/omap3isp/isp.c
index 084ecf4a..874f6fc 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -2015,6 +2015,8 @@ static int isp_remove(struct platform_device *pdev)
 
media_entity_enum_cleanup(>crashed);
 
+   kfree(isp);
+
return 0;
 }
 
@@ -2203,7 +2205,7 @@ static int isp_probe(struct platform_device *pdev)
int ret;
int i, m;
 
-   isp = devm_kzalloc(>dev, sizeof(*isp), GFP_KERNEL);
+   isp = kzalloc(sizeof(*isp), GFP_KERNEL);
if (!isp) {
dev_err(>dev, "could not allocate memory\n");
return -ENOMEM;
@@ -2212,21 +2214,23 @@ static int isp_probe(struct platform_device *pdev)
ret = of_property_read_u32(pdev->dev.of_node, "ti,phy-type",
   >phy_type);
if (ret)
-   return ret;
+   goto error_release_isp;
 
isp->syscon = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
  "syscon");
-   if (IS_ERR(isp->syscon))
-   return PTR_ERR(isp->syscon);
+   if (IS_ERR(isp->syscon)) {
+   ret = PTR_ERR(isp->syscon);
+   goto error_release_isp;
+   }
 
ret = of_property_read_u32_index(pdev->dev.of_node, "syscon", 1,
 >syscon_offset);
if (ret)
-   return ret;
+   goto error_release_isp;
 
ret = isp_of_parse_nodes(>dev, >notifier);
if (ret < 0)
-   return ret;
+   goto error_release_isp;
 
isp->autoidle = autoidle;
 
@@ -2376,6 +2380,8 @@ static int isp_probe(struct platform_device *pdev)
__omap3isp_put(isp, false);
 error:
mutex_destroy(>isp_mutex);
+error_release_isp:
+   kfree(isp);
 
return ret;
 }
diff --git a/drivers/media/platform/omap3isp/isph3a_aewb.c 
b/drivers/media/platform/omap3isp/isph3a_aewb.c
index d44626f2..efddafd 100644
--- a/drivers/media/platform/omap3isp/isph3a_aewb.c
+++ b/drivers/media/platform/omap3isp/isph3a_aewb.c
@@ -289,9 +289,10 @@ int omap3isp_h3a_aewb_init(struct isp_device *isp)
 {
struct ispstat *aewb = >isp_aewb;
struct omap3isp_h3a_aewb_config *aewb_cfg;
-   struct omap3isp_h3a_aewb_config *aewb_recover_cfg;
+   struct omap3isp_h3a_aewb_config *aewb_recover_cfg = NULL;
+   int ret;
 
-   aewb_cfg = devm_kzalloc(isp->dev, sizeof(*aewb_cfg), GFP_KERNEL);
+   aewb_cfg = kzalloc(sizeof(*aewb_cfg), GFP_KERNEL);
if (!aewb_cfg)
return -ENOMEM;
 
@@ -301,12 +302,12 @@ int omap3isp_h3a_aewb_init(struct isp_device *isp)
aewb->isp = isp;
 
/* Set recover state configuration */
-   aewb_recover_cfg = devm_kzalloc(isp->dev, sizeof(*aewb_recover_cfg),
-   GFP_KERNEL);
+   aewb_recover_cfg = kzalloc(sizeof(*aewb_recover_cfg), GFP_KERNEL);
if (!aewb_recover_cfg) {
dev_err(aewb->isp->dev,
"AEWB: cannot allocate memory for recover 
configuration.\n");
-   return -ENOMEM;
+   ret = -ENOMEM;
+   goto err;
}
 
aewb_recover_cfg->saturation_limit = OMAP3ISP_AEWB_MAX_SATURATION_LIM;
@@ -323,13 +324,22 @@ int omap3isp_h3a_aewb_init(struct isp_device *isp)
if (h3a_aewb_validate_params(aewb, aewb_recover_cfg)) {
dev_err(aewb->isp->dev,
"AEWB: recover configuration is invalid.\n");
-   return -EINVAL;
+   ret = -EINVAL;
+   goto err;
}
 
aewb_recover_cfg->buf_size = h3a_aewb_get_buf_size(aewb_recover_cfg);
aewb->recover_priv = aewb_recover_cfg;
 
-   return omap3isp_stat_init(aewb, "AEWB", _aewb_subdev_ops);
+   ret = omap3isp_stat_init(aewb, "AEWB", _aewb_subdev_ops);
+
+err:
+   if (ret) {
+   

[PATCH 2/6] omap3isp: Call video_unregister_device() unconditionally

[Sakari Ailus]

video_unregister_device() can be called on a never or an already
unregistered device. Drop the redundant check.

Signed-off-by: Sakari Ailus 
---
 drivers/media/platform/omap3isp/ispvideo.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/media/platform/omap3isp/ispvideo.c 
b/drivers/media/platform/omap3isp/ispvideo.c
index 218e6d7..9e9b18c 100644
--- a/drivers/media/platform/omap3isp/ispvideo.c
+++ b/drivers/media/platform/omap3isp/ispvideo.c
@@ -1495,6 +1495,5 @@ int omap3isp_video_register(struct isp_video *video, 
struct v4l2_device *vdev)
 
 void omap3isp_video_unregister(struct isp_video *video)
 {
-   if (video_is_registered(>video))
-   video_unregister_device(>video);
+   video_unregister_device(>video);
 }
-- 
2.1.4

[PATCH 0/6] Media controller and omap3isp cleanups

[Sakari Ailus]

Hi all,

These patches prepare for media device refcounting but do not begin those
changes yet. They're worthwhile on their own merits.

-- 
Kind regards,
Sakari

[PATCH 5/6] media: Remove useless curly braces and parentheses

[Sakari Ailus]

Signed-off-by: Sakari Ailus 
Acked-by: Hans Verkuil 
---
 drivers/media/media-device.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/media/media-device.c b/drivers/media/media-device.c
index 760e3e4..c51e2e5 100644
--- a/drivers/media/media-device.c
+++ b/drivers/media/media-device.c
@@ -591,9 +591,8 @@ int __must_check media_device_register_entity(struct 
media_device *mdev,
   >pads[i].graph_obj);
 
/* invoke entity_notify callbacks */
-   list_for_each_entry_safe(notify, next, >entity_notify, list) {
-   (notify)->notify(entity, notify->notify_data);
-   }
+   list_for_each_entry_safe(notify, next, >entity_notify, list)
+   notify->notify(entity, notify->notify_data);
 
if (mdev->entity_internal_idx_max
>= mdev->pm_count_walk.ent_enum.idx_max) {
-- 
2.1.4

[PATCH 4/6] omap3isp: Disable streaming at driver unbind time

[Sakari Ailus]

Once the driver is unbound accessing the hardware is not allowed anymore.
Due to this, disable streaming when the device driver is unbound. The
states of the associated objects related to Media controller and videobuf2
frameworks are updated as well, just like if the application disabled
streaming explicitly.

Signed-off-by: Sakari Ailus 
---
 drivers/media/platform/omap3isp/ispvideo.c | 23 +++
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/drivers/media/platform/omap3isp/ispvideo.c 
b/drivers/media/platform/omap3isp/ispvideo.c
index a3ca2a4..c04d357 100644
--- a/drivers/media/platform/omap3isp/ispvideo.c
+++ b/drivers/media/platform/omap3isp/ispvideo.c
@@ -1191,22 +1191,17 @@ isp_video_streamon(struct file *file, void *fh, enum 
v4l2_buf_type type)
 }
 
 static int
-isp_video_streamoff(struct file *file, void *fh, enum v4l2_buf_type type)
+__isp_video_streamoff(struct isp_video *video)
 {
-   struct isp_video_fh *vfh = to_isp_video_fh(fh);
-   struct isp_video *video = video_drvdata(file);
struct isp_pipeline *pipe = to_isp_pipeline(>video.entity);
enum isp_pipeline_state state;
unsigned int streaming;
unsigned long flags;
 
-   if (type != video->type)
-   return -EINVAL;
-
mutex_lock(>stream_lock);
 
mutex_lock(>queue_lock);
-   streaming = vb2_is_streaming(>queue);
+   streaming = video->queue && vb2_is_streaming(video->queue);
mutex_unlock(>queue_lock);
 
if (!streaming)
@@ -1229,7 +1224,7 @@ isp_video_streamoff(struct file *file, void *fh, enum 
v4l2_buf_type type)
omap3isp_video_cancel_stream(video);
 
mutex_lock(>queue_lock);
-   vb2_streamoff(>queue, type);
+   vb2_streamoff(video->queue, video->queue->type);
mutex_unlock(>queue_lock);
video->queue = NULL;
video->error = false;
@@ -1245,6 +1240,17 @@ isp_video_streamoff(struct file *file, void *fh, enum 
v4l2_buf_type type)
 }
 
 static int
+isp_video_streamoff(struct file *file, void *fh, enum v4l2_buf_type type)
+{
+   struct isp_video *video = video_drvdata(file);
+
+   if (type != video->type)
+   return -EINVAL;
+
+   return __isp_video_streamoff(video);
+}
+
+static int
 isp_video_enum_input(struct file *file, void *fh, struct v4l2_input *input)
 {
if (input->index > 0)
@@ -1494,5 +1500,6 @@ int omap3isp_video_register(struct isp_video *video, 
struct v4l2_device *vdev)
 
 void omap3isp_video_unregister(struct isp_video *video)
 {
+   __isp_video_streamoff(video);
video_unregister_device(>video);
 }
-- 
2.1.4

[PATCH 3/6] omap3isp: Remove misleading comment

[Sakari Ailus]

The intent of the check the comment is related to is to ensure we are
streaming --- still. Not that streaming wouldn't be enabled yet. Remove
it.

Signed-off-by: Sakari Ailus 
---
 drivers/media/platform/omap3isp/ispvideo.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/media/platform/omap3isp/ispvideo.c 
b/drivers/media/platform/omap3isp/ispvideo.c
index 9e9b18c..a3ca2a4 100644
--- a/drivers/media/platform/omap3isp/ispvideo.c
+++ b/drivers/media/platform/omap3isp/ispvideo.c
@@ -1205,7 +1205,6 @@ isp_video_streamoff(struct file *file, void *fh, enum 
v4l2_buf_type type)
 
mutex_lock(>stream_lock);
 
-   /* Make sure we're not streaming yet. */
mutex_lock(>queue_lock);
streaming = vb2_is_streaming(>queue);
mutex_unlock(>queue_lock);
-- 
2.1.4

Re: [PATCH 1/4] v4l2: device_register_subdev_nodes: allow calling multiple times

[Sakari Ailus]

On Mon, Feb 20, 2017 at 03:09:13PM +0200, Sakari Ailus wrote:
> I've tested ACPI, will test DT soon...

DT case works, too (Nokia N9).

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v2 08/15] media: s5p-mfc: Move firmware allocation to DMA configure function

[Javier Martinez Canillas]

Hello Marek,

On 02/20/2017 10:38 AM, Marek Szyprowski wrote:
> To complete DMA memory configuration for MFC device, allocation of the
> firmware buffer is needed, because some parameters are dependant on its base
> address. Till now, this has been handled in the s5p_mfc_alloc_firmware()
> function. This patch moves that logic to s5p_mfc_configure_dma_memory() to
> keep DMA memory related operations in a single place. This way
> s5p_mfc_alloc_firmware() is simplified and does what it name says. The
> other consequence of this change is moving s5p_mfc_alloc_firmware() call
> from the s5p_mfc_probe() function to the s5p_mfc_configure_dma_memory().
> 
> Signed-off-by: Marek Szyprowski 
> ---

Reviewed-by: Javier Martinez Canillas 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

[PATCH v2 06/15] media: s5p-mfc: Move setting DMA max segment size to DMA configure function

[Marek Szyprowski]

Setting DMA max segment size to 32 bit mask is a part of DMA memory
configuration, so move those calls to s5p_mfc_configure_dma_memory()
function.

Signed-off-by: Marek Szyprowski 
Reviewed-by: Javier Martinez Canillas 
Tested-by: Javier Martinez Canillas 
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index f7664910f12c..bc1aeb25ebeb 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1122,9 +1122,13 @@ static int s5p_mfc_configure_dma_memory(struct 
s5p_mfc_dev *mfc_dev)
if (exynos_is_iommu_available(dev)) {
int ret = exynos_configure_iommu(dev, S5P_MFC_IOMMU_DMA_BASE,
 S5P_MFC_IOMMU_DMA_SIZE);
-   if (ret == 0)
+   if (ret == 0) {
mfc_dev->mem_dev[BANK1_CTX] =
mfc_dev->mem_dev[BANK2_CTX] = dev;
+   vb2_dma_contig_set_max_seg_size(dev,
+   DMA_BIT_MASK(32));
+   }
+
return ret;
}
 
@@ -1143,6 +1147,11 @@ static int s5p_mfc_configure_dma_memory(struct 
s5p_mfc_dev *mfc_dev)
return -ENODEV;
}
 
+   vb2_dma_contig_set_max_seg_size(mfc_dev->mem_dev[BANK1_CTX],
+   DMA_BIT_MASK(32));
+   vb2_dma_contig_set_max_seg_size(mfc_dev->mem_dev[BANK2_CTX],
+   DMA_BIT_MASK(32));
+
return 0;
 }
 
@@ -1152,11 +1161,14 @@ static void s5p_mfc_unconfigure_dma_memory(struct 
s5p_mfc_dev *mfc_dev)
 
if (exynos_is_iommu_available(dev)) {
exynos_unconfigure_iommu(dev);
+   vb2_dma_contig_clear_max_seg_size(dev);
return;
}
 
device_unregister(mfc_dev->mem_dev[BANK1_CTX]);
device_unregister(mfc_dev->mem_dev[BANK2_CTX]);
+   vb2_dma_contig_clear_max_seg_size(mfc_dev->mem_dev[BANK1_CTX]);
+   vb2_dma_contig_clear_max_seg_size(mfc_dev->mem_dev[BANK2_CTX]);
 }
 
 /* MFC probe function */
@@ -1214,11 +1226,6 @@ static int s5p_mfc_probe(struct platform_device *pdev)
goto err_dma;
}
 
-   vb2_dma_contig_set_max_seg_size(dev->mem_dev[BANK1_CTX],
-   DMA_BIT_MASK(32));
-   vb2_dma_contig_set_max_seg_size(dev->mem_dev[BANK2_CTX],
-   DMA_BIT_MASK(32));
-
mutex_init(>mfc_mutex);
init_waitqueue_head(>queue);
dev->hw_lock = 0;
@@ -1351,8 +1358,6 @@ static int s5p_mfc_remove(struct platform_device *pdev)
v4l2_device_unregister(>v4l2_dev);
s5p_mfc_release_firmware(dev);
s5p_mfc_unconfigure_dma_memory(dev);
-   vb2_dma_contig_clear_max_seg_size(dev->mem_dev[BANK1_CTX]);
-   vb2_dma_contig_clear_max_seg_size(dev->mem_dev[BANK2_CTX]);
 
s5p_mfc_final_pm(dev);
return 0;
-- 
1.9.1

[PATCH v2 03/15] media: s5p-mfc: Replace mem_dev_* entries with an array

[Marek Szyprowski]

Internal MFC driver device structure contains two pointers to devices used
for DMA memory allocation: mem_dev_l and mem_dev_r. Replace them with the
mem_dev[] array and use defines for accessing particular banks. This will
help to simplify code in the next patches.

Signed-off-by: Marek Szyprowski 
Reviewed-by: Javier Martinez Canillas 
Tested-by: Javier Martinez Canillas 
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c| 31 +---
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 11 -
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c   | 23 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c|  8 +++
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c| 10 
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c | 32 ++---
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 15 ++--
 7 files changed, 69 insertions(+), 61 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index ad3d7377f40d..f7664910f12c 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1123,7 +1123,8 @@ static int s5p_mfc_configure_dma_memory(struct 
s5p_mfc_dev *mfc_dev)
int ret = exynos_configure_iommu(dev, S5P_MFC_IOMMU_DMA_BASE,
 S5P_MFC_IOMMU_DMA_SIZE);
if (ret == 0)
-   mfc_dev->mem_dev_l = mfc_dev->mem_dev_r = dev;
+   mfc_dev->mem_dev[BANK1_CTX] =
+   mfc_dev->mem_dev[BANK2_CTX] = dev;
return ret;
}
 
@@ -1131,14 +1132,14 @@ static int s5p_mfc_configure_dma_memory(struct 
s5p_mfc_dev *mfc_dev)
 * Create and initialize virtual devices for accessing
 * reserved memory regions.
 */
-   mfc_dev->mem_dev_l = s5p_mfc_alloc_memdev(dev, "left",
- MFC_BANK1_ALLOC_CTX);
-   if (!mfc_dev->mem_dev_l)
+   mfc_dev->mem_dev[BANK1_CTX] = s5p_mfc_alloc_memdev(dev, "left",
+  BANK1_CTX);
+   if (!mfc_dev->mem_dev[BANK1_CTX])
return -ENODEV;
-   mfc_dev->mem_dev_r = s5p_mfc_alloc_memdev(dev, "right",
- MFC_BANK2_ALLOC_CTX);
-   if (!mfc_dev->mem_dev_r) {
-   device_unregister(mfc_dev->mem_dev_l);
+   mfc_dev->mem_dev[BANK2_CTX] = s5p_mfc_alloc_memdev(dev, "right",
+  BANK2_CTX);
+   if (!mfc_dev->mem_dev[BANK2_CTX]) {
+   device_unregister(mfc_dev->mem_dev[BANK1_CTX]);
return -ENODEV;
}
 
@@ -1154,8 +1155,8 @@ static void s5p_mfc_unconfigure_dma_memory(struct 
s5p_mfc_dev *mfc_dev)
return;
}
 
-   device_unregister(mfc_dev->mem_dev_l);
-   device_unregister(mfc_dev->mem_dev_r);
+   device_unregister(mfc_dev->mem_dev[BANK1_CTX]);
+   device_unregister(mfc_dev->mem_dev[BANK2_CTX]);
 }
 
 /* MFC probe function */
@@ -1213,8 +1214,10 @@ static int s5p_mfc_probe(struct platform_device *pdev)
goto err_dma;
}
 
-   vb2_dma_contig_set_max_seg_size(dev->mem_dev_l, DMA_BIT_MASK(32));
-   vb2_dma_contig_set_max_seg_size(dev->mem_dev_r, DMA_BIT_MASK(32));
+   vb2_dma_contig_set_max_seg_size(dev->mem_dev[BANK1_CTX],
+   DMA_BIT_MASK(32));
+   vb2_dma_contig_set_max_seg_size(dev->mem_dev[BANK2_CTX],
+   DMA_BIT_MASK(32));
 
mutex_init(>mfc_mutex);
init_waitqueue_head(>queue);
@@ -1348,8 +1351,8 @@ static int s5p_mfc_remove(struct platform_device *pdev)
v4l2_device_unregister(>v4l2_dev);
s5p_mfc_release_firmware(dev);
s5p_mfc_unconfigure_dma_memory(dev);
-   vb2_dma_contig_clear_max_seg_size(dev->mem_dev_l);
-   vb2_dma_contig_clear_max_seg_size(dev->mem_dev_r);
+   vb2_dma_contig_clear_max_seg_size(dev->mem_dev[BANK1_CTX]);
+   vb2_dma_contig_clear_max_seg_size(dev->mem_dev[BANK2_CTX]);
 
s5p_mfc_final_pm(dev);
return 0;
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h 
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index 2f1387a4c386..27d4c864e06e 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -33,8 +33,9 @@
 *  while mmaping */
 #define DST_QUEUE_OFF_BASE (1 << 30)
 
-#define MFC_BANK1_ALLOC_CTX0
-#define MFC_BANK2_ALLOC_CTX1
+#define BANK1_CTX  0
+#define BANK2_CTX  1
+#define BANK_CTX_NUM   2
 
 #define MFC_BANK1_ALIGN_ORDER  13
 #define MFC_BANK2_ALIGN_ORDER  13
@@ -254,8 +255,7 @@ struct s5p_mfc_priv_buf {
  * @vfd_dec:   video device for decoding
  * @vfd_enc:   video 

[PATCH v2 02/15] media: s5p-mfc: Use generic of_device_get_match_data helper

[Marek Szyprowski]

Replace custom code with generic helper to retrieve driver data.

Signed-off-by: Marek Szyprowski 
Reviewed-by: Javier Martinez Canillas 
Tested-by: Javier Martinez Canillas 
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c| 17 ++---
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h |  4 ++--
 2 files changed, 4 insertions(+), 17 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 3e1f22eb4339..ad3d7377f40d 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "s5p_mfc_common.h"
@@ -1157,8 +1158,6 @@ static void s5p_mfc_unconfigure_dma_memory(struct 
s5p_mfc_dev *mfc_dev)
device_unregister(mfc_dev->mem_dev_r);
 }
 
-static void *mfc_get_drv_data(struct platform_device *pdev);
-
 /* MFC probe function */
 static int s5p_mfc_probe(struct platform_device *pdev)
 {
@@ -1182,7 +1181,7 @@ static int s5p_mfc_probe(struct platform_device *pdev)
return -ENODEV;
}
 
-   dev->variant = mfc_get_drv_data(pdev);
+   dev->variant = of_device_get_match_data(>dev);
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
dev->regs_base = devm_ioremap_resource(>dev, res);
@@ -1541,18 +1540,6 @@ static int s5p_mfc_resume(struct device *dev)
 };
 MODULE_DEVICE_TABLE(of, exynos_mfc_match);
 
-static void *mfc_get_drv_data(struct platform_device *pdev)
-{
-   struct s5p_mfc_variant *driver_data = NULL;
-   const struct of_device_id *match;
-
-   match = of_match_node(exynos_mfc_match, pdev->dev.of_node);
-   if (match)
-   driver_data = (struct s5p_mfc_variant *)match->data;
-
-   return driver_data;
-}
-
 static struct platform_driver s5p_mfc_driver = {
.probe  = s5p_mfc_probe,
.remove = s5p_mfc_remove,
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h 
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index 3e0e8eaf8bfe..2f1387a4c386 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -192,7 +192,7 @@ struct s5p_mfc_buf {
  */
 struct s5p_mfc_pm {
struct clk  *clock_gate;
-   const char  **clk_names;
+   const char * const *clk_names;
struct clk  *clocks[MFC_MAX_CLOCKS];
int num_clocks;
booluse_clock_gating;
@@ -304,7 +304,7 @@ struct s5p_mfc_dev {
struct v4l2_ctrl_handler dec_ctrl_handler;
struct v4l2_ctrl_handler enc_ctrl_handler;
struct s5p_mfc_pm   pm;
-   struct s5p_mfc_variant  *variant;
+   const struct s5p_mfc_variant*variant;
int num_inst;
spinlock_t irqlock; /* lock when operating on context */
spinlock_t condlock;/* lock when changing/checking if a context is
-- 
1.9.1

[PATCH v2 10/15] media: s5p-mfc: Reduce firmware buffer size for MFC v6+ variants

[Marek Szyprowski]

Firmware for MFC v6+ variants is not larger than 400 KiB, so there is no
need to allocate a full 1 MiB buffer for it. Reduce it to 512 KiB to keep
proper alignment of allocated buffer.

Signed-off-by: Marek Szyprowski 
Reviewed-by: Javier Martinez Canillas 
---
 drivers/media/platform/s5p-mfc/regs-mfc-v6.h | 2 +-
 drivers/media/platform/s5p-mfc/regs-mfc-v7.h | 2 +-
 drivers/media/platform/s5p-mfc/regs-mfc-v8.h | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v6.h 
b/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
index d2cd35916dc5..c0166ee9a455 100644
--- a/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
+++ b/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
@@ -403,7 +403,7 @@
 #define MFC_OTHER_ENC_CTX_BUF_SIZE_V6  (12 * SZ_1K)/*  12KB */
 
 /* MFCv6 variant defines */
-#define MAX_FW_SIZE_V6 (SZ_1M) /* 1MB */
+#define MAX_FW_SIZE_V6 (SZ_512K)   /* 512KB */
 #define MAX_CPB_SIZE_V6(3 * SZ_1M) /* 3MB */
 #define MFC_VERSION_V6 0x61
 #define MFC_NUM_PORTS_V6   1
diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v7.h 
b/drivers/media/platform/s5p-mfc/regs-mfc-v7.h
index 1a5c6fdf7846..9f220769d970 100644
--- a/drivers/media/platform/s5p-mfc/regs-mfc-v7.h
+++ b/drivers/media/platform/s5p-mfc/regs-mfc-v7.h
@@ -34,7 +34,7 @@
 #define S5P_FIMV_E_VP8_NUM_T_LAYER_V7  0xfdc4
 
 /* MFCv7 variant defines */
-#define MAX_FW_SIZE_V7 (SZ_1M) /* 1MB */
+#define MAX_FW_SIZE_V7 (SZ_512K)   /* 512KB */
 #define MAX_CPB_SIZE_V7(3 * SZ_1M) /* 3MB */
 #define MFC_VERSION_V7 0x72
 #define MFC_NUM_PORTS_V7   1
diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v8.h 
b/drivers/media/platform/s5p-mfc/regs-mfc-v8.h
index 4d1c3750eb5e..75f5f7511d72 100644
--- a/drivers/media/platform/s5p-mfc/regs-mfc-v8.h
+++ b/drivers/media/platform/s5p-mfc/regs-mfc-v8.h
@@ -116,7 +116,7 @@
 #define S5P_FIMV_D_ALIGN_PLANE_SIZE_V8 64
 
 /* MFCv8 variant defines */
-#define MAX_FW_SIZE_V8 (SZ_1M) /* 1MB */
+#define MAX_FW_SIZE_V8 (SZ_512K)   /* 512KB */
 #define MAX_CPB_SIZE_V8(3 * SZ_1M) /* 3MB */
 #define MFC_VERSION_V8 0x80
 #define MFC_NUM_PORTS_V8   1
-- 
1.9.1

[PATCH v2 07/15] media: s5p-mfc: Put firmware to private buffer structure

[Marek Szyprowski]

Use s5p_mfc_priv_buf structure for keeping the firmware image. This will
help handling of firmware buffer allocation in the next patches.

Signed-off-by: Marek Szyprowski 
Reviewed-by: Javier Martinez Canillas 
Tested-by: Javier Martinez Canillas 
---
 drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v5.c |  2 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h |  3 +--
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c   | 36 -
 3 files changed, 20 insertions(+), 21 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v5.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v5.c
index 8c4739ca16d6..4c80bb4243be 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v5.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v5.c
@@ -47,7 +47,7 @@ static int s5p_mfc_sys_init_cmd_v5(struct s5p_mfc_dev *dev)
struct s5p_mfc_cmd_args h2r_args;
 
memset(_args, 0, sizeof(struct s5p_mfc_cmd_args));
-   h2r_args.arg[0] = dev->fw_size;
+   h2r_args.arg[0] = dev->fw_buf.size;
return s5p_mfc_cmd_host2risc_v5(dev, S5P_FIMV_H2R_CMD_SYS_INIT,
_args);
 }
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h 
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index 9cf860f34c71..cea17a737ef7 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -314,8 +314,7 @@ struct s5p_mfc_dev {
int int_type;
unsigned int int_err;
wait_queue_head_t queue;
-   size_t fw_size;
-   void *fw_virt_addr;
+   struct s5p_mfc_priv_buf fw_buf;
dma_addr_t dma_base[BANK_CTX_NUM];
unsigned long hw_lock;
struct s5p_mfc_ctx *ctx[MFC_NUM_CONTEXTS];
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
index c9bff3d0655f..50d698968049 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
@@ -29,21 +29,22 @@ int s5p_mfc_alloc_firmware(struct s5p_mfc_dev *dev)
void *bank2_virt;
dma_addr_t bank2_dma_addr;
unsigned int align_size = 1 << MFC_BASE_ALIGN_ORDER;
+   struct s5p_mfc_priv_buf *fw_buf = >fw_buf;
 
-   dev->fw_size = dev->variant->buf_size->fw;
+   fw_buf->size = dev->variant->buf_size->fw;
 
-   if (dev->fw_virt_addr) {
+   if (fw_buf->virt) {
mfc_err("Attempting to allocate firmware when it seems that it 
is already loaded\n");
return -ENOMEM;
}
 
-   dev->fw_virt_addr = dma_alloc_coherent(dev->mem_dev[BANK1_CTX],
-   dev->fw_size, >dma_base[BANK1_CTX],
-   GFP_KERNEL);
-   if (!dev->fw_virt_addr) {
+   fw_buf->virt = dma_alloc_coherent(dev->mem_dev[BANK1_CTX], fw_buf->size,
+_buf->dma, GFP_KERNEL);
+   if (!fw_buf->virt) {
mfc_err("Allocating bitprocessor buffer failed\n");
return -ENOMEM;
}
+   dev->dma_base[BANK1_CTX] = fw_buf->dma;
 
if (HAS_PORTNUM(dev) && IS_TWOPORT(dev)) {
bank2_virt = dma_alloc_coherent(dev->mem_dev[BANK2_CTX],
@@ -51,10 +52,9 @@ int s5p_mfc_alloc_firmware(struct s5p_mfc_dev *dev)
 
if (!bank2_virt) {
mfc_err("Allocating bank2 base failed\n");
-   dma_free_coherent(dev->mem_dev[BANK1_CTX], dev->fw_size,
- dev->fw_virt_addr,
- dev->dma_base[BANK1_CTX]);
-   dev->fw_virt_addr = NULL;
+   dma_free_coherent(dev->mem_dev[BANK1_CTX], fw_buf->size,
+ fw_buf->virt, fw_buf->dma);
+   fw_buf->virt = NULL;
return -ENOMEM;
}
 
@@ -101,17 +101,17 @@ int s5p_mfc_load_firmware(struct s5p_mfc_dev *dev)
mfc_err("Firmware is not present in the /lib/firmware directory 
nor compiled in kernel\n");
return -EINVAL;
}
-   if (fw_blob->size > dev->fw_size) {
+   if (fw_blob->size > dev->fw_buf.size) {
mfc_err("MFC firmware is too big to be loaded\n");
release_firmware(fw_blob);
return -ENOMEM;
}
-   if (!dev->fw_virt_addr) {
+   if (!dev->fw_buf.virt) {
mfc_err("MFC firmware is not allocated\n");
release_firmware(fw_blob);
return -EINVAL;
}
-   memcpy(dev->fw_virt_addr, fw_blob->data, fw_blob->size);
+   memcpy(dev->fw_buf.virt, fw_blob->data, fw_blob->size);
wmb();
release_firmware(fw_blob);
mfc_debug_leave();
@@ -123,11 +123,11 @@ int s5p_mfc_release_firmware(struct s5p_mfc_dev *dev)
 {
/* Before calling 

[PATCH v2 13/15] media: s5p-mfc: Remove special configuration of IOMMU domain

[Marek Szyprowski]

The main reason for using special configuration of IOMMU domain was the
problem with MFC firmware, which failed to operate properly when placed
at 0 DMA address. Instead of adding custom code for configuring each
variant of IOMMU domain and architecture specific glue code, simply use
what arch code provides and if the DMA base address equals zero, skip
first 128 KiB to keep required alignment. This patch also make the driver
operational on ARM64 architecture, because it no longer depends on ARM
specific DMA-mapping and IOMMU glue code functions.

Signed-off-by: Marek Szyprowski 
Reviewed-by: Javier Martinez Canillas 
Tested-by: Javier Martinez Canillas 
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c   | 30 +++
 drivers/media/platform/s5p-mfc/s5p_mfc_iommu.h | 51 +-
 2 files changed, 14 insertions(+), 67 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 1c5ec8257f4f..b70cbd637851 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1184,18 +1184,6 @@ static int s5p_mfc_configure_common_memory(struct 
s5p_mfc_dev *mfc_dev)
struct device *dev = _dev->plat_dev->dev;
unsigned long mem_size = SZ_8M;
unsigned int bitmap_size;
-   /*
-* When IOMMU is available, we cannot use the default configuration,
-* because of MFC firmware requirements: address space limited to
-* 256M and non-zero default start address.
-* This is still simplified, not optimal configuration, but for now
-* IOMMU core doesn't allow to configure device's IOMMUs channel
-* separately.
-*/
-   int ret = exynos_configure_iommu(dev, S5P_MFC_IOMMU_DMA_BASE,
-S5P_MFC_IOMMU_DMA_SIZE);
-   if (ret)
-   return ret;
 
if (mfc_mem_size)
mem_size = memparse(mfc_mem_size, NULL);
@@ -1203,10 +1191,8 @@ static int s5p_mfc_configure_common_memory(struct 
s5p_mfc_dev *mfc_dev)
bitmap_size = BITS_TO_LONGS(mem_size >> PAGE_SHIFT) * sizeof(long);
 
mfc_dev->mem_bitmap = kzalloc(bitmap_size, GFP_KERNEL);
-   if (!mfc_dev->mem_bitmap) {
-   exynos_unconfigure_iommu(dev);
+   if (!mfc_dev->mem_bitmap)
return -ENOMEM;
-   }
 
mfc_dev->mem_virt = dma_alloc_coherent(dev, mem_size,
   _dev->mem_base, GFP_KERNEL);
@@ -1214,13 +1200,24 @@ static int s5p_mfc_configure_common_memory(struct 
s5p_mfc_dev *mfc_dev)
kfree(mfc_dev->mem_bitmap);
dev_err(dev, "failed to preallocate %ld MiB for the firmware 
and context buffers\n",
(mem_size / SZ_1M));
-   exynos_unconfigure_iommu(dev);
return -ENOMEM;
}
mfc_dev->mem_size = mem_size;
mfc_dev->dma_base[BANK1_CTX] = mfc_dev->mem_base;
mfc_dev->dma_base[BANK2_CTX] = mfc_dev->mem_base;
 
+   /*
+* MFC hardware cannot handle 0 as a base address, so mark first 128K
+* as used (to keep required base alignment) and adjust base address
+*/
+   if (mfc_dev->mem_base == (dma_addr_t)0) {
+   unsigned int offset = 1 << MFC_BASE_ALIGN_ORDER;
+
+   bitmap_set(mfc_dev->mem_bitmap, 0, offset >> PAGE_SHIFT);
+   mfc_dev->dma_base[BANK1_CTX] += offset;
+   mfc_dev->dma_base[BANK2_CTX] += offset;
+   }
+
/* Firmware allocation cannot fail in this case */
s5p_mfc_alloc_firmware(mfc_dev);
 
@@ -1237,7 +1234,6 @@ static void s5p_mfc_unconfigure_common_memory(struct 
s5p_mfc_dev *mfc_dev)
 {
struct device *dev = _dev->plat_dev->dev;
 
-   exynos_unconfigure_iommu(dev);
dma_free_coherent(dev, mfc_dev->mem_size, mfc_dev->mem_virt,
  mfc_dev->mem_base);
kfree(mfc_dev->mem_bitmap);
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_iommu.h 
b/drivers/media/platform/s5p-mfc/s5p_mfc_iommu.h
index 6962132ae8fa..76667924ee2a 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_iommu.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_iommu.h
@@ -11,54 +11,13 @@
 #ifndef S5P_MFC_IOMMU_H_
 #define S5P_MFC_IOMMU_H_
 
-#define S5P_MFC_IOMMU_DMA_BASE 0x2000lu
-#define S5P_MFC_IOMMU_DMA_SIZE SZ_256M
-
-#if defined(CONFIG_EXYNOS_IOMMU) && defined(CONFIG_ARM_DMA_USE_IOMMU)
-
-#include 
+#if defined(CONFIG_EXYNOS_IOMMU)
 
 static inline bool exynos_is_iommu_available(struct device *dev)
 {
return dev->archdata.iommu != NULL;
 }
 
-static inline void exynos_unconfigure_iommu(struct device *dev)
-{
-   struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
-
-   arm_iommu_detach_device(dev);
-   arm_iommu_release_mapping(mapping);
-}
-
-static inline int exynos_configure_iommu(struct 

[PATCH v2 11/15] media: s5p-mfc: Split variant DMA memory configuration into separate functions

[Marek Szyprowski]

Move code for DMA memory configuration with IOMMU into separate function
to make it easier to compare what is being done in each case.

Signed-off-by: Marek Szyprowski 
Reviewed-by: Javier Martinez Canillas 
Tested-by: Javier Martinez Canillas 
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c | 102 ++-
 1 file changed, 61 insertions(+), 41 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 4403487a494a..04067bcc3feb 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1107,44 +1107,15 @@ static struct device *s5p_mfc_alloc_memdev(struct 
device *dev,
return NULL;
 }
 
-static int s5p_mfc_configure_dma_memory(struct s5p_mfc_dev *mfc_dev)
+static int s5p_mfc_configure_2port_memory(struct s5p_mfc_dev *mfc_dev)
 {
struct device *dev = _dev->plat_dev->dev;
void *bank2_virt;
dma_addr_t bank2_dma_addr;
unsigned long align_size = 1 << MFC_BASE_ALIGN_ORDER;
-   struct s5p_mfc_priv_buf *fw_buf = _dev->fw_buf;
int ret;
 
/*
-* When IOMMU is available, we cannot use the default configuration,
-* because of MFC firmware requirements: address space limited to
-* 256M and non-zero default start address.
-* This is still simplified, not optimal configuration, but for now
-* IOMMU core doesn't allow to configure device's IOMMUs channel
-* separately.
-*/
-   if (exynos_is_iommu_available(dev)) {
-   int ret = exynos_configure_iommu(dev, S5P_MFC_IOMMU_DMA_BASE,
-S5P_MFC_IOMMU_DMA_SIZE);
-   if (ret)
-   return ret;
-
-   mfc_dev->mem_dev[BANK1_CTX] = mfc_dev->mem_dev[BANK2_CTX] = dev;
-   ret = s5p_mfc_alloc_firmware(mfc_dev);
-   if (ret) {
-   exynos_unconfigure_iommu(dev);
-   return ret;
-   }
-
-   mfc_dev->dma_base[BANK1_CTX] = fw_buf->dma;
-   mfc_dev->dma_base[BANK2_CTX] = fw_buf->dma;
-   vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
-
-   return 0;
-   }
-
-   /*
 * Create and initialize virtual devices for accessing
 * reserved memory regions.
 */
@@ -1167,7 +1138,7 @@ static int s5p_mfc_configure_dma_memory(struct 
s5p_mfc_dev *mfc_dev)
return ret;
}
 
-   mfc_dev->dma_base[BANK1_CTX] = fw_buf->dma;
+   mfc_dev->dma_base[BANK1_CTX] = mfc_dev->fw_buf.dma;
 
bank2_virt = dma_alloc_coherent(mfc_dev->mem_dev[BANK2_CTX], align_size,
_dma_addr, GFP_KERNEL);
@@ -1196,22 +1167,71 @@ static int s5p_mfc_configure_dma_memory(struct 
s5p_mfc_dev *mfc_dev)
return 0;
 }
 
-static void s5p_mfc_unconfigure_dma_memory(struct s5p_mfc_dev *mfc_dev)
+static void s5p_mfc_unconfigure_2port_memory(struct s5p_mfc_dev *mfc_dev)
 {
-   struct device *dev = _dev->plat_dev->dev;
+   device_unregister(mfc_dev->mem_dev[BANK1_CTX]);
+   device_unregister(mfc_dev->mem_dev[BANK2_CTX]);
+   vb2_dma_contig_clear_max_seg_size(mfc_dev->mem_dev[BANK1_CTX]);
+   vb2_dma_contig_clear_max_seg_size(mfc_dev->mem_dev[BANK2_CTX]);
+}
 
-   s5p_mfc_release_firmware(mfc_dev);
+static int s5p_mfc_configure_common_memory(struct s5p_mfc_dev *mfc_dev)
+{
+   struct device *dev = _dev->plat_dev->dev;
+   /*
+* When IOMMU is available, we cannot use the default configuration,
+* because of MFC firmware requirements: address space limited to
+* 256M and non-zero default start address.
+* This is still simplified, not optimal configuration, but for now
+* IOMMU core doesn't allow to configure device's IOMMUs channel
+* separately.
+*/
+   int ret = exynos_configure_iommu(dev, S5P_MFC_IOMMU_DMA_BASE,
+S5P_MFC_IOMMU_DMA_SIZE);
+   if (ret)
+   return ret;
 
-   if (exynos_is_iommu_available(dev)) {
+   mfc_dev->mem_dev[BANK1_CTX] = mfc_dev->mem_dev[BANK2_CTX] = dev;
+   ret = s5p_mfc_alloc_firmware(mfc_dev);
+   if (ret) {
exynos_unconfigure_iommu(dev);
-   vb2_dma_contig_clear_max_seg_size(dev);
-   return;
+   return ret;
}
 
-   device_unregister(mfc_dev->mem_dev[BANK1_CTX]);
-   device_unregister(mfc_dev->mem_dev[BANK2_CTX]);
-   vb2_dma_contig_clear_max_seg_size(mfc_dev->mem_dev[BANK1_CTX]);
-   vb2_dma_contig_clear_max_seg_size(mfc_dev->mem_dev[BANK2_CTX]);
+   mfc_dev->dma_base[BANK1_CTX] = mfc_dev->fw_buf.dma;
+   mfc_dev->dma_base[BANK2_CTX] = mfc_dev->fw_buf.dma;
+   vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
+
+   

[PATCH v2 08/15] media: s5p-mfc: Move firmware allocation to DMA configure function

[Marek Szyprowski]

To complete DMA memory configuration for MFC device, allocation of the
firmware buffer is needed, because some parameters are dependant on its base
address. Till now, this has been handled in the s5p_mfc_alloc_firmware()
function. This patch moves that logic to s5p_mfc_configure_dma_memory() to
keep DMA memory related operations in a single place. This way
s5p_mfc_alloc_firmware() is simplified and does what it name says. The
other consequence of this change is moving s5p_mfc_alloc_firmware() call
from the s5p_mfc_probe() function to the s5p_mfc_configure_dma_memory().

Signed-off-by: Marek Szyprowski 
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c  | 62 +--
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c | 31 --
 2 files changed, 49 insertions(+), 44 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index bc1aeb25ebeb..4403487a494a 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1110,6 +1110,11 @@ static struct device *s5p_mfc_alloc_memdev(struct device 
*dev,
 static int s5p_mfc_configure_dma_memory(struct s5p_mfc_dev *mfc_dev)
 {
struct device *dev = _dev->plat_dev->dev;
+   void *bank2_virt;
+   dma_addr_t bank2_dma_addr;
+   unsigned long align_size = 1 << MFC_BASE_ALIGN_ORDER;
+   struct s5p_mfc_priv_buf *fw_buf = _dev->fw_buf;
+   int ret;
 
/*
 * When IOMMU is available, we cannot use the default configuration,
@@ -1122,14 +1127,21 @@ static int s5p_mfc_configure_dma_memory(struct 
s5p_mfc_dev *mfc_dev)
if (exynos_is_iommu_available(dev)) {
int ret = exynos_configure_iommu(dev, S5P_MFC_IOMMU_DMA_BASE,
 S5P_MFC_IOMMU_DMA_SIZE);
-   if (ret == 0) {
-   mfc_dev->mem_dev[BANK1_CTX] =
-   mfc_dev->mem_dev[BANK2_CTX] = dev;
-   vb2_dma_contig_set_max_seg_size(dev,
-   DMA_BIT_MASK(32));
+   if (ret)
+   return ret;
+
+   mfc_dev->mem_dev[BANK1_CTX] = mfc_dev->mem_dev[BANK2_CTX] = dev;
+   ret = s5p_mfc_alloc_firmware(mfc_dev);
+   if (ret) {
+   exynos_unconfigure_iommu(dev);
+   return ret;
}
 
-   return ret;
+   mfc_dev->dma_base[BANK1_CTX] = fw_buf->dma;
+   mfc_dev->dma_base[BANK2_CTX] = fw_buf->dma;
+   vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
+
+   return 0;
}
 
/*
@@ -1147,6 +1159,35 @@ static int s5p_mfc_configure_dma_memory(struct 
s5p_mfc_dev *mfc_dev)
return -ENODEV;
}
 
+   /* Allocate memory for firmware and initialize both banks addresses */
+   ret = s5p_mfc_alloc_firmware(mfc_dev);
+   if (ret) {
+   device_unregister(mfc_dev->mem_dev[BANK2_CTX]);
+   device_unregister(mfc_dev->mem_dev[BANK1_CTX]);
+   return ret;
+   }
+
+   mfc_dev->dma_base[BANK1_CTX] = fw_buf->dma;
+
+   bank2_virt = dma_alloc_coherent(mfc_dev->mem_dev[BANK2_CTX], align_size,
+   _dma_addr, GFP_KERNEL);
+   if (!bank2_virt) {
+   mfc_err("Allocating bank2 base failed\n");
+   s5p_mfc_release_firmware(mfc_dev);
+   device_unregister(mfc_dev->mem_dev[BANK2_CTX]);
+   device_unregister(mfc_dev->mem_dev[BANK1_CTX]);
+   return -ENOMEM;
+   }
+
+   /* Valid buffers passed to MFC encoder with LAST_FRAME command
+* should not have address of bank2 - MFC will treat it as a null frame.
+* To avoid such situation we set bank2 address below the pool address.
+*/
+   mfc_dev->dma_base[BANK2_CTX] = bank2_dma_addr - align_size;
+
+   dma_free_coherent(mfc_dev->mem_dev[BANK2_CTX], align_size, bank2_virt,
+ bank2_dma_addr);
+
vb2_dma_contig_set_max_seg_size(mfc_dev->mem_dev[BANK1_CTX],
DMA_BIT_MASK(32));
vb2_dma_contig_set_max_seg_size(mfc_dev->mem_dev[BANK2_CTX],
@@ -1159,6 +1200,8 @@ static void s5p_mfc_unconfigure_dma_memory(struct 
s5p_mfc_dev *mfc_dev)
 {
struct device *dev = _dev->plat_dev->dev;
 
+   s5p_mfc_release_firmware(mfc_dev);
+
if (exynos_is_iommu_available(dev)) {
exynos_unconfigure_iommu(dev);
vb2_dma_contig_clear_max_seg_size(dev);
@@ -1235,10 +1278,6 @@ static int s5p_mfc_probe(struct platform_device *pdev)
dev->watchdog_timer.data = (unsigned long)dev;
dev->watchdog_timer.function = s5p_mfc_watchdog;
 
-   ret = s5p_mfc_alloc_firmware(dev);
-   if (ret)
-   goto err_res;
-
ret = 

[PATCH v2 14/15] media: s5p-mfc: Use preallocated block allocator always for MFC v6+

[Marek Szyprowski]

It turned out that all versions of MFC v6+ hardware doesn't have a strict
requirement for ALL buffers to be allocated on higher addresses than the
firmware base like it was documented for MFC v5. This requirement is true
only for the device and per-context buffers. All video data buffers can be
allocated anywhere for all MFC v6+ versions. Basing on this fact, the
special DMA configuration based on two reserved memory regions is not
really needed for MFC v6+ devices, because the memory requirements for the
firmware, device and per-context buffers can be fulfilled by the simple
probe-time pre-allocated block allocator instroduced in previous patch.

This patch enables support for such pre-allocated block based allocator
always for MFC v6+ devices. Due to the limitations of the memory management
subsystem the largest supported size of the pre-allocated buffer when no
CMA (Contiguous Memory Allocator) is enabled is 4MiB.

This patch also removes the requirement to provide two reserved memory
regions for MFC v6+ devices in device tree. Now the driver is fully
functional without them.

Signed-off-by: Marek Szyprowski 
Reviewed-by: Javier Martinez Canillas 
Tested-by: Javier Martinez Canillas 
---
 Documentation/devicetree/bindings/media/s5p-mfc.txt | 2 +-
 drivers/media/platform/s5p-mfc/s5p_mfc.c| 9 ++---
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt 
b/Documentation/devicetree/bindings/media/s5p-mfc.txt
index 2c901286d818..d3404b5d4d17 100644
--- a/Documentation/devicetree/bindings/media/s5p-mfc.txt
+++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt
@@ -28,7 +28,7 @@ Optional properties:
   - memory-region : from reserved memory binding: phandles to two reserved
memory regions, first is for "left" mfc memory bus interfaces,
second if for the "right" mfc memory bus, used when no SYSMMU
-   support is available
+   support is available; used only by MFC v5 present in Exynos4 SoCs
 
 Obsolete properties:
   - samsung,mfc-r, samsung,mfc-l : support removed, please use memory-region
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index b70cbd637851..b4a13e4cc9d4 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1182,9 +1182,12 @@ static void s5p_mfc_unconfigure_2port_memory(struct 
s5p_mfc_dev *mfc_dev)
 static int s5p_mfc_configure_common_memory(struct s5p_mfc_dev *mfc_dev)
 {
struct device *dev = _dev->plat_dev->dev;
-   unsigned long mem_size = SZ_8M;
+   unsigned long mem_size = SZ_4M;
unsigned int bitmap_size;
 
+   if (IS_ENABLED(CONFIG_DMA_CMA) || exynos_is_iommu_available(dev))
+   mem_size = SZ_8M;
+
if (mfc_mem_size)
mem_size = memparse(mfc_mem_size, NULL);
 
@@ -1244,7 +1247,7 @@ static int s5p_mfc_configure_dma_memory(struct 
s5p_mfc_dev *mfc_dev)
 {
struct device *dev = _dev->plat_dev->dev;
 
-   if (exynos_is_iommu_available(dev))
+   if (exynos_is_iommu_available(dev) || !IS_TWOPORT(mfc_dev))
return s5p_mfc_configure_common_memory(mfc_dev);
else
return s5p_mfc_configure_2port_memory(mfc_dev);
@@ -1255,7 +1258,7 @@ static void s5p_mfc_unconfigure_dma_memory(struct 
s5p_mfc_dev *mfc_dev)
struct device *dev = _dev->plat_dev->dev;
 
s5p_mfc_release_firmware(mfc_dev);
-   if (exynos_is_iommu_available(dev))
+   if (exynos_is_iommu_available(dev) || !IS_TWOPORT(mfc_dev))
s5p_mfc_unconfigure_common_memory(mfc_dev);
else
s5p_mfc_unconfigure_2port_memory(mfc_dev);
-- 
1.9.1

[PATCH v2 12/15] media: s5p-mfc: Add support for probe-time preallocated block based allocator

[Marek Szyprowski]

Current MFC driver depends on the fact that when IOMMU is available, the
DMA-mapping framework and its IOMMU glue will use first-fit allocator.
This was true for ARM architecture, but its not for ARM64 arch. However, in
case of MFC v6+ hardware and latest firmware, it turned out that there is
no strict requirement for ALL buffers to be allocated on higher addresses
than the firmware base. This requirement is true only for the device and
per-context buffers. All video data buffers can be allocated anywhere for
all MFC v6+ versions.

Such relaxed requirements for the memory buffers can be easily fulfilled
by allocating firmware, device and per-context buffers from the probe-time
preallocated larger buffer. This patch adds support for it. This way the
driver finally works fine on ARM64 architecture. The size of the
preallocated buffer is 8 MiB, what is enough for three instances H264
decoders or encoders (other codecs have smaller memory requirements).
If one needs more for particular use case, one can use "mem" module
parameter to force larger (or smaller) buffer (for example by adding
"s5p_mfc.mem=16M" to kernel command line).

Signed-off-by: Marek Szyprowski 
Reviewed-by: Javier Martinez Canillas 
Tested-by: Javier Martinez Canillas 
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c| 43 ---
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h |  4 ++
 drivers/media/platform/s5p-mfc/s5p_mfc_opr.c| 57 -
 3 files changed, 79 insertions(+), 25 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 04067bcc3feb..1c5ec8257f4f 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -43,6 +43,10 @@
 module_param_named(debug, mfc_debug_level, int, S_IRUGO | S_IWUSR);
 MODULE_PARM_DESC(debug, "Debug level - higher value produces more verbose 
messages");
 
+static char *mfc_mem_size = NULL;
+module_param_named(mem, mfc_mem_size, charp, S_IRUGO | S_IWUSR);
+MODULE_PARM_DESC(mem, "Preallocated memory size for the firmware and context 
buffers");
+
 /* Helper functions for interrupt processing */
 
 /* Remove from hw execution round robin */
@@ -1178,6 +1182,8 @@ static void s5p_mfc_unconfigure_2port_memory(struct 
s5p_mfc_dev *mfc_dev)
 static int s5p_mfc_configure_common_memory(struct s5p_mfc_dev *mfc_dev)
 {
struct device *dev = _dev->plat_dev->dev;
+   unsigned long mem_size = SZ_8M;
+   unsigned int bitmap_size;
/*
 * When IOMMU is available, we cannot use the default configuration,
 * because of MFC firmware requirements: address space limited to
@@ -1191,17 +1197,39 @@ static int s5p_mfc_configure_common_memory(struct 
s5p_mfc_dev *mfc_dev)
if (ret)
return ret;
 
-   mfc_dev->mem_dev[BANK1_CTX] = mfc_dev->mem_dev[BANK2_CTX] = dev;
-   ret = s5p_mfc_alloc_firmware(mfc_dev);
-   if (ret) {
+   if (mfc_mem_size)
+   mem_size = memparse(mfc_mem_size, NULL);
+
+   bitmap_size = BITS_TO_LONGS(mem_size >> PAGE_SHIFT) * sizeof(long);
+
+   mfc_dev->mem_bitmap = kzalloc(bitmap_size, GFP_KERNEL);
+   if (!mfc_dev->mem_bitmap) {
exynos_unconfigure_iommu(dev);
-   return ret;
+   return -ENOMEM;
}
 
-   mfc_dev->dma_base[BANK1_CTX] = mfc_dev->fw_buf.dma;
-   mfc_dev->dma_base[BANK2_CTX] = mfc_dev->fw_buf.dma;
+   mfc_dev->mem_virt = dma_alloc_coherent(dev, mem_size,
+  _dev->mem_base, GFP_KERNEL);
+   if (!mfc_dev->mem_virt) {
+   kfree(mfc_dev->mem_bitmap);
+   dev_err(dev, "failed to preallocate %ld MiB for the firmware 
and context buffers\n",
+   (mem_size / SZ_1M));
+   exynos_unconfigure_iommu(dev);
+   return -ENOMEM;
+   }
+   mfc_dev->mem_size = mem_size;
+   mfc_dev->dma_base[BANK1_CTX] = mfc_dev->mem_base;
+   mfc_dev->dma_base[BANK2_CTX] = mfc_dev->mem_base;
+
+   /* Firmware allocation cannot fail in this case */
+   s5p_mfc_alloc_firmware(mfc_dev);
+
+   mfc_dev->mem_dev[BANK1_CTX] = mfc_dev->mem_dev[BANK2_CTX] = dev;
vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32));
 
+   dev_info(dev, "preallocated %ld MiB buffer for the firmware and context 
buffers\n",
+(mem_size / SZ_1M));
+
return 0;
 }
 
@@ -1210,6 +1238,9 @@ static void s5p_mfc_unconfigure_common_memory(struct 
s5p_mfc_dev *mfc_dev)
struct device *dev = _dev->plat_dev->dev;
 
exynos_unconfigure_iommu(dev);
+   dma_free_coherent(dev, mfc_dev->mem_size, mfc_dev->mem_virt,
+ mfc_dev->mem_base);
+   kfree(mfc_dev->mem_bitmap);
vb2_dma_contig_clear_max_seg_size(dev);
 }
 
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h 

[PATCH v2 15/15] ARM: dts: exynos: Remove MFC reserved buffers

[Marek Szyprowski]

During my research I found that some of the requirements for the memory
buffers for MFC v6+ devices were blindly copied from the previous (v5)
version and simply turned out to be excessive. The relaxed requirements
are applied by the recent patches to the MFC driver and the driver is
now fully functional even without the reserved memory blocks for all
v6+ variants. This patch removes those reserved memory nodes from all
boards having MFC v6+ hardware block.

Signed-off-by: Marek Szyprowski 
Reviewed-by: Javier Martinez Canillas 
Tested-by: Javier Martinez Canillas 
---
 arch/arm/boot/dts/exynos5250-arndale.dts   | 1 -
 arch/arm/boot/dts/exynos5250-smdk5250.dts  | 1 -
 arch/arm/boot/dts/exynos5250-spring.dts| 1 -
 arch/arm/boot/dts/exynos5420-arndale-octa.dts  | 1 -
 arch/arm/boot/dts/exynos5420-peach-pit.dts | 1 -
 arch/arm/boot/dts/exynos5420-smdk5420.dts  | 1 -
 arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 1 -
 arch/arm/boot/dts/exynos5800-peach-pi.dts  | 1 -
 8 files changed, 8 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts 
b/arch/arm/boot/dts/exynos5250-arndale.dts
index 6098dacd09f1..6a432460eb77 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -14,7 +14,6 @@
 #include 
 #include 
 #include "exynos5250.dtsi"
-#include "exynos-mfc-reserved-memory.dtsi"
 
 / {
model = "Insignal Arndale evaluation board based on EXYNOS5250";
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index a97a785ccc6b..6632f657394e 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -13,7 +13,6 @@
 #include 
 #include 
 #include "exynos5250.dtsi"
-#include "exynos-mfc-reserved-memory.dtsi"
 
 / {
model = "SAMSUNG SMDK5250 board based on EXYNOS5250";
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts 
b/arch/arm/boot/dts/exynos5250-spring.dts
index 4d7bdb735ed3..95c3bcace9dc 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -14,7 +14,6 @@
 #include 
 #include 
 #include "exynos5250.dtsi"
-#include "exynos-mfc-reserved-memory.dtsi"
 
 / {
model = "Google Spring";
diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts 
b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
index 9cc83c51c925..ee1bb9b8b366 100644
--- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
+++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
@@ -16,7 +16,6 @@
 #include 
 #include 
 #include 
-#include "exynos-mfc-reserved-memory.dtsi"
 
 / {
model = "Insignal Arndale Octa evaluation board based on EXYNOS5420";
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 1f964ec35c5e..2cd65699a29c 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -16,7 +16,6 @@
 #include 
 #include "exynos5420.dtsi"
 #include "exynos5420-cpus.dtsi"
-#include "exynos-mfc-reserved-memory.dtsi"
 
 / {
model = "Google Peach Pit Rev 6+";
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts 
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index aaccd0da41e5..08c8ab173e87 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -13,7 +13,6 @@
 #include "exynos5420.dtsi"
 #include "exynos5420-cpus.dtsi"
 #include 
-#include "exynos-mfc-reserved-memory.dtsi"
 
 / {
model = "Samsung SMDK5420 board based on EXYNOS5420";
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 
b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index 05b9afdd6757..657535e2e3cc 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -18,7 +18,6 @@
 #include 
 #include "exynos5800.dtsi"
 #include "exynos5422-cpus.dtsi"
-#include "exynos-mfc-reserved-memory.dtsi"
 
 / {
memory@4000 {
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index f9ff7f07ae0c..ecf1c916e8fc 100644
--- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
+++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
@@ -16,7 +16,6 @@
 #include 
 #include "exynos5800.dtsi"
 #include "exynos5420-cpus.dtsi"
-#include "exynos-mfc-reserved-memory.dtsi"
 
 / {
model = "Google Peach Pi Rev 10+";
-- 
1.9.1

[PATCH v2 04/15] media: s5p-mfc: Replace bank1/bank2 entries with an array

[Marek Szyprowski]

Internal MFC driver device structure contains two entries for keeping
addresses of the DMA memory banks. Replace them with the dma_base[] array
and use defines for accessing particular banks. This will help to simplify
code in the next patches.

Signed-off-by: Marek Szyprowski 
Reviewed-by: Javier Martinez Canillas 
Tested-by: Javier Martinez Canillas 
---
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h |  6 ++--
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c   | 27 +++---
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c | 38 +
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 10 +++
 4 files changed, 43 insertions(+), 38 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h 
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index 27d4c864e06e..da601a2dba2f 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -273,8 +273,7 @@ struct s5p_mfc_priv_buf {
  * @queue: waitqueue for waiting for completion of device commands
  * @fw_size:   size of firmware
  * @fw_virt_addr:  virtual firmware address
- * @bank1: address of the beginning of bank 1 memory
- * @bank2: address of the beginning of bank 2 memory
+ * @dma_base[]:address of the beginning of memory banks
  * @hw_lock:   used for hardware locking
  * @ctx:   array of driver contexts
  * @curr_ctx:  number of the currently running context
@@ -315,8 +314,7 @@ struct s5p_mfc_dev {
wait_queue_head_t queue;
size_t fw_size;
void *fw_virt_addr;
-   dma_addr_t bank1;
-   dma_addr_t bank2;
+   dma_addr_t dma_base[BANK_CTX_NUM];
unsigned long hw_lock;
struct s5p_mfc_ctx *ctx[MFC_NUM_CONTEXTS];
int curr_ctx;
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
index cd1406c75d9a..c9bff3d0655f 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
@@ -38,8 +38,8 @@ int s5p_mfc_alloc_firmware(struct s5p_mfc_dev *dev)
}
 
dev->fw_virt_addr = dma_alloc_coherent(dev->mem_dev[BANK1_CTX],
-   dev->fw_size, >bank1, GFP_KERNEL);
-
+   dev->fw_size, >dma_base[BANK1_CTX],
+   GFP_KERNEL);
if (!dev->fw_virt_addr) {
mfc_err("Allocating bitprocessor buffer failed\n");
return -ENOMEM;
@@ -52,7 +52,8 @@ int s5p_mfc_alloc_firmware(struct s5p_mfc_dev *dev)
if (!bank2_virt) {
mfc_err("Allocating bank2 base failed\n");
dma_free_coherent(dev->mem_dev[BANK1_CTX], dev->fw_size,
- dev->fw_virt_addr, dev->bank1);
+ dev->fw_virt_addr,
+ dev->dma_base[BANK1_CTX]);
dev->fw_virt_addr = NULL;
return -ENOMEM;
}
@@ -61,7 +62,7 @@ int s5p_mfc_alloc_firmware(struct s5p_mfc_dev *dev)
 * should not have address of bank2 - MFC will treat it as a 
null frame.
 * To avoid such situation we set bank2 address below the pool 
address.
 */
-   dev->bank2 = bank2_dma_addr - align_size;
+   dev->dma_base[BANK2_CTX] = bank2_dma_addr - align_size;
 
dma_free_coherent(dev->mem_dev[BANK2_CTX], align_size,
  bank2_virt, bank2_dma_addr);
@@ -70,7 +71,7 @@ int s5p_mfc_alloc_firmware(struct s5p_mfc_dev *dev)
/* In this case bank2 can point to the same address as bank1.
 * Firmware will always occupy the beginning of this area so it 
is
 * impossible having a video frame buffer with zero address. */
-   dev->bank2 = dev->bank1;
+   dev->dma_base[BANK2_CTX] = dev->dma_base[BANK1_CTX];
}
return 0;
 }
@@ -125,7 +126,7 @@ int s5p_mfc_release_firmware(struct s5p_mfc_dev *dev)
if (!dev->fw_virt_addr)
return -EINVAL;
dma_free_coherent(dev->mem_dev[BANK1_CTX], dev->fw_size,
- dev->fw_virt_addr, dev->bank1);
+ dev->fw_virt_addr, dev->dma_base[BANK1_CTX]);
dev->fw_virt_addr = NULL;
return 0;
 }
@@ -211,13 +212,17 @@ int s5p_mfc_reset(struct s5p_mfc_dev *dev)
 static inline void s5p_mfc_init_memctrl(struct s5p_mfc_dev *dev)
 {
if (IS_MFCV6_PLUS(dev)) {
-   mfc_write(dev, dev->bank1, S5P_FIMV_RISC_BASE_ADDRESS_V6);
-   mfc_debug(2, "Base Address : %pad\n", >bank1);
+   mfc_write(dev, dev->dma_base[BANK1_CTX],
+   

[PATCH v2 05/15] media: s5p-mfc: Simplify alloc/release private buffer functions

[Marek Szyprowski]

Change parameters for s5p_mfc_alloc_priv_buf() and s5p_mfc_release_priv_buf()
functions. Instead of DMA device pointer and a base, provide common MFC
device structure and memory bank context identifier.

Signed-off-by: Marek Szyprowski 
Reviewed-by: Javier Martinez Canillas 
Tested-by: Javier Martinez Canillas 
---
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h |  2 ++
 drivers/media/platform/s5p-mfc/s5p_mfc_opr.c| 20 +++--
 drivers/media/platform/s5p-mfc/s5p_mfc_opr.h|  8 +++
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c | 30 ++---
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 15 +
 5 files changed, 37 insertions(+), 38 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h 
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index da601a2dba2f..9cf860f34c71 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -240,12 +240,14 @@ struct s5p_mfc_variant {
  * buffer accessed by driver
  * @dma:   DMA address, only valid when kernel DMA API used
  * @size:  size of the buffer
+ * @ctx:   memory context (bank) used for this allocation
  */
 struct s5p_mfc_priv_buf {
unsigned long   ofs;
void*virt;
dma_addr_t  dma;
size_t  size;
+   unsigned intctx;
 };
 
 /**
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr.c
index 99f65a92a6be..9294ee124661 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr.c
@@ -37,12 +37,16 @@ void s5p_mfc_init_regs(struct s5p_mfc_dev *dev)
dev->mfc_regs = s5p_mfc_init_regs_v6_plus(dev);
 }
 
-int s5p_mfc_alloc_priv_buf(struct device *dev, dma_addr_t base,
-   struct s5p_mfc_priv_buf *b)
+int s5p_mfc_alloc_priv_buf(struct s5p_mfc_dev *dev, unsigned int mem_ctx,
+  struct s5p_mfc_priv_buf *b)
 {
+   struct device *mem_dev = dev->mem_dev[mem_ctx];
+   dma_addr_t base = dev->dma_base[mem_ctx];
+
mfc_debug(3, "Allocating priv: %zu\n", b->size);
 
-   b->virt = dma_alloc_coherent(dev, b->size, >dma, GFP_KERNEL);
+   b->ctx = mem_ctx;
+   b->virt = dma_alloc_coherent(mem_dev, b->size, >dma, GFP_KERNEL);
 
if (!b->virt) {
mfc_err("Allocating private buffer of size %zu failed\n",
@@ -53,7 +57,7 @@ int s5p_mfc_alloc_priv_buf(struct device *dev, dma_addr_t 
base,
if (b->dma < base) {
mfc_err("Invalid memory configuration - buffer (%pad) is below 
base memory address(%pad)\n",
>dma, );
-   dma_free_coherent(dev, b->size, b->virt, b->dma);
+   dma_free_coherent(mem_dev, b->size, b->virt, b->dma);
return -ENOMEM;
}
 
@@ -61,11 +65,13 @@ int s5p_mfc_alloc_priv_buf(struct device *dev, dma_addr_t 
base,
return 0;
 }
 
-void s5p_mfc_release_priv_buf(struct device *dev,
-   struct s5p_mfc_priv_buf *b)
+void s5p_mfc_release_priv_buf(struct s5p_mfc_dev *dev,
+ struct s5p_mfc_priv_buf *b)
 {
+   struct device *mem_dev = dev->mem_dev[b->ctx];
+
if (b->virt) {
-   dma_free_coherent(dev, b->size, b->virt, b->dma);
+   dma_free_coherent(mem_dev, b->size, b->virt, b->dma);
b->virt = NULL;
b->dma = 0;
b->size = 0;
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h 
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h
index b6ac417ab63e..108e59382e0c 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h
@@ -315,10 +315,10 @@ struct s5p_mfc_hw_ops {
 
 void s5p_mfc_init_hw_ops(struct s5p_mfc_dev *dev);
 void s5p_mfc_init_regs(struct s5p_mfc_dev *dev);
-int s5p_mfc_alloc_priv_buf(struct device *dev, dma_addr_t base,
-   struct s5p_mfc_priv_buf *b);
-void s5p_mfc_release_priv_buf(struct device *dev,
-   struct s5p_mfc_priv_buf *b);
+int s5p_mfc_alloc_priv_buf(struct s5p_mfc_dev *dev, unsigned int mem_ctx,
+  struct s5p_mfc_priv_buf *b);
+void s5p_mfc_release_priv_buf(struct s5p_mfc_dev *dev,
+ struct s5p_mfc_priv_buf *b);
 
 
 #endif /* S5P_MFC_OPR_H_ */
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c
index 32ce9ade2edb..20e8a1bdc984 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c
@@ -41,8 +41,7 @@ static int s5p_mfc_alloc_dec_temp_buffers_v5(struct 
s5p_mfc_ctx *ctx)
int ret;
 
  

[PATCH v2 09/15] media: s5p-mfc: Allocate firmware with internal private buffer alloc function

[Marek Szyprowski]

Once firmware buffer has been converted to use s5p_mfc_priv_buf structure,
it is possible to allocate it with existing s5p_mfc_alloc_priv_buf()
function. This change will help to reduce code variants in the next
patches.

Signed-off-by: Marek Szyprowski 
Reviewed-by: Javier Martinez Canillas 
---
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c | 14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
index b0cf3970117a..a1811ee538bd 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c
@@ -27,6 +27,7 @@
 int s5p_mfc_alloc_firmware(struct s5p_mfc_dev *dev)
 {
struct s5p_mfc_priv_buf *fw_buf = >fw_buf;
+   int err;
 
fw_buf->size = dev->variant->buf_size->fw;
 
@@ -35,11 +36,10 @@ int s5p_mfc_alloc_firmware(struct s5p_mfc_dev *dev)
return -ENOMEM;
}
 
-   fw_buf->virt = dma_alloc_coherent(dev->mem_dev[BANK1_CTX], fw_buf->size,
-_buf->dma, GFP_KERNEL);
-   if (!fw_buf->virt) {
+   err = s5p_mfc_alloc_priv_buf(dev, BANK1_CTX, >fw_buf);
+   if (err) {
mfc_err("Allocating bitprocessor buffer failed\n");
-   return -ENOMEM;
+   return err;
}
 
return 0;
@@ -92,11 +92,7 @@ int s5p_mfc_release_firmware(struct s5p_mfc_dev *dev)
 {
/* Before calling this function one has to make sure
 * that MFC is no longer processing */
-   if (!dev->fw_buf.virt)
-   return -EINVAL;
-   dma_free_coherent(dev->mem_dev[BANK1_CTX], dev->fw_buf.size,
- dev->fw_buf.virt, dev->fw_buf.dma);
-   dev->fw_buf.virt = NULL;
+   s5p_mfc_release_priv_buf(dev, >fw_buf);
return 0;
 }
 
-- 
1.9.1

[PATCH v2 00/15] Exynos MFC v6+ - remove the need for the reserved memory

[Marek Szyprowski]

Dear All,

This patchset is a result of my work on enabling full support for MFC device
(multimedia codec) on Exynos 5433 on ARM64 architecture. Initially I thought
that to let it working on ARM64 architecture with IOMMU, I would need to
solve the issue related to the fact that s5p-mfc driver was depending on the
first-fit allocation method in the DMA-mapping / IOMMU glue code (ARM64 use
different algorithm). It turned out, that there is a much simpler way.

During my research I found that some of the requirements for the memory
buffers for MFC v6+ devices were blindly copied from the previous
hardware (v5) version and simply turned out to be excessive. It turned out
that there is no strict requirement for ALL buffers to be allocated on
the higher addresses than the firmware base. This requirement is true only
for the device and per-context buffers. All video data buffers can be
allocated anywhere for all MFC v6+ versions. This heavily simplifies
memory management in the driver.

Such relaxed requirements for the memory buffers can be easily fulfilled
by allocating firmware, device and per-context buffers from the probe-time
preallocated larger buffer. There is no need to create special reserved
memory regions. The only case, when those memory regions are needed is an
oldest Exynos series - Exynos4210 or Exyno4412, which both have MFC v5
hardware, and only when IOMMU is disabled.

This patchset has been tested on Odroid U3 (Exynos4412 with MFC v5), Google
Snow (Exynos5250 with MFC v6), Odroid XU3 (Exynos5422 with MFC v8) and
TM2 (Exynos5433 with MFC v8, ARM64) boards.

To get it working on TM2/Exynos5433 with IOMMU enabled, the 'architectural
clock gating' in SYSMMU has to be disabled. Fixing this will be handled
separately. As a temporary solution, one need to clear CFG_ACGEN bit in
REG_MMU_CFG of the SYSMMU, see __sysmmu_init_config function in
drivers/iommu/exynos-iommu.c.

Patches are based on linux-next from 20th February 2017 with "media:
s5p-mfc: Fix initialization of internal structures" patch applied:
https://patchwork.linuxtv.org/patch/39198/

I've tried to split changes into small pieces to make it easier to review
the code. I've also did a bit of cleanup while touching the driver.

Best regards
Marek Szyprowski
Samsung R Institute Poland


Changelog:

v2:
- fixed issues pointed by Javier Martinez Canillas: code compiles now
  after applying each patch, added missing cleanup
- added tags

v1: https://www.spinics.net/lists/linux-media/msg56.html
- initial version


Patch summary:

Marek Szyprowski (15):
  media: s5p-mfc: Remove unused structures and dead code
  media: s5p-mfc: Use generic of_device_get_match_data helper
  media: s5p-mfc: Replace mem_dev_* entries with an array
  media: s5p-mfc: Replace bank1/bank2 entries with an array
  media: s5p-mfc: Simplify alloc/release private buffer functions
  media: s5p-mfc: Move setting DMA max segment size to DMA configure
function
  media: s5p-mfc: Put firmware to private buffer structure
  media: s5p-mfc: Move firmware allocation to DMA configure function
  media: s5p-mfc: Allocate firmware with internal private buffer alloc
function
  media: s5p-mfc: Reduce firmware buffer size for MFC v6+ variants
  media: s5p-mfc: Split variant DMA memory configuration into separate
functions
  media: s5p-mfc: Add support for probe-time preallocated block based
allocator
  media: s5p-mfc: Remove special configuration of IOMMU domain
  media: s5p-mfc: Use preallocated block allocator always for MFC v6+
  ARM: dts: exynos: Remove MFC reserved buffers

 .../devicetree/bindings/media/s5p-mfc.txt  |   2 +-
 arch/arm/boot/dts/exynos5250-arndale.dts   |   1 -
 arch/arm/boot/dts/exynos5250-smdk5250.dts  |   1 -
 arch/arm/boot/dts/exynos5250-spring.dts|   1 -
 arch/arm/boot/dts/exynos5420-arndale-octa.dts  |   1 -
 arch/arm/boot/dts/exynos5420-peach-pit.dts |   1 -
 arch/arm/boot/dts/exynos5420-smdk5420.dts  |   1 -
 arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi |   1 -
 arch/arm/boot/dts/exynos5800-peach-pi.dts  |   1 -
 drivers/media/platform/s5p-mfc/regs-mfc-v6.h   |   2 +-
 drivers/media/platform/s5p-mfc/regs-mfc-v7.h   |   2 +-
 drivers/media/platform/s5p-mfc/regs-mfc-v8.h   |   2 +-
 drivers/media/platform/s5p-mfc/s5p_mfc.c   | 214 +
 drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v5.c|   2 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h|  43 ++---
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c  |  71 ++-
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.h  |   1 -
 drivers/media/platform/s5p-mfc/s5p_mfc_dec.c   |   8 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_enc.c   |  10 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_iommu.h |  51 +
 drivers/media/platform/s5p-mfc/s5p_mfc_opr.c   |  65 +--
 drivers/media/platform/s5p-mfc/s5p_mfc_opr.h   |   8 +-
 drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c

[PATCH v2 01/15] media: s5p-mfc: Remove unused structures and dead code

[Marek Szyprowski]

Remove unused structures, definitions and functions that are no longer
called from the driver code.

Signed-off-by: Marek Szyprowski 
Reviewed-by: Javier Martinez Canillas 
Tested-by: Javier Martinez Canillas 
---
 drivers/media/platform/s5p-mfc/s5p_mfc.c| 21 -
 drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 13 -
 drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.h   |  1 -
 3 files changed, 35 deletions(-)

diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 05fe82be6584..3e1f22eb4339 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1422,16 +1422,11 @@ static int s5p_mfc_resume(struct device *dev)
.priv   = _buf_size_v5,
 };
 
-static struct s5p_mfc_buf_align mfc_buf_align_v5 = {
-   .base = MFC_BASE_ALIGN_ORDER,
-};
-
 static struct s5p_mfc_variant mfc_drvdata_v5 = {
.version= MFC_VERSION,
.version_bit= MFC_V5_BIT,
.port_num   = MFC_NUM_PORTS,
.buf_size   = _size_v5,
-   .buf_align  = _buf_align_v5,
.fw_name[0] = "s5p-mfc.fw",
.clk_names  = {"mfc", "sclk_mfc"},
.num_clocks = 2,
@@ -1452,16 +1447,11 @@ static int s5p_mfc_resume(struct device *dev)
.priv   = _buf_size_v6,
 };
 
-static struct s5p_mfc_buf_align mfc_buf_align_v6 = {
-   .base = 0,
-};
-
 static struct s5p_mfc_variant mfc_drvdata_v6 = {
.version= MFC_VERSION_V6,
.version_bit= MFC_V6_BIT,
.port_num   = MFC_NUM_PORTS_V6,
.buf_size   = _size_v6,
-   .buf_align  = _buf_align_v6,
.fw_name[0] = "s5p-mfc-v6.fw",
/*
 * v6-v2 firmware contains bug fixes and interface change
@@ -1486,16 +1476,11 @@ static int s5p_mfc_resume(struct device *dev)
.priv   = _buf_size_v7,
 };
 
-static struct s5p_mfc_buf_align mfc_buf_align_v7 = {
-   .base = 0,
-};
-
 static struct s5p_mfc_variant mfc_drvdata_v7 = {
.version= MFC_VERSION_V7,
.version_bit= MFC_V7_BIT,
.port_num   = MFC_NUM_PORTS_V7,
.buf_size   = _size_v7,
-   .buf_align  = _buf_align_v7,
.fw_name[0] = "s5p-mfc-v7.fw",
.clk_names  = {"mfc", "sclk_mfc"},
.num_clocks = 2,
@@ -1515,16 +1500,11 @@ static int s5p_mfc_resume(struct device *dev)
.priv   = _buf_size_v8,
 };
 
-static struct s5p_mfc_buf_align mfc_buf_align_v8 = {
-   .base = 0,
-};
-
 static struct s5p_mfc_variant mfc_drvdata_v8 = {
.version= MFC_VERSION_V8,
.version_bit= MFC_V8_BIT,
.port_num   = MFC_NUM_PORTS_V8,
.buf_size   = _size_v8,
-   .buf_align  = _buf_align_v8,
.fw_name[0] = "s5p-mfc-v8.fw",
.clk_names  = {"mfc"},
.num_clocks = 1,
@@ -1535,7 +1515,6 @@ static int s5p_mfc_resume(struct device *dev)
.version_bit= MFC_V8_BIT,
.port_num   = MFC_NUM_PORTS_V8,
.buf_size   = _size_v8,
-   .buf_align  = _buf_align_v8,
.fw_name[0] = "s5p-mfc-v8.fw",
.clk_names  = {"pclk", "aclk", "aclk_xiu"},
.num_clocks = 3,
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h 
b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index ab23236aa942..3e0e8eaf8bfe 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -44,14 +44,6 @@
 
 #include 
 
-static inline dma_addr_t s5p_mfc_mem_cookie(void *a, void *b)
-{
-   /* Same functionality as the vb2_dma_contig_plane_paddr */
-   dma_addr_t *paddr = vb2_dma_contig_memops.cookie(b);
-
-   return *paddr;
-}
-
 /* MFC definitions */
 #define MFC_MAX_EXTRA_DPB   5
 #define MFC_MAX_BUFFERS32
@@ -229,16 +221,11 @@ struct s5p_mfc_buf_size {
void *priv;
 };
 
-struct s5p_mfc_buf_align {
-   unsigned int base;
-};
-
 struct s5p_mfc_variant {
unsigned int version;
unsigned int port_num;
u32 version_bit;
struct s5p_mfc_buf_size *buf_size;
-   struct s5p_mfc_buf_align *buf_align;
char*fw_name[MFC_FW_MAX_VERSIONS];
const char  *clk_names[MFC_MAX_CLOCKS];
int num_clocks;
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.h 
b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.h
index 8e5df041edf7..45c807bf19cc 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.h
@@ -18,7 +18,6 @@
 int s5p_mfc_release_firmware(struct s5p_mfc_dev *dev);
 int s5p_mfc_alloc_firmware(struct s5p_mfc_dev *dev);
 int s5p_mfc_load_firmware(struct s5p_mfc_dev *dev);
-int s5p_mfc_reload_firmware(struct s5p_mfc_dev *dev);
 
 int s5p_mfc_init_hw(struct s5p_mfc_dev *dev);
 void s5p_mfc_deinit_hw(struct 

Re: [PATCH 14/15] media: s5p-mfc: Use preallocated block allocator always for MFC v6+

[Javier Martinez Canillas]

Hello Marek,

On 02/20/2017 10:23 AM, Marek Szyprowski wrote:
> Hi Javier,
> 
> On 2017-02-17 22:13, Javier Martinez Canillas wrote:
>> On 02/14/2017 04:52 AM, Marek Szyprowski wrote:
>>> It turned out that all versions of MFC v6+ hardware doesn't have a strict
>>> requirement for ALL buffers to be allocated on higher addresses than the
>>> firmware base like it was documented for MFC v5. This requirement is true
>>> only for the device and per-context buffers. All video data buffers can be
>>> allocated anywhere for all MFC v6+ versions. Basing on this fact, the
>>> special DMA configuration based on two reserved memory regions is not
>>> really needed for MFC v6+ devices, because the memory requirements for the
>>> firmware, device and per-context buffers can be fulfilled by the simple
>>> probe-time pre-allocated block allocator instroduced in previous patch.
>> s/instroduced/introduced
>>
>>> This patch enables support for such pre-allocated block based allocator
>>> always for MFC v6+ devices. Due to the limitations of the memory management
>>> subsystem the largest supported size of the pre-allocated buffer when no
>>> CMA (Contiguous Memory Allocator) is enabled is 4MiB.
>>>
>>> This patch also removes the requirement to provide two reserved memory
>>> regions for MFC v6+ devices in device tree. Now the driver is fully
>>> functional without them.
>>>
>> Great!
>>
>>> Signed-off-by: Marek Szyprowski 
>>> ---
>> The patch looks good to me though and it works on my tests,
>> I've just one comment below.
>>
>> Reviewed-by: Javier Martinez Canillas 
>> Tested-by: Javier Martinez Canillas 
>>
>>>   Documentation/devicetree/bindings/media/s5p-mfc.txt | 2 +-
>>>   drivers/media/platform/s5p-mfc/s5p_mfc.c| 9 ++---
>>>   2 files changed, 7 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt 
>>> b/Documentation/devicetree/bindings/media/s5p-mfc.txt
>>> index 2c901286d818..d3404b5d4d17 100644
>>> --- a/Documentation/devicetree/bindings/media/s5p-mfc.txt
>>> +++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt
>>> @@ -28,7 +28,7 @@ Optional properties:
>>> - memory-region : from reserved memory binding: phandles to two reserved
>>>   memory regions, first is for "left" mfc memory bus interfaces,
>>>   second if for the "right" mfc memory bus, used when no SYSMMU
>>> -support is available
>>> +support is available; used only by MFC v5 present in Exynos4 SoCs
>>> Obsolete properties:
>>> - samsung,mfc-r, samsung,mfc-l : support removed, please use 
>>> memory-region
>>> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
>>> b/drivers/media/platform/s5p-mfc/s5p_mfc.c
>>> index 8fc6fe4ba087..36f0aec2a1b3 100644
>>> --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
>>> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
>>> @@ -1178,9 +1178,12 @@ static void s5p_mfc_unconfigure_2port_memory(struct 
>>> s5p_mfc_dev *mfc_dev)
>>>   static int s5p_mfc_configure_common_memory(struct s5p_mfc_dev *mfc_dev)
>>>   {
>>>   struct device *dev = _dev->plat_dev->dev;
>>> -unsigned long mem_size = SZ_8M;
>>> +unsigned long mem_size = SZ_4M;
>>>   unsigned int bitmap_size;
>>>   +if (IS_ENABLED(CONFIG_DMA_CMA) || exynos_is_iommu_available(dev))
>>> +mem_size = SZ_8M;
>>> +
>>>   if (mfc_mem_size)
>>>   mem_size = memparse(mfc_mem_size, NULL);
>>>
>> The driver allows the user to set mem_size > SZ_4M using the s5p_mfc.mem
>> parameter even when CMA ins't enabled and IOMMU isn't available. Maybe it
>> should fail early instead and notify the user what's missing?
> 
> It will notify user that driver failed to preallocate memory. 4M is the upper
> limit for standard kernel configuration, but afair there were some kconfig
> knobs to force kernel to use larger buckets for buddy allocator (what changes
> the limit). Frankly I would leave it as is.
> 
> If user wants to specify s5p-mfc.mem, he already has some knowledge how to
> configure the kernel. I don't think that driver should check all possible
> scenarios of failing and give detailed explanation what was configured
> wrong. You can also enable CMA and configure the 8MiB of the default global
> area. In such configuration preallocation of mfc firmware buffer will also
> fail. Should the driver care about it? IMO it is enough to tell user that
> preallocating of given megabytes failed.
> 

Right, it makes sense to leave it at is then indeed and let the users figure
out why the allocation failed with their specific kernel configuration.

> Best regards

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

Re: [PATCH 14/15] media: s5p-mfc: Use preallocated block allocator always for MFC v6+

[Marek Szyprowski]

Hi Javier,

On 2017-02-17 22:13, Javier Martinez Canillas wrote:

On 02/14/2017 04:52 AM, Marek Szyprowski wrote:

It turned out that all versions of MFC v6+ hardware doesn't have a strict
requirement for ALL buffers to be allocated on higher addresses than the
firmware base like it was documented for MFC v5. This requirement is true
only for the device and per-context buffers. All video data buffers can be
allocated anywhere for all MFC v6+ versions. Basing on this fact, the
special DMA configuration based on two reserved memory regions is not
really needed for MFC v6+ devices, because the memory requirements for the
firmware, device and per-context buffers can be fulfilled by the simple
probe-time pre-allocated block allocator instroduced in previous patch.

s/instroduced/introduced


This patch enables support for such pre-allocated block based allocator
always for MFC v6+ devices. Due to the limitations of the memory management
subsystem the largest supported size of the pre-allocated buffer when no
CMA (Contiguous Memory Allocator) is enabled is 4MiB.

This patch also removes the requirement to provide two reserved memory
regions for MFC v6+ devices in device tree. Now the driver is fully
functional without them.


Great!


Signed-off-by: Marek Szyprowski 
---

The patch looks good to me though and it works on my tests,
I've just one comment below.

Reviewed-by: Javier Martinez Canillas 
Tested-by: Javier Martinez Canillas 


  Documentation/devicetree/bindings/media/s5p-mfc.txt | 2 +-
  drivers/media/platform/s5p-mfc/s5p_mfc.c| 9 ++---
  2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt 
b/Documentation/devicetree/bindings/media/s5p-mfc.txt
index 2c901286d818..d3404b5d4d17 100644
--- a/Documentation/devicetree/bindings/media/s5p-mfc.txt
+++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt
@@ -28,7 +28,7 @@ Optional properties:
- memory-region : from reserved memory binding: phandles to two reserved
memory regions, first is for "left" mfc memory bus interfaces,
second if for the "right" mfc memory bus, used when no SYSMMU
-   support is available
+   support is available; used only by MFC v5 present in Exynos4 SoCs
  
  Obsolete properties:

- samsung,mfc-r, samsung,mfc-l : support removed, please use memory-region
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
b/drivers/media/platform/s5p-mfc/s5p_mfc.c
index 8fc6fe4ba087..36f0aec2a1b3 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
@@ -1178,9 +1178,12 @@ static void s5p_mfc_unconfigure_2port_memory(struct 
s5p_mfc_dev *mfc_dev)
  static int s5p_mfc_configure_common_memory(struct s5p_mfc_dev *mfc_dev)
  {
struct device *dev = _dev->plat_dev->dev;
-   unsigned long mem_size = SZ_8M;
+   unsigned long mem_size = SZ_4M;
unsigned int bitmap_size;
  
+	if (IS_ENABLED(CONFIG_DMA_CMA) || exynos_is_iommu_available(dev))

+   mem_size = SZ_8M;
+
if (mfc_mem_size)
mem_size = memparse(mfc_mem_size, NULL);


The driver allows the user to set mem_size > SZ_4M using the s5p_mfc.mem
parameter even when CMA ins't enabled and IOMMU isn't available. Maybe it
should fail early instead and notify the user what's missing?


It will notify user that driver failed to preallocate memory. 4M is the 
upper

limit for standard kernel configuration, but afair there were some kconfig
knobs to force kernel to use larger buckets for buddy allocator (what 
changes

the limit). Frankly I would leave it as is.

If user wants to specify s5p-mfc.mem, he already has some knowledge how to
configure the kernel. I don't think that driver should check all possible
scenarios of failing and give detailed explanation what was configured
wrong. You can also enable CMA and configure the 8MiB of the default global
area. In such configuration preallocation of mfc firmware buffer will also
fail. Should the driver care about it? IMO it is enough to tell user that
preallocating of given megabytes failed.

Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

Re: [PATCH 1/4] v4l2: device_register_subdev_nodes: allow calling multiple times

[Sakari Ailus]

Hi Pavel,

On Mon, Feb 20, 2017 at 11:31:14AM +0100, Pavel Machek wrote:
> Hi!
> 
> On Tue 2017-02-14 23:38:49, Pavel Machek wrote:
> > From: Sebastian Reichel 
> > 
> > If v4l2_device_register_subdev_nodes() is called multiple times, it is
> > better to return early than corrupt memory.
> > 
> > Without this, exposure / gain controls do not work in the camera
> > application on N900.
> > 
> > Signed-off-by: Sebastian Reichel 
> > Signed-off-by: Ivaylo Dimitrov 
> > Signed-off-by: Pavel Machek 
> 
> Can I get some updates/feedback here?
> 
> You liked this one and whole series should be ready...

:-)

I was just rebasing the CCP2 support on the fwnode patchset.

I'm just pushing the result here:



I've tested ACPI, will test DT soon...

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

[PATCH] omap3isp: avoid uninitialized memory

[Pavel Machek]

Code in ispcsiphy is quite confusing, and does not initialize phy1 in
case of isp rev. 2. Set it to zero, to prevent confusion.

Signed-off-by: Pavel Machek 

index 8f73f6d..a2474b6 100644
--- a/drivers/media/platform/omap3isp/ispcsiphy.c
+++ b/drivers/media/platform/omap3isp/ispcsiphy.c
@@ -362,14 +374,16 @@ int omap3isp_csiphy_init(struct isp_device *isp)
phy2->phy_regs = OMAP3_ISP_IOMEM_CSIPHY2;
mutex_init(>mutex);
 
-   if (isp->revision == ISP_REVISION_15_0) {
-   phy1->isp = isp;
-   phy1->csi2 = >isp_csi2c;
-   phy1->num_data_lanes = ISP_CSIPHY1_NUM_DATA_LANES;
-   phy1->cfg_regs = OMAP3_ISP_IOMEM_CSI2C_REGS1;
-   phy1->phy_regs = OMAP3_ISP_IOMEM_CSIPHY1;
-   mutex_init(>mutex);
+   if (isp->revision != ISP_REVISION_15_0) {
+   memset(phy1, sizeof(*phy1), 0);
+   return 0;
}
 
+   phy1->isp = isp;
+   phy1->csi2 = >isp_csi2c;
+   phy1->num_data_lanes = ISP_CSIPHY1_NUM_DATA_LANES;
+   phy1->cfg_regs = OMAP3_ISP_IOMEM_CSI2C_REGS1;
+   phy1->phy_regs = OMAP3_ISP_IOMEM_CSIPHY1;
+   mutex_init(>mutex);
return 0;
 }


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: PATCH: v4l-utils/utils/ir-ctl/irc-ctl.c: fix musl build

[Baruch Siach]

Hi Francesco,

On Mon, Feb 20, 2017 at 12:33:14PM +0100, Francesco wrote:
> This is my fist attempt to send a patch for v4l-utils project.
> I maintain v4l-utils package for Alpine Linux (www.alpinelinux.org), a
> musl-based distro.
> 
> This patch allows the build for v4l-utils by allowing alternatives to GLIBC
> assumptions.
> 
> Thanks for considering.

> From 71f399cb1399c35ff4ce165c2cec0fcd3256d34e Mon Sep 17 00:00:00 2001
> From: Francesco Colista 
> Date: Mon, 20 Feb 2017 10:16:01 +0100
> Subject: [PATCH] utils/ir-ctl/ir-ctl.c: fix build with musl library
> 
> This patch allows to build correctly v4l-utils on musl-based distributions.
> It provides alternative to glibc assumptions.
> ---
>  utils/ir-ctl/ir-ctl.c | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/utils/ir-ctl/ir-ctl.c b/utils/ir-ctl/ir-ctl.c
> index bc58cee0..0bd0ddcc 100644
> --- a/utils/ir-ctl/ir-ctl.c
> +++ b/utils/ir-ctl/ir-ctl.c
> @@ -42,6 +42,20 @@
>  # define _(string) string
>  #endif
>  
> +#if !defined(__GLIBC__)

This might break other libc implementations. Instead, do

  #ifndef TEMP_FAILURE_RETRY

See 
https://git.busybox.net/buildroot/tree/package/libv4l/0002-ir-ctl-fixes-for-musl-compile.patch

> +
> +/* Evaluate EXPRESSION, and repeat as long as it returns -1 with `errno'
> +   set to EINTR.  */
> +
> +# define TEMP_FAILURE_RETRY(expression) \
> +  (__extension__ 
>  \
> +({ long int __result;
>  \
> +   do __result = (long int) (expression);
>  \
> +   while (__result == -1L && errno == EINTR);
>  \
> +   __result; }))
> +
> +#endif
> +
>  # define N_(string) string

baruch

-- 
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -

PATCH: v4l-utils/utils/ir-ctl/irc-ctl.c: fix musl build

[Francesco]

Hi.
This is my fist attempt to send a patch for v4l-utils project.
I maintain v4l-utils package for Alpine Linux (www.alpinelinux.org), a 
musl-based distro.


This patch allows the build for v4l-utils by allowing alternatives to 
GLIBC assumptions.


Thanks for considering.

--
:: Francesco ::
Twit.http://twitter.com/fcolista
e-mail...france...@bsod.eu
AboutMe..http://about.me/fcolista
GnuPG ID: C4FB9584From 71f399cb1399c35ff4ce165c2cec0fcd3256d34e Mon Sep 17 00:00:00 2001
From: Francesco Colista 
Date: Mon, 20 Feb 2017 10:16:01 +0100
Subject: [PATCH] utils/ir-ctl/ir-ctl.c: fix build with musl library

This patch allows to build correctly v4l-utils on musl-based distributions.
It provides alternative to glibc assumptions.
---
 utils/ir-ctl/ir-ctl.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/utils/ir-ctl/ir-ctl.c b/utils/ir-ctl/ir-ctl.c
index bc58cee0..0bd0ddcc 100644
--- a/utils/ir-ctl/ir-ctl.c
+++ b/utils/ir-ctl/ir-ctl.c
@@ -42,6 +42,20 @@
 # define _(string) string
 #endif
 
+#if !defined(__GLIBC__)
+
+/* Evaluate EXPRESSION, and repeat as long as it returns -1 with `errno'
+   set to EINTR.  */
+
+# define TEMP_FAILURE_RETRY(expression) \
+  (__extension__  \
+({ long int __result; \
+   do __result = (long int) (expression); \
+   while (__result == -1L && errno == EINTR); \
+   __result; }))
+
+#endif
+
 # define N_(string) string
 
 
-- 
2.11.1

Re: [PATCH 15/15] ARM: dts: exynos: Remove MFC reserved buffersg

[Krzysztof Kozlowski]

On Mon, Feb 20, 2017 at 12:28 PM, Sylwester Nawrocki
 wrote:
> On 02/14/2017 06:03 PM, Krzysztof Kozlowski wrote:
>> On Tue, Feb 14, 2017 at 08:52:08AM +0100, Marek Szyprowski wrote:
>>> During my research I found that some of the requirements for the memory
>>> buffers for MFC v6+ devices were blindly copied from the previous (v5)
>>> version and simply turned out to be excessive. The relaxed requirements
>>> are applied by the recent patches to the MFC driver and the driver is
>>> now fully functional even without the reserved memory blocks for all
>>> v6+ variants. This patch removes those reserved memory nodes from all
>> boards having MFC v6+ hardware block.
>>
>> Signed-off-by: Marek Szyprowski 
>> ---
>>
>> Looks okay (for v4.12). Full bisectability depends on changes in MFC
>> driver, right?  I will need a stable branch/tag with driver changes
>> (although recently Arnd did not want driver changes mixed with DTS...).
>
> I'd suggest postponing that dts cleanup patch to v4.13, everything
> should continue to work properly with just the driver patches merged
> and that way there will be no need to pull all 14 driver patches
> into the arm-soc tree.

Yes. I didn't post an update here but to make it clear - the DTS
change in this case have to wait. It cannot go to a branch with the
driver changes (regardless if these as pulled from outside or included
as is).

Best regards,
Krzysztof

Re: [PATCH] v4l: vsp1: Fix WPF U/V order in 3-planar formats on Gen3

[Kieran Bingham]

Hi Laurent,

On 12/02/17 23:17, Laurent Pinchart wrote:
> The WPF U/V order bit has no effect for 3-planar formats on Gen3
> hardware. Swap the U and V planes manually instead in that case.

Nice effective solution.

> Fixes: b915bd24a034 ("[media] v4l: vsp1: Add tri-planar memory formats 
> support")
> Signed-off-by: Laurent Pinchart 

Reviewed-by: Kieran Bingham 

> ---
>  drivers/media/platform/vsp1/vsp1_wpf.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> This makes the vsp-unit-test-0002.sh test pass on both H2 and H3.
> 
> diff --git a/drivers/media/platform/vsp1/vsp1_wpf.c 
> b/drivers/media/platform/vsp1/vsp1_wpf.c
> index 7c48f81cd5c1..052a83e2d489 100644
> --- a/drivers/media/platform/vsp1/vsp1_wpf.c
> +++ b/drivers/media/platform/vsp1/vsp1_wpf.c
> @@ -216,6 +216,7 @@ static void wpf_configure(struct vsp1_entity *entity,
>  
>   if (params == VSP1_ENTITY_PARAMS_PARTITION) {
>   const struct v4l2_pix_format_mplane *format = >format;
> + const struct vsp1_format_info *fmtinfo = wpf->fmtinfo;
>   struct vsp1_rwpf_memory mem = wpf->mem;
>   unsigned int flip = wpf->flip.active;
>   unsigned int width = source_format->width;
> @@ -281,6 +282,14 @@ static void wpf_configure(struct vsp1_entity *entity,
>   }
>   }
>  
> + /*
> +  * On Gen3 hardware the SPUVS bit has no effect on 3-planar
> +  * formats. Swap the U and V planes manually in that case.
> +  */
> + if (vsp1->info->gen == 3 && format->num_planes == 3 &&
> + fmtinfo->swap_uv)
> + swap(mem.addr[1], mem.addr[2]);
> +
>   vsp1_wpf_write(wpf, dl, VI6_WPF_DSTM_ADDR_Y, mem.addr[0]);
>   vsp1_wpf_write(wpf, dl, VI6_WPF_DSTM_ADDR_C0, mem.addr[1]);
>   vsp1_wpf_write(wpf, dl, VI6_WPF_DSTM_ADDR_C1, mem.addr[2]);
> 

Re: [PATCH 1/4] v4l2: device_register_subdev_nodes: allow calling multiple times

[Pavel Machek]

Hi!

On Tue 2017-02-14 23:38:49, Pavel Machek wrote:
> From: Sebastian Reichel 
> 
> If v4l2_device_register_subdev_nodes() is called multiple times, it is
> better to return early than corrupt memory.
> 
> Without this, exposure / gain controls do not work in the camera
> application on N900.
> 
> Signed-off-by: Sebastian Reichel 
> Signed-off-by: Ivaylo Dimitrov 
> Signed-off-by: Pavel Machek 

Can I get some updates/feedback here?

You liked this one and whole series should be ready...

Best regards,
Pavel



-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH 15/15] ARM: dts: exynos: Remove MFC reserved buffersg

[Sylwester Nawrocki]

On 02/14/2017 06:03 PM, Krzysztof Kozlowski wrote:
> On Tue, Feb 14, 2017 at 08:52:08AM +0100, Marek Szyprowski wrote:
>> During my research I found that some of the requirements for the memory
>> buffers for MFC v6+ devices were blindly copied from the previous (v5)
>> version and simply turned out to be excessive. The relaxed requirements
>> are applied by the recent patches to the MFC driver and the driver is
>> now fully functional even without the reserved memory blocks for all
>> v6+ variants. This patch removes those reserved memory nodes from all
> boards having MFC v6+ hardware block.
> 
> Signed-off-by: Marek Szyprowski 
> ---
> 
> Looks okay (for v4.12). Full bisectability depends on changes in MFC
> driver, right?  I will need a stable branch/tag with driver changes
> (although recently Arnd did not want driver changes mixed with DTS...).

I'd suggest postponing that dts cleanup patch to v4.13, everything
should continue to work properly with just the driver patches merged
and that way there will be no need to pull all 14 driver patches
into the arm-soc tree.

--
Regards,
Sylwester

Re: Bug#854100: libdvbv5-0: fails to tune / scan

[Mauro Carvalho Chehab]

Em Fri, 17 Feb 2017 22:50:57 +0100
Marcel Heinz  escreveu:

> Hi,
> 
> Am 13. Februar 2017 schrieb Mauro Carvalho Chehab:
> 
> > Em Fri, 10 Feb 2017 22:02:01 +0100
> > Gregor Jasny  escreveu:
> >   
> >> Bug report against libdvbv5 is here:
> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854100  
> > 
> > There was a bug at the logic that was checking if the frequency was
> > at the range of the local oscillators. This patch should be addressing
> > it:
> > 
> > https://git.linuxtv.org/v4l-utils.git/commit/?id=5380ad44de416a41b4972e8a9c147ce42b0e3ba0
> > 
> > With that, the logic now seems to be working fine:
> > 
> > $ ./utils/dvb/dvbv5-scan ~/Intelsat-34 --lnbf universal -vv
> > Using LNBf UNIVERSAL
> > Universal, Europe
> > 10800 to 11800 MHz, LO: 9750 MHz
> > 11600 to 12700 MHz, LO: 10600 MHz
> > ...
> > Seeking for LO for 12.17 MHz frequency
> > LO setting 0: 10.80 MHz to 11.80 MHz
> > LO setting 1: 11.60 MHz to 12.70 MHz
> > Multi-LO LNBf. using LO setting 1 at 10600.00 MHz
> > frequency: 12170.00 MHz, high_band: 1
> > L-Band frequency: 1570.00 MHz (offset = 10600.00 MHz)
> > 
> > I can't really test it here, as my satellite dish uses a different
> > type of LNBf, but, from the above logs, the bug should be fixed.
> > 
> > Marcel,
> > 
> > Could you please test? The patch is already upstream.
> > I added a debug patch after it, in order to help LNBf issues
> > (enabled by using "-vv" command line parameters).  
> 
> I can confirm that 1.12.3 solves the issue for me. Thanks for the fix.

Good!

Thanks for testing!

Regards,
Mauro