[PATCH 1/4] staging: atomisp: fix unsigned int comparison with less than zero

[Daeseok Youn]

Fix warnings from the smatch tool

atomisp_cmd.c:2649
  atomisp_set_array_res() warn:
  unsigned 'config->width' is never less than zero.

atomisp_cmd.c:2650
  atomisp_set_array_res() warn:
  unsigned 'config->height' is never less than zero.

Signed-off-by: Daeseok Youn 
---
 drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
index 1ee99d0..9c3ba11 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_cmd.c
@@ -2646,8 +2646,7 @@ int atomisp_set_array_res(struct atomisp_sub_device *asd,
 struct atomisp_resolution  *config)
 {
dev_dbg(asd->isp->dev, ">%s start\n", __func__);
-   if (config == NULL || config->width < 0
-   || config->height < 0) {
+   if (!config) {
dev_err(asd->isp->dev, "Set sensor array size is not valid\n");
return -EINVAL;
}
-- 
1.9.1

cron job: media_tree daily build: ERRORS

[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:   Wed Mar 15 05:00:14 CET 2017
media-tree git hash:700ea5e0e0dd70420a04e703ff264cc133834cba
media_build git hash:   bc4c2a205c087c8deff3cd14ed663c4767dd2016
v4l-utils git hash: ca6a0c099399cc51ecfacff7ef938be6ef73b8b3
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: ERRORS
linux-3.12.67-i686: ERRORS
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.1-i686: OK
linux-4.11-rc1-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: ERRORS
linux-3.12.67-x86_64: ERRORS
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: WARNINGS
linux-4.9-x86_64: WARNINGS
linux-4.10.1-x86_64: WARNINGS
linux-4.11-rc1-x86_64: OK
apps: WARNINGS
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

Re: [PATCH] media: mtk-jpeg: fix continuous log "Context is NULL"

[Rick Chang]

On Tue, 2017-03-14 at 22:21 +0800, Minghsiu Tsai wrote:
> The symptom is continuous log "mtk-jpeg 18004000.jpegdec: Context is NULL"
> in kernel log. It is becauese the error handling in irq doesn't clear
> interrupt.
> 
> The calling flow like as below when issue happen
> mtk_jpeg_device_run()
> mtk_jpeg_job_abort()
>   v4l2_m2m_job_finish() -> m2m_dev->curr_ctx = NULL;
> mtk_jpeg_dec_irq()
>   v4l2_m2m_get_curr_priv()
>  -> m2m_dev->curr_ctx == NULL
>  -> return NULL
> log "Context is NULL"
> 
> There is race condition between job_abort() and irq. In order to simplify
> code, don't want to add extra flag to maintain state, empty job_abort() and
> clear interrupt before v4l2_m2m_get_curr_priv() in irq.
> 
> Signed-off-by: Minghsiu Tsai 
> ---
>  drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 14 ++
>  1 file changed, 2 insertions(+), 12 deletions(-)
Acked-by: Rick Chang 

Re: media / v4l2-mc: wishlist for complex cameras (was Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline)

[Mauro Carvalho Chehab]

Em Tue, 14 Mar 2017 23:32:54 +0100
Pavel Machek  escreveu:

> Hi!
> 
> > > > Even if they were merged, if we keep the same mean time to develop a
> > > > libv4l plugin, that would mean that a plugin for i.MX6 could take 2-3
> > > > years to be developed.
> > > > 
> > > > There's a clear message on it:
> > > > - we shouldn't keep pushing for a solution via libv4l.
> > > 
> > > Or:
> > > 
> > >   - userspace plugin development had a very a low priority and
> > > never got the attention it needed.  
> > 
> > The end result is the same: we can't count on it.
> >   
> > > 
> > > I know that's *my* reason. I rarely if ever looked at it. I always assumed
> > > Sakari and/or Laurent would look at it. If this reason is also valid for
> > > Sakari and Laurent, then it is no wonder nothing has happened in all that
> > > time.
> > > 
> > > We're all very driver-development-driven, and userspace gets very little
> > > attention in general. So before just throwing in the towel we should take
> > > a good look at the reasons why there has been little or no development: is
> > > it because of fundamental design defects, or because nobody paid attention
> > > to it?  
> > 
> > No. We should look it the other way: basically, there are patches
> > for i.MX6 driver that sends control from videonode to subdevs. 
> > 
> > If we nack apply it, who will write the userspace plugin? When
> > such change will be merged upstream?  
> 
> Well, I believe first question is: what applications would we want to
> run on complex devices? Will sending control from video to subdevs
> actually help?

I would say: camorama, xawtv3, zbar, google talk, skype. If it runs
with those, it will likely run with any other application.

> mplayer is useful for testing... but that one already works (after you
> setup the pipeline, and configure exposure/gain).
> 
> But thats useful for testing, not really for production. Image will be
> out of focus and with wrong white balance.
> 
> What I would really like is an application to get still photos. For
> taking pictures with manual settings we need
> 
> a) units for controls: user wants to focus on 1m, and take picture
> with ISO200, 1/125 sec. We should also tell him that lens is f/5.6 and
> focal length is 20mm with 5mm chip.
> 
> But... autofocus/autogain would really be good to have. Thus we need:
> 
> b) for each frame, we need exposure settings and focus position at
> time frame was taken. Otherwise autofocus/autogain will be too
> slow. At least focus position is going to be tricky -- either kernel
> would have to compute focus position for us (not trivial) or we'd need
> enough information to compute it in userspace.
> 
> There are more problems: hardware-accelerated preview is not trivial
> to set up (and I'm unsure if it can be done in generic way). Still
> photos application needs to switch resolutions between preview and
> photo capture. Probably hardware-accelerated histograms are needed for
> white balance, auto gain and auto focus, 
> 
> It seems like there's a _lot_ of stuff to be done before we have
> useful support for complex cameras...

Taking still pictures using a hardware-accelerated preview is
a sophisticated use case. I don't know any userspace application
that does that. Ok, several allow taking snapshots, by simply
storing the image of the current frame.

> (And I'm not sure... when application such as skype is running, is
> there some way to run autogain/autofocus/autowhitebalance? Is that
> something we want to support?)

Autofocus no. Autogain/Autowhite can be done via libv4l, provided that
it can access the device's controls via /dev/video devnode. Other
applications may be using some other similar algorithms.

Ok, they don't use histograms provided by the SoC. So, they do it in
software, with is slower. Still, it works fine when the light
conditions don't change too fast.

> > If we don't have answers to any of the above questions, we should not
> > nack it.
> > 
> > That's said, that doesn't prevent merging a libv4l plugin if/when
> > someone can find time/interest to develop it.  
> 
> I believe other question is: will not having same control on main
> video device and subdevs be confusing? Does it actually help userspace
> in any way? Yes, we can make controls accessible to old application,
> but does it make them more useful? 

Yes. As I said, libv4l (and some apps) have logic inside to adjust
the image via bright, contrast and white balance controls, using the
video devnode. They don't talk subdev API. So, if those controls
aren't exported, they won't be able to provide a good quality image.

> > > In addition, I suspect end-users of these complex devices don't really 
> > > care
> > > about a plugin: they want full control and won't typically use generic
> > > applications. If they would need support for that, we'd have seen much 
> > > more
> > > interest. The main reason for having a plugin is to simplify testing and
> > > if this is 

media / v4l2-mc: wishlist for complex cameras (was Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline)

[Pavel Machek]

Hi!

> > > Even if they were merged, if we keep the same mean time to develop a
> > > libv4l plugin, that would mean that a plugin for i.MX6 could take 2-3
> > > years to be developed.
> > > 
> > > There's a clear message on it:
> > >   - we shouldn't keep pushing for a solution via libv4l.  
> > 
> > Or:
> > 
> > - userspace plugin development had a very a low priority and
> >   never got the attention it needed.
> 
> The end result is the same: we can't count on it.
> 
> > 
> > I know that's *my* reason. I rarely if ever looked at it. I always assumed
> > Sakari and/or Laurent would look at it. If this reason is also valid for
> > Sakari and Laurent, then it is no wonder nothing has happened in all that
> > time.
> > 
> > We're all very driver-development-driven, and userspace gets very little
> > attention in general. So before just throwing in the towel we should take
> > a good look at the reasons why there has been little or no development: is
> > it because of fundamental design defects, or because nobody paid attention
> > to it?
> 
> No. We should look it the other way: basically, there are patches
> for i.MX6 driver that sends control from videonode to subdevs. 
> 
> If we nack apply it, who will write the userspace plugin? When
> such change will be merged upstream?

Well, I believe first question is: what applications would we want to
run on complex devices? Will sending control from video to subdevs
actually help?

mplayer is useful for testing... but that one already works (after you
setup the pipeline, and configure exposure/gain).

But thats useful for testing, not really for production. Image will be
out of focus and with wrong white balance.

What I would really like is an application to get still photos. For
taking pictures with manual settings we need

a) units for controls: user wants to focus on 1m, and take picture
with ISO200, 1/125 sec. We should also tell him that lens is f/5.6 and
focal length is 20mm with 5mm chip.

But... autofocus/autogain would really be good to have. Thus we need:

b) for each frame, we need exposure settings and focus position at
time frame was taken. Otherwise autofocus/autogain will be too
slow. At least focus position is going to be tricky -- either kernel
would have to compute focus position for us (not trivial) or we'd need
enough information to compute it in userspace.

There are more problems: hardware-accelerated preview is not trivial
to set up (and I'm unsure if it can be done in generic way). Still
photos application needs to switch resolutions between preview and
photo capture. Probably hardware-accelerated histograms are needed for
white balance, auto gain and auto focus, 

It seems like there's a _lot_ of stuff to be done before we have
useful support for complex cameras...

(And I'm not sure... when application such as skype is running, is
there some way to run autogain/autofocus/autowhitebalance? Is that
something we want to support?)

> If we don't have answers to any of the above questions, we should not
> nack it.
> 
> That's said, that doesn't prevent merging a libv4l plugin if/when
> someone can find time/interest to develop it.

I believe other question is: will not having same control on main
video device and subdevs be confusing? Does it actually help userspace
in any way? Yes, we can make controls accessible to old application,
but does it make them more useful? 

> > In addition, I suspect end-users of these complex devices don't really care
> > about a plugin: they want full control and won't typically use generic
> > applications. If they would need support for that, we'd have seen much more
> > interest. The main reason for having a plugin is to simplify testing and
> > if this is going to be used on cheap hobbyist devkits.
> 
> What are the needs for a cheap hobbyist devkit owner? Do we currently
> satisfy those needs? I'd say that having a functional driver when
> compiled without the subdev API, that implements the ioctl's/controls

Having different interface based on config options... is just
weird. What about poor people (like me) trying to develop complex
applications?

> [1] Yet, I might eventually do that for fun, an OMAP3 board with tvp5150
> just arrived here last week. It would be nice to have xawtv3 running on it :-)
> So, if I have a lot of spare time (with is very unlikely), I might eventually 
> do something for it to work.
> 
> > I know it took me a very long time before I had a working omap3.
> 
> My first OMAP3 board with working V4L2 source just arrived last week
> :-)

You can get Nokia N900 on aliexpress. If not, they are still available
between people :-).

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

[PATCH] [media] dvb-frontends/drxk: don't log errors on unsupported operation mode

[Daniel Scheller]

From: Daniel Scheller 

When fe_ops.read_status is called and no channel is tuned (yet), the
subsequent calls to get_lock_status() causes the kernel log to be filled
with

drxk: Error -22 on get_lock_status

which either means a NULL pointer was passed for the p_lock_status var,
or neither QAM nor OFDM/DVBT operation mode are active. Instead of
filling the kernel log in the latter case, print out a message to the debug
level and return 0 (this isn't used in the calling drxk_get_stats() anyway).

Signed-off-by: Daniel Scheller 
---
 drivers/media/dvb-frontends/drxk_hard.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/drxk_hard.c 
b/drivers/media/dvb-frontends/drxk_hard.c
index 7e1bbba..b5ea919 100644
--- a/drivers/media/dvb-frontends/drxk_hard.c
+++ b/drivers/media/dvb-frontends/drxk_hard.c
@@ -1904,7 +1904,9 @@ static int get_lock_status(struct drxk_state *state, u32 
*p_lock_status)
status = get_dvbt_lock_status(state, p_lock_status);
break;
default:
-   break;
+   pr_debug("Unsupported operation mode %d in %s\n",
+   state->m_operation_mode, __func__);
+   return 0;
}
 error:
if (status < 0)
-- 
2.10.2

Re: [PATCH 12/13] [media] tuners/tda18212: add flag for retrying tuner init on failure

[Daniel Scheller]

Am Mon, 13 Mar 2017 16:16:29 +0200
schrieb Antti Palosaari :

> On 03/07/2017 08:57 PM, Daniel Scheller wrote:
> > From: Daniel Scheller 
> >
> > Taken from tda18212dd, first read after cold reset sometimes fails
> > on some cards, trying twice shall do the trick. This is the case
> > with the STV0367 demods soldered on the CineCTv6 bridge boards and
> > older DuoFlex CT modules.
> >
> > All other users (configs) of the tda18212 are updated as well to be
> > sure they won't be affected at all by this change.  
> 
> That sounds like a i2c adapter problem and fix should be there, no
> hack on a tuner driver.
> 
> Antti

This indeed is due to some HW issue. Patch has been removed though and
the retry logic put into ddbridge-core.c:tuner_attach_tda18212() for
the STV demod type with explaining comments, will be in a V2 of the
patch series.

Thanks,
Daniel

> >
> > Signed-off-by: Daniel Scheller 
> > ---
> >  drivers/media/platform/sti/c8sectpfe/c8sectpfe-dvb.c | 1 +
> >  drivers/media/tuners/tda18212.c  | 5 +
> >  drivers/media/tuners/tda18212.h  | 7 +++
> >  drivers/media/usb/dvb-usb-v2/anysee.c| 2 ++
> >  drivers/media/usb/em28xx/em28xx-dvb.c| 1 +
> >  5 files changed, 16 insertions(+)
> >
> > diff --git a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-dvb.c
> > b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-dvb.c index
> > 2c0015b..03688ee 100644 ---
> > a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-dvb.c +++
> > b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-dvb.c @@ -111,6
> > +111,7 @@ static struct tda18212_config tda18212_conf =
> > { .if_dvbt_7 = 4150, .if_dvbt_8 = 4500,
> > .if_dvbc = 5000,
> > +   .init_flags = 0,
> >  };
> >
> >  int c8sectpfe_frontend_attach(struct dvb_frontend **fe,
> > diff --git a/drivers/media/tuners/tda18212.c
> > b/drivers/media/tuners/tda18212.c index 7b80683..2488537 100644
> > --- a/drivers/media/tuners/tda18212.c
> > +++ b/drivers/media/tuners/tda18212.c
> > @@ -220,6 +220,11 @@ static int tda18212_probe(struct i2c_client
> > *client, fe->ops.i2c_gate_ctrl(fe, 1); /* open I2C-gate */
> >
> > ret = regmap_read(dev->regmap, 0x00, _id);
> > +
> > +   /* retry probe if desired */
> > +   if (ret && (cfg->init_flags & TDA18212_INIT_RETRY))
> > +   ret = regmap_read(dev->regmap, 0x00, _id);
> > +
> > dev_dbg(>client->dev, "chip_id=%02x\n", chip_id);
> >
> > if (fe->ops.i2c_gate_ctrl)
> > diff --git a/drivers/media/tuners/tda18212.h
> > b/drivers/media/tuners/tda18212.h index 6391daf..717aa2c 100644
> > --- a/drivers/media/tuners/tda18212.h
> > +++ b/drivers/media/tuners/tda18212.h
> > @@ -23,6 +23,8 @@
> >
> >  #include "dvb_frontend.h"
> >
> > +#define TDA18212_INIT_RETRY(1 << 0)
> > +
> >  struct tda18212_config {
> > u16 if_dvbt_6;
> > u16 if_dvbt_7;
> > @@ -36,6 +38,11 @@ struct tda18212_config {
> > u16 if_atsc_qam;
> >
> > /*
> > +* flags for tuner init control
> > +*/
> > +   u32 init_flags;
> > +
> > +   /*
> >  * pointer to DVB frontend
> >  */
> > struct dvb_frontend *fe;
> > diff --git a/drivers/media/usb/dvb-usb-v2/anysee.c
> > b/drivers/media/usb/dvb-usb-v2/anysee.c index 6795c0c..c35b66e
> > 100644 --- a/drivers/media/usb/dvb-usb-v2/anysee.c
> > +++ b/drivers/media/usb/dvb-usb-v2/anysee.c
> > @@ -332,6 +332,7 @@ static struct tda18212_config
> > anysee_tda18212_config = { .if_dvbt_7 = 4150,
> > .if_dvbt_8 = 4150,
> > .if_dvbc = 5000,
> > +   .init_flags = 0,
> >  };
> >
> >  static struct tda18212_config anysee_tda18212_config2 = {
> > @@ -342,6 +343,7 @@ static struct tda18212_config
> > anysee_tda18212_config2 = { .if_dvbt2_7 = 4000,
> > .if_dvbt2_8 = 4000,
> > .if_dvbc = 5000,
> > +   .init_flags = 0,
> >  };
> >
> >  static struct cx24116_config anysee_cx24116_config = {
> > diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c
> > b/drivers/media/usb/em28xx/em28xx-dvb.c index 82edd37..143efb0
> > 100644 --- a/drivers/media/usb/em28xx/em28xx-dvb.c
> > +++ b/drivers/media/usb/em28xx/em28xx-dvb.c
> > @@ -380,6 +380,7 @@ static struct tda18271_config
> > kworld_ub435q_v2_config = { static struct tda18212_config
> > kworld_ub435q_v3_config = { .if_atsc_vsb= 3600,
> > .if_atsc_qam= 3600,
> > +   .init_flags = 0,
> >  };
> >
> >  static struct zl10353_config em28xx_zl10353_xc3028_no_i2c_gate = {
> >  
> 

Re: [RFC][PATCH] dma-buf: Introduce dma-buf test module

[Laura Abbott]

On 03/14/2017 01:13 PM, Daniel Vetter wrote:
> On Tue, Mar 14, 2017 at 01:04:19PM -0700, Laura Abbott wrote:
>>
>> dma-buf is designed to share buffers. Sharing means that there needs to
>> be another subsystem to accept those buffers. Introduce a simple test
>> module to act as a dummy system to accept dma_bufs from elsewhere. The
>> goal is to provide a very simple interface to validate exported buffers
>> do something reasonable. This is based on ion_test.c that existed for
>> the Ion framework.
>>
>> Signed-off-by: Laura Abbott 
>> ---
>> This is basically a drop in of what was available as
>> drivers/staging/android/ion/ion_test.c. Given it has no Ion specific
>> parts it might be useful as a more general test module. RFC mostly
>> to see if this is generally useful or not.
> 
> We already have a test dma-buf driver, which also handles reservation
> objects and can create fences to provoke signalling races an all kinds of
> other fun. It's drivers/gpu/drm/vgem.
> 
> If there's anything missing in there, patches very much welcome.
> -Daniel
> 

Thanks for that pointer. It certainly looks more complete vs. allocating
a platform_device. I'll look and see if there's anything that needs
extension. Plus this means I can probably delete more code from Ion (woo)

Thanks,
Laura

>> ---
>>  drivers/dma-buf/Kconfig   |   9 ++
>>  drivers/dma-buf/Makefile  |   1 +
>>  drivers/dma-buf/dma-buf-test.c| 309 
>> ++
>>  include/uapi/linux/dma_buf_test.h |  67 +
>>  4 files changed, 386 insertions(+)
>>  create mode 100644 drivers/dma-buf/dma-buf-test.c
>>  create mode 100644 include/uapi/linux/dma_buf_test.h
>>
>> diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
>> index ed3b785..8b3fdb1 100644
>> --- a/drivers/dma-buf/Kconfig
>> +++ b/drivers/dma-buf/Kconfig
>> @@ -30,4 +30,13 @@ config SW_SYNC
>>WARNING: improper use of this can result in deadlocking kernel
>>drivers from userspace. Intended for test and debug only.
>>  
>> +config DMA_BUF_TEST
>> +bool "Test module for dma-buf"
>> +default n
>> +---help---
>> +  A test module to validate dma_buf APIs. This should not be
>> +  enabled for general use.
>> +
>> +  Say N here unless you know you want this.
>> +
>>  endmenu
>> diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
>> index c33bf88..5029608 100644
>> --- a/drivers/dma-buf/Makefile
>> +++ b/drivers/dma-buf/Makefile
>> @@ -1,3 +1,4 @@
>>  obj-y := dma-buf.o dma-fence.o dma-fence-array.o reservation.o seqno-fence.o
>>  obj-$(CONFIG_SYNC_FILE) += sync_file.o
>>  obj-$(CONFIG_SW_SYNC)   += sw_sync.o sync_debug.o
>> +obj-$(CONFIG_DMA_BUF_TEST)  += dma-buf-test.o
>> diff --git a/drivers/dma-buf/dma-buf-test.c b/drivers/dma-buf/dma-buf-test.c
>> new file mode 100644
>> index 000..3af131c
>> --- /dev/null
>> +++ b/drivers/dma-buf/dma-buf-test.c
>> @@ -0,0 +1,309 @@
>> +/*
>> + * Copyright (C) 2013 Google, Inc.
>> + *
>> + * This software is licensed under the terms of the GNU General Public
>> + * License versdma_buf 2, as published by the Free Software Foundatdma_buf, 
>> and
>> + * may be copied, distributed, and modified under those terms.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + */
>> +
>> +#define pr_fmt(fmt) "dma-buf-test: " fmt
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include 
>> +
>> +struct dma_buf_test_device {
>> +struct miscdevice misc;
>> +};
>> +
>> +struct dma_buf_test_data {
>> +struct dma_buf *dma_buf;
>> +struct device *dev;
>> +};
>> +
>> +static int dma_buf_handle_test_dma(struct device *dev, struct dma_buf 
>> *dma_buf,
>> +   void __user *ptr, size_t offset, size_t size,
>> +   bool write)
>> +{
>> +int ret = 0;
>> +struct dma_buf_attachment *attach;
>> +struct sg_table *table;
>> +pgprot_t pgprot = pgprot_writecombine(PAGE_KERNEL);
>> +enum dma_data_direction dir = write ? DMA_FROM_DEVICE : DMA_TO_DEVICE;
>> +struct sg_page_iter sg_iter;
>> +unsigned long offset_page;
>> +
>> +attach = dma_buf_attach(dma_buf, dev);
>> +if (IS_ERR(attach))
>> +return PTR_ERR(attach);
>> +
>> +table = dma_buf_map_attachment(attach, dir);
>> +if (IS_ERR(table))
>> +return PTR_ERR(table);
>> +
>> +offset_page = offset >> PAGE_SHIFT;
>> +offset %= PAGE_SIZE;
>> +
>> +for_each_sg_page(table->sgl, _iter, table->nents, offset_page) {
>> +struct page *page = sg_page_iter_page(_iter);
>> +void *vaddr = vmap(, 1, VM_MAP, 

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Nicolas Dufresne]

Le mardi 14 mars 2017 à 15:47 +0100, Benjamin Gaignard a écrit :
> Should we use /devi/ion/$heap instead of /dev/ion_$heap ?
> I think it would be easier for user to look into one directory rather
> then in whole /dev to find the heaps
> 
> > is that we don't have to worry about a limit of 32 possible
> > heaps per system (32-bit heap id allocation field). But dealing
> > with an ioctl seems easier than names. Userspace might be less
> > likely to hardcode random id numbers vs. names as well.
> 
> In the futur I think that heap type will be replaced by a "get caps"
> ioctl which will
> describe heap capabilities. At least that is my understanding of
> kernel part
> of "unix memory allocator" project

I think what we really need from userspace point of view, is the
ability to find a compatible heap for a set of drivers. And this
without specific knowledge of the drivers.

Nicolas

signature.asc
Description: This is a digitally signed message part

Re: [RFC][PATCH] dma-buf: Introduce dma-buf test module

[Daniel Vetter]

On Tue, Mar 14, 2017 at 01:04:19PM -0700, Laura Abbott wrote:
> 
> dma-buf is designed to share buffers. Sharing means that there needs to
> be another subsystem to accept those buffers. Introduce a simple test
> module to act as a dummy system to accept dma_bufs from elsewhere. The
> goal is to provide a very simple interface to validate exported buffers
> do something reasonable. This is based on ion_test.c that existed for
> the Ion framework.
> 
> Signed-off-by: Laura Abbott 
> ---
> This is basically a drop in of what was available as
> drivers/staging/android/ion/ion_test.c. Given it has no Ion specific
> parts it might be useful as a more general test module. RFC mostly
> to see if this is generally useful or not.

We already have a test dma-buf driver, which also handles reservation
objects and can create fences to provoke signalling races an all kinds of
other fun. It's drivers/gpu/drm/vgem.

If there's anything missing in there, patches very much welcome.
-Daniel

> ---
>  drivers/dma-buf/Kconfig   |   9 ++
>  drivers/dma-buf/Makefile  |   1 +
>  drivers/dma-buf/dma-buf-test.c| 309 
> ++
>  include/uapi/linux/dma_buf_test.h |  67 +
>  4 files changed, 386 insertions(+)
>  create mode 100644 drivers/dma-buf/dma-buf-test.c
>  create mode 100644 include/uapi/linux/dma_buf_test.h
> 
> diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
> index ed3b785..8b3fdb1 100644
> --- a/drivers/dma-buf/Kconfig
> +++ b/drivers/dma-buf/Kconfig
> @@ -30,4 +30,13 @@ config SW_SYNC
> WARNING: improper use of this can result in deadlocking kernel
> drivers from userspace. Intended for test and debug only.
>  
> +config DMA_BUF_TEST
> + bool "Test module for dma-buf"
> + default n
> + ---help---
> +   A test module to validate dma_buf APIs. This should not be
> +   enabled for general use.
> +
> +   Say N here unless you know you want this.
> +
>  endmenu
> diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
> index c33bf88..5029608 100644
> --- a/drivers/dma-buf/Makefile
> +++ b/drivers/dma-buf/Makefile
> @@ -1,3 +1,4 @@
>  obj-y := dma-buf.o dma-fence.o dma-fence-array.o reservation.o seqno-fence.o
>  obj-$(CONFIG_SYNC_FILE)  += sync_file.o
>  obj-$(CONFIG_SW_SYNC)+= sw_sync.o sync_debug.o
> +obj-$(CONFIG_DMA_BUF_TEST)   += dma-buf-test.o
> diff --git a/drivers/dma-buf/dma-buf-test.c b/drivers/dma-buf/dma-buf-test.c
> new file mode 100644
> index 000..3af131c
> --- /dev/null
> +++ b/drivers/dma-buf/dma-buf-test.c
> @@ -0,0 +1,309 @@
> +/*
> + * Copyright (C) 2013 Google, Inc.
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License versdma_buf 2, as published by the Free Software Foundatdma_buf, 
> and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#define pr_fmt(fmt) "dma-buf-test: " fmt
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +struct dma_buf_test_device {
> + struct miscdevice misc;
> +};
> +
> +struct dma_buf_test_data {
> + struct dma_buf *dma_buf;
> + struct device *dev;
> +};
> +
> +static int dma_buf_handle_test_dma(struct device *dev, struct dma_buf 
> *dma_buf,
> +void __user *ptr, size_t offset, size_t size,
> +bool write)
> +{
> + int ret = 0;
> + struct dma_buf_attachment *attach;
> + struct sg_table *table;
> + pgprot_t pgprot = pgprot_writecombine(PAGE_KERNEL);
> + enum dma_data_direction dir = write ? DMA_FROM_DEVICE : DMA_TO_DEVICE;
> + struct sg_page_iter sg_iter;
> + unsigned long offset_page;
> +
> + attach = dma_buf_attach(dma_buf, dev);
> + if (IS_ERR(attach))
> + return PTR_ERR(attach);
> +
> + table = dma_buf_map_attachment(attach, dir);
> + if (IS_ERR(table))
> + return PTR_ERR(table);
> +
> + offset_page = offset >> PAGE_SHIFT;
> + offset %= PAGE_SIZE;
> +
> + for_each_sg_page(table->sgl, _iter, table->nents, offset_page) {
> + struct page *page = sg_page_iter_page(_iter);
> + void *vaddr = vmap(, 1, VM_MAP, pgprot);
> + size_t to_copy = PAGE_SIZE - offset;
> +
> + to_copy = min(to_copy, size);
> + if (!vaddr) {
> + ret = -ENOMEM;
> + goto err;
> + }
> +
> + if (write)
> + ret = copy_from_user(vaddr + offset, ptr, to_copy);
> + else
> + 

[RFC][PATCH] dma-buf: Introduce dma-buf test module

[Laura Abbott]

dma-buf is designed to share buffers. Sharing means that there needs to
be another subsystem to accept those buffers. Introduce a simple test
module to act as a dummy system to accept dma_bufs from elsewhere. The
goal is to provide a very simple interface to validate exported buffers
do something reasonable. This is based on ion_test.c that existed for
the Ion framework.

Signed-off-by: Laura Abbott 
---
This is basically a drop in of what was available as
drivers/staging/android/ion/ion_test.c. Given it has no Ion specific
parts it might be useful as a more general test module. RFC mostly
to see if this is generally useful or not.
---
 drivers/dma-buf/Kconfig   |   9 ++
 drivers/dma-buf/Makefile  |   1 +
 drivers/dma-buf/dma-buf-test.c| 309 ++
 include/uapi/linux/dma_buf_test.h |  67 +
 4 files changed, 386 insertions(+)
 create mode 100644 drivers/dma-buf/dma-buf-test.c
 create mode 100644 include/uapi/linux/dma_buf_test.h

diff --git a/drivers/dma-buf/Kconfig b/drivers/dma-buf/Kconfig
index ed3b785..8b3fdb1 100644
--- a/drivers/dma-buf/Kconfig
+++ b/drivers/dma-buf/Kconfig
@@ -30,4 +30,13 @@ config SW_SYNC
  WARNING: improper use of this can result in deadlocking kernel
  drivers from userspace. Intended for test and debug only.
 
+config DMA_BUF_TEST
+   bool "Test module for dma-buf"
+   default n
+   ---help---
+ A test module to validate dma_buf APIs. This should not be
+ enabled for general use.
+
+ Say N here unless you know you want this.
+
 endmenu
diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
index c33bf88..5029608 100644
--- a/drivers/dma-buf/Makefile
+++ b/drivers/dma-buf/Makefile
@@ -1,3 +1,4 @@
 obj-y := dma-buf.o dma-fence.o dma-fence-array.o reservation.o seqno-fence.o
 obj-$(CONFIG_SYNC_FILE)+= sync_file.o
 obj-$(CONFIG_SW_SYNC)  += sw_sync.o sync_debug.o
+obj-$(CONFIG_DMA_BUF_TEST) += dma-buf-test.o
diff --git a/drivers/dma-buf/dma-buf-test.c b/drivers/dma-buf/dma-buf-test.c
new file mode 100644
index 000..3af131c
--- /dev/null
+++ b/drivers/dma-buf/dma-buf-test.c
@@ -0,0 +1,309 @@
+/*
+ * Copyright (C) 2013 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License versdma_buf 2, as published by the Free Software Foundatdma_buf, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#define pr_fmt(fmt) "dma-buf-test: " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+struct dma_buf_test_device {
+   struct miscdevice misc;
+};
+
+struct dma_buf_test_data {
+   struct dma_buf *dma_buf;
+   struct device *dev;
+};
+
+static int dma_buf_handle_test_dma(struct device *dev, struct dma_buf *dma_buf,
+  void __user *ptr, size_t offset, size_t size,
+  bool write)
+{
+   int ret = 0;
+   struct dma_buf_attachment *attach;
+   struct sg_table *table;
+   pgprot_t pgprot = pgprot_writecombine(PAGE_KERNEL);
+   enum dma_data_direction dir = write ? DMA_FROM_DEVICE : DMA_TO_DEVICE;
+   struct sg_page_iter sg_iter;
+   unsigned long offset_page;
+
+   attach = dma_buf_attach(dma_buf, dev);
+   if (IS_ERR(attach))
+   return PTR_ERR(attach);
+
+   table = dma_buf_map_attachment(attach, dir);
+   if (IS_ERR(table))
+   return PTR_ERR(table);
+
+   offset_page = offset >> PAGE_SHIFT;
+   offset %= PAGE_SIZE;
+
+   for_each_sg_page(table->sgl, _iter, table->nents, offset_page) {
+   struct page *page = sg_page_iter_page(_iter);
+   void *vaddr = vmap(, 1, VM_MAP, pgprot);
+   size_t to_copy = PAGE_SIZE - offset;
+
+   to_copy = min(to_copy, size);
+   if (!vaddr) {
+   ret = -ENOMEM;
+   goto err;
+   }
+
+   if (write)
+   ret = copy_from_user(vaddr + offset, ptr, to_copy);
+   else
+   ret = copy_to_user(ptr, vaddr + offset, to_copy);
+
+   vunmap(vaddr);
+   if (ret) {
+   ret = -EFAULT;
+   goto err;
+   }
+   size -= to_copy;
+   if (!size)
+   break;
+   ptr += to_copy;
+   offset = 0;
+   }
+
+err:
+   dma_buf_unmap_attachment(attach, table, dir);
+   dma_buf_detach(dma_buf, attach);
+   return ret;
+}
+
+static int 

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Laura Abbott]

On 03/14/2017 07:47 AM, Benjamin Gaignard wrote:
> 2017-03-13 22:09 GMT+01:00 Laura Abbott :
>> On 03/12/2017 12:05 PM, Daniel Vetter wrote:
>>> On Sun, Mar 12, 2017 at 2:34 PM, Benjamin Gaignard
>>>  wrote:
 2017-03-09 18:38 GMT+01:00 Laura Abbott :
> On 03/09/2017 02:00 AM, Benjamin Gaignard wrote:
>> 2017-03-06 17:04 GMT+01:00 Daniel Vetter :
>>> On Mon, Mar 06, 2017 at 11:58:05AM +0100, Mark Brown wrote:
 On Mon, Mar 06, 2017 at 11:40:41AM +0100, Daniel Vetter wrote:

> No one gave a thing about android in upstream, so Greg KH just dumped 
> it
> all into staging/android/. We've discussed ION a bunch of times, 
> recorded
> anything we'd like to fix in staging/android/TODO, and Laura's patch
> series here addresses a big chunk of that.

> This is pretty much the same approach we (gpu folks) used to de-stage 
> the
> syncpt stuff.

 Well, there's also the fact that quite a few people have issues with 
 the
 design (like Laurent).  It seems like a lot of them have either got 
 more
 comfortable with it over time, or at least not managed to come up with
 any better ideas in the meantime.
>>>
>>> See the TODO, it has everything a really big group (look at the patch 
>>> for
>>> the full Cc: list) figured needs to be improved at LPC 2015. We don't 
>>> just
>>> merge stuff because merging stuff is fun :-)
>>>
>>> Laurent was even in that group ...
>>> -Daniel
>>
>> For me those patches are going in the right direction.
>>
>> I still have few questions:
>> - since alignment management has been remove from ion-core, should it
>> be also removed from ioctl structure ?
>
> Yes, I think I'm going to go with the suggestion to fixup the ABI
> so we don't need the compat layer and as part of that I'm also
> dropping the align argument.
>
>> - can you we ride off ion_handle (at least in userland) and only
>> export a dma-buf descriptor ?
>
> Yes, I think this is the right direction given we're breaking
> everything anyway. I was debating trying to keep the two but
> moving to only dma bufs is probably cleaner. The only reason
> I could see for keeping the handles is running out of file
> descriptors for dma-bufs but that seems unlikely.
>>
>> In the future how can we add new heaps ?
>> Some platforms have very specific memory allocation
>> requirements (just have a look in the number of gem custom allocator in 
>> drm)
>> Do you plan to add heap type/mask for each ?
>
> Yes, that was my thinking.

 My concern is about the policy to adding heaps, will you accept
 "customs" heap per
 platforms ? per devices ? or only generic ones ?
 If you are too strict, we will have lot of out-of-tree heaps and if
 you accept of of them
 it will be a nightmare to maintain
>>>
>>> I think ion should expose any heap that's also directly accessible to
>>> devices using dma_alloc(_coherent). That should leave very few things
>>> left, like your SMA heap.
>>>
 Another point is how can we put secure rules (like selinux policy) on
 heaps since all the allocations
 go to the same device (/dev/ion) ? For example, until now, in Android
 we have to give the same
 access rights to all the process that use ION.
 It will become problem when we will add secure heaps because we won't
 be able to distinguish secure
 processes to standard ones or set specific policy per heaps.
 Maybe I'm wrong here but I have never see selinux policy checking an
 ioctl field but if that
 exist it could be a solution.
>>>
>>> Hm, we might want to expose all the heaps as individual
>>> /dev/ion_$heapname nodes? Should we do this from the start, since
>>> we're massively revamping the uapi anyway (imo not needed, current
>>> state seems to work too)?
>>> -Daniel
>>>
>>
>> I thought about that. One advantage with separate /dev/ion_$heap
> 
> Should we use /devi/ion/$heap instead of /dev/ion_$heap ?
> I think it would be easier for user to look into one directory rather
> then in whole /dev to find the heaps
> 

If we decide to move away from /dev/ion we can consider it.

>> is that we don't have to worry about a limit of 32 possible
>> heaps per system (32-bit heap id allocation field). But dealing
>> with an ioctl seems easier than names. Userspace might be less
>> likely to hardcode random id numbers vs. names as well.
> 
> In the futur I think that heap type will be replaced by a "get caps"
> ioctl which will
> describe heap capabilities. At least that is my understanding of kernel part
> of "unix memory allocator" project
> 

I don't think it will be completely replaced. A heap can have multiple

Re: [PATCH] [media] v4l2-dv-timings: Introduce v4l2_calc_fps()

[Jose Abreu]

Hi Hans,


On 14-03-2017 07:24, Hans Verkuil wrote:
>> Right, I was forgetting about this ...
>>
>> So:
>> 1) Most of HDMI receivers do not have the expected precision in
>> measuring pixel clock value;
> s/Most/Some/
>
> Newer HDMI receivers tend to have better precision.
>
> However, the 1000/1001 factor is within the error of margin that the HDMI
> spec has for the pixelclock, so even if it is 59.94 you still (theoretically)
> do not know if that is because it really has that fps or if the source just 
> has
> a bad clock.

Hmm. But if source has a bad clock then it won't send at the
expected frame rate, so if we are able to measure pixel clock
value we will get the approximated frame rate for that source,
right? Unless the source also doesn't have standard h/v timings,
but as long as receiver detects this correctly then we can calculate.

>
> It's a bit theoretical, in practice you can assume the source really is 
> sending
> at 59.94 AFAIK.
>
>> 2) Most (I would guess all of them?) have access to AVI infoframe
>> contents;
> All will have that.
>
>> 3) The FPS value is generally used by applications to calculate
>> expected frame rate and number of frames dropped (right?);
> Not really. Most HDMI drivers do not implement g_parm, instead they fill in
> the detected pixelclock in QUERY_DV_TIMINGS, leaving it up to the application
> to calculate the fps from that.
>
>> 4) The factor in FPS value can be adjusted by 1000/1001;
>>
>> From these points I would propose in just using the vic and drop
>> the resolution in fps a little bit, do you agree?
> The reality is that how to detect the 1000/1001 reduced fps is fuzzy. Part of
> the reason for that is that most of the HDMI receivers we have in the kernel
> were developed by Cisco/Tandberg (i.e. mostly me) for our video conferencing
> systems, and those all run at 60 Hz. So we never had the need to detect 59.94 
> vs
> 60 Hz. In addition, some of the older Analog Devices devices didn't have the
> resolution to detect the difference.
>
> So I always held off a bit with defining exactly how to do this since I had
> no experience with it.
>
> My question to you is: can you reliably detect the difference between 60 and 
> 59.94
> Hz and between 24 and 23.976 Hz by just the measured pixelclock?
>
> You need to test this with different sources, not just signal generators. You
> probably get a range of pixelclock values for the same framerate for different
> sources, since each source has their own clock.

I will have to conduct more tests to confirm but the expected
resolution is more than enough to detect 1000/1001 changes.

>
> My preference would be to extend query_dv_timings a bit for this:
>
> 
> Add a flag V4L2_DV_FL_CAN_DETECT_REDUCED_FPS. If set, then the hw can detect 
> the
> difference between regular fps and 1000/1001 fps. Note: this is only valid for
> timings of VIC codes with the V4L2_DV_FL_CAN_REDUCE_FPS flag set.

Where should we set the flag? In v4l2_dv_timings_cap?

>
> Allow V4L2_DV_FL_REDUCED_FPS to be used for receivers if 
> V4L2_DV_FL_CAN_DETECT_REDUCED_FPS
> is set.
>
> For standard VIC codes the pixelclock returned by query_dv_timings is that of 
> the
> corresponding VIC timing, not what is measured. This will ensure fixed fps 
> values
>
> g_parm should calculate the fps based on the v4l2_bt_timings struct, looking 
> at the
> REDUCES_FPS flags.
>
> For those receivers that cannot detect the difference, the fps will be 
> 24/30/60 Hz,
> for those that can detect the difference g_parm can check if both 
> V4L2_DV_FL_CAN_DETECT_REDUCED_FPS
> and V4L2_DV_FL_REDUCED_FPS are set and reduce the fps by 1000/1001.
> 
>
> If your hw can reliably detect the difference, then now is a good time to 
> close
> this gap in the DV_TIMINGS API.

Sounds nice :) Let me conduct more tests first and I will try to
make the patch.

Best regards,
Jose Miguel Abreu

>
> Regards,
>
>   Hans

[PATCH v3 14/27] rcar-vin: move media bus configuration to struct rvin_info

[Niklas Söderlund]

Bus configuration will once the driver is extended to to support Gen3
contain information not specific to only the directly connected parallel
subdevice. Move it to struct rvin_info to show it's not always coupled
to the parallel subdevice.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 14 +++---
 drivers/media/platform/rcar-vin/rcar-dma.c  | 11 ++-
 drivers/media/platform/rcar-vin/rcar-v4l2.c |  2 +-
 drivers/media/platform/rcar-vin/rcar-vin.h  |  9 -
 4 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 998617711f1ad045..ed99b1abb99e9ef9 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -45,15 +45,15 @@ static int rvin_find_pad(struct v4l2_subdev *sd, int 
direction)
return -EINVAL;
 }
 
-static bool rvin_mbus_supported(struct rvin_graph_entity *entity)
+static bool rvin_mbus_supported(struct rvin_dev *vin)
 {
-   struct v4l2_subdev *sd = entity->subdev;
+   struct v4l2_subdev *sd = vin->digital.subdev;
struct v4l2_subdev_mbus_code_enum code = {
.which = V4L2_SUBDEV_FORMAT_ACTIVE,
};
 
code.index = 0;
-   code.pad = entity->source_pad;
+   code.pad = vin->digital.source_pad;
while (!v4l2_subdev_call(sd, pad, enum_mbus_code, NULL, )) {
code.index++;
switch (code.code) {
@@ -61,7 +61,7 @@ static bool rvin_mbus_supported(struct rvin_graph_entity 
*entity)
case MEDIA_BUS_FMT_UYVY8_2X8:
case MEDIA_BUS_FMT_UYVY10_2X10:
case MEDIA_BUS_FMT_RGB888_1X24:
-   entity->code = code.code;
+   vin->code = code.code;
return true;
default:
break;
@@ -77,14 +77,14 @@ static int rvin_digital_notify_complete(struct 
v4l2_async_notifier *notifier)
int ret;
 
/* Verify subdevices mbus format */
-   if (!rvin_mbus_supported(>digital)) {
+   if (!rvin_mbus_supported(vin)) {
vin_err(vin, "Unsupported media bus format for %s\n",
vin->digital.subdev->name);
return -EINVAL;
}
 
vin_dbg(vin, "Found media bus format for %s: %d\n",
-   vin->digital.subdev->name, vin->digital.code);
+   vin->digital.subdev->name, vin->code);
 
ret = v4l2_device_register_subdev_nodes(>v4l2_dev);
if (ret < 0) {
@@ -201,7 +201,7 @@ static int rvin_digital_graph_parse(struct rvin_dev *vin)
}
of_node_put(np);
 
-   ret = rvin_digitial_parse_v4l2(vin, ep, >digital.mbus_cfg);
+   ret = rvin_digitial_parse_v4l2(vin, ep, >mbus_cfg);
of_node_put(ep);
if (ret)
return ret;
diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index ef029e4c7882322e..2931ba7998709307 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -634,7 +634,7 @@ static int rvin_setup(struct rvin_dev *vin)
/*
 * Input interface
 */
-   switch (vin->digital.code) {
+   switch (vin->code) {
case MEDIA_BUS_FMT_YUYV8_1X16:
/* BT.601/BT.1358 16bit YCbCr422 */
vnmc |= VNMC_INF_YUV16;
@@ -642,7 +642,7 @@ static int rvin_setup(struct rvin_dev *vin)
break;
case MEDIA_BUS_FMT_UYVY8_2X8:
/* BT.656 8bit YCbCr422 or BT.601 8bit YCbCr422 */
-   vnmc |= vin->digital.mbus_cfg.type == V4L2_MBUS_BT656 ?
+   vnmc |= vin->mbus_cfg.type == V4L2_MBUS_BT656 ?
VNMC_INF_YUV8_BT656 : VNMC_INF_YUV8_BT601;
input_is_yuv = true;
break;
@@ -651,7 +651,7 @@ static int rvin_setup(struct rvin_dev *vin)
break;
case MEDIA_BUS_FMT_UYVY10_2X10:
/* BT.656 10bit YCbCr422 or BT.601 10bit YCbCr422 */
-   vnmc |= vin->digital.mbus_cfg.type == V4L2_MBUS_BT656 ?
+   vnmc |= vin->mbus_cfg.type == V4L2_MBUS_BT656 ?
VNMC_INF_YUV10_BT656 : VNMC_INF_YUV10_BT601;
input_is_yuv = true;
break;
@@ -663,11 +663,11 @@ static int rvin_setup(struct rvin_dev *vin)
dmr2 = VNDMR2_FTEV | VNDMR2_VLV(1);
 
/* Hsync Signal Polarity Select */
-   if (!(vin->digital.mbus_cfg.flags & V4L2_MBUS_HSYNC_ACTIVE_LOW))
+   if (!(vin->mbus_cfg.flags & V4L2_MBUS_HSYNC_ACTIVE_LOW))
dmr2 |= VNDMR2_HPS;
 
/* Vsync Signal Polarity Select */
-   if (!(vin->digital.mbus_cfg.flags & V4L2_MBUS_VSYNC_ACTIVE_LOW))
+   if (!(vin->mbus_cfg.flags & V4L2_MBUS_VSYNC_ACTIVE_LOW))
dmr2 |= VNDMR2_VPS;
 
  

[PATCH 02/16] rcar-vin: use rvin_reset_format() in S_DV_TIMINGS

[Niklas Söderlund]

Use rvin_reset_format() in rvin_s_dv_timings() instead of just resetting
a few fields. This fixes an issue where the field format was not
properly set after S_DV_TIMINGS.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 69bc4cfea6a8aeb5..7ca27599b9982ffc 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -573,12 +573,8 @@ static int rvin_s_dv_timings(struct file *file, void 
*priv_fh,
if (ret)
return ret;
 
-   vin->source.width = timings->bt.width;
-   vin->source.height = timings->bt.height;
-   vin->format.width = timings->bt.width;
-   vin->format.height = timings->bt.height;
-
-   return 0;
+   /* Changing the timings will change the width/height */
+   return rvin_reset_format(vin);
 }
 
 static int rvin_g_dv_timings(struct file *file, void *priv_fh,
-- 
2.12.0

[PATCH 08/16] rcar-vin: use pad information when verifying media bus format

[Niklas Söderlund]

Use information about pad index when enumerating mbus codes.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index d7aba15f6761259b..c4d4f112da0c9d45 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -53,6 +53,7 @@ static bool rvin_mbus_supported(struct rvin_graph_entity 
*entity)
};
 
code.index = 0;
+   code.pad = entity->source_pad;
while (!v4l2_subdev_call(sd, pad, enum_mbus_code, NULL, )) {
code.index++;
switch (code.code) {
-- 
2.12.0

[PATCH 12/16] rcar-vin: allow switch between capturing modes when stalling

[Niklas Söderlund]

If userspace can't feed the driver with buffers as fast as the driver
consumes them the driver will stop video capturing and wait for more
buffers from userspace, the driver is stalled. Once it have been feed
one or more free buffers it will recover from the stall and resume
capturing.

Instead of of continue to capture using the same capture mode as before
the stall allow the driver to choose between single and continuous mode
base on free buffer availability. Do this by stopping capturing when the
driver becomes stalled and restart capturing once it continues. By doing
this the capture mode will be evaluated each time the driver is
recovering from a stall.

This behavior is needed to fix a bug where continuous capturing mode is
used, userspace is about to stop the stream and is waiting for the last
buffers to be returned from the driver and is not queuing any new
buffers. In this case the driver becomes stalled when there are only 3
buffers remaining streaming will never resume since the driver is
waiting for userspace to feed it more buffers before it can continue
streaming.  With this fix the driver will then switch to single capture
mode for the last 3 buffers and a deadlock is avoided. The issue can be
demonstrated using yavta.

$ yavta -f RGB565 -s 640x480 -n 4 --capture=10  /dev/video22
Device /dev/video22 opened.
Device `R_Car_VIN' on `platform:e6ef1000.video' (driver 'rcar_vin') supports 
video, capture, without mplanes.
Video format set: RGB565 (50424752) 640x480 (stride 1280) field interlaced 
buffer size 614400
Video format: RGB565 (50424752) 640x480 (stride 1280) field interlaced buffer 
size 614400
4 buffers requested.
length: 614400 offset: 0 timestamp type/source: mono/EoF
Buffer 0/0 mapped at address 0xb6cc7000.
length: 614400 offset: 614400 timestamp type/source: mono/EoF
Buffer 1/0 mapped at address 0xb6c31000.
length: 614400 offset: 1228800 timestamp type/source: mono/EoF
Buffer 2/0 mapped at address 0xb6b9b000.
length: 614400 offset: 1843200 timestamp type/source: mono/EoF
Buffer 3/0 mapped at address 0xb6b05000.
0 (0) [-] interlaced 0 614400 B 38.240285 38.240303 12.421 fps ts mono/EoF
1 (1) [-] interlaced 1 614400 B 38.282329 38.282346 23.785 fps ts mono/EoF
2 (2) [-] interlaced 2 614400 B 38.322324 38.322338 25.003 fps ts mono/EoF
3 (3) [-] interlaced 3 614400 B 38.362318 38.362333 25.004 fps ts mono/EoF
4 (0) [-] interlaced 4 614400 B 38.402313 38.402328 25.003 fps ts mono/EoF
5 (1) [-] interlaced 5 614400 B 38.442307 38.442321 25.004 fps ts mono/EoF
6 (2) [-] interlaced 6 614400 B 38.482301 38.482316 25.004 fps ts mono/EoF
7 (3) [-] interlaced 7 614400 B 38.522295 38.522312 25.004 fps ts mono/EoF
8 (0) [-] interlaced 8 614400 B 38.562290 38.562306 25.003 fps ts mono/EoF


This fix also allow the driver to switch to single capture mode if
userspace don't feed it buffers fast enough. Or the other way around, if
userspace suddenly feeds the driver buffers faster it can switch to
continues capturing mode.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-dma.c | 22 +-
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index f7776592b9a13d41..bd1ccb70ae2bc47e 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -428,6 +428,8 @@ static int rvin_capture_start(struct rvin_dev *vin)
 
rvin_capture_on(vin);
 
+   vin->state = RUNNING;
+
return 0;
 }
 
@@ -906,7 +908,7 @@ static irqreturn_t rvin_irq(int irq, void *data)
struct rvin_dev *vin = data;
u32 int_status, vnms;
int slot;
-   unsigned int sequence, handled = 0;
+   unsigned int i, sequence, handled = 0;
unsigned long flags;
 
spin_lock_irqsave(>qlock, flags);
@@ -968,8 +970,20 @@ static irqreturn_t rvin_irq(int irq, void *data)
 * the VnMBm registers.
 */
if (vin->continuous) {
-   rvin_capture_off(vin);
+   rvin_capture_stop(vin);
vin_dbg(vin, "IRQ %02d: hw not ready stop\n", sequence);
+
+   /* Maybe we can continue in single capture mode */
+   for (i = 0; i < HW_BUFFER_NUM; i++) {
+   if (vin->queue_buf[i]) {
+   list_add(to_buf_list(vin->queue_buf[i]),
+>buf_list);
+   vin->queue_buf[i] = NULL;
+   }
+   }
+
+   if (!list_empty(>buf_list))
+   rvin_capture_start(vin);
}
} else {
/*
@@ -1054,8 +1068,7 @@ static void rvin_buffer_queue(struct vb2_buffer *vb)
 * capturing if HW is ready to 

[PATCH 05/16] rcar-vin: move subdev source and sink pad index to rvin_graph_entity

[Niklas Söderlund]

It makes more sens to store the sink and source pads in struct
rvin_graph_entity since that contains other subdevice related
information.

The data type to store pad information in is unsigned int and not int,
change this. While we are at it drop the _idx suffix from the names,
this never made sens.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 20 ++--
 drivers/media/platform/rcar-vin/rcar-vin.h  |  9 +
 2 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 7be52c2036bb35fc..1a75191539b0e7d7 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -111,7 +111,7 @@ static int rvin_reset_format(struct rvin_dev *vin)
struct v4l2_mbus_framefmt *mf = 
int ret;
 
-   fmt.pad = vin->src_pad_idx;
+   fmt.pad = vin->digital.source_pad;
 
ret = v4l2_subdev_call(vin_to_source(vin), pad, get_fmt, NULL, );
if (ret)
@@ -178,7 +178,7 @@ static int __rvin_try_format_source(struct rvin_dev *vin,
if (pad_cfg == NULL)
return -ENOMEM;
 
-   format.pad = vin->src_pad_idx;
+   format.pad = vin->digital.source_pad;
 
field = pix->field;
 
@@ -559,7 +559,7 @@ static int rvin_enum_dv_timings(struct file *file, void 
*priv_fh,
if (timings->pad)
return -EINVAL;
 
-   timings->pad = vin->sink_pad_idx;
+   timings->pad = vin->digital.sink_pad;
 
ret = v4l2_subdev_call(sd, pad, enum_dv_timings, timings);
 
@@ -611,7 +611,7 @@ static int rvin_dv_timings_cap(struct file *file, void 
*priv_fh,
if (cap->pad)
return -EINVAL;
 
-   cap->pad = vin->sink_pad_idx;
+   cap->pad = vin->digital.sink_pad;
 
ret = v4l2_subdev_call(sd, pad, dv_timings_cap, cap);
 
@@ -629,7 +629,7 @@ static int rvin_g_edid(struct file *file, void *fh, struct 
v4l2_edid *edid)
if (edid->pad)
return -EINVAL;
 
-   edid->pad = vin->sink_pad_idx;
+   edid->pad = vin->digital.sink_pad;
 
ret = v4l2_subdev_call(sd, pad, get_edid, edid);
 
@@ -647,7 +647,7 @@ static int rvin_s_edid(struct file *file, void *fh, struct 
v4l2_edid *edid)
if (edid->pad)
return -EINVAL;
 
-   edid->pad = vin->sink_pad_idx;
+   edid->pad = vin->digital.sink_pad;
 
ret = v4l2_subdev_call(sd, pad, set_edid, edid);
 
@@ -920,19 +920,19 @@ int rvin_v4l2_probe(struct rvin_dev *vin)
vdev->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING |
V4L2_CAP_READWRITE;
 
-   vin->src_pad_idx = 0;
+   vin->digital.source_pad = 0;
for (pad_idx = 0; pad_idx < sd->entity.num_pads; pad_idx++)
if (sd->entity.pads[pad_idx].flags == MEDIA_PAD_FL_SOURCE)
break;
if (pad_idx >= sd->entity.num_pads)
return -EINVAL;
 
-   vin->src_pad_idx = pad_idx;
+   vin->digital.source_pad = pad_idx;
 
-   vin->sink_pad_idx = 0;
+   vin->digital.sink_pad = 0;
for (pad_idx = 0; pad_idx < sd->entity.num_pads; pad_idx++)
if (sd->entity.pads[pad_idx].flags == MEDIA_PAD_FL_SINK) {
-   vin->sink_pad_idx = pad_idx;
+   vin->digital.sink_pad = pad_idx;
break;
}
 
diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h 
b/drivers/media/platform/rcar-vin/rcar-vin.h
index 727e215c08718eb9..9bfb5a7c4dc4f215 100644
--- a/drivers/media/platform/rcar-vin/rcar-vin.h
+++ b/drivers/media/platform/rcar-vin/rcar-vin.h
@@ -74,6 +74,8 @@ struct rvin_video_format {
  * @subdev:subdevice matched using async framework
  * @code:  Media bus format from source
  * @mbus_cfg:  Media bus format from DT
+ * @source_pad:source pad of remote subdevice
+ * @sink_pad:  sink pad of remote subdevice
  */
 struct rvin_graph_entity {
struct v4l2_async_subdev asd;
@@ -81,6 +83,9 @@ struct rvin_graph_entity {
 
u32 code;
struct v4l2_mbus_config mbus_cfg;
+
+   unsigned int source_pad;
+   unsigned int sink_pad;
 };
 
 /**
@@ -91,8 +96,6 @@ struct rvin_graph_entity {
  *
  * @vdev:  V4L2 video device associated with VIN
  * @v4l2_dev:  V4L2 device
- * @src_pad_idx:   source pad index for media controller drivers
- * @sink_pad_idx:  sink pad index for media controller drivers
  * @ctrl_handler:  V4L2 control handler
  * @notifier:  V4L2 asynchronous subdevs notifier
  * @digital:   entity in the DT for local digital subdevice
@@ -121,8 +124,6 @@ struct rvin_dev {
 
struct video_device vdev;
struct v4l2_device v4l2_dev;
-   int src_pad_idx;
-   int sink_pad_idx;
struct v4l2_ctrl_handler ctrl_handler;
struct 

[PATCH 07/16] rcar-vin: move pad lookup to async bound handler

[Niklas Söderlund]

Information about pads will be needed when enumerating the media bus
codes in the async complete handler which is run before
rvin_v4l2_probe(). Move the pad lookup to the async bound handler so
they are available when needed.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 32 -
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 24 --
 2 files changed, 31 insertions(+), 25 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 098a0b1cc10a26ba..d7aba15f6761259b 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -31,6 +31,20 @@
 
 #define notifier_to_vin(n) container_of(n, struct rvin_dev, notifier)
 
+static int rvin_find_pad(struct v4l2_subdev *sd, int direction)
+{
+   unsigned int pad;
+
+   if (sd->entity.num_pads <= 1)
+   return 0;
+
+   for (pad = 0; pad < sd->entity.num_pads; pad++)
+   if (sd->entity.pads[pad].flags & direction)
+   return pad;
+
+   return -EINVAL;
+}
+
 static bool rvin_mbus_supported(struct rvin_graph_entity *entity)
 {
struct v4l2_subdev *sd = entity->subdev;
@@ -101,12 +115,28 @@ static int rvin_digital_notify_bound(struct 
v4l2_async_notifier *notifier,
 struct v4l2_async_subdev *asd)
 {
struct rvin_dev *vin = notifier_to_vin(notifier);
+   int ret;
 
v4l2_set_subdev_hostdata(subdev, vin);
 
if (vin->digital.asd.match.of.node == subdev->dev->of_node) {
-   vin_dbg(vin, "bound digital subdev %s\n", subdev->name);
+   /* Find surce and sink pad of remote subdevice */
+
+   ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SOURCE);
+   if (ret < 0)
+   return ret;
+   vin->digital.source_pad = ret;
+
+   ret = rvin_find_pad(subdev, MEDIA_PAD_FL_SINK);
+   if (ret < 0)
+   return ret;
+   vin->digital.sink_pad = ret;
+
vin->digital.subdev = subdev;
+
+   vin_dbg(vin, "bound subdev %s source pad: %d sink pad: %d\n",
+   subdev->name, vin->digital.source_pad,
+   vin->digital.sink_pad);
return 0;
}
 
diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index ce29a21888da48d5..be6f41bf82ac3bc5 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -870,20 +870,6 @@ static void rvin_notify(struct v4l2_subdev *sd,
}
 }
 
-static int rvin_find_pad(struct v4l2_subdev *sd, int direction)
-{
-   unsigned int pad;
-
-   if (sd->entity.num_pads <= 1)
-   return 0;
-
-   for (pad = 0; pad < sd->entity.num_pads; pad++)
-   if (sd->entity.pads[pad].flags & direction)
-   return pad;
-
-   return -EINVAL;
-}
-
 int rvin_v4l2_probe(struct rvin_dev *vin)
 {
struct video_device *vdev = >vdev;
@@ -934,16 +920,6 @@ int rvin_v4l2_probe(struct rvin_dev *vin)
vdev->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING |
V4L2_CAP_READWRITE;
 
-   ret = rvin_find_pad(sd, MEDIA_PAD_FL_SOURCE);
-   if (ret < 0)
-   return ret;
-   vin->digital.source_pad = ret;
-
-   ret = rvin_find_pad(sd, MEDIA_PAD_FL_SINK);
-   if (ret < 0)
-   return ret;
-   vin->digital.sink_pad = ret;
-
vin->format.pixelformat = RVIN_DEFAULT_FORMAT;
rvin_reset_format(vin);
 
-- 
2.12.0

[PATCH 13/16] rcar-vin: refactor and fold in function after stall handling rework

[Niklas Söderlund]

With the driver stopping and starting the stream each time the driver is
stalled rvin_capture_off() can be folded in to the only caller.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-dma.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index bd1ccb70ae2bc47e..c5fa176ac9d8cc4a 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -396,12 +396,6 @@ static void rvin_capture_on(struct rvin_dev *vin)
rvin_write(vin, VNFC_S_FRAME, VNFC_REG);
 }
 
-static void rvin_capture_off(struct rvin_dev *vin)
-{
-   /* Set continuous & single transfer off */
-   rvin_write(vin, 0, VNFC_REG);
-}
-
 static int rvin_capture_start(struct rvin_dev *vin)
 {
struct rvin_buffer *buf, *node;
@@ -435,7 +429,8 @@ static int rvin_capture_start(struct rvin_dev *vin)
 
 static void rvin_capture_stop(struct rvin_dev *vin)
 {
-   rvin_capture_off(vin);
+   /* Set continuous & single transfer off */
+   rvin_write(vin, 0, VNFC_REG);
 
/* Disable module */
rvin_write(vin, rvin_read(vin, VNMC_REG) & ~VNMC_ME, VNMC_REG);
-- 
2.12.0

[PATCH 10/16] rcar-vin: move functions which acts on hardware

[Niklas Söderlund]

This only moves whole structs, defines and functions around, no code is
changed inside any function. The reason for moving this code around is
to prepare for refactoring and fixing of a start/stop stream bug without
having to use forward declarations.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-dma.c | 181 ++---
 1 file changed, 90 insertions(+), 91 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index c37f7a2993fb5565..c10d75aa7e71d665 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -119,6 +119,15 @@
 #define VNDMR2_FTEV(1 << 17)
 #define VNDMR2_VLV(n)  ((n & 0xf) << 12)
 
+struct rvin_buffer {
+   struct vb2_v4l2_buffer vb;
+   struct list_head list;
+};
+
+#define to_buf_list(vb2_buffer) (_of(vb2_buffer, \
+  struct rvin_buffer, \
+  vb)->list)
+
 static void rvin_write(struct rvin_dev *vin, u32 value, u32 offset)
 {
iowrite32(value, vin->base + offset);
@@ -269,48 +278,6 @@ static int rvin_setup(struct rvin_dev *vin)
return 0;
 }
 
-static void rvin_capture_on(struct rvin_dev *vin)
-{
-   vin_dbg(vin, "Capture on in %s mode\n",
-   vin->continuous ? "continuous" : "single");
-
-   if (vin->continuous)
-   /* Continuous Frame Capture Mode */
-   rvin_write(vin, VNFC_C_FRAME, VNFC_REG);
-   else
-   /* Single Frame Capture Mode */
-   rvin_write(vin, VNFC_S_FRAME, VNFC_REG);
-}
-
-static void rvin_capture_off(struct rvin_dev *vin)
-{
-   /* Set continuous & single transfer off */
-   rvin_write(vin, 0, VNFC_REG);
-}
-
-static int rvin_capture_start(struct rvin_dev *vin)
-{
-   int ret;
-
-   rvin_crop_scale_comp(vin);
-
-   ret = rvin_setup(vin);
-   if (ret)
-   return ret;
-
-   rvin_capture_on(vin);
-
-   return 0;
-}
-
-static void rvin_capture_stop(struct rvin_dev *vin)
-{
-   rvin_capture_off(vin);
-
-   /* Disable module */
-   rvin_write(vin, rvin_read(vin, VNMC_REG) & ~VNMC_ME, VNMC_REG);
-}
-
 static void rvin_disable_interrupts(struct rvin_dev *vin)
 {
rvin_write(vin, 0, VNIE_REG);
@@ -377,6 +344,87 @@ static void rvin_set_slot_addr(struct rvin_dev *vin, int 
slot, dma_addr_t addr)
rvin_write(vin, offset, VNMB_REG(slot));
 }
 
+static bool rvin_fill_hw_slot(struct rvin_dev *vin, int slot)
+{
+   struct rvin_buffer *buf;
+   struct vb2_v4l2_buffer *vbuf;
+   dma_addr_t phys_addr_top;
+
+   if (vin->queue_buf[slot] != NULL)
+   return true;
+
+   if (list_empty(>buf_list))
+   return false;
+
+   vin_dbg(vin, "Filling HW slot: %d\n", slot);
+
+   /* Keep track of buffer we give to HW */
+   buf = list_entry(vin->buf_list.next, struct rvin_buffer, list);
+   vbuf = >vb;
+   list_del_init(to_buf_list(vbuf));
+   vin->queue_buf[slot] = vbuf;
+
+   /* Setup DMA */
+   phys_addr_top = vb2_dma_contig_plane_dma_addr(>vb2_buf, 0);
+   rvin_set_slot_addr(vin, slot, phys_addr_top);
+
+   return true;
+}
+
+static bool rvin_fill_hw(struct rvin_dev *vin)
+{
+   int slot, limit;
+
+   limit = vin->continuous ? HW_BUFFER_NUM : 1;
+
+   for (slot = 0; slot < limit; slot++)
+   if (!rvin_fill_hw_slot(vin, slot))
+   return false;
+   return true;
+}
+
+static void rvin_capture_on(struct rvin_dev *vin)
+{
+   vin_dbg(vin, "Capture on in %s mode\n",
+   vin->continuous ? "continuous" : "single");
+
+   if (vin->continuous)
+   /* Continuous Frame Capture Mode */
+   rvin_write(vin, VNFC_C_FRAME, VNFC_REG);
+   else
+   /* Single Frame Capture Mode */
+   rvin_write(vin, VNFC_S_FRAME, VNFC_REG);
+}
+
+static void rvin_capture_off(struct rvin_dev *vin)
+{
+   /* Set continuous & single transfer off */
+   rvin_write(vin, 0, VNFC_REG);
+}
+
+static int rvin_capture_start(struct rvin_dev *vin)
+{
+   int ret;
+
+   rvin_crop_scale_comp(vin);
+
+   ret = rvin_setup(vin);
+   if (ret)
+   return ret;
+
+   rvin_capture_on(vin);
+
+   return 0;
+}
+
+static void rvin_capture_stop(struct rvin_dev *vin)
+{
+   rvin_capture_off(vin);
+
+   /* Disable module */
+   rvin_write(vin, rvin_read(vin, VNMC_REG) & ~VNMC_ME, VNMC_REG);
+}
+
 /* 
-
  * Crop and Scaling Gen2
  */
@@ -839,55 +887,6 @@ void rvin_scale_try(struct rvin_dev *vin, struct 
v4l2_pix_format *pix,
 #define RVIN_TIMEOUT_MS 100
 #define RVIN_RETRIES 10
 
-struct rvin_buffer {
-   struct vb2_v4l2_buffer vb;
-   struct list_head list;

[PATCH 06/16] rcar-vin: refactor pad lookup code

[Niklas Söderlund]

The pad lookup code can be broken out to increase readability and to
reduce code duplication.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 38 +
 1 file changed, 23 insertions(+), 15 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 1a75191539b0e7d7..ce29a21888da48d5 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -870,11 +870,25 @@ static void rvin_notify(struct v4l2_subdev *sd,
}
 }
 
+static int rvin_find_pad(struct v4l2_subdev *sd, int direction)
+{
+   unsigned int pad;
+
+   if (sd->entity.num_pads <= 1)
+   return 0;
+
+   for (pad = 0; pad < sd->entity.num_pads; pad++)
+   if (sd->entity.pads[pad].flags & direction)
+   return pad;
+
+   return -EINVAL;
+}
+
 int rvin_v4l2_probe(struct rvin_dev *vin)
 {
struct video_device *vdev = >vdev;
struct v4l2_subdev *sd = vin_to_source(vin);
-   int pad_idx, ret;
+   int ret;
 
v4l2_set_subdev_hostdata(sd, vin);
 
@@ -920,21 +934,15 @@ int rvin_v4l2_probe(struct rvin_dev *vin)
vdev->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING |
V4L2_CAP_READWRITE;
 
-   vin->digital.source_pad = 0;
-   for (pad_idx = 0; pad_idx < sd->entity.num_pads; pad_idx++)
-   if (sd->entity.pads[pad_idx].flags == MEDIA_PAD_FL_SOURCE)
-   break;
-   if (pad_idx >= sd->entity.num_pads)
-   return -EINVAL;
-
-   vin->digital.source_pad = pad_idx;
+   ret = rvin_find_pad(sd, MEDIA_PAD_FL_SOURCE);
+   if (ret < 0)
+   return ret;
+   vin->digital.source_pad = ret;
 
-   vin->digital.sink_pad = 0;
-   for (pad_idx = 0; pad_idx < sd->entity.num_pads; pad_idx++)
-   if (sd->entity.pads[pad_idx].flags == MEDIA_PAD_FL_SINK) {
-   vin->digital.sink_pad = pad_idx;
-   break;
-   }
+   ret = rvin_find_pad(sd, MEDIA_PAD_FL_SINK);
+   if (ret < 0)
+   return ret;
+   vin->digital.sink_pad = ret;
 
vin->format.pixelformat = RVIN_DEFAULT_FORMAT;
rvin_reset_format(vin);
-- 
2.12.0

[PATCH 03/16] rcar-vin: fix how pads are handled for v4l2 subdevice operations

[Niklas Söderlund]

The rcar-vin driver only uses one pad, pad number 0.

- All v4l2 operations that did not check that the requested operation
  was for pad 0 have been updated with a check to enforce this.

- All v4l2 operations that stored (and later restore) the requested pad
  before substituting it for the subdevice pad number have been updated
  to not store the incoming pad and simply restore it to 0 after the
  subdevice operation is complete.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 7ca27599b9982ffc..610f59e2a9142622 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -550,14 +550,16 @@ static int rvin_enum_dv_timings(struct file *file, void 
*priv_fh,
 {
struct rvin_dev *vin = video_drvdata(file);
struct v4l2_subdev *sd = vin_to_source(vin);
-   int pad, ret;
+   int ret;
+
+   if (timings->pad)
+   return -EINVAL;
 
-   pad = timings->pad;
timings->pad = vin->sink_pad_idx;
 
ret = v4l2_subdev_call(sd, pad, enum_dv_timings, timings);
 
-   timings->pad = pad;
+   timings->pad = 0;
 
return ret;
 }
@@ -600,14 +602,16 @@ static int rvin_dv_timings_cap(struct file *file, void 
*priv_fh,
 {
struct rvin_dev *vin = video_drvdata(file);
struct v4l2_subdev *sd = vin_to_source(vin);
-   int pad, ret;
+   int ret;
+
+   if (cap->pad)
+   return -EINVAL;
 
-   pad = cap->pad;
cap->pad = vin->sink_pad_idx;
 
ret = v4l2_subdev_call(sd, pad, dv_timings_cap, cap);
 
-   cap->pad = pad;
+   cap->pad = 0;
 
return ret;
 }
@@ -616,17 +620,16 @@ static int rvin_g_edid(struct file *file, void *fh, 
struct v4l2_edid *edid)
 {
struct rvin_dev *vin = video_drvdata(file);
struct v4l2_subdev *sd = vin_to_source(vin);
-   int input, ret;
+   int ret;
 
if (edid->pad)
return -EINVAL;
 
-   input = edid->pad;
edid->pad = vin->sink_pad_idx;
 
ret = v4l2_subdev_call(sd, pad, get_edid, edid);
 
-   edid->pad = input;
+   edid->pad = 0;
 
return ret;
 }
@@ -635,17 +638,16 @@ static int rvin_s_edid(struct file *file, void *fh, 
struct v4l2_edid *edid)
 {
struct rvin_dev *vin = video_drvdata(file);
struct v4l2_subdev *sd = vin_to_source(vin);
-   int input, ret;
+   int ret;
 
if (edid->pad)
return -EINVAL;
 
-   input = edid->pad;
edid->pad = vin->sink_pad_idx;
 
ret = v4l2_subdev_call(sd, pad, set_edid, edid);
 
-   edid->pad = input;
+   edid->pad = 0;
 
return ret;
 }
-- 
2.12.0

[PATCH 04/16] rcar-vin: fix standard in input enumeration

[Niklas Söderlund]

If the subdevice supports dv_timings_cap the driver should not fill in
the standard.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 610f59e2a9142622..7be52c2036bb35fc 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -483,10 +483,14 @@ static int rvin_enum_input(struct file *file, void *priv,
return ret;
 
i->type = V4L2_INPUT_TYPE_CAMERA;
-   i->std = vin->vdev.tvnorms;
 
-   if (v4l2_subdev_has_op(sd, pad, dv_timings_cap))
+   if (v4l2_subdev_has_op(sd, pad, dv_timings_cap)) {
i->capabilities = V4L2_IN_CAP_DV_TIMINGS;
+   i->std = 0;
+   } else {
+   i->capabilities = V4L2_IN_CAP_STD;
+   i->std = vin->vdev.tvnorms;
+   }
 
strlcpy(i->name, "Camera", sizeof(i->name));
 
-- 
2.12.0

[PATCH 00/16] rcar-vin: fix issues with format and capturing

[Niklas Söderlund]

Hi,

This series fix a number of issues for the rcar-vin driver regarding 
format and capturing. It is based on top of v4.11-rc1 and is tested on 
Koelsch.

Parts of this series where previously part of '[PATCH 00/11] media: 
rcar-vin: fix OPS and format/pad index issues'. But after good reviews 
a large part of that series where dropped.

Niklas Söderlund (16):
  rcar-vin: reset bytesperline and sizeimage when resetting format
  rcar-vin: use rvin_reset_format() in S_DV_TIMINGS
  rcar-vin: fix how pads are handled for v4l2 subdevice operations
  rcar-vin: fix standard in input enumeration
  rcar-vin: move subdev source and sink pad index to rvin_graph_entity
  rcar-vin: refactor pad lookup code
  rcar-vin: move pad lookup to async bound handler
  rcar-vin: use pad information when verifying media bus format
  rcar-vin: decrease buffers needed to capture
  rcar-vin: move functions which acts on hardware
  rcar-vin: select capture mode based on free buffers
  rcar-vin: allow switch between capturing modes when stalling
  rcar-vin: refactor and fold in function after stall handling rework
  rcar-vin: make use of video_device_alloc() and video_device_release()
  rcar-vin: add missing error check to propagate error
  rcar-vin: fix bug in pixelformat selection

 drivers/media/platform/rcar-vin/rcar-core.c |  33 +++-
 drivers/media/platform/rcar-vin/rcar-dma.c  | 229 ++--
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 127 ---
 drivers/media/platform/rcar-vin/rcar-vin.h  |  11 +-
 4 files changed, 216 insertions(+), 184 deletions(-)

-- 
2.12.0

[PATCH 14/16] rcar-vin: make use of video_device_alloc() and video_device_release()

[Niklas Söderlund]

Make use of the helper functions video_device_alloc() and
video_device_release() to control the lifetime of the struct
video_device.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 44 -
 drivers/media/platform/rcar-vin/rcar-vin.h  |  2 +-
 2 files changed, 25 insertions(+), 21 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index be6f41bf82ac3bc5..c40f5bc3e3d26472 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -489,7 +489,7 @@ static int rvin_enum_input(struct file *file, void *priv,
i->std = 0;
} else {
i->capabilities = V4L2_IN_CAP_STD;
-   i->std = vin->vdev.tvnorms;
+   i->std = vin->vdev->tvnorms;
}
 
strlcpy(i->name, "Camera", sizeof(i->name));
@@ -752,8 +752,8 @@ static int rvin_initialize_device(struct file *file)
if (ret < 0)
return ret;
 
-   pm_runtime_enable(>vdev.dev);
-   ret = pm_runtime_resume(>vdev.dev);
+   pm_runtime_enable(>vdev->dev);
+   ret = pm_runtime_resume(>vdev->dev);
if (ret < 0 && ret != -ENOSYS)
goto eresume;
 
@@ -771,7 +771,7 @@ static int rvin_initialize_device(struct file *file)
 
return 0;
 esfmt:
-   pm_runtime_disable(>vdev.dev);
+   pm_runtime_disable(>vdev->dev);
 eresume:
rvin_power_off(vin);
 
@@ -823,8 +823,8 @@ static int rvin_release(struct file *file)
 * Then de-initialize hw module.
 */
if (fh_singular) {
-   pm_runtime_suspend(>vdev.dev);
-   pm_runtime_disable(>vdev.dev);
+   pm_runtime_suspend(>vdev->dev);
+   pm_runtime_disable(>vdev->dev);
rvin_power_off(vin);
}
 
@@ -846,13 +846,13 @@ static const struct v4l2_file_operations rvin_fops = {
 void rvin_v4l2_remove(struct rvin_dev *vin)
 {
v4l2_info(>v4l2_dev, "Removing %s\n",
- video_device_node_name(>vdev));
+ video_device_node_name(vin->vdev));
 
/* Checks internaly if handlers have been init or not */
v4l2_ctrl_handler_free(>ctrl_handler);
 
/* Checks internaly if vdev have been init or not */
-   video_unregister_device(>vdev);
+   video_unregister_device(vin->vdev);
 }
 
 static void rvin_notify(struct v4l2_subdev *sd,
@@ -863,7 +863,7 @@ static void rvin_notify(struct v4l2_subdev *sd,
 
switch (notification) {
case V4L2_DEVICE_NOTIFY_EVENT:
-   v4l2_event_queue(>vdev, arg);
+   v4l2_event_queue(vin->vdev, arg);
break;
default:
break;
@@ -872,7 +872,7 @@ static void rvin_notify(struct v4l2_subdev *sd,
 
 int rvin_v4l2_probe(struct rvin_dev *vin)
 {
-   struct video_device *vdev = >vdev;
+   struct video_device *vdev;
struct v4l2_subdev *sd = vin_to_source(vin);
int ret;
 
@@ -880,16 +880,18 @@ int rvin_v4l2_probe(struct rvin_dev *vin)
 
vin->v4l2_dev.notify = rvin_notify;
 
-   ret = v4l2_subdev_call(sd, video, g_tvnorms, >vdev.tvnorms);
+   vdev = video_device_alloc();
+
+   ret = v4l2_subdev_call(sd, video, g_tvnorms, >tvnorms);
if (ret < 0 && ret != -ENOIOCTLCMD && ret != -ENODEV)
return ret;
 
-   if (vin->vdev.tvnorms == 0) {
+   if (vdev->tvnorms == 0) {
/* Disable the STD API if there are no tvnorms defined */
-   v4l2_disable_ioctl(>vdev, VIDIOC_G_STD);
-   v4l2_disable_ioctl(>vdev, VIDIOC_S_STD);
-   v4l2_disable_ioctl(>vdev, VIDIOC_QUERYSTD);
-   v4l2_disable_ioctl(>vdev, VIDIOC_ENUMSTD);
+   v4l2_disable_ioctl(vdev, VIDIOC_G_STD);
+   v4l2_disable_ioctl(vdev, VIDIOC_S_STD);
+   v4l2_disable_ioctl(vdev, VIDIOC_QUERYSTD);
+   v4l2_disable_ioctl(vdev, VIDIOC_ENUMSTD);
}
 
/* Add the controls */
@@ -913,7 +915,7 @@ int rvin_v4l2_probe(struct rvin_dev *vin)
vdev->v4l2_dev = >v4l2_dev;
vdev->queue = >queue;
strlcpy(vdev->name, KBUILD_MODNAME, sizeof(vdev->name));
-   vdev->release = video_device_release_empty;
+   vdev->release = video_device_release;
vdev->ioctl_ops = _ioctl_ops;
vdev->lock = >lock;
vdev->ctrl_handler = >ctrl_handler;
@@ -923,16 +925,18 @@ int rvin_v4l2_probe(struct rvin_dev *vin)
vin->format.pixelformat = RVIN_DEFAULT_FORMAT;
rvin_reset_format(vin);
 
-   ret = video_register_device(>vdev, VFL_TYPE_GRABBER, -1);
+   ret = video_register_device(vdev, VFL_TYPE_GRABBER, -1);
if (ret) {
vin_err(vin, "Failed to register video device\n");
return ret;
}
 
-   video_set_drvdata(>vdev, vin);
+   

[PATCH 11/16] rcar-vin: select capture mode based on free buffers

[Niklas Söderlund]

Instead of selecting single or continuous capture mode based on how many
buffers userspace intends to give us select capture mode based on number
of free buffers we can allocate to hardware when the stream is started.

This change is a prerequisite to enable the driver to switch from
continuous to single capture mode (or the other way around) when the
driver is stalled by userspace not feeding it buffers as fast as it
consumes it.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-dma.c | 31 +++---
 1 file changed, 15 insertions(+), 16 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index c10d75aa7e71d665..f7776592b9a13d41 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -404,7 +404,21 @@ static void rvin_capture_off(struct rvin_dev *vin)
 
 static int rvin_capture_start(struct rvin_dev *vin)
 {
-   int ret;
+   struct rvin_buffer *buf, *node;
+   int bufs, ret;
+
+   /* Count number of free buffers */
+   bufs = 0;
+   list_for_each_entry_safe(buf, node, >buf_list, list)
+   bufs++;
+
+   /* Continuous capture requires more buffers then there are HW slots */
+   vin->continuous = bufs > HW_BUFFER_NUM;
+
+   if (!rvin_fill_hw(vin)) {
+   vin_err(vin, "HW not ready to start, not enough buffers 
available\n");
+   return -EINVAL;
+   }
 
rvin_crop_scale_comp(vin);
 
@@ -1061,22 +1075,7 @@ static int rvin_start_streaming(struct vb2_queue *vq, 
unsigned int count)
vin->state = RUNNING;
vin->sequence = 0;
 
-   /* Continuous capture requires more buffers then there are HW slots */
-   vin->continuous = count > HW_BUFFER_NUM;
-
-   /*
-* This should never happen but if we don't have enough
-* buffers for HW bail out
-*/
-   if (!rvin_fill_hw(vin)) {
-   vin_err(vin, "HW not ready to start, not enough buffers 
available\n");
-   ret = -EINVAL;
-   goto out;
-   }
-
ret = rvin_capture_start(vin);
-out:
-   /* Return all buffers if something went wrong */
if (ret) {
return_all_buffers(vin, VB2_BUF_STATE_QUEUED);
v4l2_subdev_call(sd, video, s_stream, 0);
-- 
2.12.0

[PATCH 15/16] rcar-vin: add missing error check to propagate error

[Niklas Söderlund]

The return value of __rvin_try_format_source is not checked, add a check
and propagate the error.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index c40f5bc3e3d26472..956092ba6ef9bc6f 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -208,6 +208,7 @@ static int __rvin_try_format(struct rvin_dev *vin,
 {
const struct rvin_video_format *info;
u32 rwidth, rheight, walign;
+   int ret;
 
/* Requested */
rwidth = pix->width;
@@ -235,7 +236,9 @@ static int __rvin_try_format(struct rvin_dev *vin,
pix->sizeimage = 0;
 
/* Limit to source capabilities */
-   __rvin_try_format_source(vin, which, pix, source);
+   ret = __rvin_try_format_source(vin, which, pix, source);
+   if (ret)
+   return ret;
 
switch (pix->field) {
case V4L2_FIELD_TOP:
-- 
2.12.0

[PATCH 01/16] rcar-vin: reset bytesperline and sizeimage when resetting format

[Niklas Söderlund]

These two where forgotten when refactoring the format reset code. If
they are not also reset at the same time as width and height the format
returned from G_FMT will not match reality.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 2bbe6d495fa634da..69bc4cfea6a8aeb5 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -151,6 +151,9 @@ static int rvin_reset_format(struct rvin_dev *vin)
 
rvin_reset_crop_compose(vin);
 
+   vin->format.bytesperline = rvin_format_bytesperline(>format);
+   vin->format.sizeimage = rvin_format_sizeimage(>format);
+
return 0;
 }
 
-- 
2.12.0

[PATCH 16/16] rcar-vin: fix bug in pixelformat selection

[Niklas Söderlund]

If the requested pixelformat is not supported only revert to the current
pixelformat, do not revert the entire format. Also if the pixelformat
needs to be reverted the pixel information needs to be fetched once
more.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 956092ba6ef9bc6f..27b7733e96afe3e9 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -226,9 +226,8 @@ static int __rvin_try_format(struct rvin_dev *vin,
if (!info) {
vin_dbg(vin, "Format %x not found, keeping %x\n",
pix->pixelformat, vin->format.pixelformat);
-   *pix = vin->format;
-   pix->width = rwidth;
-   pix->height = rheight;
+   pix->pixelformat = vin->format.pixelformat;
+   info = rvin_format_from_pixel(pix->pixelformat);
}
 
/* Always recalculate */
-- 
2.12.0

[PATCH 09/16] rcar-vin: decrease buffers needed to capture

[Niklas Söderlund]

It's possible to grab frames using only one buffer, this should never
have been set to anything else then 1.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-dma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index 9ccd5ff55e192514..c37f7a2993fb5565 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -1183,7 +1183,7 @@ int rvin_dma_probe(struct rvin_dev *vin, int irq)
q->ops = _qops;
q->mem_ops = _dma_contig_memops;
q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
-   q->min_buffers_needed = 2;
+   q->min_buffers_needed = 1;
q->dev = vin->dev;
 
ret = vb2_queue_init(q);
-- 
2.12.0

[PATCH v3 06/27] rcar-vin: move max width and height information to chip information

[Niklas Söderlund]

On Gen3 the max supported width and height will be different from Gen2.
Move the limits to the struct chip_info to prepare for Gen3 support.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 6 ++
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 6 ++
 drivers/media/platform/rcar-vin/rcar-vin.h  | 6 ++
 3 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index ec1eb723d401fda2..998617711f1ad045 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -257,14 +257,20 @@ static int rvin_digital_graph_init(struct rvin_dev *vin)
 
 static const struct rvin_info rcar_info_h1 = {
.chip = RCAR_H1,
+   .max_width = 2048,
+   .max_height = 2048,
 };
 
 static const struct rvin_info rcar_info_m1 = {
.chip = RCAR_M1,
+   .max_width = 2048,
+   .max_height = 2048,
 };
 
 static const struct rvin_info rcar_info_gen2 = {
.chip = RCAR_GEN2,
+   .max_width = 2048,
+   .max_height = 2048,
 };
 
 static const struct of_device_id rvin_of_id_table[] = {
diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 7deca15d22b4d6e3..1b364f359ff4b5ed 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -23,8 +23,6 @@
 #include "rcar-vin.h"
 
 #define RVIN_DEFAULT_FORMATV4L2_PIX_FMT_YUYV
-#define RVIN_MAX_WIDTH 2048
-#define RVIN_MAX_HEIGHT2048
 
 /* 
-
  * Format Conversions
@@ -264,8 +262,8 @@ static int __rvin_try_format(struct rvin_dev *vin,
walign = vin->format.pixelformat == V4L2_PIX_FMT_NV16 ? 5 : 1;
 
/* Limit to VIN capabilities */
-   v4l_bound_align_image(>width, 2, RVIN_MAX_WIDTH, walign,
- >height, 4, RVIN_MAX_HEIGHT, 2, 0);
+   v4l_bound_align_image(>width, 2, vin->info->max_width, walign,
+ >height, 4, vin->info->max_height, 2, 0);
 
pix->bytesperline = max_t(u32, pix->bytesperline,
  rvin_format_bytesperline(pix));
diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h 
b/drivers/media/platform/rcar-vin/rcar-vin.h
index c07b4a6893440a6a..32d9d130dd6e2e44 100644
--- a/drivers/media/platform/rcar-vin/rcar-vin.h
+++ b/drivers/media/platform/rcar-vin/rcar-vin.h
@@ -91,9 +91,15 @@ struct rvin_graph_entity {
 /**
  * struct rvin_info- Information about the particular VIN implementation
  * @chip:  type of VIN chip
+ *
+ * max_width:  max input width the VIN supports
+ * max_height: max input height the VIN supports
  */
 struct rvin_info {
enum chip_id chip;
+
+   unsigned int max_width;
+   unsigned int max_height;
 };
 
 /**
-- 
2.12.0

[PATCH v3 12/27] rcar-vin: read subdevice format for crop only when needed

[Niklas Söderlund]

Instead of caching the subdevice format each time the video device
format is set read it directly when its needed. As it turns out the
format is only needed when figuring out the max rectangle for cropping.

This simplify the code and makes it clearer what the source format is
used for.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 76 -
 drivers/media/platform/rcar-vin/rcar-vin.h  | 12 -
 2 files changed, 42 insertions(+), 46 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 919040e40aec60f6..80421421625e6f6f 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -90,6 +90,24 @@ static u32 rvin_format_sizeimage(struct v4l2_pix_format *pix)
  * V4L2
  */
 
+static int rvin_get_sd_format(struct rvin_dev *vin, struct v4l2_pix_format 
*pix)
+{
+   struct v4l2_subdev_format fmt = {
+   .which = V4L2_SUBDEV_FORMAT_ACTIVE,
+   };
+   int ret;
+
+   fmt.pad = vin->digital.source_pad;
+
+   ret = v4l2_subdev_call(vin_to_source(vin), pad, get_fmt, NULL, );
+   if (ret)
+   return ret;
+
+   v4l2_fill_pix_format(pix, );
+
+   return 0;
+}
+
 static int rvin_reset_format(struct rvin_dev *vin)
 {
struct v4l2_subdev_format fmt = {
@@ -151,9 +169,7 @@ static int rvin_reset_format(struct rvin_dev *vin)
 }
 
 static int __rvin_try_format_source(struct rvin_dev *vin,
-   u32 which,
-   struct v4l2_pix_format *pix,
-   struct rvin_source_fmt *source)
+   u32 which, struct v4l2_pix_format *pix)
 {
struct v4l2_subdev *sd;
struct v4l2_subdev_pad_config *pad_cfg;
@@ -186,25 +202,15 @@ static int __rvin_try_format_source(struct rvin_dev *vin,
v4l2_fill_pix_format(pix, );
 
pix->field = field;
-
-   source->width = pix->width;
-   source->height = pix->height;
-
pix->width = width;
pix->height = height;
-
-   vin_dbg(vin, "Source resolution: %ux%u\n", source->width,
-   source->height);
-
 done:
v4l2_subdev_free_pad_config(pad_cfg);
return ret;
 }
 
 static int __rvin_try_format(struct rvin_dev *vin,
-u32 which,
-struct v4l2_pix_format *pix,
-struct rvin_source_fmt *source)
+u32 which, struct v4l2_pix_format *pix)
 {
const struct rvin_video_format *info;
u32 walign;
@@ -231,7 +237,7 @@ static int __rvin_try_format(struct rvin_dev *vin,
pix->sizeimage = 0;
 
/* Limit to source capabilities */
-   ret = __rvin_try_format_source(vin, which, pix, source);
+   ret = __rvin_try_format_source(vin, which, pix);
if (ret)
return ret;
 
@@ -240,7 +246,6 @@ static int __rvin_try_format(struct rvin_dev *vin,
case V4L2_FIELD_BOTTOM:
case V4L2_FIELD_ALTERNATE:
pix->height /= 2;
-   source->height /= 2;
break;
case V4L2_FIELD_NONE:
case V4L2_FIELD_INTERLACED_TB:
@@ -292,30 +297,23 @@ static int rvin_try_fmt_vid_cap(struct file *file, void 
*priv,
struct v4l2_format *f)
 {
struct rvin_dev *vin = video_drvdata(file);
-   struct rvin_source_fmt source;
 
-   return __rvin_try_format(vin, V4L2_SUBDEV_FORMAT_TRY, >fmt.pix,
-);
+   return __rvin_try_format(vin, V4L2_SUBDEV_FORMAT_TRY, >fmt.pix);
 }
 
 static int rvin_s_fmt_vid_cap(struct file *file, void *priv,
  struct v4l2_format *f)
 {
struct rvin_dev *vin = video_drvdata(file);
-   struct rvin_source_fmt source;
int ret;
 
if (vb2_is_busy(>queue))
return -EBUSY;
 
-   ret = __rvin_try_format(vin, V4L2_SUBDEV_FORMAT_ACTIVE, >fmt.pix,
-   );
+   ret = __rvin_try_format(vin, V4L2_SUBDEV_FORMAT_ACTIVE, >fmt.pix);
if (ret)
return ret;
 
-   vin->source.width = source.width;
-   vin->source.height = source.height;
-
vin->format = f->fmt.pix;
 
return 0;
@@ -346,6 +344,8 @@ static int rvin_g_selection(struct file *file, void *fh,
struct v4l2_selection *s)
 {
struct rvin_dev *vin = video_drvdata(file);
+   struct v4l2_pix_format pix;
+   int ret;
 
if (s->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
return -EINVAL;
@@ -353,9 +353,12 @@ static int rvin_g_selection(struct file *file, void *fh,
switch (s->target) {
case V4L2_SEL_TGT_CROP_BOUNDS:
case V4L2_SEL_TGT_CROP_DEFAULT:
+   ret = rvin_get_sd_format(vin, );
+ 

[PATCH v3 05/27] rcar-vin: move chip information to own struct

[Niklas Söderlund]

When Gen3 support is added to the driver more then chip id will be
different for the different Soc. To avoid a lot of if statements in the
code create a struct chip_info to contain this information.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 49 -
 drivers/media/platform/rcar-vin/rcar-v4l2.c |  3 +-
 drivers/media/platform/rcar-vin/rcar-vin.h  | 12 +--
 3 files changed, 53 insertions(+), 11 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index c4d4f112da0c9d45..ec1eb723d401fda2 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -255,14 +255,47 @@ static int rvin_digital_graph_init(struct rvin_dev *vin)
  * Platform Device Driver
  */
 
+static const struct rvin_info rcar_info_h1 = {
+   .chip = RCAR_H1,
+};
+
+static const struct rvin_info rcar_info_m1 = {
+   .chip = RCAR_M1,
+};
+
+static const struct rvin_info rcar_info_gen2 = {
+   .chip = RCAR_GEN2,
+};
+
 static const struct of_device_id rvin_of_id_table[] = {
-   { .compatible = "renesas,vin-r8a7794", .data = (void *)RCAR_GEN2 },
-   { .compatible = "renesas,vin-r8a7793", .data = (void *)RCAR_GEN2 },
-   { .compatible = "renesas,vin-r8a7791", .data = (void *)RCAR_GEN2 },
-   { .compatible = "renesas,vin-r8a7790", .data = (void *)RCAR_GEN2 },
-   { .compatible = "renesas,vin-r8a7779", .data = (void *)RCAR_H1 },
-   { .compatible = "renesas,vin-r8a7778", .data = (void *)RCAR_M1 },
-   { .compatible = "renesas,rcar-gen2-vin", .data = (void *)RCAR_GEN2 },
+   {
+   .compatible = "renesas,vin-r8a7794",
+   .data = _info_gen2,
+   },
+   {
+   .compatible = "renesas,vin-r8a7793",
+   .data = _info_gen2,
+   },
+   {
+   .compatible = "renesas,vin-r8a7791",
+   .data = _info_gen2,
+   },
+   {
+   .compatible = "renesas,vin-r8a7790",
+   .data = _info_gen2,
+   },
+   {
+   .compatible = "renesas,vin-r8a7779",
+   .data = _info_h1,
+   },
+   {
+   .compatible = "renesas,vin-r8a7778",
+   .data = _info_m1,
+   },
+   {
+   .compatible = "renesas,rcar-gen2-vin",
+   .data = _info_gen2,
+   },
{ },
 };
 MODULE_DEVICE_TABLE(of, rvin_of_id_table);
@@ -283,7 +316,7 @@ static int rcar_vin_probe(struct platform_device *pdev)
return -ENODEV;
 
vin->dev = >dev;
-   vin->chip = (enum chip_id)match->data;
+   vin->info = match->data;
 
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (mem == NULL)
diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 27b7733e96afe3e9..7deca15d22b4d6e3 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -272,7 +272,8 @@ static int __rvin_try_format(struct rvin_dev *vin,
pix->sizeimage = max_t(u32, pix->sizeimage,
   rvin_format_sizeimage(pix));
 
-   if (vin->chip == RCAR_M1 && pix->pixelformat == V4L2_PIX_FMT_XBGR32) {
+   if (vin->info->chip == RCAR_M1 &&
+   pix->pixelformat == V4L2_PIX_FMT_XBGR32) {
vin_err(vin, "pixel format XBGR32 not supported on M1\n");
return -EINVAL;
}
diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h 
b/drivers/media/platform/rcar-vin/rcar-vin.h
index 9454ef80bc2b3961..c07b4a6893440a6a 100644
--- a/drivers/media/platform/rcar-vin/rcar-vin.h
+++ b/drivers/media/platform/rcar-vin/rcar-vin.h
@@ -89,10 +89,18 @@ struct rvin_graph_entity {
 };
 
 /**
+ * struct rvin_info- Information about the particular VIN implementation
+ * @chip:  type of VIN chip
+ */
+struct rvin_info {
+   enum chip_id chip;
+};
+
+/**
  * struct rvin_dev - Renesas VIN device structure
  * @dev:   (OF) device
  * @base:  device I/O register space remapped to virtual memory
- * @chip:  type of VIN chip
+ * @info:  info about VIN instance
  *
  * @vdev:  V4L2 video device associated with VIN
  * @v4l2_dev:  V4L2 device
@@ -120,7 +128,7 @@ struct rvin_graph_entity {
 struct rvin_dev {
struct device *dev;
void __iomem *base;
-   enum chip_id chip;
+   const struct rvin_info *info;
 
struct video_device *vdev;
struct v4l2_device v4l2_dev;
-- 
2.12.0

[PATCH v3 13/27] rcar-vin: do not cut height in two for top, bottom or alternate fields

[Niklas Söderlund]

The height should not be cut in half for the format for top, bottom or
alternate fields settings. This was a mistake and it was made
visible by the scaling refactoring.

Correct behavior is that the user should request a frame size that fits
the half height frame reflected in the field setting. If not the VIN
will do it's best to scale the top or bottom to the requested format and
cropping and scaling do not work as expected.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 80421421625e6f6f..28b62a514bbb93a9 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -142,8 +142,6 @@ static int rvin_reset_format(struct rvin_dev *vin)
case V4L2_FIELD_TOP:
case V4L2_FIELD_BOTTOM:
case V4L2_FIELD_ALTERNATE:
-   vin->format.height /= 2;
-   break;
case V4L2_FIELD_NONE:
case V4L2_FIELD_INTERLACED_TB:
case V4L2_FIELD_INTERLACED_BT:
@@ -245,8 +243,6 @@ static int __rvin_try_format(struct rvin_dev *vin,
case V4L2_FIELD_TOP:
case V4L2_FIELD_BOTTOM:
case V4L2_FIELD_ALTERNATE:
-   pix->height /= 2;
-   break;
case V4L2_FIELD_NONE:
case V4L2_FIELD_INTERLACED_TB:
case V4L2_FIELD_INTERLACED_BT:
-- 
2.12.0

[PATCH v3 04/27] media: entity: Swap pads if route is checked from source to sink

[Niklas Söderlund]

From: Sakari Ailus 

This way the pads are always passed to the has_route() op sink pad first.
Makes sense.

Signed-off-by: Sakari Ailus 
Signed-off-by: Niklas Söderlund 
---
 drivers/media/media-entity.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index ccd991d2d3450ab3..f0386ddd7c92cc4e 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -256,6 +256,10 @@ bool media_entity_has_route(struct media_entity *entity, 
unsigned int pad0,
if (!entity->ops || !entity->ops->has_route)
return true;
 
+   if (entity->pads[pad0].flags & MEDIA_PAD_FL_SOURCE
+   && entity->pads[pad1].flags & MEDIA_PAD_FL_SINK)
+   swap(pad0, pad1);
+
return entity->ops->has_route(entity, pad0, pad1);
 }
 EXPORT_SYMBOL_GPL(media_entity_has_route);
-- 
2.12.0

[PATCH v3 08/27] rcar-vin: move functions regarding scaling

[Niklas Söderlund]

In preparation of refactoring the scaling code move the code regarding
scaling to to the top of the file to avoid the need to add forward
declarations. No code is changed in this commit only whole functions
moved inside the same file.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-dma.c | 804 +++--
 1 file changed, 404 insertions(+), 400 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index c5fa176ac9d8cc4a..eff5d8f719e4ab26 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -138,304 +138,6 @@ static u32 rvin_read(struct rvin_dev *vin, u32 offset)
return ioread32(vin->base + offset);
 }
 
-static int rvin_setup(struct rvin_dev *vin)
-{
-   u32 vnmc, dmr, dmr2, interrupts;
-   v4l2_std_id std;
-   bool progressive = false, output_is_yuv = false, input_is_yuv = false;
-
-   switch (vin->format.field) {
-   case V4L2_FIELD_TOP:
-   vnmc = VNMC_IM_ODD;
-   break;
-   case V4L2_FIELD_BOTTOM:
-   vnmc = VNMC_IM_EVEN;
-   break;
-   case V4L2_FIELD_INTERLACED:
-   /* Default to TB */
-   vnmc = VNMC_IM_FULL;
-   /* Use BT if video standard can be read and is 60 Hz format */
-   if (!v4l2_subdev_call(vin_to_source(vin), video, g_std, )) {
-   if (std & V4L2_STD_525_60)
-   vnmc = VNMC_IM_FULL | VNMC_FOC;
-   }
-   break;
-   case V4L2_FIELD_INTERLACED_TB:
-   vnmc = VNMC_IM_FULL;
-   break;
-   case V4L2_FIELD_INTERLACED_BT:
-   vnmc = VNMC_IM_FULL | VNMC_FOC;
-   break;
-   case V4L2_FIELD_ALTERNATE:
-   case V4L2_FIELD_NONE:
-   if (vin->continuous) {
-   vnmc = VNMC_IM_ODD_EVEN;
-   progressive = true;
-   } else {
-   vnmc = VNMC_IM_ODD;
-   }
-   break;
-   default:
-   vnmc = VNMC_IM_ODD;
-   break;
-   }
-
-   /*
-* Input interface
-*/
-   switch (vin->digital.code) {
-   case MEDIA_BUS_FMT_YUYV8_1X16:
-   /* BT.601/BT.1358 16bit YCbCr422 */
-   vnmc |= VNMC_INF_YUV16;
-   input_is_yuv = true;
-   break;
-   case MEDIA_BUS_FMT_UYVY8_2X8:
-   /* BT.656 8bit YCbCr422 or BT.601 8bit YCbCr422 */
-   vnmc |= vin->digital.mbus_cfg.type == V4L2_MBUS_BT656 ?
-   VNMC_INF_YUV8_BT656 : VNMC_INF_YUV8_BT601;
-   input_is_yuv = true;
-   break;
-   case MEDIA_BUS_FMT_RGB888_1X24:
-   vnmc |= VNMC_INF_RGB888;
-   break;
-   case MEDIA_BUS_FMT_UYVY10_2X10:
-   /* BT.656 10bit YCbCr422 or BT.601 10bit YCbCr422 */
-   vnmc |= vin->digital.mbus_cfg.type == V4L2_MBUS_BT656 ?
-   VNMC_INF_YUV10_BT656 : VNMC_INF_YUV10_BT601;
-   input_is_yuv = true;
-   break;
-   default:
-   break;
-   }
-
-   /* Enable VSYNC Field Toogle mode after one VSYNC input */
-   dmr2 = VNDMR2_FTEV | VNDMR2_VLV(1);
-
-   /* Hsync Signal Polarity Select */
-   if (!(vin->digital.mbus_cfg.flags & V4L2_MBUS_HSYNC_ACTIVE_LOW))
-   dmr2 |= VNDMR2_HPS;
-
-   /* Vsync Signal Polarity Select */
-   if (!(vin->digital.mbus_cfg.flags & V4L2_MBUS_VSYNC_ACTIVE_LOW))
-   dmr2 |= VNDMR2_VPS;
-
-   /*
-* Output format
-*/
-   switch (vin->format.pixelformat) {
-   case V4L2_PIX_FMT_NV16:
-   rvin_write(vin,
-  ALIGN(vin->format.width * vin->format.height, 0x80),
-  VNUVAOF_REG);
-   dmr = VNDMR_DTMD_YCSEP;
-   output_is_yuv = true;
-   break;
-   case V4L2_PIX_FMT_YUYV:
-   dmr = VNDMR_BPSM;
-   output_is_yuv = true;
-   break;
-   case V4L2_PIX_FMT_UYVY:
-   dmr = 0;
-   output_is_yuv = true;
-   break;
-   case V4L2_PIX_FMT_XRGB555:
-   dmr = VNDMR_DTMD_ARGB1555;
-   break;
-   case V4L2_PIX_FMT_RGB565:
-   dmr = 0;
-   break;
-   case V4L2_PIX_FMT_XBGR32:
-   /* Note: not supported on M1 */
-   dmr = VNDMR_EXRGB;
-   break;
-   default:
-   vin_err(vin, "Invalid pixelformat (0x%x)\n",
-   vin->format.pixelformat);
-   return -EINVAL;
-   }
-
-   /* Always update on field change */
-   vnmc |= VNMC_VUP;
-
-   /* If input and output use the same colorspace, use bypass mode */
-   

[PATCH v3 01/27] rcar-vin: add Gen3 devicetree bindings documentation

[Niklas Söderlund]

Document the devicetree bindings for the CSI-2 inputs available on Gen3.

There is a need to add a custom property 'renesas,id' and to define
which CSI-2 input is described in which endpoint under the port@1 node.
This information is needed since there are a set of predefined routes
between each VIN and CSI-2 block. This routing table will be kept
inside the driver but in order for it to act on it it must know which
VIN and CSI-2 is which.

Signed-off-by: Niklas Söderlund 
---
 .../devicetree/bindings/media/rcar_vin.txt | 122 +++--
 1 file changed, 112 insertions(+), 10 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
b/Documentation/devicetree/bindings/media/rcar_vin.txt
index 6a4e61cbe0116064..ffdfa97ac37753f9 100644
--- a/Documentation/devicetree/bindings/media/rcar_vin.txt
+++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
@@ -2,8 +2,12 @@ Renesas RCar Video Input driver (rcar_vin)
 --
 
 The rcar_vin device provides video input capabilities for the Renesas R-Car
-family of devices. The current blocks are always slaves and suppot one input
-channel which can be either RGB, YUYV or BT656.
+family of devices.
+
+On Gen2 the current blocks are always slaves and support one input channel
+which can be either RGB, YUYV or BT656. On Gen3 the current blocks are
+always slaves and support multiple input channels which can be either RGB,
+YUVU, BT656 or CSI-2.
 
  - compatible: Must be one or more of the following
- "renesas,vin-r8a7795" for the R8A7795 device
@@ -28,7 +32,7 @@ channel which can be either RGB, YUYV or BT656.
 Additionally, an alias named vinX will need to be created to specify
 which video input device this is.
 
-The per-board settings:
+The per-board settings Gen2:
  - port sub-node describing a single endpoint connected to the vin
as described in video-interfaces.txt[1]. Only the first one will
be considered as each vin interface has one input port.
@@ -36,13 +40,23 @@ The per-board settings:
These settings are used to work out video input format and widths
into the system.
 
+The per-board settings Gen3:
+
+- renesas,id - ID number of the VIN
+- ports
+- port@0 - Digital video source (same as port node on Gen2)
+- port@1 - CSI-2 video sources
+-reg 0 - sub-node describing the endpoint which is CSI20
+-reg 1 - sub-node describing the endpoint which is CSI21
+-reg 2 - sub-node describing the endpoint which is CSI40
+-reg 3 - sub-node describing the endpoint which is CSI41
 
-Device node example

+Device node example Gen2
+
 
-   aliases {
-  vin0 = 
-   };
+aliases {
+vin0 = 
+};
 
 vin0: vin@0xe6ef {
 compatible = "renesas,vin-r8a7790", "renesas,rcar-gen2-vin";
@@ -52,8 +66,8 @@ Device node example
 status = "disabled";
 };
 
-Board setup example (vin1 composite video input)
-
+Board setup example Gen2 (vin1 composite video input)
+-
 
{
 status = "ok";
@@ -92,6 +106,94 @@ Board setup example (vin1 composite video input)
 };
 };
 
+Device node example Gen3
+
+
+vin0: video@e6ef {
+compatible = "renesas,vin-r8a7795";
+reg = <0 0xe6ef 0 0x1000>;
+interrupts = <0 188 IRQ_TYPE_LEVEL_HIGH>;
+clocks = < CPG_MOD 811>;
+power-domains = < R8A7795_PD_ALWAYS_ON>;
+status = "disabled";
+
+renesas,id = <0>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@1 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+reg = <1>;
+
+vin0csi20: endpoint@0 {
+reg = <0>;
+remote-endpoint= <>;
+};
+vin0csi21: endpoint@1 {
+reg = <1>;
+remote-endpoint= <>;
+};
+vin0csi40: endpoint@2 {
+reg = <2>;
+remote-endpoint= <>;
+};
+};
+};
+};
+
+csi20: csi2@fea8 {
+compatible = "renesas,r8a7795-csi2", "renesas,rcar-gen3-csi2";
+reg = <0 0xfea8 0 0x1>;
+   

[PATCH v3 10/27] rcar-vin: do not reset crop and compose when setting format

[Niklas Söderlund]

It was a bad idea to reset the crop and compose settings when a new
format is set. This would overwrite any crop/compose set by s_select and
cause unexpected behaviors, remove it. Also fold the reset helper in to
the only remaining caller.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 21 +++--
 1 file changed, 7 insertions(+), 14 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 40bb3d7e73131d3b..e14f0aff8ceecc68 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -90,17 +90,6 @@ static u32 rvin_format_sizeimage(struct v4l2_pix_format *pix)
  * V4L2
  */
 
-static void rvin_reset_crop_compose(struct rvin_dev *vin)
-{
-   vin->crop.top = vin->crop.left = 0;
-   vin->crop.width = vin->source.width;
-   vin->crop.height = vin->source.height;
-
-   vin->compose.top = vin->compose.left = 0;
-   vin->compose.width = vin->format.width;
-   vin->compose.height = vin->format.height;
-}
-
 static int rvin_reset_format(struct rvin_dev *vin)
 {
struct v4l2_subdev_format fmt = {
@@ -147,7 +136,13 @@ static int rvin_reset_format(struct rvin_dev *vin)
break;
}
 
-   rvin_reset_crop_compose(vin);
+   vin->crop.top = vin->crop.left = 0;
+   vin->crop.width = mf->width;
+   vin->crop.height = mf->height;
+
+   vin->compose.top = vin->compose.left = 0;
+   vin->compose.width = mf->width;
+   vin->compose.height = mf->height;
 
vin->format.bytesperline = rvin_format_bytesperline(>format);
vin->format.sizeimage = rvin_format_sizeimage(>format);
@@ -323,8 +318,6 @@ static int rvin_s_fmt_vid_cap(struct file *file, void *priv,
 
vin->format = f->fmt.pix;
 
-   rvin_reset_crop_compose(vin);
-
return 0;
 }
 
-- 
2.12.0

[PATCH v3 17/27] rcar-vin: prepare digital notifier for group notifier

[Niklas Söderlund]

The media bus parsing functions used by the digital subdevice V4L2
notifier can be shared with the upcoming CSI-2 notifier. To prepare for
this move and rename the function to reflect it's generic.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 70 +++--
 1 file changed, 37 insertions(+), 33 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index ed99b1abb99e9ef9..adc38696a0ba70b9 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -45,6 +45,42 @@ static int rvin_find_pad(struct v4l2_subdev *sd, int 
direction)
return -EINVAL;
 }
 
+static int rvin_parse_v4l2(struct rvin_dev *vin,
+  struct device_node *ep,
+  struct v4l2_mbus_config *mbus_cfg)
+{
+   struct v4l2_of_endpoint v4l2_ep;
+   int ret;
+
+   ret = v4l2_of_parse_endpoint(ep, _ep);
+   if (ret) {
+   vin_err(vin, "Could not parse v4l2 endpoint\n");
+   return -EINVAL;
+   }
+
+   mbus_cfg->type = v4l2_ep.bus_type;
+
+   switch (mbus_cfg->type) {
+   case V4L2_MBUS_PARALLEL:
+   vin_dbg(vin, "Found PARALLEL media bus\n");
+   mbus_cfg->flags = v4l2_ep.bus.parallel.flags;
+   break;
+   case V4L2_MBUS_BT656:
+   vin_dbg(vin, "Found BT656 media bus\n");
+   mbus_cfg->flags = 0;
+   break;
+   default:
+   vin_err(vin, "Unknown media bus type\n");
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+/* 
-
+ * Digital async notifier
+ */
+
 static bool rvin_mbus_supported(struct rvin_dev *vin)
 {
struct v4l2_subdev *sd = vin->digital.subdev;
@@ -145,38 +181,6 @@ static int rvin_digital_notify_bound(struct 
v4l2_async_notifier *notifier,
return -EINVAL;
 }
 
-static int rvin_digitial_parse_v4l2(struct rvin_dev *vin,
-   struct device_node *ep,
-   struct v4l2_mbus_config *mbus_cfg)
-{
-   struct v4l2_of_endpoint v4l2_ep;
-   int ret;
-
-   ret = v4l2_of_parse_endpoint(ep, _ep);
-   if (ret) {
-   vin_err(vin, "Could not parse v4l2 endpoint\n");
-   return -EINVAL;
-   }
-
-   mbus_cfg->type = v4l2_ep.bus_type;
-
-   switch (mbus_cfg->type) {
-   case V4L2_MBUS_PARALLEL:
-   vin_dbg(vin, "Found PARALLEL media bus\n");
-   mbus_cfg->flags = v4l2_ep.bus.parallel.flags;
-   break;
-   case V4L2_MBUS_BT656:
-   vin_dbg(vin, "Found BT656 media bus\n");
-   mbus_cfg->flags = 0;
-   break;
-   default:
-   vin_err(vin, "Unknown media bus type\n");
-   return -EINVAL;
-   }
-
-   return 0;
-}
-
 static int rvin_digital_graph_parse(struct rvin_dev *vin)
 {
struct device_node *ep, *np;
@@ -201,7 +205,7 @@ static int rvin_digital_graph_parse(struct rvin_dev *vin)
}
of_node_put(np);
 
-   ret = rvin_digitial_parse_v4l2(vin, ep, >mbus_cfg);
+   ret = rvin_parse_v4l2(vin, ep, >mbus_cfg);
of_node_put(ep);
if (ret)
return ret;
-- 
2.12.0

[PATCH v3 25/27] rcar-vin: extend {start,stop}_streaming to work with media controller

[Niklas Söderlund]

The procedure to start or stop streaming using the none MC single
subdevice and the MC graph and multiple subdevices are quiet different.
Create a new function to abstract which method is used based on which
mode the driver is running in and add logic to start the MC graph.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-dma.c | 82 +++---
 1 file changed, 75 insertions(+), 7 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index 34f01f32bab7bd32..2a525bb3506c2e37 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -1099,15 +1099,85 @@ static void rvin_buffer_queue(struct vb2_buffer *vb)
spin_unlock_irqrestore(>qlock, flags);
 }
 
+static int rvin_set_stream(struct rvin_dev *vin, int on)
+{
+   struct v4l2_subdev_format fmt = {
+   .which = V4L2_SUBDEV_FORMAT_ACTIVE,
+   };
+   struct media_pipeline *pipe;
+   struct  v4l2_subdev *sd;
+   struct media_pad *pad;
+   int ret = -EPIPE;
+
+   /* Not media controller used, simply pass operation to subdevice */
+   if (!vin->info->use_mc) {
+   ret = v4l2_subdev_call(vin->digital.subdev, video, s_stream,
+  on);
+
+   return ret == -ENOIOCTLCMD ? 0 : ret;
+   }
+   mutex_lock(>group->lock);
+
+   pad = media_entity_remote_pad(>pad);
+   if (!pad)
+   goto out;
+
+   sd = media_entity_to_v4l2_subdev(pad->entity);
+   if (!sd)
+   goto out;
+
+   if (on) {
+   fmt.pad = pad->index;
+   if (v4l2_subdev_call(sd, pad, get_fmt, NULL, ))
+   goto out;
+
+   switch (fmt.format.code) {
+   case MEDIA_BUS_FMT_YUYV8_1X16:
+   case MEDIA_BUS_FMT_UYVY8_2X8:
+   case MEDIA_BUS_FMT_UYVY10_2X10:
+   case MEDIA_BUS_FMT_RGB888_1X24:
+   vin->code = fmt.format.code;
+   break;
+   default:
+   goto out;
+   }
+
+   if (fmt.format.width != vin->format.width ||
+   fmt.format.height != vin->format.height)
+   goto out;
+
+   pipe = sd->entity.pipe ? sd->entity.pipe : >vdev->pipe;
+   if (media_pipeline_start(>vdev->entity, pipe))
+   goto out;
+
+   ret = v4l2_subdev_call(sd, video, s_stream, 1);
+   if (ret == -ENOIOCTLCMD)
+   ret = 0;
+   if (ret)
+   media_pipeline_stop(>vdev->entity);
+   } else {
+   media_pipeline_stop(>vdev->entity);
+   ret = v4l2_subdev_call(sd, video, s_stream, 0);
+   }
+out:
+   mutex_unlock(>group->lock);
+
+   return ret;
+}
+
 static int rvin_start_streaming(struct vb2_queue *vq, unsigned int count)
 {
struct rvin_dev *vin = vb2_get_drv_priv(vq);
-   struct v4l2_subdev *sd;
unsigned long flags;
int ret;
 
-   sd = vin_to_source(vin);
-   v4l2_subdev_call(sd, video, s_stream, 1);
+   ret = rvin_set_stream(vin, 1);
+   if (ret) {
+   spin_lock_irqsave(>qlock, flags);
+   return_all_buffers(vin, VB2_BUF_STATE_QUEUED);
+   spin_unlock_irqrestore(>qlock, flags);
+   return ret;
+   }
 
spin_lock_irqsave(>qlock, flags);
 
@@ -1116,7 +1186,7 @@ static int rvin_start_streaming(struct vb2_queue *vq, 
unsigned int count)
ret = rvin_capture_start(vin);
if (ret) {
return_all_buffers(vin, VB2_BUF_STATE_QUEUED);
-   v4l2_subdev_call(sd, video, s_stream, 0);
+   rvin_set_stream(vin, 0);
}
 
spin_unlock_irqrestore(>qlock, flags);
@@ -1127,7 +1197,6 @@ static int rvin_start_streaming(struct vb2_queue *vq, 
unsigned int count)
 static void rvin_stop_streaming(struct vb2_queue *vq)
 {
struct rvin_dev *vin = vb2_get_drv_priv(vq);
-   struct v4l2_subdev *sd;
unsigned long flags;
int retries = 0;
 
@@ -1166,8 +1235,7 @@ static void rvin_stop_streaming(struct vb2_queue *vq)
 
spin_unlock_irqrestore(>qlock, flags);
 
-   sd = vin_to_source(vin);
-   v4l2_subdev_call(sd, video, s_stream, 0);
+   rvin_set_stream(vin, 0);
 
/* disable interrupts */
rvin_disable_interrupts(vin);
-- 
2.12.0

[PATCH v3 24/27] rcar-vin: add link notify for Gen3

[Niklas Söderlund]

Add the ability to process media device link change request. Link
enablement are a bit complicated on Gen3, if it's possible to enable a
link depends on what other links already are enabled. On Gen3 the 8 VIN
are split into two subgroups (VIN0-3 and VIN4-7) and from a routing
perspective these two groups are independent of each other. Each
subgroups routing is controlled by the subgroup VIN master instance
(VIN0 and VIN4).

There are a limited number of possible route setups available for each
subgroup and the configuration of each setup is dictated by the
hardware. On H3 for example there are 6 possible route setups for each
subgroup to choose from.

This leads to the media device link notification code being rather large
since it will find the best routing configuration to try and accommodate
as many links as possible. When it's not possible to enable a new link
due to hardware constrains the link_notifier callback will return
-EMLINK.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 204 
 1 file changed, 204 insertions(+)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index d3a9bd007dea73d7..68eca8e005f976d6 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -27,6 +27,208 @@
 #include "rcar-vin.h"
 
 /* 
-
+ * Media Controller link notification
+ */
+
+static unsigned int rvin_group_csi_pad_to_chan(unsigned int pad)
+{
+   /*
+* The CSI2 driver is rcar-csi2 and we know it's pad layout are
+* 0: Source 1-4: Sinks so if we remove one from the pad we
+* get the rcar-vin internal CSI2 channel number
+*/
+   return pad - 1;
+}
+
+/* group lock should be held when calling this function */
+static int rvin_group_entity_to_vin_num(struct rvin_group *group,
+   struct media_entity *entity)
+{
+   struct video_device *vdev;
+   int i;
+
+   if (!is_media_entity_v4l2_video_device(entity))
+   return -ENODEV;
+
+   vdev = media_entity_to_video_device(entity);
+
+   for (i = 0; i < RCAR_VIN_NUM; i++) {
+   if (!group->vin[i])
+   continue;
+
+   if (group->vin[i]->vdev == vdev)
+   return i;
+   }
+
+   return -ENODEV;
+}
+
+/* group lock should be held when calling this function */
+static int rvin_group_entity_to_csi_num(struct rvin_group *group,
+   struct media_entity *entity)
+{
+   struct v4l2_subdev *sd;
+   int i;
+
+   if (!is_media_entity_v4l2_subdev(entity))
+   return -ENODEV;
+
+   sd = media_entity_to_v4l2_subdev(entity);
+
+   for (i = 0; i < RVIN_CSI_MAX; i++)
+   if (group->bridge[i].subdev == sd)
+   return i;
+
+   return -ENODEV;
+}
+
+/* group lock should be held when calling this function */
+static void __rvin_group_build_link_list(struct rvin_group *group,
+struct rvin_group_chsel *map,
+int start, int len)
+{
+   struct media_pad *vin_pad, *remote_pad;
+   unsigned int n;
+
+   for (n = 0; n < len; n++) {
+   map[n].csi = -1;
+   map[n].chan = -1;
+
+   if (!group->vin[start + n])
+   continue;
+
+   vin_pad = >vin[start + n]->vdev->entity.pads[0];
+
+   remote_pad = media_entity_remote_pad(vin_pad);
+   if (!remote_pad)
+   continue;
+
+   map[n].csi =
+   rvin_group_entity_to_csi_num(group, remote_pad->entity);
+   map[n].chan = rvin_group_csi_pad_to_chan(remote_pad->index);
+   }
+}
+
+/* group lock should be held when calling this function */
+static int __rvin_group_try_get_chsel(struct rvin_group *group,
+ struct rvin_group_chsel *map,
+ int start, int len)
+{
+   const struct rvin_group_chsel *sel;
+   unsigned int i, n;
+   int chsel;
+
+   for (i = 0; i < group->vin[start]->info->num_chsels; i++) {
+   chsel = i;
+   for (n = 0; n < len; n++) {
+
+   /* If the link is not active it's OK */
+   if (map[n].csi == -1)
+   continue;
+
+   /* Check if chsel match requested link */
+   sel = >vin[start]->info->chsels[start + n][i];
+   if (map[n].csi != sel->csi ||
+   map[n].chan != sel->chan) {
+   chsel = -1;
+   break;
+   }
+ 

[PATCH v3 27/27] rcar-vin: enable support for r8a7796

[Niklas Söderlund]

Add the SoC specific information for Renesas r8a7796.

Signed-off-by: Niklas Söderlund 
---
 .../devicetree/bindings/media/rcar_vin.txt |  1 +
 drivers/media/platform/rcar-vin/rcar-core.c| 64 ++
 2 files changed, 65 insertions(+)

diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt 
b/Documentation/devicetree/bindings/media/rcar_vin.txt
index ffdfa97ac37753f9..7e36ebe5c89b7dfd 100644
--- a/Documentation/devicetree/bindings/media/rcar_vin.txt
+++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
@@ -10,6 +10,7 @@ always slaves and support multiple input channels which can 
be either RGB,
 YUVU, BT656 or CSI-2.
 
  - compatible: Must be one or more of the following
+   - "renesas,vin-r8a7796" for the R8A7796 device
- "renesas,vin-r8a7795" for the R8A7795 device
- "renesas,vin-r8a7794" for the R8A7794 device
- "renesas,vin-r8a7793" for the R8A7793 device
diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index c30040c42ce588a9..8930189638473f37 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -1119,6 +1119,66 @@ static const struct rvin_info rcar_info_r8a7795 = {
},
 };
 
+static const struct rvin_info rcar_info_r8a7796 = {
+   .chip = RCAR_GEN3,
+   .use_mc = true,
+   .max_width = 4096,
+   .max_height = 4096,
+
+   .num_chsels = 5,
+   .chsels = {
+   {
+   { .csi = RVIN_CSI40, .chan = 0 },
+   { .csi = RVIN_CSI20, .chan = 0 },
+   { .csi = RVIN_NC, .chan = 0 },
+   { .csi = RVIN_CSI40, .chan = 0 },
+   { .csi = RVIN_CSI20, .chan = 0 },
+   }, {
+   { .csi = RVIN_CSI20, .chan = 0 },
+   { .csi = RVIN_NC, .chan = 0 },
+   { .csi = RVIN_CSI40, .chan = 0 },
+   { .csi = RVIN_CSI40, .chan = 1 },
+   { .csi = RVIN_CSI20, .chan = 1 },
+   }, {
+   { .csi = RVIN_NC, .chan = 0 },
+   { .csi = RVIN_CSI40, .chan = 0 },
+   { .csi = RVIN_CSI20, .chan = 0 },
+   { .csi = RVIN_CSI40, .chan = 2 },
+   { .csi = RVIN_CSI20, .chan = 2 },
+   }, {
+   { .csi = RVIN_CSI40, .chan = 1 },
+   { .csi = RVIN_CSI20, .chan = 1 },
+   { .csi = RVIN_NC, .chan = 1 },
+   { .csi = RVIN_CSI40, .chan = 3 },
+   { .csi = RVIN_CSI20, .chan = 3 },
+   }, {
+   { .csi = RVIN_CSI40, .chan = 0 },
+   { .csi = RVIN_CSI20, .chan = 0 },
+   { .csi = RVIN_NC, .chan = 0 },
+   { .csi = RVIN_CSI40, .chan = 0 },
+   { .csi = RVIN_CSI20, .chan = 0 },
+   }, {
+   { .csi = RVIN_CSI20, .chan = 0 },
+   { .csi = RVIN_NC, .chan = 0 },
+   { .csi = RVIN_CSI40, .chan = 0 },
+   { .csi = RVIN_CSI40, .chan = 1 },
+   { .csi = RVIN_CSI20, .chan = 1 },
+   }, {
+   { .csi = RVIN_NC, .chan = 0 },
+   { .csi = RVIN_CSI40, .chan = 0 },
+   { .csi = RVIN_CSI20, .chan = 0 },
+   { .csi = RVIN_CSI40, .chan = 2 },
+   { .csi = RVIN_CSI20, .chan = 2 },
+   }, {
+   { .csi = RVIN_CSI40, .chan = 1 },
+   { .csi = RVIN_CSI20, .chan = 1 },
+   { .csi = RVIN_NC, .chan = 1 },
+   { .csi = RVIN_CSI40, .chan = 3 },
+   { .csi = RVIN_CSI20, .chan = 3 },
+   },
+   },
+};
+
 static const struct rvin_info rcar_info_gen2 = {
.chip = RCAR_GEN2,
.use_mc = false,
@@ -1132,6 +1192,10 @@ static const struct of_device_id rvin_of_id_table[] = {
.data = _info_r8a7795,
},
{
+   .compatible = "renesas,vin-r8a7796",
+   .data = _info_r8a7796,
+   },
+   {
.compatible = "renesas,vin-r8a7794",
.data = _info_gen2,
},
-- 
2.12.0

[PATCH v3 23/27] rcar-vin: parse Gen3 OF and setup media graph

[Niklas Söderlund]

Parse the VIN Gen3 OF graph and register all devices in the CSI2 group
common media device. Once a subdevice is added to the common media
device list as many links as possible are added and if possible enabled.

The links between the video source device and the CSI2 bridge are
enabled as immutable since they can't change during runtime. While the
link between the CSI2 bridge and the VIN video device are enabled
according the CHSEL routing table suitable for the SoC.

The parsing and registering subdevices is a collaborative effort shared
between all rcar-vin instances which are part of the CSI2 group. Which
ever rcar-vin instance which fist sees a new subdevice in the graph adds
it to its private v4l2 async notifier and once it's bound it will be
available for the whole CSI2 group.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 472 +++-
 1 file changed, 459 insertions(+), 13 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index c10770d5ec37816c..d3a9bd007dea73d7 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -158,21 +158,32 @@ static int rvin_parse_v4l2(struct rvin_dev *vin,
 
mbus_cfg->type = v4l2_ep.bus_type;
 
-   switch (mbus_cfg->type) {
-   case V4L2_MBUS_PARALLEL:
-   vin_dbg(vin, "Found PARALLEL media bus\n");
-   mbus_cfg->flags = v4l2_ep.bus.parallel.flags;
-   break;
-   case V4L2_MBUS_BT656:
-   vin_dbg(vin, "Found BT656 media bus\n");
-   mbus_cfg->flags = 0;
-   break;
-   default:
-   vin_err(vin, "Unknown media bus type\n");
-   return -EINVAL;
+   if (vin->info->chip == RCAR_GEN3) {
+   switch (mbus_cfg->type) {
+   case V4L2_MBUS_CSI2:
+   vin_dbg(vin, "Found CSI-2 media bus\n");
+   mbus_cfg->flags = 0;
+   return 0;
+   default:
+   break;
+   }
+   } else {
+   switch (mbus_cfg->type) {
+   case V4L2_MBUS_PARALLEL:
+   vin_dbg(vin, "Found PARALLEL media bus\n");
+   mbus_cfg->flags = v4l2_ep.bus.parallel.flags;
+   return 0;
+   case V4L2_MBUS_BT656:
+   vin_dbg(vin, "Found BT656 media bus\n");
+   mbus_cfg->flags = 0;
+   return 0;
+   default:
+   break;
+   }
}
 
-   return 0;
+   vin_err(vin, "Unknown media bus type\n");
+   return -EINVAL;
 }
 
 /* 
-
@@ -357,6 +368,431 @@ static int rvin_digital_graph_init(struct rvin_dev *vin)
  * Group async notifier
  */
 
+/* group lock should be held when calling this function */
+static void rvin_group_update_pads(struct rvin_graph_entity *entity)
+{
+   struct media_entity *ent = >subdev->entity;
+   unsigned int i;
+
+   /* Make sure source pad idx are sane */
+   if (entity->source_pad >= ent->num_pads ||
+   ent->pads[entity->source_pad].flags != MEDIA_PAD_FL_SOURCE) {
+   entity->source_pad =
+   rvin_find_pad(entity->subdev, MEDIA_PAD_FL_SOURCE);
+   }
+
+   /* Try to find sink for source, fall back 0 which always is sink */
+   entity->sink_pad = 0;
+   for (i = 0; i < ent->num_pads; ++i) {
+   struct media_pad *sink = >pads[i];
+
+   if (!(sink->flags & MEDIA_PAD_FL_SINK))
+   continue;
+
+   if (sink->index == entity->source_pad)
+   continue;
+
+   if (media_entity_has_route(ent, sink->index,
+  entity->source_pad))
+   entity->sink_pad = sink->index;
+   }
+}
+
+/* group lock should be held when calling this function */
+static int rvin_group_add_link(struct rvin_dev *vin,
+  struct media_entity *source,
+  unsigned int source_idx,
+  struct media_entity *sink,
+  unsigned int sink_idx,
+  u32 flags)
+{
+   struct media_pad *source_pad, *sink_pad;
+   int ret = 0;
+
+   source_pad = >pads[source_idx];
+   sink_pad = >pads[sink_idx];
+
+   if (!media_entity_find_link(source_pad, sink_pad))
+   ret = media_create_pad_link(source, source_idx,
+   sink, sink_idx, flags);
+
+   if (ret)
+   vin_err(vin, "Error adding link from %s to %s\n",
+   source->name, sink->name);
+
+   return ret;
+}
+

[PATCH v3 02/27] media: entity: Add has_route entity operation

[Niklas Söderlund]

From: Laurent Pinchart 

The optional operation can be used by entities to report whether two
pads are internally connected.

Signed-off-by: Laurent Pinchart 
Signed-off-by: Michal Simek 
Signed-off-by: Niklas Söderlund 
Acked-by: Sakari Ailus 
---
 include/media/media-entity.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index c7c254c5bca1761b..bcb08c1f8c6265e8 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -177,6 +177,9 @@ struct media_pad {
  * @link_validate: Return whether a link is valid from the entity point of
  * view. The media_pipeline_start() function
  * validates all links by calling this operation. Optional.
+ * @has_route: Return whether a route exists inside the entity between
+ * two given pads. Optional. If the operation isn't
+ * implemented all pads will be considered as connected.
  *
  * .. note::
  *
@@ -188,6 +191,8 @@ struct media_entity_operations {
  const struct media_pad *local,
  const struct media_pad *remote, u32 flags);
int (*link_validate)(struct media_link *link);
+   bool (*has_route)(struct media_entity *entity, unsigned int pad0,
+ unsigned int pad1);
 };
 
 /**
-- 
2.12.0

[PATCH v3 18/27] rcar-vin: add flag to switch to media controller mode

[Niklas Söderlund]

On Gen3 a media controller API needs to be used to allow userspace to
configure the subdevices in the pipeline instead of directly controlling
a single source subdevice, which is and will continue to be the mode of
operation on Gen2.

Prepare for these two modes of operation by adding a flag to struct
rvin_graph_entity which will control which mode to use.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 3 +++
 drivers/media/platform/rcar-vin/rcar-vin.h  | 2 ++
 2 files changed, 5 insertions(+)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index adc38696a0ba70b9..8b30d8d3ec7d9c04 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -261,18 +261,21 @@ static int rvin_digital_graph_init(struct rvin_dev *vin)
 
 static const struct rvin_info rcar_info_h1 = {
.chip = RCAR_H1,
+   .use_mc = false,
.max_width = 2048,
.max_height = 2048,
 };
 
 static const struct rvin_info rcar_info_m1 = {
.chip = RCAR_M1,
+   .use_mc = false,
.max_width = 2048,
.max_height = 2048,
 };
 
 static const struct rvin_info rcar_info_gen2 = {
.chip = RCAR_GEN2,
+   .use_mc = false,
.max_width = 2048,
.max_height = 2048,
 };
diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h 
b/drivers/media/platform/rcar-vin/rcar-vin.h
index b1cd0abba9ca9c94..512e67fdefd15015 100644
--- a/drivers/media/platform/rcar-vin/rcar-vin.h
+++ b/drivers/media/platform/rcar-vin/rcar-vin.h
@@ -77,12 +77,14 @@ struct rvin_graph_entity {
 /**
  * struct rvin_info- Information about the particular VIN implementation
  * @chip:  type of VIN chip
+ * @use_mc:use media controller instead of controlling subdevice
  *
  * max_width:  max input width the VIN supports
  * max_height: max input height the VIN supports
  */
 struct rvin_info {
enum chip_id chip;
+   bool use_mc;
 
unsigned int max_width;
unsigned int max_height;
-- 
2.12.0

[PATCH v3 09/27] rcar-vin: all Gen2 boards can scale simplify logic

[Niklas Söderlund]

The logic to preserve the requested format width and height are too
complex and come from a premature optimization for Gen3. All Gen2 SoC
can scale and the Gen3 implementation will not use these functions at
all so simply preserve the width and hight when interacting with the
subdevice much like the field is preserved simplifies the logic quiet a
bit.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-dma.c  |  8 
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 22 ++
 drivers/media/platform/rcar-vin/rcar-vin.h  |  2 --
 3 files changed, 10 insertions(+), 22 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index eff5d8f719e4ab26..286aafab533cda9d 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -585,14 +585,6 @@ void rvin_crop_scale_comp(struct rvin_dev *vin)
0, 0);
 }
 
-void rvin_scale_try(struct rvin_dev *vin, struct v4l2_pix_format *pix,
-   u32 width, u32 height)
-{
-   /* All VIN channels on Gen2 have scalers */
-   pix->width = width;
-   pix->height = height;
-}
-
 /* 
-
  * Hardware setup
  */
diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 709ee828f2ac2173..40bb3d7e73131d3b 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -166,6 +166,7 @@ static int __rvin_try_format_source(struct rvin_dev *vin,
.which = which,
};
enum v4l2_field field;
+   u32 width, height;
int ret;
 
sd = vin_to_source(vin);
@@ -178,7 +179,10 @@ static int __rvin_try_format_source(struct rvin_dev *vin,
 
format.pad = vin->digital.source_pad;
 
+   /* Allow the video device to override field and to scale */
field = pix->field;
+   width = pix->width;
+   height = pix->height;
 
ret = v4l2_subdev_call(sd, pad, set_fmt, pad_cfg, );
if (ret < 0 && ret != -ENOIOCTLCMD)
@@ -191,6 +195,9 @@ static int __rvin_try_format_source(struct rvin_dev *vin,
source->width = pix->width;
source->height = pix->height;
 
+   pix->width = width;
+   pix->height = height;
+
vin_dbg(vin, "Source resolution: %ux%u\n", source->width,
source->height);
 
@@ -205,13 +212,9 @@ static int __rvin_try_format(struct rvin_dev *vin,
 struct rvin_source_fmt *source)
 {
const struct rvin_video_format *info;
-   u32 rwidth, rheight, walign;
+   u32 walign;
int ret;
 
-   /* Requested */
-   rwidth = pix->width;
-   rheight = pix->height;
-
/* Keep current field if no specific one is asked for */
if (pix->field == V4L2_FIELD_ANY)
pix->field = vin->format.field;
@@ -254,10 +257,6 @@ static int __rvin_try_format(struct rvin_dev *vin,
break;
}
 
-   /* If source can't match format try if VIN can scale */
-   if (source->width != rwidth || source->height != rheight)
-   rvin_scale_try(vin, pix, rwidth, rheight);
-
/* HW limit width to a multiple of 32 (2^5) for NV16 else 2 (2^1) */
walign = vin->format.pixelformat == V4L2_PIX_FMT_NV16 ? 5 : 1;
 
@@ -276,9 +275,8 @@ static int __rvin_try_format(struct rvin_dev *vin,
return -EINVAL;
}
 
-   vin_dbg(vin, "Requested %ux%u Got %ux%u bpl: %d size: %d\n",
-   rwidth, rheight, pix->width, pix->height,
-   pix->bytesperline, pix->sizeimage);
+   vin_dbg(vin, "Format %ux%u bpl: %d size: %d\n",
+   pix->width, pix->height, pix->bytesperline, pix->sizeimage);
 
return 0;
 }
diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h 
b/drivers/media/platform/rcar-vin/rcar-vin.h
index 32d9d130dd6e2e44..6bf2e4ff8f6076c7 100644
--- a/drivers/media/platform/rcar-vin/rcar-vin.h
+++ b/drivers/media/platform/rcar-vin/rcar-vin.h
@@ -176,8 +176,6 @@ void rvin_v4l2_remove(struct rvin_dev *vin);
 const struct rvin_video_format *rvin_format_from_pixel(u32 pixelformat);
 
 /* Cropping, composing and scaling */
-void rvin_scale_try(struct rvin_dev *vin, struct v4l2_pix_format *pix,
-   u32 width, u32 height);
 void rvin_crop_scale_comp(struct rvin_dev *vin);
 
 #endif
-- 
2.12.0

[PATCH v3 15/27] rcar-vin: enable Gen3 hardware configuration

[Niklas Söderlund]

Add the register needed to work with Gen3 hardware. This patch adds
the logic for how to work with the Gen3 hardware. More work is required
to enable the subdevice structure needed to configure capturing.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-dma.c | 94 --
 drivers/media/platform/rcar-vin/rcar-vin.h |  1 +
 2 files changed, 64 insertions(+), 31 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index 2931ba7998709307..7fecb616b6c45a32 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -33,21 +33,23 @@
 #define VNELPRC_REG0x10/* Video n End Line Pre-Clip Register */
 #define VNSPPRC_REG0x14/* Video n Start Pixel Pre-Clip Register */
 #define VNEPPRC_REG0x18/* Video n End Pixel Pre-Clip Register */
-#define VNSLPOC_REG0x1C/* Video n Start Line Post-Clip Register */
-#define VNELPOC_REG0x20/* Video n End Line Post-Clip Register */
-#define VNSPPOC_REG0x24/* Video n Start Pixel Post-Clip Register */
-#define VNEPPOC_REG0x28/* Video n End Pixel Post-Clip Register */
 #define VNIS_REG   0x2C/* Video n Image Stride Register */
 #define VNMB_REG(m)(0x30 + ((m) << 2)) /* Video n Memory Base m Register */
 #define VNIE_REG   0x40/* Video n Interrupt Enable Register */
 #define VNINTS_REG 0x44/* Video n Interrupt Status Register */
 #define VNSI_REG   0x48/* Video n Scanline Interrupt Register */
 #define VNMTC_REG  0x4C/* Video n Memory Transfer Control Register */
-#define VNYS_REG   0x50/* Video n Y Scale Register */
-#define VNXS_REG   0x54/* Video n X Scale Register */
 #define VNDMR_REG  0x58/* Video n Data Mode Register */
 #define VNDMR2_REG 0x5C/* Video n Data Mode Register 2 */
 #define VNUVAOF_REG0x60/* Video n UV Address Offset Register */
+
+/* Register offsets specific for Gen2 */
+#define VNSLPOC_REG0x1C/* Video n Start Line Post-Clip Register */
+#define VNELPOC_REG0x20/* Video n End Line Post-Clip Register */
+#define VNSPPOC_REG0x24/* Video n Start Pixel Post-Clip Register */
+#define VNEPPOC_REG0x28/* Video n End Pixel Post-Clip Register */
+#define VNYS_REG   0x50/* Video n Y Scale Register */
+#define VNXS_REG   0x54/* Video n X Scale Register */
 #define VNC1A_REG  0x80/* Video n Coefficient Set C1A Register */
 #define VNC1B_REG  0x84/* Video n Coefficient Set C1B Register */
 #define VNC1C_REG  0x88/* Video n Coefficient Set C1C Register */
@@ -73,9 +75,13 @@
 #define VNC8B_REG  0xF4/* Video n Coefficient Set C8B Register */
 #define VNC8C_REG  0xF8/* Video n Coefficient Set C8C Register */
 
+/* Register offsets specific for Gen3 */
+#define VNCSI_IFMD_REG 0x20 /* Video n CSI2 Interface Mode Register */
 
 /* Register bit fields for R-Car VIN */
 /* Video n Main Control Register bits */
+#define VNMC_DPINE (1 << 27) /* Gen3 specific */
+#define VNMC_SCLE  (1 << 26) /* Gen3 specific */
 #define VNMC_FOC   (1 << 21)
 #define VNMC_YCAL  (1 << 19)
 #define VNMC_INF_YUV8_BT656(0 << 16)
@@ -119,6 +125,13 @@
 #define VNDMR2_FTEV(1 << 17)
 #define VNDMR2_VLV(n)  ((n & 0xf) << 12)
 
+/* Video n CSI2 Interface Mode Register (Gen3) */
+#define VNCSI_IFMD_DES2(1 << 27)
+#define VNCSI_IFMD_DES1(1 << 26)
+#define VNCSI_IFMD_DES0(1 << 25)
+#define VNCSI_IFMD_CSI_CHSEL(n) ((n & 0xf) << 0)
+#define VNCSI_IFMD_CSI_CHSEL_MASK 0xf
+
 struct rvin_buffer {
struct vb2_v4l2_buffer vb;
struct list_head list;
@@ -514,28 +527,10 @@ static void rvin_set_coeff(struct rvin_dev *vin, unsigned 
short xs)
rvin_write(vin, p_set->coeff_set[23], VNC8C_REG);
 }
 
-static void rvin_crop_scale_comp(struct rvin_dev *vin)
+static void rvin_crop_scale_comp_gen2(struct rvin_dev *vin)
 {
u32 xs, ys;
 
-   /* Set Start/End Pixel/Line Pre-Clip */
-   rvin_write(vin, vin->crop.left, VNSPPRC_REG);
-   rvin_write(vin, vin->crop.left + vin->crop.width - 1, VNEPPRC_REG);
-   switch (vin->format.field) {
-   case V4L2_FIELD_INTERLACED:
-   case V4L2_FIELD_INTERLACED_TB:
-   case V4L2_FIELD_INTERLACED_BT:
-   rvin_write(vin, vin->crop.top / 2, VNSLPRC_REG);
-   rvin_write(vin, (vin->crop.top + vin->crop.height) / 2 - 1,
-  VNELPRC_REG);
-   break;
-   default:
-   rvin_write(vin, vin->crop.top, VNSLPRC_REG);
-   rvin_write(vin, vin->crop.top + vin->crop.height - 1,
-  VNELPRC_REG);
-   break;
-   }
-
/* Set scaling coefficient */
ys = 0;
if (vin->crop.height != 

[PATCH v3 07/27] rcar-vin: change name of video device

[Niklas Söderlund]

The rcar-vin driver needs to be part of a media controller to support
Gen3. Give each VIN instance a unique name so it can be referenced from
userspace.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 1b364f359ff4b5ed..709ee828f2ac2173 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -915,7 +915,8 @@ int rvin_v4l2_probe(struct rvin_dev *vin)
vdev->fops = _fops;
vdev->v4l2_dev = >v4l2_dev;
vdev->queue = >queue;
-   strlcpy(vdev->name, KBUILD_MODNAME, sizeof(vdev->name));
+   snprintf(vdev->name, sizeof(vdev->name), "%s %s", KBUILD_MODNAME,
+dev_name(vin->dev));
vdev->release = video_device_release;
vdev->ioctl_ops = _ioctl_ops;
vdev->lock = >lock;
-- 
2.12.0

[PATCH v3 16/27] rcar-vin: add functions to manipulate Gen3 CHSEL value

[Niklas Söderlund]

On Gen3 the CSI routing is controlled by the VnCSI_IFMD register. One
feature of this register is that it's only present in the VIN0 and VIN4
instances. The register in VIN0 controls the routing for VIN0-3 and the
register in VIN4 controls routing for VIN4-7.

To be able to control routing from a media device these functions need
to control runtime PM for the subgroup master (VIN0 and VIN4). The
subgroup master must be switched on before the register is manipulated,
once the operation is complete it's safe to switch the master off and
the new routing will still be in effect.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-dma.c | 43 ++
 drivers/media/platform/rcar-vin/rcar-vin.h |  3 +++
 2 files changed, 46 insertions(+)

diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index 7fecb616b6c45a32..fef31aac0ed40979 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -16,6 +16,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -1240,3 +1241,45 @@ int rvin_dma_probe(struct rvin_dev *vin, int irq)
 
return ret;
 }
+
+/* 
-
+ * Gen3 CHSEL manipulation
+ */
+
+int rvin_set_chsel(struct rvin_dev *vin, u8 chsel)
+{
+   u32 ifmd;
+
+   pm_runtime_get_sync(vin->dev);
+
+   /*
+* Undocumented feature: Writing to VNCSI_IFMD_REG will go
+* through and on read back look correct but won't have
+* any effect if VNMC_REG is not first set to 0.
+*/
+   rvin_write(vin, 0, VNMC_REG);
+
+   ifmd = VNCSI_IFMD_DES2 | VNCSI_IFMD_DES1 | VNCSI_IFMD_DES0 |
+   VNCSI_IFMD_CSI_CHSEL(chsel);
+
+   rvin_write(vin, ifmd, VNCSI_IFMD_REG);
+
+   vin_dbg(vin, "Set IFMD 0x%x\n", ifmd);
+
+   pm_runtime_put(vin->dev);
+
+   return 0;
+}
+
+int rvin_get_chsel(struct rvin_dev *vin)
+{
+   int chsel;
+
+   pm_runtime_get_sync(vin->dev);
+
+   chsel = rvin_read(vin, VNCSI_IFMD_REG) & VNCSI_IFMD_CSI_CHSEL_MASK;
+
+   pm_runtime_put(vin->dev);
+
+   return chsel;
+}
diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h 
b/drivers/media/platform/rcar-vin/rcar-vin.h
index 09fc70e192699f35..b1cd0abba9ca9c94 100644
--- a/drivers/media/platform/rcar-vin/rcar-vin.h
+++ b/drivers/media/platform/rcar-vin/rcar-vin.h
@@ -163,4 +163,7 @@ void rvin_v4l2_remove(struct rvin_dev *vin);
 
 const struct rvin_video_format *rvin_format_from_pixel(u32 pixelformat);
 
+int rvin_set_chsel(struct rvin_dev *vin, u8 chsel);
+int rvin_get_chsel(struct rvin_dev *vin);
+
 #endif
-- 
2.12.0

[PATCH v3 19/27] rcar-vin: use different v4l2 operations in media controller mode

[Niklas Söderlund]

When the driver runs in media controller mode it should not directly
control the subdevice instead userspace will be responsible for
configuring the pipeline. To be able to run in this mode a different set
of v4l2 operations needs to be used.

Add a new set of v4l2 operations to support the running without directly
interacting with the source subdevice.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-core.c |  25 ++-
 drivers/media/platform/rcar-vin/rcar-dma.c  |   3 +-
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 239 
 drivers/media/platform/rcar-vin/rcar-vin.h  |   3 +
 4 files changed, 268 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 8b30d8d3ec7d9c04..7aaa01dee014d64b 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -256,6 +256,21 @@ static int rvin_digital_graph_init(struct rvin_dev *vin)
 }
 
 /* 
-
+ * Group async notifier
+ */
+
+static int rvin_group_init(struct rvin_dev *vin)
+{
+   int ret;
+
+   ret = rvin_v4l2_mc_probe(vin);
+   if (ret)
+   return ret;
+
+   return 0;
+}
+
+/* 
-
  * Platform Device Driver
  */
 
@@ -347,7 +362,10 @@ static int rcar_vin_probe(struct platform_device *pdev)
if (ret)
return ret;
 
-   ret = rvin_digital_graph_init(vin);
+   if (vin->info->use_mc)
+   ret = rvin_group_init(vin);
+   else
+   ret = rvin_digital_graph_init(vin);
if (ret < 0)
goto error;
 
@@ -371,6 +389,11 @@ static int rcar_vin_remove(struct platform_device *pdev)
 
v4l2_async_notifier_unregister(>notifier);
 
+   if (vin->info->use_mc)
+   rvin_v4l2_mc_remove(vin);
+   else
+   rvin_v4l2_remove(vin);
+
rvin_dma_remove(vin);
 
return 0;
diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index fef31aac0ed40979..34f01f32bab7bd32 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -628,7 +628,8 @@ static int rvin_setup(struct rvin_dev *vin)
/* Default to TB */
vnmc = VNMC_IM_FULL;
/* Use BT if video standard can be read and is 60 Hz format */
-   if (!v4l2_subdev_call(vin_to_source(vin), video, g_std, )) {
+   if (!vin->info->use_mc &&
+   !v4l2_subdev_call(vin_to_source(vin), video, g_std, )) {
if (std & V4L2_STD_525_60)
vnmc = VNMC_IM_FULL | VNMC_FOC;
}
diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index 1ee9dcb621350f77..ae6910ac87ec7f6a 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -23,6 +23,9 @@
 #include "rcar-vin.h"
 
 #define RVIN_DEFAULT_FORMATV4L2_PIX_FMT_YUYV
+#define RVIN_DEFAULT_WIDTH 800
+#define RVIN_DEFAULT_HEIGHT600
+#define RVIN_DEFAULT_COLORSPACEV4L2_COLORSPACE_SRGB
 
 /* 
-
  * Format Conversions
@@ -694,6 +697,126 @@ static const struct v4l2_ioctl_ops rvin_ioctl_ops = {
 };
 
 /* 
-
+ * V4L2 Media Controller
+ */
+
+static int __rvin_mc_try_format(struct rvin_dev *vin,
+   struct v4l2_pix_format *pix)
+{
+   const struct rvin_video_format *info;
+   u32 walign;
+
+   /* Keep current field if no specific one is asked for */
+   if (pix->field == V4L2_FIELD_ANY)
+   pix->field = vin->format.field;
+
+   switch (pix->field) {
+   case V4L2_FIELD_TOP:
+   case V4L2_FIELD_BOTTOM:
+   case V4L2_FIELD_ALTERNATE:
+   case V4L2_FIELD_NONE:
+   case V4L2_FIELD_INTERLACED_TB:
+   case V4L2_FIELD_INTERLACED_BT:
+   case V4L2_FIELD_INTERLACED:
+   break;
+   default:
+   pix->field = V4L2_FIELD_NONE;
+   break;
+   }
+
+   /* Check that colorspace is resonable, if not keep current */
+   if (!pix->colorspace || pix->colorspace >= 0xff)
+   pix->colorspace = vin->format.colorspace;
+
+   info = rvin_format_from_pixel(pix->pixelformat);
+   if (!info) {
+   vin_dbg(vin, "Format %x not found, keeping %x\n",
+   pix->pixelformat, vin->format.pixelformat);
+   pix->pixelformat = vin->format.pixelformat;
+   info = rvin_format_from_pixel(pix->pixelformat);
+   }
+
+ 

[PATCH v3 26/27] rcar-vin: enable support for r8a7795

[Niklas Söderlund]

Add the SoC specific information for Renesas r8a7795.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/Kconfig |  2 +-
 drivers/media/platform/rcar-vin/rcar-core.c | 72 +
 2 files changed, 73 insertions(+), 1 deletion(-)

diff --git a/drivers/media/platform/rcar-vin/Kconfig 
b/drivers/media/platform/rcar-vin/Kconfig
index 111d2a151f6a4d44..e0e981c14b081bc6 100644
--- a/drivers/media/platform/rcar-vin/Kconfig
+++ b/drivers/media/platform/rcar-vin/Kconfig
@@ -5,7 +5,7 @@ config VIDEO_RCAR_VIN
select VIDEOBUF2_DMA_CONTIG
---help---
  Support for Renesas R-Car Video Input (VIN) driver.
- Supports R-Car Gen2 SoCs.
+ Supports R-Car Gen2 and Gen3 SoCs.
 
  To compile this driver as a module, choose M here: the
  module will be called rcar-vin.
diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 68eca8e005f976d6..c30040c42ce588a9 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -1051,6 +1051,74 @@ static const struct rvin_info rcar_info_m1 = {
.max_height = 2048,
 };
 
+static const struct rvin_info rcar_info_r8a7795 = {
+   .chip = RCAR_GEN3,
+   .use_mc = true,
+   .max_width = 4096,
+   .max_height = 4096,
+
+   .num_chsels = 6,
+   .chsels = {
+   {
+   { .csi = RVIN_CSI40, .chan = 0 },
+   { .csi = RVIN_CSI20, .chan = 0 },
+   { .csi = RVIN_CSI21, .chan = 0 },
+   { .csi = RVIN_CSI40, .chan = 0 },
+   { .csi = RVIN_CSI20, .chan = 0 },
+   { .csi = RVIN_CSI21, .chan = 0 },
+   }, {
+   { .csi = RVIN_CSI20, .chan = 0 },
+   { .csi = RVIN_CSI21, .chan = 0 },
+   { .csi = RVIN_CSI40, .chan = 0 },
+   { .csi = RVIN_CSI40, .chan = 1 },
+   { .csi = RVIN_CSI20, .chan = 1 },
+   { .csi = RVIN_CSI21, .chan = 1 },
+   }, {
+   { .csi = RVIN_CSI21, .chan = 0 },
+   { .csi = RVIN_CSI40, .chan = 0 },
+   { .csi = RVIN_CSI20, .chan = 0 },
+   { .csi = RVIN_CSI40, .chan = 2 },
+   { .csi = RVIN_CSI20, .chan = 2 },
+   { .csi = RVIN_CSI21, .chan = 2 },
+   }, {
+   { .csi = RVIN_CSI40, .chan = 1 },
+   { .csi = RVIN_CSI20, .chan = 1 },
+   { .csi = RVIN_CSI21, .chan = 1 },
+   { .csi = RVIN_CSI40, .chan = 3 },
+   { .csi = RVIN_CSI20, .chan = 3 },
+   { .csi = RVIN_CSI21, .chan = 3 },
+   }, {
+   { .csi = RVIN_CSI41, .chan = 0 },
+   { .csi = RVIN_CSI20, .chan = 0 },
+   { .csi = RVIN_CSI21, .chan = 0 },
+   { .csi = RVIN_CSI41, .chan = 0 },
+   { .csi = RVIN_CSI20, .chan = 0 },
+   { .csi = RVIN_CSI21, .chan = 0 },
+   }, {
+   { .csi = RVIN_CSI20, .chan = 0 },
+   { .csi = RVIN_CSI21, .chan = 0 },
+   { .csi = RVIN_CSI41, .chan = 0 },
+   { .csi = RVIN_CSI41, .chan = 1 },
+   { .csi = RVIN_CSI20, .chan = 1 },
+   { .csi = RVIN_CSI21, .chan = 1 },
+   }, {
+   { .csi = RVIN_CSI21, .chan = 0 },
+   { .csi = RVIN_CSI41, .chan = 0 },
+   { .csi = RVIN_CSI20, .chan = 0 },
+   { .csi = RVIN_CSI41, .chan = 2 },
+   { .csi = RVIN_CSI20, .chan = 2 },
+   { .csi = RVIN_CSI21, .chan = 2 },
+   }, {
+   { .csi = RVIN_CSI41, .chan = 1 },
+   { .csi = RVIN_CSI20, .chan = 1 },
+   { .csi = RVIN_CSI21, .chan = 1 },
+   { .csi = RVIN_CSI41, .chan = 3 },
+   { .csi = RVIN_CSI20, .chan = 3 },
+   { .csi = RVIN_CSI21, .chan = 3 },
+   },
+   },
+};
+
 static const struct rvin_info rcar_info_gen2 = {
.chip = RCAR_GEN2,
.use_mc = false,
@@ -1060,6 +1128,10 @@ static const struct rvin_info rcar_info_gen2 = {
 
 static const struct of_device_id rvin_of_id_table[] = {
{
+   .compatible = "renesas,vin-r8a7795",
+   .data = _info_r8a7795,
+   },
+   {
.compatible = "renesas,vin-r8a7794",
.data = _info_gen2,
},
-- 
2.12.0

[PATCH v3 21/27] rcar-vin: add group allocator functions

[Niklas Söderlund]

In media controller mode all VIN instances needs to be part of the same
media graph. There is also a need to each VIN instance to know and in
some cases be able to communicate with other VIN instances.

Add a allocator framework where the first VIN instance to be probed
creates a shared data structure and creates a media device.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 112 +++-
 drivers/media/platform/rcar-vin/rcar-vin.h  |  40 ++
 2 files changed, 149 insertions(+), 3 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index f560d27449b84882..c10770d5ec37816c 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -20,12 +20,110 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
 #include "rcar-vin.h"
 
 /* 
-
+ * Gen3 CSI2 Group Allocator
+ */
+
+static DEFINE_MUTEX(rvin_group_lock);
+static struct rvin_group *rvin_group_data;
+
+static void rvin_group_release(struct kref *kref)
+{
+   struct rvin_group *group =
+   container_of(kref, struct rvin_group, refcount);
+
+   mutex_lock(_group_lock);
+
+   media_device_unregister(>mdev);
+   media_device_cleanup(>mdev);
+
+   rvin_group_data = NULL;
+
+   mutex_unlock(_group_lock);
+
+   kfree(group);
+}
+
+static struct rvin_group *__rvin_group_allocate(struct rvin_dev *vin)
+{
+   struct rvin_group *group;
+
+   if (rvin_group_data) {
+   group = rvin_group_data;
+   kref_get(>refcount);
+   vin_dbg(vin, "%s: get group=%p\n", __func__, group);
+   return group;
+   }
+
+   group = kzalloc(sizeof(*group), GFP_KERNEL);
+   if (!group)
+   return NULL;
+
+   kref_init(>refcount);
+   rvin_group_data = group;
+
+   vin_dbg(vin, "%s: alloc group=%p\n", __func__, group);
+   return group;
+}
+
+static struct rvin_group *rvin_group_allocate(struct rvin_dev *vin)
+{
+   struct rvin_group *group;
+   struct media_device *mdev;
+   int ret;
+
+   mutex_lock(_group_lock);
+
+   group = __rvin_group_allocate(vin);
+   if (!group) {
+   mutex_unlock(_group_lock);
+   return ERR_PTR(-ENOMEM);
+   }
+
+   /* Init group data if its not already initialized */
+   mdev = >mdev;
+   if (!mdev->dev) {
+   mutex_init(>lock);
+   mdev->dev = vin->dev;
+
+   strlcpy(mdev->driver_name, "Renesas VIN",
+   sizeof(mdev->driver_name));
+   strlcpy(mdev->model, vin->dev->of_node->name,
+   sizeof(mdev->model));
+   strlcpy(mdev->bus_info, of_node_full_name(vin->dev->of_node),
+   sizeof(mdev->bus_info));
+   mdev->driver_version = LINUX_VERSION_CODE;
+   media_device_init(mdev);
+
+   ret = media_device_register(mdev);
+   if (ret) {
+   vin_err(vin, "Failed to register media device\n");
+   kref_put(>refcount, rvin_group_release);
+   mutex_unlock(_group_lock);
+   return ERR_PTR(ret);
+   }
+   }
+
+   vin->v4l2_dev.mdev = mdev;
+
+   mutex_unlock(_group_lock);
+
+   return group;
+}
+
+static void rvin_group_delete(struct rvin_dev *vin)
+{
+   vin_dbg(vin, "%s: group=%p\n", __func__, >group);
+   kref_put(>group->refcount, rvin_group_release);
+}
+
+/* 
-
  * Async notifier
  */
 
@@ -263,9 +361,13 @@ static int rvin_group_init(struct rvin_dev *vin)
 {
int ret;
 
+   vin->group = rvin_group_allocate(vin);
+   if (IS_ERR(vin->group))
+   return PTR_ERR(vin->group);
+
ret = rvin_v4l2_mc_probe(vin);
if (ret)
-   return ret;
+   goto error_group;
 
vin->pad.flags = MEDIA_PAD_FL_SINK;
ret = media_entity_pads_init(>vdev->entity, 1, >pad);
@@ -275,6 +377,8 @@ static int rvin_group_init(struct rvin_dev *vin)
return 0;
 error_v4l2:
rvin_v4l2_mc_remove(vin);
+error_group:
+   rvin_group_delete(vin);
 
return ret;
 }
@@ -398,10 +502,12 @@ static int rcar_vin_remove(struct platform_device *pdev)
 
v4l2_async_notifier_unregister(>notifier);
 
-   if (vin->info->use_mc)
+   if (vin->info->use_mc) {
rvin_v4l2_mc_remove(vin);
-   else
+   rvin_group_delete(vin);
+   } else {
rvin_v4l2_remove(vin);
+   }
 
rvin_dma_remove(vin);
 
diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h 
b/drivers/media/platform/rcar-vin/rcar-vin.h
index 

[PATCH v3 11/27] rcar-vin: do not allow changing scaling and composing while streaming

[Niklas Söderlund]

It is possible on Gen2 to change the registers controlling composing and
scaling while the stream is running. Is however not a good idea to do so
and could result in trouble. There are also no good reason to allow
this, remove immediate reflection in hardware registers from
vidioc_s_selection and only configure scaling and composing when the
stream starts.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-dma.c  | 2 +-
 drivers/media/platform/rcar-vin/rcar-v4l2.c | 3 ---
 drivers/media/platform/rcar-vin/rcar-vin.h  | 3 ---
 3 files changed, 1 insertion(+), 7 deletions(-)

diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c 
b/drivers/media/platform/rcar-vin/rcar-dma.c
index 286aafab533cda9d..ef029e4c7882322e 100644
--- a/drivers/media/platform/rcar-vin/rcar-dma.c
+++ b/drivers/media/platform/rcar-vin/rcar-dma.c
@@ -514,7 +514,7 @@ static void rvin_set_coeff(struct rvin_dev *vin, unsigned 
short xs)
rvin_write(vin, p_set->coeff_set[23], VNC8C_REG);
 }
 
-void rvin_crop_scale_comp(struct rvin_dev *vin)
+static void rvin_crop_scale_comp(struct rvin_dev *vin)
 {
u32 xs, ys;
 
diff --git a/drivers/media/platform/rcar-vin/rcar-v4l2.c 
b/drivers/media/platform/rcar-vin/rcar-v4l2.c
index e14f0aff8ceecc68..919040e40aec60f6 100644
--- a/drivers/media/platform/rcar-vin/rcar-v4l2.c
+++ b/drivers/media/platform/rcar-vin/rcar-v4l2.c
@@ -442,9 +442,6 @@ static int rvin_s_selection(struct file *file, void *fh,
return -EINVAL;
}
 
-   /* HW supports modifying configuration while running */
-   rvin_crop_scale_comp(vin);
-
return 0;
 }
 
diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h 
b/drivers/media/platform/rcar-vin/rcar-vin.h
index 6bf2e4ff8f6076c7..f1251c013d1d2d80 100644
--- a/drivers/media/platform/rcar-vin/rcar-vin.h
+++ b/drivers/media/platform/rcar-vin/rcar-vin.h
@@ -175,7 +175,4 @@ void rvin_v4l2_remove(struct rvin_dev *vin);
 
 const struct rvin_video_format *rvin_format_from_pixel(u32 pixelformat);
 
-/* Cropping, composing and scaling */
-void rvin_crop_scale_comp(struct rvin_dev *vin);
-
 #endif
-- 
2.12.0

[PATCH v3 22/27] rcar-vin: add chsel information to rvin_info

[Niklas Söderlund]

Each Gen3 SoC has a limited set of predefined routing possibilities for
which CSI-2 device and virtual channel can be routed to which VIN
instance. Prepare to store this information in the struct rvin_info.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-vin.h | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h 
b/drivers/media/platform/rcar-vin/rcar-vin.h
index 94258bf7cd58d097..386ede9c95d9aedb 100644
--- a/drivers/media/platform/rcar-vin/rcar-vin.h
+++ b/drivers/media/platform/rcar-vin/rcar-vin.h
@@ -35,6 +35,9 @@
 /* Max number on VIN instances that can be in a system */
 #define RCAR_VIN_NUM 8
 
+/* Max number of CHSEL values for any Gen3 SoC */
+#define RCAR_CHSEL_MAX 6
+
 enum chip_id {
RCAR_H1,
RCAR_M1,
@@ -91,6 +94,19 @@ struct rvin_graph_entity {
 
 struct rvin_group;
 
+
+/** struct rvin_group_chsel - Map a CSI2 device and channel for a CHSEL value
+ * @csi:   VIN internal number for CSI2 device
+ * @chan:  CSI-2 channel number on remote. Note that channel
+ * is not the same as VC. The CSI-2 hardware have 4
+ * channels it can output on but which VC is outputted
+ * on which channel is configurable inside the CSI-2.
+ */
+struct rvin_group_chsel {
+   enum rvin_csi_id csi;
+   unsigned int chan;
+};
+
 /**
  * struct rvin_info- Information about the particular VIN implementation
  * @chip:  type of VIN chip
@@ -98,6 +114,9 @@ struct rvin_group;
  *
  * max_width:  max input width the VIN supports
  * max_height: max input height the VIN supports
+ *
+ * num_chsels: number of possible chsel values for this VIN
+ * chsels: routing table VIN <-> CSI-2 for the chsel values
  */
 struct rvin_info {
enum chip_id chip;
@@ -105,6 +124,9 @@ struct rvin_info {
 
unsigned int max_width;
unsigned int max_height;
+
+   unsigned int num_chsels;
+   struct rvin_group_chsel chsels[RCAR_VIN_NUM][RCAR_CHSEL_MAX];
 };
 
 /**
-- 
2.12.0

[PATCH v3 20/27] rcar-vin: register a media pad if running in media controller mode

[Niklas Söderlund]

When running in media controller mode a media pad is needed, register
one.

Signed-off-by: Niklas Söderlund 
---
 drivers/media/platform/rcar-vin/rcar-core.c | 9 +
 drivers/media/platform/rcar-vin/rcar-vin.h  | 4 
 2 files changed, 13 insertions(+)

diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
b/drivers/media/platform/rcar-vin/rcar-core.c
index 7aaa01dee014d64b..f560d27449b84882 100644
--- a/drivers/media/platform/rcar-vin/rcar-core.c
+++ b/drivers/media/platform/rcar-vin/rcar-core.c
@@ -267,7 +267,16 @@ static int rvin_group_init(struct rvin_dev *vin)
if (ret)
return ret;
 
+   vin->pad.flags = MEDIA_PAD_FL_SINK;
+   ret = media_entity_pads_init(>vdev->entity, 1, >pad);
+   if (ret)
+   goto error_v4l2;
+
return 0;
+error_v4l2:
+   rvin_v4l2_mc_remove(vin);
+
+   return ret;
 }
 
 /* 
-
diff --git a/drivers/media/platform/rcar-vin/rcar-vin.h 
b/drivers/media/platform/rcar-vin/rcar-vin.h
index 6f2b1e28381678a9..06934313950253f4 100644
--- a/drivers/media/platform/rcar-vin/rcar-vin.h
+++ b/drivers/media/platform/rcar-vin/rcar-vin.h
@@ -103,6 +103,8 @@ struct rvin_info {
  * @notifier:  V4L2 asynchronous subdevs notifier
  * @digital:   entity in the DT for local digital subdevice
  *
+ * @pad:   pad for media controller
+ *
  * @lock:  protects @queue
  * @queue: vb2 buffers queue
  *
@@ -132,6 +134,8 @@ struct rvin_dev {
struct v4l2_async_notifier notifier;
struct rvin_graph_entity digital;
 
+   struct media_pad pad;
+
struct mutex lock;
struct vb2_queue queue;
 
-- 
2.12.0

[PATCH v3 03/27] media: entity: Add media_entity_has_route() function

[Niklas Söderlund]

From: Laurent Pinchart 

This is a wrapper around the media entity has_route operation.

Signed-off-by: Laurent Pinchart 
Signed-off-by: Michal Simek 
Signed-off-by: Sakari Ailus 
Signed-off-by: Niklas Söderlund 
---
 drivers/media/media-entity.c | 16 
 include/media/media-entity.h | 16 
 2 files changed, 32 insertions(+)

diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
index 5640ca29da8c9bbc..ccd991d2d3450ab3 100644
--- a/drivers/media/media-entity.c
+++ b/drivers/media/media-entity.c
@@ -244,6 +244,22 @@ EXPORT_SYMBOL_GPL(media_entity_pads_init);
  * Graph traversal
  */
 
+bool media_entity_has_route(struct media_entity *entity, unsigned int pad0,
+   unsigned int pad1)
+{
+   if (pad0 >= entity->num_pads || pad1 >= entity->num_pads)
+   return false;
+
+   if (pad0 == pad1)
+   return true;
+
+   if (!entity->ops || !entity->ops->has_route)
+   return true;
+
+   return entity->ops->has_route(entity, pad0, pad1);
+}
+EXPORT_SYMBOL_GPL(media_entity_has_route);
+
 static struct media_entity *
 media_entity_other(struct media_entity *entity, struct media_link *link)
 {
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index bcb08c1f8c6265e8..b896827b4ebdfaa6 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -830,6 +830,22 @@ __must_check int media_graph_walk_init(
struct media_graph *graph, struct media_device *mdev);
 
 /**
+ * media_entity_has_route - Check if two entity pads are connected internally
+ *
+ * @entity: The entity
+ * @pad0: The first pad index
+ * @pad1: The second pad index
+ *
+ * This function can be used to check whether two pads of an entity are
+ * connected internally in the entity.
+ *
+ * The caller must hold entity->graph_obj.mdev->mutex.
+ *
+ * Return: true if the pads are connected internally and false otherwise.
+ */
+bool media_entity_has_route(struct media_entity *entity, unsigned int pad0,
+   unsigned int pad1);
+/**
  * media_graph_walk_cleanup - Release resources used by graph walk.
  *
  * @graph: Media graph structure that will be used to walk the graph
-- 
2.12.0

[PATCH v3 00/27] rcar-vin: Add Gen3 with media controller support

[Niklas Söderlund]

Hi All,

This series enable Gen3 VIN support in rcar-vin driver for Renesas r8a7795 and 
r8a7796. It is based on top of v4.11-rc1.

Patches that previously have been part of this series have been broken out to a 
separate series since they fix issues in the rcar-vin driver which are not 
strictly related to the Gen3 MC enablement. This series depends on that 
patch series which is posted separately as '[PATCH 00/16] rcar-vin: fix 
issues with format and capturing'.

The driver is tested on both Renesas H3 (r8a7795) and M3-W (r8a7796) together 
with the rcar-csi2 driver (posted separately) and a prototype driver of the 
ADV7482 (not ready for upstream but publicly available). It is possible to 
capture both CVBS and HDMI video streams, v4l2-compliance passes with no 
errors and media-ctl can be used to change the routing and formats for 
the different entities in the media graph.

Gen2 compatibility is verified on Koelsch and no problems where found, video 
can be captured just like before and v4l2-compliance passes without errors or 
warnings.

I have started on a very basic test suite for the VIN driver at:

  https://git.ragnatech.se/vin-tests

And as before the state of the driver and information about how to test it can
be found on the elinux wiki:

  http://elinux.org/R-Car/Tests:rcar-vin

* Changes since v2
- Do not try to control the subdevices in the media graph from the rcar-vin 
  driver. Have user-space configure to format in the pipeline instead.
- Add link validation before starting the stream.
- Rework on how the subdevices are and the video node behave by defining 
  specific V4L2 operations for the MC mode of operation, this simplified the 
  driver quit a bit, thanks Laurent!
- Add a new 'renesas,id' DT property which is needed to to be able to keep the 
  VIN to CSI-2 routing table inside the driver. Previously this information was 
  taken from the CSI-2 DT node which is obviusly the wrong way to do things.  
  Thanks Laurent for pointing this out.
- Fixed a memory leek in the group allocator function.
- Return -EMLINK instead of -EBUSY if a MC link is not possible given the 
  current routing setup.
- Add comments to clarify that the 4 channels from the CSI-2 node is not 
  directly related to CSI-2 virtual channels, the CSI-2 node can output any VC 
  on any of its output channels.

* Changes since v1
- Remove unneeded casts as pointed out by Geert.
- Fix spelling and DT documentation as pointed out by Geert and Sergei, thanks!
- Refresh patch 2/32 with an updated version, thanks Sakari for pointing this
  out.
- Add Sakaris Ack to patch 1/32.
- Rebase on top of v4.9-rc1 instead of v4.9-rc3 to ease integration testing
  together with renesas-drivers tree.


Laurent Pinchart (2):
  media: entity: Add has_route entity operation
  media: entity: Add media_entity_has_route() function

Niklas Söderlund (24):
  rcar-vin: add Gen3 devicetree bindings documentation
  rcar-vin: move chip information to own struct
  rcar-vin: move max width and height information to chip information
  rcar-vin: change name of video device
  rcar-vin: move functions regarding scaling
  rcar-vin: all Gen2 boards can scale simplify logic
  rcar-vin: do not reset crop and compose when setting format
  rcar-vin: do not allow changing scaling and composing while streaming
  rcar-vin: read subdevice format for crop only when needed
  rcar-vin: do not cut height in two for top, bottom or alternate fields
  rcar-vin: move media bus configuration to struct rvin_info
  rcar-vin: enable Gen3 hardware configuration
  rcar-vin: add functions to manipulate Gen3 CHSEL value
  rcar-vin: prepare digital notifier for group notifier
  rcar-vin: add flag to switch to media controller mode
  rcar-vin: use different v4l2 operations in media controller mode
  rcar-vin: register a media pad if running in media controller mode
  rcar-vin: add group allocator functions
  rcar-vin: add chsel information to rvin_info
  rcar-vin: parse Gen3 OF and setup media graph
  rcar-vin: add link notify for Gen3
  rcar-vin: extend {start,stop}_streaming to work with media controller
  rcar-vin: enable support for r8a7795
  rcar-vin: enable support for r8a7796

Sakari Ailus (1):
  media: entity: Swap pads if route is checked from source to sink

 .../devicetree/bindings/media/rcar_vin.txt |  123 ++-
 drivers/media/media-entity.c   |   20 +
 drivers/media/platform/rcar-vin/Kconfig|2 +-
 drivers/media/platform/rcar-vin/rcar-core.c| 1066 +++-
 drivers/media/platform/rcar-vin/rcar-dma.c |  979 ++
 drivers/media/platform/rcar-vin/rcar-v4l2.c|  369 +--
 drivers/media/platform/rcar-vin/rcar-vin.h |  117 ++-
 include/media/media-entity.h   |   21 +
 8 files changed, 2127 insertions(+), 570 deletions(-)

-- 
2.12.0

Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event

[Pavel Machek]

On Mon 2017-03-13 10:45:38, Russell King - ARM Linux wrote:
> On Mon, Mar 13, 2017 at 11:02:34AM +0100, Hans Verkuil wrote:
> > On 03/11/2017 07:14 PM, Steve Longerbeam wrote:
> > > The event must be user visible, otherwise the user has no indication
> > > the error, and can't correct it by stream restart.
> > 
> > In that case the driver can detect this and call vb2_queue_error. It's
> > what it is there for.
> > 
> > The event doesn't help you since only this driver has this issue. So nobody
> > will watch this event, unless it is sw specifically written for this SoC.
> > 
> > Much better to call vb2_queue_error to signal a fatal error (which this
> > apparently is) since there are more drivers that do this, and vivid supports
> > triggering this condition as well.
> 
> So today, I can fiddle around with the IMX219 registers to help gain
> an understanding of how this sensor works.  Several of the registers
> (such as the PLL setup [*]) require me to disable streaming on the
> sensor while changing them.
> 
> This is something I've done many times while testing various ideas,
> and is my primary way of figuring out and testing such things.
> 
> Whenever I resume streaming (provided I've let the sensor stop
> streaming at a frame boundary) it resumes as if nothing happened.  If I
> stop the sensor mid-frame, then I get the rolling issue that Steve
> reports, but once the top of the frame becomes aligned with the top of
> the capture, everything then becomes stable again as if nothing happened.
> 
> The side effect of what you're proposing is that when I disable streaming
> at the sensor by poking at its registers, rather than the capture just
> stopping, an error is going to be delivered to gstreamer, and gstreamer
> is going to exit, taking the entire capture process down.
> 
> This severely restricts the ability to be able to develop and test
> sensor drivers.

Well, but kernel should do what is best for production, not what is
best for driver debugging.

And yes, I guess you can have #ifdef or module parameter or something
switching for behaviour you prefer when you are debugging. But for
production, vb2_queue_error() seems to be the right solution.

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 v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

[Pavel Machek]

Hi!

> > Mid-layer is difficult... there are _hundreds_ of possible
> > pipeline setups. If it should live in kernel or in userspace is a
> > question... but I don't think having it in kernel helps in any way.
> 
> Mid-layer is difficult, because we either need to feed some
> library with knowledge for all kernel drivers or we need to improve
> the MC API to provide more details.
> 
> For example, several drivers used to expose entities via the
> generic MEDIA_ENT_T_DEVNODE to represent entities of different
> types. See, for example, entities 1, 5 and 7 (and others) at:
>
> > https://mchehab.fedorapeople.org/mc-next-gen/igepv2_omap3isp.png

Well... we provide enough information, so that device-specific code
does not have to be in kernel.

There are few types of ENT_T_DEVNODE there. "ISP CCP2" does not really
provide any functionality to the user. It just has to be there,
because the pipeline needs to be connected. "ISP Preview" provides
format conversion. "ISP Resizer" provides rescaling.

I'm not sure if it ever makes sense to use "ISP Preview
output". Normally you take data for display from "ISP Resizer
output". (Would there be some power advantage from that?)

> A device-specific code could either be hardcoding the entity number
> or checking for the entity strings to add some logic to setup
> controls on those "unknown" entities, a generic app won't be able 
> to do anything with them, as it doesn't know what function(s) such
> entity provide.

Generic app should know if it wants RGGB10 data, then it can use "ISP
CCDC output", or if it wants "cooked" data suitable for display, then
it wants to use "ISP Resizer output". Once application knows what
output it wants, there's just one path through the system. So being
able to tell the ENT_T_DEVNODEs apart does not seem to be critical.

OTOH, for useful camera application, different paths are needed at
different phases.
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 v5 00/39] i.MX Media Driver

[Steve Longerbeam]

On 03/12/2017 02:09 PM, Russell King - ARM Linux wrote:

On Sun, Mar 12, 2017 at 08:40:37PM +, Russell King - ARM Linux wrote:

On Sun, Mar 12, 2017 at 01:36:32PM -0700, Steve Longerbeam wrote:

But hold on, if my logic is correct, then why did the CSI power-off
get reached in your case, multiple times? Yes I think there is a bug,
link_notify() is not checking if the link has already been disabled.
I will fix this. But I'm surprised media core's link_notify handling
doesn't do this.

Well, I think there's something incredibly fishy going on here.  I
turned that dev_dbg() at the top of the function into a dev_info(),
and I get:

root@hbi2ex:~# dmesg |grep -A2 imx-ipuv3-csi
[   53.370949] imx-ipuv3-csi imx-ipuv3-csi.0: power OFF
[   53.371015] [ cut here ]
[   53.371075] WARNING: CPU: 0 PID: 1515 at 
drivers/staging/media/imx/imx-media-csi.c:806 csi_s_power+0xb8/0xd0 
[imx_media_csi]
--
[   53.372624] imx-ipuv3-csi imx-ipuv3-csi.0: power OFF
[   53.372637] [ cut here ]
[   53.372663] WARNING: CPU: 0 PID: 1515 at 
drivers/staging/media/imx/imx-media-csi.c:806 csi_s_power+0xb8/0xd0 
[imx_media_csi]

There isn't a power on event being generated before these two power
off events.  I don't see a power on event even when I attempt to
start streaming either (which fails due to the lack of bayer
support.)

Found it - my imx219 driver returns '1' from its s_power function when
powering up, which triggers a bug in your code - when imx_media_set_power()
fails to power up, you call imx_media_set_power() telling it to power
everything off - including devices that are already powered off.


Yep, there's a bug in the error cleanup in imx_media_pipeline_set_power().
On error, it needs to backout by calling s_power(off) as it is doing, 
but not

through the whole pipeline, but needs to stop at the subdev encountered
just before the subdev that failed. This was causing the s_power() 
imbalance.

I will fix.




This is really bad news - s_power() may be called via other paths,
such as when the subdev is opened.


I don't think that is a problem, as long as power_count is working
as it should, and the caller from the other paths has not created an
imbalance.

Steve

Re: [PATCH v5 00/39] i.MX Media Driver

[Steve Longerbeam]

On 03/12/2017 03:10 PM, Mauro Carvalho Chehab wrote:

Em Sun, 12 Mar 2017 21:13:24 +
Russell King - ARM Linux  escreveu:


On Sun, Mar 12, 2017 at 05:59:28PM -0300, Mauro Carvalho Chehab wrote:

Yet, udev/systemd has some rules that provide an unique name for V4L
devices at /lib/udev/rules.d/60-persistent-v4l.rules. Basically, it
runs a small application (v4l_id) with creates a persistent symling
using rules like this:

KERNEL=="video*", ENV{ID_SERIAL}=="?*", 
SYMLINK+="v4l/by-id/$env{ID_BUS}-$env{ID_SERIAL}-video-index$attr{index}"

Those names are stored at /dev/v4l/by-path.

This doesn't help:

$ ls -Al /dev/v4l/by-id/
total 0
lrwxrwxrwx 1 root root 13 Mar 12 19:54 
usb-Sonix_Technology_Co.__Ltd._USB_2.0_Camera-video-index0 -> ../../video10
$ ls -Al /dev/v4l/by-path/
total 0
lrwxrwxrwx 1 root root 12 Mar 12 19:54 platform-204.vpu-video-index0 -> 
../../video0
lrwxrwxrwx 1 root root 12 Mar 12 19:54 platform-204.vpu-video-index1 -> 
../../video1
lrwxrwxrwx 1 root root 12 Mar 12 20:53 platform-capture-subsystem-video-index0 
-> ../../video2
lrwxrwxrwx 1 root root 12 Mar 12 20:53 platform-capture-subsystem-video-index1 
-> ../../video3
lrwxrwxrwx 1 root root 12 Mar 12 20:53 platform-capture-subsystem-video-index2 
-> ../../video4
lrwxrwxrwx 1 root root 12 Mar 12 20:53 platform-capture-subsystem-video-index3 
-> ../../video5
lrwxrwxrwx 1 root root 12 Mar 12 20:53 platform-capture-subsystem-video-index4 
-> ../../video6
lrwxrwxrwx 1 root root 12 Mar 12 20:53 platform-capture-subsystem-video-index5 
-> ../../video7
lrwxrwxrwx 1 root root 12 Mar 12 20:53 platform-capture-subsystem-video-index6 
-> ../../video8
lrwxrwxrwx 1 root root 12 Mar 12 20:53 platform-capture-subsystem-video-index7 
-> ../../video9
lrwxrwxrwx 1 root root 13 Mar 12 19:54 platform-ci_hdrc.0-usb-0:1:1.0-video-index0 
-> ../../video10

The problem is the "platform-capture-subsystem-video-index" entries.
These themselves change order.  For instance, I now have:

- entity 72: ipu1_csi0 capture (1 pad, 1 link)
  type Node subtype V4L flags 0
  device node name /dev/video6

which means it's platform-capture-subsystem-video-index4.  Before, it
was platform-capture-subsystem-video-index2.

That's a driver problem. v4l_id gets information to build the persistent
name from the result of VIDIOC_QUERYCAP.

In the case of Exynos gsc driver, for example, the information is here:

static int gsc_m2m_querycap(struct file *file, void *fh,
   struct v4l2_capability *cap)
{
struct gsc_ctx *ctx = fh_to_ctx(fh);
struct gsc_dev *gsc = ctx->gsc_dev;

strlcpy(cap->driver, GSC_MODULE_NAME, sizeof(cap->driver));
strlcpy(cap->card, GSC_MODULE_NAME " gscaler", sizeof(cap->card));
snprintf(cap->bus_info, sizeof(cap->bus_info), "platform:%s",
 dev_name(>pdev->dev));
cap->device_caps = V4L2_CAP_STREAMING | V4L2_CAP_VIDEO_M2M_MPLANE |
V4L2_CAP_VIDEO_CAPTURE_MPLANE | V4L2_CAP_VIDEO_OUTPUT_MPLANE;

cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS;
return 0;
}

See that the bus_info there is filled with:

snprintf(cap->bus_info, sizeof(cap->bus_info), "platform:%s", 
dev_name(>pdev->dev));

 From the output you printed, it seems that the i.MX6 is just doing:
snprintf(cap->bus_info, sizeof(cap->bus_info), "platform:");
for some devices.


imx6 is setting bus_info string on all capture devices as:

snprintf(cap->bus_info, sizeof(cap->bus_info),
 "platform:%s", dev_name(priv->dev));

dev_name(priv->dev) is the device name of the attached subdev.
So the bus_info string, at least for attached CSI subdevs, should
be "platform:imx-ipuv3-csi".

Maybe there is something else missing, I haven't had a chance to
look at this yet.

Steve




If you change the i.MX6 driver to do the same, you'll likely be able to
have unique names there too.

Regards,
Mauro

Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event

[Steve Longerbeam]

On 03/14/2017 09:47 AM, Russell King - ARM Linux wrote:

On Tue, Mar 14, 2017 at 12:21:31PM -0400, Nicolas Dufresne wrote:

My main concern here based on what I'm reading, is that this driver is
not even able to notice immediately that a produced frame was corrupted
(because it's out of sync). From usability perspective, this is really
bad. Can't the driver derive a clock from some irq and calculate for
each frame if the timing was correct ? And if not mark the buffer with
V4L2_BUF_FLAG_ERROR ?

One of the issues of measuring timing with IRQs is the fact that the
IRQ subsystem only allows one IRQ to run at a time.  If an IRQ takes
a relatively long time to process, then it throws the timing of other
IRQs out.

If you're going to decide that a buffer should be marked in error on
the basis of an interrupt arriving late, this can trigger spuriously.

It wasn't that long ago that USB HID was regularly eating something
like 20ms of interrupt time... that's been solved, but that doesn't
mean all cases are solved - there are still interrupt handlers in the
kernel that are on the order of milliseconds to complete.

Given the quality I observe of some USB serial devices (eg, running at
115200 baud, but feeling like they deliver characters to userspace at
9600 baud) I wouldn't be surprised if some USB serial drivers eat a lot
of IRQ time... and if so, all it'll take is to plug such a device in
to disrupt capture.

That sounds way too fragile to me.


exactly, hence the imx6 timer input capture support.

Steve

Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event

[Russell King - ARM Linux]

On Tue, Mar 14, 2017 at 12:21:31PM -0400, Nicolas Dufresne wrote:
> My main concern here based on what I'm reading, is that this driver is
> not even able to notice immediately that a produced frame was corrupted
> (because it's out of sync). From usability perspective, this is really
> bad. Can't the driver derive a clock from some irq and calculate for
> each frame if the timing was correct ? And if not mark the buffer with
> V4L2_BUF_FLAG_ERROR ?

One of the issues of measuring timing with IRQs is the fact that the
IRQ subsystem only allows one IRQ to run at a time.  If an IRQ takes
a relatively long time to process, then it throws the timing of other
IRQs out.

If you're going to decide that a buffer should be marked in error on
the basis of an interrupt arriving late, this can trigger spuriously.

It wasn't that long ago that USB HID was regularly eating something
like 20ms of interrupt time... that's been solved, but that doesn't
mean all cases are solved - there are still interrupt handlers in the
kernel that are on the order of milliseconds to complete.

Given the quality I observe of some USB serial devices (eg, running at
115200 baud, but feeling like they deliver characters to userspace at
9600 baud) I wouldn't be surprised if some USB serial drivers eat a lot
of IRQ time... and if so, all it'll take is to plug such a device in
to disrupt capture.

That sounds way too fragile to me.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event

[Steve Longerbeam]

On 03/14/2017 09:21 AM, Nicolas Dufresne wrote:

Le lundi 13 mars 2017 à 10:45 +, Russell King - ARM Linux a écrit :

On Mon, Mar 13, 2017 at 11:02:34AM +0100, Hans Verkuil wrote:

On 03/11/2017 07:14 PM, Steve Longerbeam wrote:

The event must be user visible, otherwise the user has no indication
the error, and can't correct it by stream restart.

In that case the driver can detect this and call vb2_queue_error. It's
what it is there for.

The event doesn't help you since only this driver has this issue. So nobody
will watch this event, unless it is sw specifically written for this SoC.

Much better to call vb2_queue_error to signal a fatal error (which this
apparently is) since there are more drivers that do this, and vivid supports
triggering this condition as well.

So today, I can fiddle around with the IMX219 registers to help gain
an understanding of how this sensor works.  Several of the registers
(such as the PLL setup [*]) require me to disable streaming on the
sensor while changing them.

This is something I've done many times while testing various ideas,
and is my primary way of figuring out and testing such things.

Whenever I resume streaming (provided I've let the sensor stop
streaming at a frame boundary) it resumes as if nothing happened.  If I
stop the sensor mid-frame, then I get the rolling issue that Steve
reports, but once the top of the frame becomes aligned with the top of
the capture, everything then becomes stable again as if nothing happened.

The side effect of what you're proposing is that when I disable streaming
at the sensor by poking at its registers, rather than the capture just
stopping, an error is going to be delivered to gstreamer, and gstreamer
is going to exit, taking the entire capture process down.

Indeed, there is no recovery attempt in GStreamer code, and it's hard
for an higher level programs to handle this. Nothing prevents from
adding something of course, but the errors are really un-specific, so
it would be something pretty blind. For what it has been tested, this
case was never met, usually the error is triggered by a USB camera
being un-plugged, a driver failure or even a firmware crash. Most of
the time, this is not recoverable.

My main concern here based on what I'm reading, is that this driver is
not even able to notice immediately that a produced frame was corrupted
(because it's out of sync). From usability perspective, this is really
bad.


First, this is an isolated problem, specific to bt.656 and it only
occurs when disrupting the analog video source signal in some
way (by unplugging the RCA cable from the ADV718x connector
for example).

Second, there is no DMA status support in i.MX6 to catch these
shifted bt.656 codes, and the ADV718x does not provide any
status indicators of this event either. So monitoring frame intervals
is the only solution available, until FSL/NXP issues a new silicon rev.



  Can't the driver derive a clock from some irq and calculate for
each frame if the timing was correct ?


That's what is being done, essentially.


  And if not mark the buffer with
V4L2_BUF_FLAG_ERROR ?


I prefer to keep the private event, V4L2_BUF_FLAG_ERROR is too
unspecific.

Steve





This severely restricts the ability to be able to develop and test
sensor drivers.

So, I strongly disagree with you.

Loss of capture frames is not necessarily a fatal error - as I have been
saying repeatedly.  In Steve's case, there's some unknown interaction
between the source and iMX6 hardware that is causing the instability,
but that is simply not true of other sources, and I oppose any idea that
we should cripple the iMX6 side of the capture based upon just one
hardware combination where this is a problem.

Indeed, it happens all the time with slow USB port and UVC devices.
Though, the driver is well aware, and mark the buffers with
V4L2_BUF_FLAG_ERROR.


Steve suggested that the problem could be in the iMX6 CSI block - and I
note comparing Steve's code with the code in FSL's repository that there
are some changes that are missing in Steve's code to do with the CCIR656
sync code setup, particularly for >8 bit.  The progressive CCIR656 8-bit
setup looks pretty similar though - but I think what needs to be asked
is whether the same problem is visible using the FSL/NXP vendor kernel.


* - the PLL setup is something that requires research at the moment.
Sony's official position (even to their customers) is that they do not
supply the necessary information, instead they expect customers to tell
them the capture settings they want, and Sony will throw the values into
a spreadsheet, and they'll supply the register settings back to the
customer.  Hence, the only way to proceed with a generic driver for
this sensor is to experiment, and experimenting requires the ability to
pause the stream at the sensor while making changes.  Take this away,
and we're stuck with the tables-of-register-settings-for-set-of-fixed-
capture-settings approach.  I've made a lot 

Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event

[Nicolas Dufresne]

Le lundi 13 mars 2017 à 10:45 +, Russell King - ARM Linux a écrit :
> On Mon, Mar 13, 2017 at 11:02:34AM +0100, Hans Verkuil wrote:
> > On 03/11/2017 07:14 PM, Steve Longerbeam wrote:
> > > The event must be user visible, otherwise the user has no indication
> > > the error, and can't correct it by stream restart.
> > 
> > In that case the driver can detect this and call vb2_queue_error. It's
> > what it is there for.
> > 
> > The event doesn't help you since only this driver has this issue. So nobody
> > will watch this event, unless it is sw specifically written for this SoC.
> > 
> > Much better to call vb2_queue_error to signal a fatal error (which this
> > apparently is) since there are more drivers that do this, and vivid supports
> > triggering this condition as well.
> 
> So today, I can fiddle around with the IMX219 registers to help gain
> an understanding of how this sensor works.  Several of the registers
> (such as the PLL setup [*]) require me to disable streaming on the
> sensor while changing them.
> 
> This is something I've done many times while testing various ideas,
> and is my primary way of figuring out and testing such things.
> 
> Whenever I resume streaming (provided I've let the sensor stop
> streaming at a frame boundary) it resumes as if nothing happened.  If I
> stop the sensor mid-frame, then I get the rolling issue that Steve
> reports, but once the top of the frame becomes aligned with the top of
> the capture, everything then becomes stable again as if nothing happened.
> 
> The side effect of what you're proposing is that when I disable streaming
> at the sensor by poking at its registers, rather than the capture just
> stopping, an error is going to be delivered to gstreamer, and gstreamer
> is going to exit, taking the entire capture process down.

Indeed, there is no recovery attempt in GStreamer code, and it's hard
for an higher level programs to handle this. Nothing prevents from
adding something of course, but the errors are really un-specific, so
it would be something pretty blind. For what it has been tested, this
case was never met, usually the error is triggered by a USB camera
being un-plugged, a driver failure or even a firmware crash. Most of
the time, this is not recoverable.

My main concern here based on what I'm reading, is that this driver is
not even able to notice immediately that a produced frame was corrupted
(because it's out of sync). From usability perspective, this is really
bad. Can't the driver derive a clock from some irq and calculate for
each frame if the timing was correct ? And if not mark the buffer with
V4L2_BUF_FLAG_ERROR ?

> 
> This severely restricts the ability to be able to develop and test
> sensor drivers.
> 
> So, I strongly disagree with you.
> 
> Loss of capture frames is not necessarily a fatal error - as I have been
> saying repeatedly.  In Steve's case, there's some unknown interaction
> between the source and iMX6 hardware that is causing the instability,
> but that is simply not true of other sources, and I oppose any idea that
> we should cripple the iMX6 side of the capture based upon just one
> hardware combination where this is a problem.

Indeed, it happens all the time with slow USB port and UVC devices.
Though, the driver is well aware, and mark the buffers with
V4L2_BUF_FLAG_ERROR.

> 
> Steve suggested that the problem could be in the iMX6 CSI block - and I
> note comparing Steve's code with the code in FSL's repository that there
> are some changes that are missing in Steve's code to do with the CCIR656
> sync code setup, particularly for >8 bit.  The progressive CCIR656 8-bit
> setup looks pretty similar though - but I think what needs to be asked
> is whether the same problem is visible using the FSL/NXP vendor kernel.
> 
> 
> * - the PLL setup is something that requires research at the moment.
> Sony's official position (even to their customers) is that they do not
> supply the necessary information, instead they expect customers to tell
> them the capture settings they want, and Sony will throw the values into
> a spreadsheet, and they'll supply the register settings back to the
> customer.  Hence, the only way to proceed with a generic driver for
> this sensor is to experiment, and experimenting requires the ability to
> pause the stream at the sensor while making changes.  Take this away,
> and we're stuck with the tables-of-register-settings-for-set-of-fixed-
> capture-settings approach.  I've made a lot of progress away from this
> which is all down to the flexibility afforded by _not_ killing the
> capture process.
> 

signature.asc
Description: This is a digitally signed message part

Re: [PATCH] media: mtk-jpeg: fix continuous log "Context is NULL"

[李務誠]

On Tue, Mar 14, 2017 at 10:21 PM, Minghsiu Tsai
 wrote:
> The symptom is continuous log "mtk-jpeg 18004000.jpegdec: Context is NULL"
> in kernel log. It is becauese the error handling in irq doesn't clear
> interrupt.
>
> The calling flow like as below when issue happen
> mtk_jpeg_device_run()
> mtk_jpeg_job_abort()
>   v4l2_m2m_job_finish() -> m2m_dev->curr_ctx = NULL;
> mtk_jpeg_dec_irq()
>   v4l2_m2m_get_curr_priv()
>  -> m2m_dev->curr_ctx == NULL
>  -> return NULL
> log "Context is NULL"
>
> There is race condition between job_abort() and irq. In order to simplify
> code, don't want to add extra flag to maintain state, empty job_abort() and
> clear interrupt before v4l2_m2m_get_curr_priv() in irq.
>
> Signed-off-by: Minghsiu Tsai 
Reviewed-by: Wu-Cheng Li 
Tested-by: Wu-Cheng Li 
> ---
>  drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 14 ++
>  1 file changed, 2 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c 
> b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> index b10183f..c02bc7f 100644
> --- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> +++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> @@ -862,15 +862,6 @@ static int mtk_jpeg_job_ready(void *priv)
>
>  static void mtk_jpeg_job_abort(void *priv)
>  {
> -   struct mtk_jpeg_ctx *ctx = priv;
> -   struct mtk_jpeg_dev *jpeg = ctx->jpeg;
> -   struct vb2_buffer *src_buf, *dst_buf;
> -
> -   src_buf = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
> -   dst_buf = v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> -   v4l2_m2m_buf_done(to_vb2_v4l2_buffer(src_buf), VB2_BUF_STATE_ERROR);
> -   v4l2_m2m_buf_done(to_vb2_v4l2_buffer(dst_buf), VB2_BUF_STATE_ERROR);
> -   v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
>  }
>
>  static struct v4l2_m2m_ops mtk_jpeg_m2m_ops = {
> @@ -941,6 +932,8 @@ static irqreturn_t mtk_jpeg_dec_irq(int irq, void *priv)
> u32 dec_ret;
> int i;
>
> +   dec_ret = mtk_jpeg_dec_get_int_status(jpeg->dec_reg_base);
> +   dec_irq_ret = mtk_jpeg_dec_enum_result(dec_ret);
> ctx = v4l2_m2m_get_curr_priv(jpeg->m2m_dev);
> if (!ctx) {
> v4l2_err(>v4l2_dev, "Context is NULL\n");
> @@ -951,9 +944,6 @@ static irqreturn_t mtk_jpeg_dec_irq(int irq, void *priv)
> dst_buf = v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> jpeg_src_buf = mtk_jpeg_vb2_to_srcbuf(src_buf);
>
> -   dec_ret = mtk_jpeg_dec_get_int_status(jpeg->dec_reg_base);
> -   dec_irq_ret = mtk_jpeg_dec_enum_result(dec_ret);
> -
> if (dec_irq_ret >= MTK_JPEG_DEC_RESULT_UNDERFLOW)
> mtk_jpeg_dec_reset(jpeg->dec_reg_base);
>
> --
> 1.9.1
>

Re: [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t

[James Bottomley]

On Tue, 2017-03-14 at 12:29 +, Reshetova, Elena wrote:
> > Elena Reshetova  writes:
> > 
> > > refcount_t type and corresponding API should be
> > > used instead of atomic_t when the variable is used as
> > > a reference counter. This allows to avoid accidental
> > > refcounter overflows that might lead to use-after-free
> > > situations.
> > > 
> > > Signed-off-by: Elena Reshetova 
> > > Signed-off-by: Hans Liljestrand 
> > > Signed-off-by: Kees Cook 
> > > Signed-off-by: David Windsor 
> > > ---
> > >  drivers/md/md.c | 6 +++---
> > >  drivers/md/md.h | 3 ++-
> > >  2 files changed, 5 insertions(+), 4 deletions(-)
> > 
> > When booting linux-next (specifically 5be4921c9958ec) I'm seeing
> > the
> > backtrace below. I suspect this patch is just exposing an existing
> > issue?
> 
> Yes, we have actually been following this issue in the another
> thread. 
> It looks like the object is re-used somehow, but I can't quite
> understand how just by reading the code. 
> This was what I put into the previous thread:
> 
> "The log below indicates that you are using your refcounter in a bit
> weird way in mddev_find(). 
> However, I can't find the place (just by reading the code) where you
> would increment refcounter from zero (vs. setting it to one).
> It looks like you either iterate over existing nodes (and increment
> their counters, which should be >= 1 at the time of increment) or
> create a new node, but then mddev_init() sets the counter to 1. "
> 
> If you can help to understand what is going on with the object
> creation/destruction, would be appreciated!
> 
> Also Shaohua Li stopped this patch coming from his tree since the 
> issue was caught at that time, so we are not going to merge this 
> until we figure it out. 

Asking on the correct list (dm-devel) would have got you the easy
answer:  The refcount behind mddev->active is a genuine atomic.  It has
refcount properties but only if the array fails to initialise (in that
case, final put kills it).  Once it's added to the system as a gendisk,
it cannot be freed until md_free().  Thus its ->active count can go to
zero (when it becomes inactive; usually because of an unmount). On a
simple allocation regardless of outcome, the last executed statement in
md_alloc is mddev_put(): that destroys the device if we didn't manage
to create it or returns 0 and adds an inactive device to the system
which the user can get with mddev_find().

James

Re: [RFC PATCH 00/12] Ion cleanup in preparation for moving out of staging

[Benjamin Gaignard]

2017-03-13 22:09 GMT+01:00 Laura Abbott :
> On 03/12/2017 12:05 PM, Daniel Vetter wrote:
>> On Sun, Mar 12, 2017 at 2:34 PM, Benjamin Gaignard
>>  wrote:
>>> 2017-03-09 18:38 GMT+01:00 Laura Abbott :
 On 03/09/2017 02:00 AM, Benjamin Gaignard wrote:
> 2017-03-06 17:04 GMT+01:00 Daniel Vetter :
>> On Mon, Mar 06, 2017 at 11:58:05AM +0100, Mark Brown wrote:
>>> On Mon, Mar 06, 2017 at 11:40:41AM +0100, Daniel Vetter wrote:
>>>
 No one gave a thing about android in upstream, so Greg KH just dumped 
 it
 all into staging/android/. We've discussed ION a bunch of times, 
 recorded
 anything we'd like to fix in staging/android/TODO, and Laura's patch
 series here addresses a big chunk of that.
>>>
 This is pretty much the same approach we (gpu folks) used to de-stage 
 the
 syncpt stuff.
>>>
>>> Well, there's also the fact that quite a few people have issues with the
>>> design (like Laurent).  It seems like a lot of them have either got more
>>> comfortable with it over time, or at least not managed to come up with
>>> any better ideas in the meantime.
>>
>> See the TODO, it has everything a really big group (look at the patch for
>> the full Cc: list) figured needs to be improved at LPC 2015. We don't 
>> just
>> merge stuff because merging stuff is fun :-)
>>
>> Laurent was even in that group ...
>> -Daniel
>
> For me those patches are going in the right direction.
>
> I still have few questions:
> - since alignment management has been remove from ion-core, should it
> be also removed from ioctl structure ?

 Yes, I think I'm going to go with the suggestion to fixup the ABI
 so we don't need the compat layer and as part of that I'm also
 dropping the align argument.

> - can you we ride off ion_handle (at least in userland) and only
> export a dma-buf descriptor ?

 Yes, I think this is the right direction given we're breaking
 everything anyway. I was debating trying to keep the two but
 moving to only dma bufs is probably cleaner. The only reason
 I could see for keeping the handles is running out of file
 descriptors for dma-bufs but that seems unlikely.
>
> In the future how can we add new heaps ?
> Some platforms have very specific memory allocation
> requirements (just have a look in the number of gem custom allocator in 
> drm)
> Do you plan to add heap type/mask for each ?

 Yes, that was my thinking.
>>>
>>> My concern is about the policy to adding heaps, will you accept
>>> "customs" heap per
>>> platforms ? per devices ? or only generic ones ?
>>> If you are too strict, we will have lot of out-of-tree heaps and if
>>> you accept of of them
>>> it will be a nightmare to maintain
>>
>> I think ion should expose any heap that's also directly accessible to
>> devices using dma_alloc(_coherent). That should leave very few things
>> left, like your SMA heap.
>>
>>> Another point is how can we put secure rules (like selinux policy) on
>>> heaps since all the allocations
>>> go to the same device (/dev/ion) ? For example, until now, in Android
>>> we have to give the same
>>> access rights to all the process that use ION.
>>> It will become problem when we will add secure heaps because we won't
>>> be able to distinguish secure
>>> processes to standard ones or set specific policy per heaps.
>>> Maybe I'm wrong here but I have never see selinux policy checking an
>>> ioctl field but if that
>>> exist it could be a solution.
>>
>> Hm, we might want to expose all the heaps as individual
>> /dev/ion_$heapname nodes? Should we do this from the start, since
>> we're massively revamping the uapi anyway (imo not needed, current
>> state seems to work too)?
>> -Daniel
>>
>
> I thought about that. One advantage with separate /dev/ion_$heap

Should we use /devi/ion/$heap instead of /dev/ion_$heap ?
I think it would be easier for user to look into one directory rather
then in whole /dev to find the heaps

> is that we don't have to worry about a limit of 32 possible
> heaps per system (32-bit heap id allocation field). But dealing
> with an ioctl seems easier than names. Userspace might be less
> likely to hardcode random id numbers vs. names as well.

In the futur I think that heap type will be replaced by a "get caps"
ioctl which will
describe heap capabilities. At least that is my understanding of kernel part
of "unix memory allocator" project

>
> Thanks,
> Laura

[PATCH] media: mtk-jpeg: fix continuous log "Context is NULL"

[Minghsiu Tsai]

The symptom is continuous log "mtk-jpeg 18004000.jpegdec: Context is NULL"
in kernel log. It is becauese the error handling in irq doesn't clear
interrupt.

The calling flow like as below when issue happen
mtk_jpeg_device_run()
mtk_jpeg_job_abort()
  v4l2_m2m_job_finish() -> m2m_dev->curr_ctx = NULL;
mtk_jpeg_dec_irq()
  v4l2_m2m_get_curr_priv()
 -> m2m_dev->curr_ctx == NULL
 -> return NULL
log "Context is NULL"

There is race condition between job_abort() and irq. In order to simplify
code, don't want to add extra flag to maintain state, empty job_abort() and
clear interrupt before v4l2_m2m_get_curr_priv() in irq.

Signed-off-by: Minghsiu Tsai 
---
 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 14 ++
 1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c 
b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
index b10183f..c02bc7f 100644
--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -862,15 +862,6 @@ static int mtk_jpeg_job_ready(void *priv)
 
 static void mtk_jpeg_job_abort(void *priv)
 {
-   struct mtk_jpeg_ctx *ctx = priv;
-   struct mtk_jpeg_dev *jpeg = ctx->jpeg;
-   struct vb2_buffer *src_buf, *dst_buf;
-
-   src_buf = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
-   dst_buf = v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
-   v4l2_m2m_buf_done(to_vb2_v4l2_buffer(src_buf), VB2_BUF_STATE_ERROR);
-   v4l2_m2m_buf_done(to_vb2_v4l2_buffer(dst_buf), VB2_BUF_STATE_ERROR);
-   v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
 }
 
 static struct v4l2_m2m_ops mtk_jpeg_m2m_ops = {
@@ -941,6 +932,8 @@ static irqreturn_t mtk_jpeg_dec_irq(int irq, void *priv)
u32 dec_ret;
int i;
 
+   dec_ret = mtk_jpeg_dec_get_int_status(jpeg->dec_reg_base);
+   dec_irq_ret = mtk_jpeg_dec_enum_result(dec_ret);
ctx = v4l2_m2m_get_curr_priv(jpeg->m2m_dev);
if (!ctx) {
v4l2_err(>v4l2_dev, "Context is NULL\n");
@@ -951,9 +944,6 @@ static irqreturn_t mtk_jpeg_dec_irq(int irq, void *priv)
dst_buf = v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
jpeg_src_buf = mtk_jpeg_vb2_to_srcbuf(src_buf);
 
-   dec_ret = mtk_jpeg_dec_get_int_status(jpeg->dec_reg_base);
-   dec_irq_ret = mtk_jpeg_dec_enum_result(dec_ret);
-
if (dec_irq_ret >= MTK_JPEG_DEC_RESULT_UNDERFLOW)
mtk_jpeg_dec_reset(jpeg->dec_reg_base);
 
-- 
1.9.1

Re: [PATCH v6 1/3] drm_fourcc: Add new P010, P016 video format

[Ander Conselvan De Oliveira]

On Tue, 2017-03-07 at 04:27 +0800, Ayaka wrote:
> 
> 從我的 iPad 傳送
> 
> > Ville Syrjälä  於 2017年3月7日 上午2:34 寫道：
> > 
> > > On Tue, Mar 07, 2017 at 01:58:23AM +0800, Ayaka wrote:
> > > 
> > > 
> > > 從我的 iPad 傳送
> > > 
> > > > > Ville Syrjälä  於 2017年3月6日 下午9:06 寫道：
> > > > > 
> > > > > On Sun, Mar 05, 2017 at 06:00:31PM +0800, Randy Li wrote:
> > > > > P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits
> > > > > per channel video format.
> > > > > 
> > > > > P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits
> > > > > per channel video format.
> > > > > 
> > > > > V3: Added P012 and fixed cpp for P010
> > > > > V4: format definition refined per review
> > > > > V5: Format comment block for each new pixel format
> > > > > V6: reversed Cb/Cr order in comments
> > > > > v7: reversed Cb/Cr order in comments of header files, remove
> > > > > the wrong part of commit message.
> > > > 
> > > > What? Why? You just undid what Clint did in v6.
> > > 
> > > He missed a file also keeping the wrong description of rockchip.
> > 
> > I don't follow. Who missed what exactly?
> 
> What he sent is v5, I increase the order number twice in the message, it 
> confuse me as well. 
> I think Clint forgot the include/uapi/drm/drm_fourcc.h .

Clint did send a v6, and that updates "include/uapi/drm/drm_fourcc.h":

https://patchwork.freedesktop.org/patch/141342/


Ander

> > 
> > 
> > > > 
> > > > > 
> > > > > Cc: Daniel Stone 
> > > > > Cc: Ville Syrjälä 
> > > > > 
> > > > > Signed-off-by: Randy Li 
> > > > > Signed-off-by: Clint Taylor 
> > > > > ---
> > > > > drivers/gpu/drm/drm_fourcc.c  |  3 +++
> > > > > include/uapi/drm/drm_fourcc.h | 21 +
> > > > > 2 files changed, 24 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/drm_fourcc.c 
> > > > > b/drivers/gpu/drm/drm_fourcc.c
> > > > > index 90d2cc8..3e0fd58 100644
> > > > > --- a/drivers/gpu/drm/drm_fourcc.c
> > > > > +++ b/drivers/gpu/drm/drm_fourcc.c
> > > > > @@ -165,6 +165,9 @@ const struct drm_format_info 
> > > > > *__drm_format_info(u32 format)
> > > > >   { .format = DRM_FORMAT_UYVY,.depth = 0,  .num_planes = 
> > > > > 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
> > > > >   { .format = DRM_FORMAT_VYUY,.depth = 0,  .num_planes = 
> > > > > 1, .cpp = { 2, 0, 0 }, .hsub = 2, .vsub = 1 },
> > > > >   { .format = DRM_FORMAT_AYUV,.depth = 0,  .num_planes = 
> > > > > 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 },
> > > > > +{ .format = DRM_FORMAT_P010,.depth = 0,  .num_planes 
> > > > > = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
> > > > > +{ .format = DRM_FORMAT_P012,.depth = 0,  .num_planes 
> > > > > = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
> > > > > +{ .format = DRM_FORMAT_P016,.depth = 0,  .num_planes 
> > > > > = 2, .cpp = { 2, 4, 0 }, .hsub = 2, .vsub = 2 },
> > > > >   };
> > > > > 
> > > > >   unsigned int i;
> > > > > diff --git a/include/uapi/drm/drm_fourcc.h 
> > > > > b/include/uapi/drm/drm_fourcc.h
> > > > > index ef20abb..306f979 100644
> > > > > --- a/include/uapi/drm/drm_fourcc.h
> > > > > +++ b/include/uapi/drm/drm_fourcc.h
> > > > > @@ -128,6 +128,27 @@ extern "C" {
> > > > > #define DRM_FORMAT_NV42fourcc_code('N', 'V', '4', '2') /* 
> > > > > non-subsampled Cb:Cr plane */
> > > > > 
> > > > > /*
> > > > > + * 2 plane YCbCr MSB aligned
> > > > > + * index 0 = Y plane, [15:0] Y:x [10:6] little endian
> > > > > + * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [10:6:10:6] little endian
> > > > > + */
> > > > > +#define DRM_FORMAT_P010fourcc_code('P', '0', '1', '0') /* 
> > > > > 2x2 subsampled Cb:Cr plane 10 bits per channel */
> > > > > +
> > > > > +/*
> > > > > + * 2 plane YCbCr MSB aligned
> > > > > + * index 0 = Y plane, [15:0] Y:x [12:4] little endian
> > > > > + * index 1 = Cb:Cr plane, [31:0] Cb:x:Cr:x [12:4:12:4] little endian
> > > > > + */
> > > > > +#define DRM_FORMAT_P012fourcc_code('P', '0', '1', '2') /* 
> > > > > 2x2 subsampled Cb:Cr plane 12 bits per channel */
> > > > > +
> > > > > +/*
> > > > > + * 2 plane YCbCr MSB aligned
> > > > > + * index 0 = Y plane, [15:0] Y little endian
> > > > > + * index 1 = Cb:Cr plane, [31:0] Cb:Cr [16:16] little endian
> > > > > + */
> > > > > +#define DRM_FORMAT_P016fourcc_code('P', '0', '1', '6') /* 
> > > > > 2x2 subsampled Cb:Cr plane 16 bits per channel */
> > > > > +
> > > > > +/*
> > > > > * 3 plane YCbCr
> > > > > * index 0: Y plane, [7:0] Y
> > > > > * index 1: Cb plane, [7:0] Cb
> > > > > -- 
> > > > > 2.7.4
> > > > 
> > > > -- 
> > > > Ville Syrjälä
> > > > Intel OTC
> > 
> > -- 
> > Ville Syrjälä
> > Intel OTC
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> 

RE: [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t

[Reshetova, Elena]

> Elena Reshetova  writes:
> 
> > refcount_t type and corresponding API should be
> > used instead of atomic_t when the variable is used as
> > a reference counter. This allows to avoid accidental
> > refcounter overflows that might lead to use-after-free
> > situations.
> >
> > Signed-off-by: Elena Reshetova 
> > Signed-off-by: Hans Liljestrand 
> > Signed-off-by: Kees Cook 
> > Signed-off-by: David Windsor 
> > ---
> >  drivers/md/md.c | 6 +++---
> >  drivers/md/md.h | 3 ++-
> >  2 files changed, 5 insertions(+), 4 deletions(-)
> 
> When booting linux-next (specifically 5be4921c9958ec) I'm seeing the
> backtrace below. I suspect this patch is just exposing an existing
> issue?

Yes, we have actually been following this issue in the another thread. 
It looks like the object is re-used somehow, but I can't quite understand how 
just by reading the code. 
This was what I put into the previous thread:

"The log below indicates that you are using your refcounter in a bit weird way 
in mddev_find(). 
However, I can't find the place (just by reading the code) where you would 
increment refcounter from zero (vs. setting it to one).
It looks like you either iterate over existing nodes (and increment their 
counters, which should be >= 1 at the time of increment) or create a new node, 
but then mddev_init() sets the counter to 1. "

If you can help to understand what is going on with the object 
creation/destruction, would be appreciated!

Also Shaohua Li stopped this patch coming from his tree since the issue was 
caught at that time, so we are not going to merge this until we figure it out. 

Best Regards,
Elena.

> 
> cheers
> 
> 
> [0.230738] md: Waiting for all devices to be available before autodetect
> [0.230742] md: If you don't use raid, use raid=noautodetect
> [0.230962] refcount_t: increment on 0; use-after-free.
> [0.230988] [ cut here ]
> [0.230996] WARNING: CPU: 0 PID: 1 at lib/refcount.c:114
> .refcount_inc+0x5c/0x70
> [0.231001] Modules linked in:
> [0.231006] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc1-gccN-next-
> 20170310-g5be4921 #1
> [0.231012] task: c0004940 task.stack: c0004944
> [0.231016] NIP: c05ac6bc LR: c05ac6b8 CTR:
> c0743390
> [0.231021] REGS: c00049443160 TRAP: 0700   Not tainted  (4.11.0-rc1-
> gccN-next-20170310-g5be4921)
> [0.231026] MSR: 80029032 
> [0.231033]   CR: 24024422  XER: 000c
> [0.231038] CFAR: c0a5356c SOFTE: 1
> [0.231038] GPR00: c05ac6b8 c000494433e0 c1079d00
> 002b
> [0.231038] GPR04:  00ef 
> c10418a0
> [0.231038] GPR08: 4af8 c0ecc9a8 c0ecc9a8
> 
> [0.231038] GPR12: 28024824 c6bb 
> c00049443a00
> [0.231038] GPR16:  c00049443a10 
> 
> [0.231038] GPR20:   c0f7dd20
> 
> [0.231038] GPR24: 014080c0 c12060b8 c1206080
> 0009
> [0.231038] GPR28: c0f7dde0 0090 
> c000461ae800
> [0.231100] NIP [c05ac6bc] .refcount_inc+0x5c/0x70
> [0.231104] LR [c05ac6b8] .refcount_inc+0x58/0x70
> [0.231108] Call Trace:
> [0.231112] [c000494433e0] [c05ac6b8] .refcount_inc+0x58/0x70
> (unreliable)
> [0.231120] [c00049443450] [c086c008]
> .mddev_find+0x1e8/0x430
> [0.231125] [c00049443530] [c0872b6c] .md_open+0x2c/0x140
> [0.231132] [c000494435c0] [c03962a4]
> .__blkdev_get+0xd4/0x520
> [0.231138] [c00049443690] [c0396cc0] .blkdev_get+0x1c0/0x4f0
> [0.231145] [c00049443790] [c0336d64]
> .do_dentry_open.isra.1+0x2a4/0x410
> [0.231152] [c00049443830] [c03523f4]
> .path_openat+0x624/0x1580
> [0.231157] [c00049443990] [c0354ce4]
> .do_filp_open+0x84/0x120
> [0.231163] [c00049443b10] [c0338d74]
> .do_sys_open+0x214/0x300
> [0.231170] [c00049443be0] [c0da69ac]
> .md_run_setup+0xa0/0xec
> [0.231176] [c00049443c60] [c0da4fbc]
> .prepare_namespace+0x60/0x240
> [0.231182] [c00049443ce0] [c0da47a8]
> .kernel_init_freeable+0x330/0x36c
> [0.231190] [c00049443db0] [c000dc44] .kernel_init+0x24/0x160
> [0.231197] [c00049443e30] [c000badc]
> .ret_from_kernel_thread+0x58/0x7c
> [0.231202] Instruction dump:
> [0.231206] 6000 3d22ffee 89296bfb 2f89 409effdc 3c62ffc6 3921
> 3d42ffee
> [0.231216] 38630928 992a6bfb 484a6e79 6000 <0fe0> 4bb8
> 6000 6000
> [

Re: [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t

[Michael Ellerman]

Elena Reshetova  writes:

> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a reference counter. This allows to avoid accidental
> refcounter overflows that might lead to use-after-free
> situations.
>
> Signed-off-by: Elena Reshetova 
> Signed-off-by: Hans Liljestrand 
> Signed-off-by: Kees Cook 
> Signed-off-by: David Windsor 
> ---
>  drivers/md/md.c | 6 +++---
>  drivers/md/md.h | 3 ++-
>  2 files changed, 5 insertions(+), 4 deletions(-)

When booting linux-next (specifically 5be4921c9958ec) I'm seeing the
backtrace below. I suspect this patch is just exposing an existing
issue?

cheers


[0.230738] md: Waiting for all devices to be available before autodetect
[0.230742] md: If you don't use raid, use raid=noautodetect
[0.230962] refcount_t: increment on 0; use-after-free.
[0.230988] [ cut here ]
[0.230996] WARNING: CPU: 0 PID: 1 at lib/refcount.c:114 
.refcount_inc+0x5c/0x70
[0.231001] Modules linked in:
[0.231006] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
4.11.0-rc1-gccN-next-20170310-g5be4921 #1
[0.231012] task: c0004940 task.stack: c0004944
[0.231016] NIP: c05ac6bc LR: c05ac6b8 CTR: c0743390
[0.231021] REGS: c00049443160 TRAP: 0700   Not tainted  
(4.11.0-rc1-gccN-next-20170310-g5be4921)
[0.231026] MSR: 80029032 
[0.231033]   CR: 24024422  XER: 000c
[0.231038] CFAR: c0a5356c SOFTE: 1 
[0.231038] GPR00: c05ac6b8 c000494433e0 c1079d00 
002b 
[0.231038] GPR04:  00ef  
c10418a0 
[0.231038] GPR08: 4af8 c0ecc9a8 c0ecc9a8 
 
[0.231038] GPR12: 28024824 c6bb  
c00049443a00 
[0.231038] GPR16:  c00049443a10  
 
[0.231038] GPR20:   c0f7dd20 
 
[0.231038] GPR24: 014080c0 c12060b8 c1206080 
0009 
[0.231038] GPR28: c0f7dde0 0090  
c000461ae800 
[0.231100] NIP [c05ac6bc] .refcount_inc+0x5c/0x70
[0.231104] LR [c05ac6b8] .refcount_inc+0x58/0x70
[0.231108] Call Trace:
[0.231112] [c000494433e0] [c05ac6b8] .refcount_inc+0x58/0x70 
(unreliable)
[0.231120] [c00049443450] [c086c008] .mddev_find+0x1e8/0x430
[0.231125] [c00049443530] [c0872b6c] .md_open+0x2c/0x140
[0.231132] [c000494435c0] [c03962a4] .__blkdev_get+0xd4/0x520
[0.231138] [c00049443690] [c0396cc0] .blkdev_get+0x1c0/0x4f0
[0.231145] [c00049443790] [c0336d64] 
.do_dentry_open.isra.1+0x2a4/0x410
[0.231152] [c00049443830] [c03523f4] .path_openat+0x624/0x1580
[0.231157] [c00049443990] [c0354ce4] .do_filp_open+0x84/0x120
[0.231163] [c00049443b10] [c0338d74] .do_sys_open+0x214/0x300
[0.231170] [c00049443be0] [c0da69ac] .md_run_setup+0xa0/0xec
[0.231176] [c00049443c60] [c0da4fbc] 
.prepare_namespace+0x60/0x240
[0.231182] [c00049443ce0] [c0da47a8] 
.kernel_init_freeable+0x330/0x36c
[0.231190] [c00049443db0] [c000dc44] .kernel_init+0x24/0x160
[0.231197] [c00049443e30] [c000badc] 
.ret_from_kernel_thread+0x58/0x7c
[0.231202] Instruction dump:
[0.231206] 6000 3d22ffee 89296bfb 2f89 409effdc 3c62ffc6 3921 
3d42ffee 
[0.231216] 38630928 992a6bfb 484a6e79 6000 <0fe0> 4bb8 6000 
6000 
[0.231226] ---[ end trace 8c51f269ad91ffc2 ]---
[0.231233] md: Autodetecting RAID arrays.
[0.231236] md: autorun ...
[0.231239] md: ... autorun DONE.
[0.234188] EXT4-fs (sda4): mounting ext3 file system using the ext4 
subsystem
[0.250506] refcount_t: underflow; use-after-free.
[0.250531] [ cut here ]
[0.250537] WARNING: CPU: 0 PID: 3 at lib/refcount.c:207 
.refcount_dec_not_one+0x104/0x120
[0.250542] Modules linked in:
[0.250546] CPU: 0 PID: 3 Comm: kworker/0:0 Tainted: GW   
4.11.0-rc1-gccN-next-20170310-g5be4921 #1
[0.250553] Workqueue: events .delayed_fput
[0.250557] task: c00049404900 task.stack: c00049448000
[0.250562] NIP: c05ac964 LR: c05ac960 CTR: c0743390
[0.250567] REGS: c0004944b530 TRAP: 0700   Tainted: GW
(4.11.0-rc1-gccN-next-20170310-g5be4921)
[0.250572] MSR: 80029032 
[0.250578]   CR: 24002422  XER: 0007
[0.250584] CFAR: c0a5356c SOFTE: 1 
[0.250584] GPR00: c05ac960 

Re: [Patch v2 11/11] Documention: v4l: Documentation for HEVC CIDs

[Smitha T Murthy]

On Tue, 2017-03-07 at 13:08 +0100, Andrzej Hajda wrote: 
> On 03.03.2017 10:07, Smitha T Murthy wrote:
> > Added V4l2 controls for HEVC encoder
> 
> It should be rather "Document controls for HEVC encoder" or sth similar.
> 
> In general most of comments are in previous patch.
> Few additional comments:
> - please be careful about control names - they are exported to userspace
> and becomes ABI, so it will be difficult to change them later (this
> comment is rather to previous patch),
> - please provide good documentation as for most users this documentation
> will be the only available source of information,
> - in short: bugs in the driver can be easily fixed(usually), wrong
> control names will be hard to fix, weak documentation will prevent using it.
> 
> And regarding this patch:
> - please expand all acronyms (pb, tmv, BIT,...),
> - please consider using menu instead of numbers for profile, level,
> tier, types, generally everywhere where control value enumerates
> 'things' and is not a pure number (coefficient, counter,...),
> - if control is per-frame please drop it, V4L2 does not support it at
> the moment ( I suppose ),
> 
> Regards
> Andrzej
> 
> 
Ok I will change the patch description.
I will try to document each control more elaborately and check the
control names again. I do understand your concern regarding the wrong
documentation, I will try to make more understandable and helpful.
I will expand the macro names in the next version. I will
create a menu for controls where it is applicable.
Thank you so much for your review.

Regards,
Smitha 
> 

Re: [Patch v2 10/11] s5p-mfc: Add support for HEVC encoder

[Smitha T Murthy]

On Tue, 2017-03-07 at 12:33 +0100, Andrzej Hajda wrote: 
> On 03.03.2017 10:07, Smitha T Murthy wrote:
> > Add HEVC encoder support and necessary registers, V4L2 CIDs,
> > and hevc encoder parameters
> >
> > Signed-off-by: Smitha T Murthy 
> > ---
> >  drivers/media/platform/s5p-mfc/regs-mfc-v10.h   |   28 +-
> >  drivers/media/platform/s5p-mfc/s5p_mfc.c|1 +
> >  drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c |3 +
> >  drivers/media/platform/s5p-mfc/s5p_mfc_common.h |   55 ++-
> >  drivers/media/platform/s5p-mfc/s5p_mfc_enc.c|  595 
> > +++
> >  drivers/media/platform/s5p-mfc/s5p_mfc_opr.h|8 +
> >  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |  200 
> >  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h |8 +
> >  8 files changed, 896 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h 
> > b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> > index 846dcf5..caf02ff 100644
> > --- a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> > +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> > @@ -20,13 +20,35 @@
> >  #define S5P_FIMV_MFC_STATE_V10 0x7124
> >  #define S5P_FIMV_D_STATIC_BUFFER_ADDR_V10  0xF570
> >  #define S5P_FIMV_D_STATIC_BUFFER_SIZE_V10  0xF574
> > +#define S5P_FIMV_E_NUM_T_LAYER_V10 0xFBAC
> > +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER0_V10  0xFBB0
> > +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER1_V10  0xFBB4
> > +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER2_V10  0xFBB8
> > +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER3_V10  0xFBBC
> > +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER4_V10  0xFBC0
> > +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER5_V10  0xFBC4
> > +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER6_V10  0xFBC8
> > +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER0_V100xFD18
> > +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER1_V100xFD1C
> > +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER2_V100xFD20
> > +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER3_V100xFD24
> > +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER4_V100xFD28
> > +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER5_V100xFD2C
> > +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER6_V100xFD30
> > +#define S5P_FIMV_E_HEVC_OPTIONS_V100xFDD4
> > +#define S5P_FIMV_E_HEVC_REFRESH_PERIOD_V10 0xFDD8
> > +#define S5P_FIMV_E_HEVC_CHROMA_QP_OFFSET_V10   0xFDDC
> > +#define S5P_FIMV_E_HEVC_LF_BETA_OFFSET_DIV2_V100xFDE0
> > +#define S5P_FIMV_E_HEVC_LF_TC_OFFSET_DIV2_V10  0xFDE4
> > +#define S5P_FIMV_E_HEVC_NAL_CONTROL_V100xFDE8
> >  
> >  /* MFCv10 Context buffer sizes */
> >  #define MFC_CTX_BUF_SIZE_V10   (30 * SZ_1K)/* 30KB */
> >  #define MFC_H264_DEC_CTX_BUF_SIZE_V10  (2 * SZ_1M) /* 2MB */
> >  #define MFC_OTHER_DEC_CTX_BUF_SIZE_V10 (20 * SZ_1K)/* 20KB */
> >  #define MFC_H264_ENC_CTX_BUF_SIZE_V10  (100 * SZ_1K)   /* 100KB */
> > -#define MFC_OTHER_ENC_CTX_BUF_SIZE_V10 (15 * SZ_1K)/* 15KB */
> > +#define MFC_HEVC_ENC_CTX_BUF_SIZE_V10  (30 * SZ_1K)/* 30KB */
> > +#define MFC_OTHER_ENC_CTX_BUF_SIZE_V10  (15 * SZ_1K)   /* 15KB */
> >  
> >  /* MFCv10 variant defines */
> >  #define MAX_FW_SIZE_V10(SZ_1M) /* 1MB */
> > @@ -58,5 +80,9 @@
> >  #define ENC_V100_VP8_ME_SIZE(x, y) \
> > ENC_V100_BASE_SIZE(x, y)
> >  
> > +#define ENC_V100_HEVC_ME_SIZE(x, y)\
> > +   (((x + 3) * (y + 3) * 32)   \
> > ++ ((y * 128) + 1280) * DIV_ROUND_UP(x, 4))
> > +
> >  #endif /*_REGS_MFC_V10_H*/
> >  
> > diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
> > b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> > index b014038..b01c556 100644
> > --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
> > +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> > @@ -1549,6 +1549,7 @@ static int s5p_mfc_resume(struct device *dev)
> > .h264_dec_ctx   = MFC_H264_DEC_CTX_BUF_SIZE_V10,
> > .other_dec_ctx  = MFC_OTHER_DEC_CTX_BUF_SIZE_V10,
> > .h264_enc_ctx   = MFC_H264_ENC_CTX_BUF_SIZE_V10,
> > +   .hevc_enc_ctx   = MFC_HEVC_ENC_CTX_BUF_SIZE_V10,
> > .other_enc_ctx  = MFC_OTHER_ENC_CTX_BUF_SIZE_V10,
> >  };
> >  
> > diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c 
> > b/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c
> > index 102b47e..7521fce 100644
> > --- a/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c
> > +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c
> > @@ -122,6 +122,9 @@ static int s5p_mfc_open_inst_cmd_v6(struct s5p_mfc_ctx 
> > *ctx)
> > case S5P_MFC_CODEC_VP8_ENC:
> > codec_type = S5P_FIMV_CODEC_VP8_ENC_V7;
> > break;
> > +   case S5P_MFC_CODEC_HEVC_ENC:
> > +   codec_type = S5P_FIMV_CODEC_HEVC_ENC;
> > +   break;
> >

Re: [Patch v2 07/11] Documentation: v4l: Documentation for HEVC v4l2 definition

[Smitha T Murthy]

On Tue, 2017-03-07 at 09:39 +0100, Andrzej Hajda wrote: 
> On 03.03.2017 10:07, Smitha T Murthy wrote:
> > Add V4L2 definition for HEVC compressed format
> > 
> > Signed-off-by: Smitha T Murthy 
> 
> Reviewed-by: Andrzej Hajda 
> 
> 
Thank you for the review.
Regards,
Smitha T Murthy 
> 
> > ---
> >  Documentation/media/uapi/v4l/pixfmt-013.rst |5 +
> >  1 files changed, 5 insertions(+), 0 deletions(-)
> > 
> > diff --git a/Documentation/media/uapi/v4l/pixfmt-013.rst 
> > b/Documentation/media/uapi/v4l/pixfmt-013.rst
> > index 728d7ed..ff4cac2 100644
> > --- a/Documentation/media/uapi/v4l/pixfmt-013.rst
> > +++ b/Documentation/media/uapi/v4l/pixfmt-013.rst
> > @@ -90,3 +90,8 @@ Compressed Formats
> >- ``V4L2_PIX_FMT_VP9``
> >- 'VP90'
> >- VP9 video elementary stream.
> > +* .. _V4L2-PIX-FMT-HEVC:
> > +
> > +  - ``V4L2_PIX_FMT_HEVC``
> > +  - 'HEVC'
> > +  - HEVC video elementary stream.
> > 
> 
> 

Re: [Patch v2 04/11] s5p-mfc: Support MFCv10.10 buffer requirements

[Smitha T Murthy]

On Mon, 2017-03-06 at 15:48 +0100, Andrzej Hajda wrote: 
> On 03.03.2017 10:07, Smitha T Murthy wrote:
> > Aligning the luma_dpb_size, chroma_dpb_size, mv_size and me_buffer_size
> > for MFCv10.10.
> >
> > Signed-off-by: Smitha T Murthy 
> > ---
> >  drivers/media/platform/s5p-mfc/regs-mfc-v10.h   |   19 +
> >  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |   99 
> > ++-
> >  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h |2 +
> >  3 files changed, 99 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h 
> > b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> > index bd671a5..dafcf9d 100644
> > --- a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> > +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> > @@ -32,5 +32,24 @@
> >  #define MFC_VERSION_V100xA0
> >  #define MFC_NUM_PORTS_V10  1
> >  
> > +/* MFCv10 codec defines*/
> > +#define S5P_FIMV_CODEC_HEVC_ENC 26
> > +
> > +/* Encoder buffer size for MFC v10.0 */
> > +#define ENC_V100_BASE_SIZE(x, y) \
> > +   (((x + 3) * (y + 3) * 8) \
> > +   +  ((y * 64) + 1280) * DIV_ROUND_UP(x, 8))
> > +
> > +#define ENC_V100_H264_ME_SIZE(x, y) \
> > +   (ENC_V100_BASE_SIZE(x, y) \
> > +   + (DIV_ROUND_UP(x * y, 64) * 32))
> > +
> > +#define ENC_V100_MPEG4_ME_SIZE(x, y) \
> > +   (ENC_V100_BASE_SIZE(x, y) \
> > +   + (DIV_ROUND_UP(x * y, 128) * 16))
> > +
> > +#define ENC_V100_VP8_ME_SIZE(x, y) \
> > +   ENC_V100_BASE_SIZE(x, y)
> > +
> >  #endif /*_REGS_MFC_V10_H*/
> >  
> > diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c 
> > b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> > index 5f0da0b..d4c75eb 100644
> > --- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> > +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> > @@ -45,6 +45,8 @@
> >  
> >  #define IS_MFCV6_V2(dev) (!IS_MFCV7_PLUS(dev) && dev->fw_ver == MFC_FW_V2)
> >  
> > +#define calc_param(value, align) (DIV_ROUND_UP(value, align) * align)
> 
> I think it is functionally the same as ALIGN, please drop it and use
> ALIGN instead.
> 
Ok I will use ALIGN. 
> > +
> >  /* Allocate temporary buffers for decoding */
> >  static int s5p_mfc_alloc_dec_temp_buffers_v6(struct s5p_mfc_ctx *ctx)
> >  {
> > @@ -64,6 +66,7 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct 
> > s5p_mfc_ctx *ctx)
> >  {
> > struct s5p_mfc_dev *dev = ctx->dev;
> > unsigned int mb_width, mb_height;
> > +   unsigned int lcu_width = 0, lcu_height = 0;
> > int ret;
> >  
> > mb_width = MB_WIDTH(ctx->img_width);
> > @@ -74,7 +77,9 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct 
> > s5p_mfc_ctx *ctx)
> >   ctx->luma_size, ctx->chroma_size, ctx->mv_size);
> > mfc_debug(2, "Totals bufs: %d\n", ctx->total_dpb_count);
> > } else if (ctx->type == MFCINST_ENCODER) {
> > -   if (IS_MFCV8_PLUS(dev))
> > +   if (IS_MFCV10(dev)) {
> > +   ctx->tmv_buffer_size = 0;
> > +   } else if (IS_MFCV8_PLUS(dev))
> > ctx->tmv_buffer_size = S5P_FIMV_NUM_TMV_BUFFERS_V6 *
> > ALIGN(S5P_FIMV_TMV_BUFFER_SIZE_V8(mb_width, mb_height),
> > S5P_FIMV_TMV_BUFFER_ALIGN_V6);
> > @@ -82,13 +87,36 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct 
> > s5p_mfc_ctx *ctx)
> > ctx->tmv_buffer_size = S5P_FIMV_NUM_TMV_BUFFERS_V6 *
> > ALIGN(S5P_FIMV_TMV_BUFFER_SIZE_V6(mb_width, mb_height),
> > S5P_FIMV_TMV_BUFFER_ALIGN_V6);
> > -
> > -   ctx->luma_dpb_size = ALIGN((mb_width * mb_height) *
> > -   S5P_FIMV_LUMA_MB_TO_PIXEL_V6,
> > -   S5P_FIMV_LUMA_DPB_BUFFER_ALIGN_V6);
> > -   ctx->chroma_dpb_size = ALIGN((mb_width * mb_height) *
> > -   S5P_FIMV_CHROMA_MB_TO_PIXEL_V6,
> > -   S5P_FIMV_CHROMA_DPB_BUFFER_ALIGN_V6);
> > +   if (IS_MFCV10(dev)) {
> > +   lcu_width = enc_lcu_width(ctx->img_width);
> > +   lcu_height = enc_lcu_height(ctx->img_height);
> > +   if (ctx->codec_mode != S5P_FIMV_CODEC_HEVC_ENC) {
> > +   ctx->luma_dpb_size =
> > +   ALIGN(calc_param((mb_width * 16), 64)
> > +   * calc_param((mb_height * 16), 32)
> > +   + 64, 64);
> ALIGN is not necessary here, as argument is already aligned.
I will remove ALIGN and take care of the same for below. 
> > +   ctx->chroma_dpb_size =
> > +   ALIGN(calc_param((mb_width * 16), 64)
> > +   * (mb_height * 8)
> > +   + 64, 64);
> 
> ditto
> > +   } else {
> > +   ctx->luma_dpb_size =
> > +   

Re: [Patch v2 09/11] v4l2: Add v4l2 control IDs for HEVC encoder

[Smitha T Murthy]

On Tue, 2017-03-07 at 09:48 +0100, Andrzej Hajda wrote: 
> On 03.03.2017 10:07, Smitha T Murthy wrote:
> > Add v4l2 controls for HEVC encoder
> >
> > Signed-off-by: Smitha T Murthy 
> > ---
> >  drivers/media/v4l2-core/v4l2-ctrls.c |   51 +
> >  include/uapi/linux/v4l2-controls.h   |  129 
> > ++
> >  2 files changed, 180 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
> > b/drivers/media/v4l2-core/v4l2-ctrls.c
> > index 47001e2..b3ec7a3 100644
> > --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> > +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> > @@ -775,6 +775,57 @@ static bool is_new_manual(const struct v4l2_ctrl 
> > *master)
> > case V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP:return "VPX 
> > P-Frame QP Value";
> > case V4L2_CID_MPEG_VIDEO_VPX_PROFILE:   return "VPX 
> > Profile";
> >  
> > +   /* HEVC controls */
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP:   return "HEVC I 
> > frame QP value";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_P_FRAME_QP:   return "HEVC P 
> > frame QP value";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_B_FRAME_QP:   return "HEVC B 
> > frame QP value";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP:   return "HEVC 
> > Minimum QP value";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP:   return "HEVC 
> > Maximum QP value";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_ADAPTIVE_RC_DARK: return "HEVC 
> > Dark region adaptive";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_ADAPTIVE_RC_SMOOTH:   return "HEVC 
> > Smooth region adaptive";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_ADAPTIVE_RC_STATIC:   return "HEVC 
> > Static region adaptive";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_ADAPTIVE_RC_ACTIVITY: return "HEVC 
> > Region adaptive rate control";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_PROFILE:  return "HEVC 
> > Profile";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_LEVEL:return "HEVC 
> > Level";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_TIER_FLAG:return "HEVC 
> > tier_flag default is Main";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_RC_FRAME_RATE:return "HEVC 
> > Frame rate";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_MAX_PARTITION_DEPTH:  return "HEVC 
> > Maximum coding unit depth";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_REF_NUMBER_FOR_PFRAMES:   return "HEVC 
> > Number of reference frames for P Frames";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_REFRESH_TYPE: return "HEVC 
> > Refresh type";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_CONST_INTRA_PRED_ENABLE:  return "HEVC 
> > Constant intra prediction enable";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_LOSSLESS_CU_ENABLE:   return "HEVC 
> > Lossless encoding enable";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_WAVEFRONT_ENABLE: return "HEVC 
> > Wavefront enable";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_LF_DISABLE:   return "HEVC 
> > Loop filter disable";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_LF_SLICE_BOUNDARY:return "HEVC 
> > Loop filtering across slice boundary or not";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_LTR_ENABLE:   return "HEVC 
> > long term reference enable";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_HIERARCHICAL_QP_ENABLE:   return "HEVC QP 
> > values for temporal layer";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_TYPE: return "HEVC 
> > Hierarchical Coding Type";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_LAYER:return "HEVC 
> > Hierarchical Coding Layer";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_LAYER_QP:return "HEVC 
> > Hierarchical Coding Layer QP";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_LAYER_BIT0:return 
> > "HEVC Hierarchical Coding Layer BIT0";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_LAYER_BIT1:return 
> > "HEVC Hierarchical Coding Layer BIT1";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_LAYER_BIT2:return 
> > "HEVC Hierarchical Coding Layer BIT2";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_LAYER_BIT3:return 
> > "HEVC Hierarchical Coding Layer BIT3";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_LAYER_BIT4:return 
> > "HEVC Hierarchical Coding Layer BIT4";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_LAYER_BIT5:return 
> > "HEVC Hierarchical Coding Layer BIT5";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_LAYER_BIT6:return 
> > "HEVC Hierarchical Coding Layer BIT6";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_LAYER_CH:return "HEVC 
> > Hierarchical Coding Layer Change";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_SIGN_DATA_HIDING: return "HEVC 
> > Sign data hiding";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_GENERAL_PB_ENABLE:return "HEVC 
> > General pb enable";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_TEMPORAL_ID_ENABLE:   return "HEVC 
> > Temporal id 

Re: [Patch v2 05/11] videodev2.h: Add v4l2 definition for HEVC

[Smitha T Murthy]

On Mon, 2017-03-06 at 15:52 +0100, Andrzej Hajda wrote: 
> On 03.03.2017 10:07, Smitha T Murthy wrote:
> > Add V4L2 definition for HEVC compressed format
> >
> > Signed-off-by: Smitha T Murthy 
> Reviewed-by: Andrzej Hajda 
> --
> Regards
> Andrzej

Thank you for the review.
Regards,
Smitha T Murthy 
> > ---
> >  include/uapi/linux/videodev2.h |1 +
> >  1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> > index 46e8a2e3..620e941 100644
> > --- a/include/uapi/linux/videodev2.h
> > +++ b/include/uapi/linux/videodev2.h
> > @@ -630,6 +630,7 @@ struct v4l2_pix_format {
> >  #define V4L2_PIX_FMT_VC1_ANNEX_L v4l2_fourcc('V', 'C', '1', 'L') /* SMPTE 
> > 421M Annex L compliant stream */
> >  #define V4L2_PIX_FMT_VP8  v4l2_fourcc('V', 'P', '8', '0') /* VP8 */
> >  #define V4L2_PIX_FMT_VP9  v4l2_fourcc('V', 'P', '9', '0') /* VP9 */
> > +#define V4L2_PIX_FMT_HEVC v4l2_fourcc('H', 'E', 'V', 'C') /* HEVC */
> >  
> >  /*  Vendor-specific formats   */
> >  #define V4L2_PIX_FMT_CPIA1v4l2_fourcc('C', 'P', 'I', 'A') /* cpia1 YUV 
> > */
> 
> 
> 

Re: [Patch v2 03/11] s5p-mfc: Use min scratch buffer size as provided by F/W

[Smitha T Murthy]

On Mon, 2017-03-06 at 15:18 +0100, Andrzej Hajda wrote: 
> On 03.03.2017 10:07, Smitha T Murthy wrote:
> > After MFC v8.0, mfc f/w lets the driver know how much scratch buffer
> > size is required for decoder. If mfc f/w has the functionality,
> > E_MIN_SCRATCH_BUFFER_SIZE, driver can know how much scratch buffer size
> > is required for encoder too.
> >
> > Signed-off-by: Smitha T Murthy 
> Reviewed-by: Andrzej Hajda 
> --
> Regards
> Andrzej
> 
Thank you for the review.
Regards
Smitha T Murthy 
> 

Re: [Patch v2 02/11] s5p-mfc: Adding initial support for MFC v10.10

[Smitha T Murthy]

On Mon, 2017-03-06 at 14:58 +0100, Andrzej Hajda wrote: 
> On 03.03.2017 10:07, Smitha T Murthy wrote:
> > Adding the support for MFC v10.10, with new register file and
> > necessary hw control, decoder, encoder and structural changes.
> >
> > Signed-off-by: Smitha T Murthy 
> Reviewed-by: Andrzej Hajda 
> 
> Few nitpicks below.
> 
Thank you for the review. I will take care of these in the next version.

> > CC: Rob Herring 
> > CC: devicet...@vger.kernel.org
> > ---
> >  .../devicetree/bindings/media/s5p-mfc.txt  |1 +
> >  drivers/media/platform/s5p-mfc/regs-mfc-v10.h  |   36 
> >  drivers/media/platform/s5p-mfc/s5p_mfc.c   |   30 +
> >  drivers/media/platform/s5p-mfc/s5p_mfc_common.h|4 +-
> >  drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c  |4 ++
> >  drivers/media/platform/s5p-mfc/s5p_mfc_dec.c   |   44 
> > +++-
> >  drivers/media/platform/s5p-mfc/s5p_mfc_enc.c   |   21 +
> >  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c|9 +++-
> >  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h|2 +
> >  9 files changed, 118 insertions(+), 33 deletions(-)
> >  create mode 100644 drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> >
> > diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt 
> > b/Documentation/devicetree/bindings/media/s5p-mfc.txt
> > index 2c90128..b83727b 100644
> > --- a/Documentation/devicetree/bindings/media/s5p-mfc.txt
> > +++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt
> > @@ -13,6 +13,7 @@ Required properties:
> > (c) "samsung,mfc-v7" for MFC v7 present in Exynos5420 SoC
> > (d) "samsung,mfc-v8" for MFC v8 present in Exynos5800 SoC
> > (e) "samsung,exynos5433-mfc" for MFC v8 present in Exynos5433 SoC
> > +   (f) "samsung,mfc-v10" for MFC v10 present in Exynos7880 SoC
> >  
> >- reg : Physical base address of the IP registers and length of memory
> >   mapped region.
> > diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h 
> > b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> > new file mode 100644
> > index 000..bd671a5
> > --- /dev/null
> > +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> > @@ -0,0 +1,36 @@
> > +/*
> > + * Register definition file for Samsung MFC V10.x Interface (FIMV) driver
> > + *
> > + * Copyright (c) 2017 Samsung Electronics Co., Ltd.
> > + * http://www.samsung.com/
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + */
> > +
> > +#ifndef _REGS_MFC_V10_H
> > +#define _REGS_MFC_V10_H
> > +
> > +#include 
> > +#include "regs-mfc-v8.h"
> > +
> > +/* MFCv10 register definitions*/
> > +#define S5P_FIMV_MFC_CLOCK_OFF_V10 0x7120
> > +#define S5P_FIMV_MFC_STATE_V10 0x7124
> > +
> > +/* MFCv10 Context buffer sizes */
> > +#define MFC_CTX_BUF_SIZE_V10   (30 * SZ_1K)/* 30KB */
> > +#define MFC_H264_DEC_CTX_BUF_SIZE_V10  (2 * SZ_1M) /* 2MB */
> > +#define MFC_OTHER_DEC_CTX_BUF_SIZE_V10 (20 * SZ_1K)/* 20KB */
> > +#define MFC_H264_ENC_CTX_BUF_SIZE_V10  (100 * SZ_1K)   /* 100KB */
> > +#define MFC_OTHER_ENC_CTX_BUF_SIZE_V10 (15 * SZ_1K)/* 15KB */
> > +
> > +/* MFCv10 variant defines */
> > +#define MAX_FW_SIZE_V10(SZ_1M) /* 1MB */
> > +#define MAX_CPB_SIZE_V10   (3 * SZ_1M) /* 3MB */
> 
> These comments seems redundant, definition is clear enough, you could
> remove them if there will be next iteration.
> 
Yes true, I will remove them in the next version.

> > +#define MFC_VERSION_V100xA0
> > +#define MFC_NUM_PORTS_V10  1
> > +
> > +#endif /*_REGS_MFC_V10_H*/
> > +
> > diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
> > b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> > index bb0a588..a043cce 100644
> > --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
> > +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> > @@ -1542,6 +1542,33 @@ static int s5p_mfc_resume(struct device *dev)
> > .num_clocks = 3,
> >  };
> >  
> > +static struct s5p_mfc_buf_size_v6 mfc_buf_size_v10 = {
> > +   .dev_ctx= MFC_CTX_BUF_SIZE_V10,
> > +   .h264_dec_ctx   = MFC_H264_DEC_CTX_BUF_SIZE_V10,
> > +   .other_dec_ctx  = MFC_OTHER_DEC_CTX_BUF_SIZE_V10,
> > +   .h264_enc_ctx   = MFC_H264_ENC_CTX_BUF_SIZE_V10,
> > +   .other_enc_ctx  = MFC_OTHER_ENC_CTX_BUF_SIZE_V10,
> > +};
> > +
> > +static struct s5p_mfc_buf_size buf_size_v10 = {
> > +   .fw = MAX_FW_SIZE_V10,
> > +   .cpb= MAX_CPB_SIZE_V10,
> > +   .priv   = _buf_size_v10,
> > +};
> > +
> > +static struct s5p_mfc_buf_align mfc_buf_align_v10 = {
> > +   .base = 0,
> > +};
> > +
> > +static struct s5p_mfc_variant mfc_drvdata_v10 = {
> > +   .version= MFC_VERSION_V10,
> > +   .version_bit= MFC_V10_BIT,
> > +   

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

[Philipp Zabel]

On Tue, 2017-03-14 at 08:34 +0100, Hans Verkuil wrote:
> On 03/13/2017 10:03 PM, Sakari Ailus wrote:
> > Hi Steve,
> > 
> > On Mon, Mar 13, 2017 at 11:06:22AM -0700, Steve Longerbeam wrote:
> >>
> >>
> >> On 03/13/2017 06:55 AM, Philipp Zabel wrote:
> >>> On Mon, 2017-03-13 at 13:27 +, Russell King - ARM Linux wrote:
>  On Mon, Mar 13, 2017 at 03:16:48PM +0200, Sakari Ailus wrote:
> > The vast majority of existing drivers do not implement them nor the user
> > space expects having to set them. Making that mandatory would break 
> > existing
> > user space.
> >
> > In addition, that does not belong to link validation either: link 
> > validation
> > should only include static properties of the link that are required for
> > correct hardware operation. Frame rate is not such property: hardware 
> > that
> > supports the MC interface generally does not recognise such concept 
> > (with
> > the exception of some sensors). Additionally, it is dynamic: the frame 
> > rate
> > can change during streaming, making its validation at streamon time 
> > useless.
> 
>  So how do we configure the CSI, which can do frame skipping?
> 
>  With what you're proposing, it means it's possible to configure the
>  camera sensor source pad to do 50fps.  Configure the CSI sink pad to
>  an arbitary value, such as 30fps, and configure the CSI source pad to
>  15fps.
> 
>  What you actually get out of the CSI is 25fps, which bears very little
>  with the actual values used on the CSI source pad.
> 
>  You could say "CSI should ask the camera sensor" - well, that's fine
>  if it's immediately downstream, but otherwise we'd need to go walking
>  down the graph to find something that resembles its source - there may
>  be mux and CSI2 interface subdev blocks in that path.  Or we just accept
>  that frame rates are completely arbitary and bear no useful meaning what
>  so ever.
> >>>
> >>> Which would include the frame interval returned by VIDIOC_G_PARM on the
> >>> connected video device, as that gets its information from the CSI output
> >>> pad's frame interval.
> >>>
> >>
> >> I'm kinda in the middle on this topic. I agree with Sakari that
> >> frame rate can fluctuate, but that should only be temporary. If
> >> the frame rate permanently shifts from what a subdev reports via
> >> g_frame_interval, then that is a system problem. So I agree with
> >> Phillip and Russell that a link validation of frame interval still
> >> makes sense.
> >>
> >> But I also have to agree with Sakari that a subdev that has no
> >> control over frame rate has no business implementing those ops.
> >>
> >> And then I agree with Russell that for subdevs that do have control
> >> over frame rate, they would have to walk the graph to find the frame
> >> rate source.
> >>
> >> So we're stuck in a broken situation: either the subdevs have to walk
> >> the graph to find the source of frame rate, or s_frame_interval
> >> would have to be mandatory and validated between pads, same as set_fmt.
> > 
> > It's not broken; what we are missing though is documentation on how to
> > control devices that can change the frame rate i.e. presumably drop frames
> > occasionally.
> > 
> > If you're doing something that hasn't been done before, it may be that new
> > documentation needs to be written to accomodate that use case. As we have an
> > existing interface (VIDIOC_SUBDEV_[GS]_FRAME_INTERVAL) it does make sense
> > to use that. What is not possible, though, is to mandate its use in link
> > validation everywhere.
> > 
> > If you had a hardware limitation that would require that the frame rate is
> > constant, then we'd need to handle that in link validation for that
> > particular piece of hardware. But there really is no case for doing that for
> > everything else.
> > 
> 
> General note: I would strongly recommend that g/s_parm support is removed in
> v4l2_subdev in favor of g/s_frame_interval.
> 
> g/s_parm is an abomination...

Agreed. Just in this specific case I was talking about G_PARM on
the /dev/video node, not the v4l2_subdev nodes. This is currently used
by non-subdev-aware userspace to obtain the framerate from the video
capture device.

> There seem to be only a few i2c drivers that use g/s_parm, so this shouldn't
> be a lot of work.
> 
> Having two APIs for the same thing is always very bad.
> 
> Regards,
> 
>   Hans
> 

regards
Philipp

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

[Mauro Carvalho Chehab]

Em Tue, 14 Mar 2017 08:55:36 +0100
Hans Verkuil  escreveu:

> On 03/14/2017 04:45 AM, Mauro Carvalho Chehab wrote:
> > Hi Sakari,
> > 
> > I started preparing a long argument about it, but gave up in favor of a
> > simpler one.
> > 
> > Em Mon, 13 Mar 2017 14:46:22 +0200
> > Sakari Ailus  escreveu:
> >   
> >> Drivers are written to support hardware, not particular use case.
> > 
> > No, it is just the reverse: drivers and hardware are developed to
> > support use cases.
> > 
> > Btw, you should remember that the hardware is the full board, not just the
> > SoC. In practice, the board do limit the use cases: several provide a
> > single physical CSI connector, allowing just one sensor.
> >   
> >>> This situation is there since 2009. If I remember well, you tried to write
> >>> such generic plugin in the past, but never finished it, apparently because
> >>> it is too complex. Others tried too over the years. 
> >>
> >> I'd argue I know better what happened with that attempt than you do. I had 
> >> a
> >> prototype of a generic pipeline configuration library but due to various
> >> reasons I haven't been able to continue working on that since around 2012. 
> >>  
> > 
> > ...
> >   
> >>> The last trial was done by Jacek, trying to cover just the exynos4 
> >>> driver. 
> >>> Yet, even such limited scope plugin was not good enough, as it was never
> >>> merged upstream. Currently, there's no such plugins upstream.
> >>>
> >>> If we can't even merge a plugin that solves it for just *one* driver,
> >>> I have no hope that we'll be able to do it for the generic case.
> >>
> >> I believe Jacek ceased to work on that plugin in his day job; other than
> >> that, there are some matters left to be addressed in his latest patchset.  
> > 
> > The two above basically summaries the issue: the task of doing a generic
> > plugin on userspace, even for a single driver is complex enough to
> > not cover within a reasonable timeline.
> > 
> > From 2009 to 2012, you were working on it, but didn't finish it.
> > 
> > Apparently, nobody worked on it between 2013-2014 (but I may be wrong, as
> > I didn't check when the generic plugin interface was added to libv4l).
> > 
> > In the case of Jacek's work, the first patch I was able to find was
> > written in Oct, 2014:
> > https://patchwork.kernel.org/patch/5098111/
> > (not sure what happened with the version 1).
> > 
> > The last e-mail about this subject was issued in Dec, 2016.
> > 
> > In summary, you had this on your task for 3 years for an OMAP3
> > plugin (where you have a good expertise), and Jacek for 2 years, 
> > for Exynos 4, where he should also have a good knowledge.
> > 
> > Yet, with all that efforts, no concrete results were achieved, as none
> > of the plugins got merged.
> > 
> > Even if they were merged, if we keep the same mean time to develop a
> > libv4l plugin, that would mean that a plugin for i.MX6 could take 2-3
> > years to be developed.
> > 
> > There's a clear message on it:
> > - we shouldn't keep pushing for a solution via libv4l.  
> 
> Or:
> 
>   - userspace plugin development had a very a low priority and
> never got the attention it needed.

The end result is the same: we can't count on it.

> 
> I know that's *my* reason. I rarely if ever looked at it. I always assumed
> Sakari and/or Laurent would look at it. If this reason is also valid for
> Sakari and Laurent, then it is no wonder nothing has happened in all that
> time.
> 
> We're all very driver-development-driven, and userspace gets very little
> attention in general. So before just throwing in the towel we should take
> a good look at the reasons why there has been little or no development: is
> it because of fundamental design defects, or because nobody paid attention
> to it?

No. We should look it the other way: basically, there are patches
for i.MX6 driver that sends control from videonode to subdevs. 

If we nack apply it, who will write the userspace plugin? When
such change will be merged upstream?

If we don't have answers to any of the above questions, we should not
nack it.

That's said, that doesn't prevent merging a libv4l plugin if/when
someone can find time/interest to develop it.

> I strongly suspect it is the latter.
> 
> In addition, I suspect end-users of these complex devices don't really care
> about a plugin: they want full control and won't typically use generic
> applications. If they would need support for that, we'd have seen much more
> interest. The main reason for having a plugin is to simplify testing and
> if this is going to be used on cheap hobbyist devkits.

What are the needs for a cheap hobbyist devkit owner? Do we currently
satisfy those needs? I'd say that having a functional driver when
compiled without the subdev API, that implements the ioctl's/controls
that a generic application like camorama/google talk/skype/zbar...
would work should be enough to make them happy, 

Re: [PATCH v3 4/6] drm: bridge: dw-hdmi: Switch to V4L bus format and encodings

[Neil Armstrong]

On 03/13/2017 12:43 PM, Jose Abreu wrote:
> Hi Neil,
> 
> 
> On 09-03-2017 14:27, Jose Abreu wrote:
>> Hi Neil,
>>
>>
>> On 08-03-2017 12:12, Neil Armstrong wrote:
>>> Hi Jose,
>>>
>>> It seems here that we only have the RGB444<->YUV444 8bit tables, from the 
>>> Amlogic
>>> source I have the following for 10bit, 12bit and 16bit for itu601 :
>>>
>>> static const u16 csc_coeff_rgb_out_eitu601_10b[3][4] = {
>>> { 0x2000, 0x6926, 0x74fd, 0x043b },
>>> { 0x2000, 0x2cdd, 0x, 0x7a65 },
>>> { 0x2000, 0x, 0x38b4, 0x78ea }
>>> };
>>>
>>> static const u16 csc_coeff_rgb_out_eitu601_12b_16b[3][4] = {
>>> { 0x2000, 0x6926, 0x74fd, 0x10ee },
>>> { 0x2000, 0x2cdd, 0x, 0x6992 },
>>> { 0x2000, 0x, 0x38b4, 0x63a6 }
>>> };
>> These two do not match anything I have here.
>>
>>> static const u16 csc_coeff_rgb_in_eitu601_10b[3][4] = {
>>> { 0x2591, 0x1322, 0x074b, 0x },
>>> { 0x6535, 0x2000, 0x7acc, 0x0800 },
>>> { 0x6acd, 0x7534, 0x2000, 0x0800 }
>>> };
>> This is more or less correct, I have small offsets. Note that I
>> even have offsets with the values that are in dw-hdmi driver,
>> which can be caused because I'm seeing the latest document that
>> contain these values. I guess they were updated.
>>
>>> static const u16 csc_coeff_rgb_in_eitu601_12b_16b[3][4] = {
>>> { 0x2591, 0x1322, 0x074b, 0x },
>>> { 0x6535, 0x2000, 0x7acc, 0x2000 },
>>> { 0x6acd, 0x7534, 0x2000, 0x2000 }
>>> };
>> The same for this.
>>
>>> But I miss the itu709 values.
>>>
>>> Could you confirm these values and maybe provide the itu709 values ?
>> I will have to check if I can provide you the values. I will get
>> back to you.
> 
> Sorry but looks like I won't be able to provide you the correct
> values :/ If you are working for a Synopsys customer you can
> contact our CAE (If so I can guide you to the correct CAE).
> 
> Anyway, unless you can test the values you have I suggest you
> don't use them, they do not match what I have here and I can't
> test them because right now I don't have a setup (I'm assuming
> that your CSC block within the controller was not modified).
> 
> Best regards,
> Jose Miguel Abreu
> 

Hi Jose,

Thanks for your effort, I will postpone this fix and only add the tables
needed by the Amlogic platform when needed.

Thanks,
Neil

[PATCH] staging: atomicsp: fix a loop timeout

[Dan Carpenter]

It's a post-op loop so we timeout with "max_wait" set to -1, not 0.

Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2")
Signed-off-by: Dan Carpenter 

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
index 46cdb0f3f993..49f6d18a068b 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
@@ -418,7 +418,7 @@ void punit_ddr_dvfs_enable(bool enable)
}
}
 
-   if (max_wait == 0)
+   if (max_wait == -1)
pr_info("DDR DVFS, door bell is not cleared within 3ms\n");
 }
 

[patch] staging: atomisp: missing break statement in switch

[Dan Carpenter]

Static analysis tools suggest that we probably want a break statement
here before then next cast statement.  Looks true to me.

Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2")
Signed-off-by: Dan Carpenter 

diff --git a/drivers/staging/media/atomisp/i2c/ov5693/ov5693.c 
b/drivers/staging/media/atomisp/i2c/ov5693/ov5693.c
index e3d4d0e0ed9c..ac7598291b95 100644
--- a/drivers/staging/media/atomisp/i2c/ov5693/ov5693.c
+++ b/drivers/staging/media/atomisp/i2c/ov5693/ov5693.c
@@ -1132,7 +1132,7 @@ static int ov5693_g_volatile_ctrl(struct v4l2_ctrl *ctrl)
break;
case V4L2_CID_FOCUS_STATUS:
ret = ov5693_q_focus_status(>sd, >val);
-
+   break;
case V4L2_CID_BIN_FACTOR_HORZ:
ret = ov5693_g_bin_factor_x(>sd, >val);
break;

Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

[Hans Verkuil]

On 03/14/2017 04:45 AM, Mauro Carvalho Chehab wrote:
> Hi Sakari,
> 
> I started preparing a long argument about it, but gave up in favor of a
> simpler one.
> 
> Em Mon, 13 Mar 2017 14:46:22 +0200
> Sakari Ailus  escreveu:
> 
>> Drivers are written to support hardware, not particular use case.  
> 
> No, it is just the reverse: drivers and hardware are developed to
> support use cases.
> 
> Btw, you should remember that the hardware is the full board, not just the
> SoC. In practice, the board do limit the use cases: several provide a
> single physical CSI connector, allowing just one sensor.
> 
>>> This situation is there since 2009. If I remember well, you tried to write
>>> such generic plugin in the past, but never finished it, apparently because
>>> it is too complex. Others tried too over the years.   
>>
>> I'd argue I know better what happened with that attempt than you do. I had a
>> prototype of a generic pipeline configuration library but due to various
>> reasons I haven't been able to continue working on that since around 2012.
> 
> ...
> 
>>> The last trial was done by Jacek, trying to cover just the exynos4 driver. 
>>> Yet, even such limited scope plugin was not good enough, as it was never
>>> merged upstream. Currently, there's no such plugins upstream.
>>>
>>> If we can't even merge a plugin that solves it for just *one* driver,
>>> I have no hope that we'll be able to do it for the generic case.  
>>
>> I believe Jacek ceased to work on that plugin in his day job; other than
>> that, there are some matters left to be addressed in his latest patchset.
> 
> The two above basically summaries the issue: the task of doing a generic
> plugin on userspace, even for a single driver is complex enough to
> not cover within a reasonable timeline.
> 
> From 2009 to 2012, you were working on it, but didn't finish it.
> 
> Apparently, nobody worked on it between 2013-2014 (but I may be wrong, as
> I didn't check when the generic plugin interface was added to libv4l).
> 
> In the case of Jacek's work, the first patch I was able to find was
> written in Oct, 2014:
>   https://patchwork.kernel.org/patch/5098111/
>   (not sure what happened with the version 1).
> 
> The last e-mail about this subject was issued in Dec, 2016.
> 
> In summary, you had this on your task for 3 years for an OMAP3
> plugin (where you have a good expertise), and Jacek for 2 years, 
> for Exynos 4, where he should also have a good knowledge.
> 
> Yet, with all that efforts, no concrete results were achieved, as none
> of the plugins got merged.
> 
> Even if they were merged, if we keep the same mean time to develop a
> libv4l plugin, that would mean that a plugin for i.MX6 could take 2-3
> years to be developed.
> 
> There's a clear message on it:
>   - we shouldn't keep pushing for a solution via libv4l.

Or:

- userspace plugin development had a very a low priority and
  never got the attention it needed.

I know that's *my* reason. I rarely if ever looked at it. I always assumed
Sakari and/or Laurent would look at it. If this reason is also valid for
Sakari and Laurent, then it is no wonder nothing has happened in all that
time.

We're all very driver-development-driven, and userspace gets very little
attention in general. So before just throwing in the towel we should take
a good look at the reasons why there has been little or no development: is
it because of fundamental design defects, or because nobody paid attention
to it?

I strongly suspect it is the latter.

In addition, I suspect end-users of these complex devices don't really care
about a plugin: they want full control and won't typically use generic
applications. If they would need support for that, we'd have seen much more
interest. The main reason for having a plugin is to simplify testing and
if this is going to be used on cheap hobbyist devkits.

An additional complication is simply that it is hard to find fully supported
MC hardware. omap3 boards are hard to find these days, renesas boards are not
easy to get, freescale isn't the most popular either. Allwinner, mediatek,
amlogic, broadcom and qualcomm all have closed source implementations or no
implementation at all.

I know it took me a very long time before I had a working omap3.

So I am not at all surprised that little progress has been made.

Regards,

Hans

[PATCH] staging: atomisp: silence an array overflow warning

[Dan Carpenter]

Static checkers complain that we should check if "i" is in bounds
before we check if "var8[i]" is a NUL char.  This bug is harmless but
also easy to fix.

Signed-off-by: Dan Carpenter 

diff --git 
a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c 
b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
index 65513cae93ce..1dd061f00cd9 100644
--- a/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
+++ b/drivers/staging/media/atomisp/platform/intel-mid/atomisp_gmin_platform.c
@@ -669,7 +669,7 @@ int gmin_get_config_var(struct device *dev, const char 
*var, char *out, size_t *
/* Our variable names are ASCII by construction, but EFI names
 * are wide chars.  Convert and zero-pad. */
memset(var16, 0, sizeof(var16));
-   for (i=0; var8[i] && i < sizeof(var8); i++)
+   for (i = 0; i < sizeof(var8) && var8[i]; i++)
var16[i] = var8[i];
 
/* To avoid owerflows when calling the efivar API */

[patch] Staging: atomisp: kfreeing a devm allocated pointer

[Dan Carpenter]

We shouldn't pass devm allocated pointers to kfree() or it leads to a
double free.

Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2")
Signed-off-by: Dan Carpenter 

diff --git a/drivers/staging/media/atomisp/i2c/imx/otp_brcc064_e2prom.c 
b/drivers/staging/media/atomisp/i2c/imx/otp_brcc064_e2prom.c
index 242e934a6030..b11f90c5960c 100644
--- a/drivers/staging/media/atomisp/i2c/imx/otp_brcc064_e2prom.c
+++ b/drivers/staging/media/atomisp/i2c/imx/otp_brcc064_e2prom.c
@@ -69,7 +69,6 @@ void *brcc064_otp_read(struct v4l2_subdev *sd, u8 dev_addr,
 
r = i2c_transfer(client->adapter, msg, ARRAY_SIZE(msg));
if (r != ARRAY_SIZE(msg)) {
-   kfree(buffer);
dev_err(>dev, "read failed at 0x%03x\n", addr);
return NULL;
}
diff --git a/drivers/staging/media/atomisp/i2c/imx/otp_e2prom.c 
b/drivers/staging/media/atomisp/i2c/imx/otp_e2prom.c
index ce4e7ab7781c..73d041f97811 100644
--- a/drivers/staging/media/atomisp/i2c/imx/otp_e2prom.c
+++ b/drivers/staging/media/atomisp/i2c/imx/otp_e2prom.c
@@ -79,7 +79,6 @@ void *e2prom_otp_read(struct v4l2_subdev *sd, u8 dev_addr,
 
r = i2c_transfer(client->adapter, msg, ARRAY_SIZE(msg));
if (r != ARRAY_SIZE(msg)) {
-   kfree(buffer);
dev_err(>dev, "read failed at 0x%03x\n", addr);
return NULL;
}

[PATCH] staging: atomisp: off by one in atomisp_acc_load_extensions()

[Dan Carpenter]

We should be doing i-- on all error paths but we don't if the loop
finishes successfully.  I've re-arranged this so that we don't read
beyond the end of acc_flag_to_pipe[] array.

Fixes: a49d25364dfb ("staging/atomisp: Add support for the Intel IPU v2")
Signed-off-by: Dan Carpenter 

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_acc.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_acc.c
index 4c35a785c7d5..212e0a777b4b 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_acc.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_acc.c
@@ -472,10 +472,8 @@ int atomisp_acc_load_extensions(struct atomisp_sub_device 
*asd)
acc_fw->fw,
acc_flag_to_pipe[i].pipe_id,
acc_fw->type);
-   if (ret) {
-   i--;
+   if (ret)
goto error;
-   }
 
ext_loaded = true;
}
@@ -499,7 +497,7 @@ int atomisp_acc_load_extensions(struct atomisp_sub_device 
*asd)
return 0;
 
 error:
-   for (; i >= 0; i--) {
+   while (--i >= 0) {
if (acc_fw->flags & acc_flag_to_pipe[i].flag) {
atomisp_css_unload_acc_extension(asd, acc_fw->fw,
acc_flag_to_pipe[i].pipe_id);

[patch] staging/atomisp: silence uninitialized variable warnings

[Dan Carpenter]

These print an uninitialized value for "opt".  Let's just remove the
printk.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_drvfs.c 
b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_drvfs.c
index 327a5c535fab..7f7c6d5133d2 100644
--- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_drvfs.c
+++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_drvfs.c
@@ -128,11 +128,9 @@ static ssize_t iunit_dbgfun_store(struct device_driver 
*drv, const char *buf,
unsigned int opt;
int ret;
 
-   if (kstrtouint(buf, 10, )) {
-   dev_err(atomisp_dev, "%s setting %d value invalid\n",
-   __func__, opt);
-   return -EINVAL;
-   }
+   ret = kstrtouint(buf, 10, );
+   if (ret)
+   return ret;
 
ret = atomisp_set_css_dbgfunc(iunit_debug.isp, opt);
if (ret)
@@ -154,11 +152,9 @@ static ssize_t iunit_dbgopt_store(struct device_driver 
*drv, const char *buf,
unsigned int opt;
int ret;
 
-   if (kstrtouint(buf, 10, )) {
-   dev_err(atomisp_dev, "%s setting %d value invalid\n",
-   __func__, opt);
-   return -EINVAL;
-   }
+   ret = kstrtouint(buf, 10, );
+   if (ret)
+   return ret;
 
iunit_debug.dbgopt = opt;
ret = iunit_dump_dbgopt(iunit_debug.isp, iunit_debug.dbgopt);

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

[Hans Verkuil]

On 03/13/2017 10:03 PM, Sakari Ailus wrote:
> Hi Steve,
> 
> On Mon, Mar 13, 2017 at 11:06:22AM -0700, Steve Longerbeam wrote:
>>
>>
>> On 03/13/2017 06:55 AM, Philipp Zabel wrote:
>>> On Mon, 2017-03-13 at 13:27 +, Russell King - ARM Linux wrote:
 On Mon, Mar 13, 2017 at 03:16:48PM +0200, Sakari Ailus wrote:
> The vast majority of existing drivers do not implement them nor the user
> space expects having to set them. Making that mandatory would break 
> existing
> user space.
>
> In addition, that does not belong to link validation either: link 
> validation
> should only include static properties of the link that are required for
> correct hardware operation. Frame rate is not such property: hardware that
> supports the MC interface generally does not recognise such concept (with
> the exception of some sensors). Additionally, it is dynamic: the frame 
> rate
> can change during streaming, making its validation at streamon time 
> useless.

 So how do we configure the CSI, which can do frame skipping?

 With what you're proposing, it means it's possible to configure the
 camera sensor source pad to do 50fps.  Configure the CSI sink pad to
 an arbitary value, such as 30fps, and configure the CSI source pad to
 15fps.

 What you actually get out of the CSI is 25fps, which bears very little
 with the actual values used on the CSI source pad.

 You could say "CSI should ask the camera sensor" - well, that's fine
 if it's immediately downstream, but otherwise we'd need to go walking
 down the graph to find something that resembles its source - there may
 be mux and CSI2 interface subdev blocks in that path.  Or we just accept
 that frame rates are completely arbitary and bear no useful meaning what
 so ever.
>>>
>>> Which would include the frame interval returned by VIDIOC_G_PARM on the
>>> connected video device, as that gets its information from the CSI output
>>> pad's frame interval.
>>>
>>
>> I'm kinda in the middle on this topic. I agree with Sakari that
>> frame rate can fluctuate, but that should only be temporary. If
>> the frame rate permanently shifts from what a subdev reports via
>> g_frame_interval, then that is a system problem. So I agree with
>> Phillip and Russell that a link validation of frame interval still
>> makes sense.
>>
>> But I also have to agree with Sakari that a subdev that has no
>> control over frame rate has no business implementing those ops.
>>
>> And then I agree with Russell that for subdevs that do have control
>> over frame rate, they would have to walk the graph to find the frame
>> rate source.
>>
>> So we're stuck in a broken situation: either the subdevs have to walk
>> the graph to find the source of frame rate, or s_frame_interval
>> would have to be mandatory and validated between pads, same as set_fmt.
> 
> It's not broken; what we are missing though is documentation on how to
> control devices that can change the frame rate i.e. presumably drop frames
> occasionally.
> 
> If you're doing something that hasn't been done before, it may be that new
> documentation needs to be written to accomodate that use case. As we have an
> existing interface (VIDIOC_SUBDEV_[GS]_FRAME_INTERVAL) it does make sense
> to use that. What is not possible, though, is to mandate its use in link
> validation everywhere.
> 
> If you had a hardware limitation that would require that the frame rate is
> constant, then we'd need to handle that in link validation for that
> particular piece of hardware. But there really is no case for doing that for
> everything else.
> 

General note: I would strongly recommend that g/s_parm support is removed in
v4l2_subdev in favor of g/s_frame_interval.

g/s_parm is an abomination...

There seem to be only a few i2c drivers that use g/s_parm, so this shouldn't
be a lot of work.

Having two APIs for the same thing is always very bad.

Regards,

Hans

Re: [PATCH] [media] v4l2-dv-timings: Introduce v4l2_calc_fps()

[Hans Verkuil]

On 03/13/2017 08:03 PM, Jose Abreu wrote:
> Hi Hans,
> 
> 
> On 09-03-2017 15:40, Hans Verkuil wrote:
>> On 09/03/17 16:15, Jose Abreu wrote:
>>> Hi Hans,
>>>
>>>
>>> Thanks for the review!
>>>
>>>
>>> On 09-03-2017 12:29, Hans Verkuil wrote:
 On 07/03/17 17:48, Jose Abreu wrote:
> HDMI Receivers receive video modes which, according to
> CEA specification, can have different frames per second
> (fps) values.
>
> This patch introduces a helper function in the media core
> which can calculate the expected video mode fps given the
> pixel clock value and the horizontal/vertical values. HDMI
> video receiver drivers are expected to use this helper so
> that they can correctly fill the v4l2_streamparm structure
> which is requested by vidioc_g_parm callback.
>
> We could also use a lookup table for this but it wouldn't
> correctly handle 60Hz vs 59.94Hz situations as this all
> depends on the pixel clock value.
>
> Signed-off-by: Jose Abreu 
> Cc: Carlos Palminha 
> Cc: Mauro Carvalho Chehab 
> Cc: Hans Verkuil 
> Cc: Charles-Antoine Couret 
> Cc: linux-media@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> ---
>  drivers/media/v4l2-core/v4l2-dv-timings.c | 29 
> +
>  include/media/v4l2-dv-timings.h   |  8 
>  2 files changed, 37 insertions(+)
>
> diff --git a/drivers/media/v4l2-core/v4l2-dv-timings.c 
> b/drivers/media/v4l2-core/v4l2-dv-timings.c
> index 5c8c49d..19946c6 100644
> --- a/drivers/media/v4l2-core/v4l2-dv-timings.c
> +++ b/drivers/media/v4l2-core/v4l2-dv-timings.c
> @@ -814,3 +814,32 @@ struct v4l2_fract v4l2_calc_aspect_ratio(u8 
> hor_landscape, u8 vert_portrait)
>   return aspect;
>  }
>  EXPORT_SYMBOL_GPL(v4l2_calc_aspect_ratio);
> +
> +struct v4l2_fract v4l2_calc_fps(const struct v4l2_dv_timings *t)
> +{
> + const struct v4l2_bt_timings *bt = >bt;
> + struct v4l2_fract fps_fract = { 1, 1 };
> + unsigned long n, d;
> + unsigned long mask = GENMASK(BITS_PER_LONG - 1, 0);
 This is wrong since v4l2_fract uses u32, and LONG can be 64 bits.
>>> Yes, its wrong. I will remove the variable and just use fps, 100
>>> instead of mask, mask.
>>>
> + u32 htot, vtot, fps;
> + u64 pclk;
> +
> + if (t->type != V4L2_DV_BT_656_1120)
> + return fps_fract;
> +
> + htot = V4L2_DV_BT_FRAME_WIDTH(bt);
> + vtot = V4L2_DV_BT_FRAME_HEIGHT(bt);
> + pclk = bt->pixelclock;
> + if (bt->interlaced)
> + htot /= 2;
 This can be dropped. This is the timeperframe, not timeperfield. So for 
 interleaved
 formats the time is that of two fields (aka one frame).
>>> Ok, but then there is something not correct in
>>> v4l2_dv_timings_presets structure field values because I get
>>> wrong results in double clocked modes. I checked the definition
>>> and the modes that are double clocked are defined with half the
>>> clock, i.e., V4L2_DV_BT_CEA_720X480I59_94 is defined with a pixel
>>> clock of 13.5MHz but in CEA spec this mode is defined with pixel
>>> clock of 27MHz.
>> It's defined in the CEA spec as 1440x480 which is the double clocked
>> version of 720x480.
>>
>> The presets are defined without any pixel repeating. In fact, no driver
>> that is in the kernel today supports pixel repeating. Mostly because there 
>> was
>> never any need since almost nobody uses resolutions that require this.
>>
>> If you decide to add support for this, then it would not surprise me if
>> some of the core dv-timings support needs to be adjusted.
>>
>> To be honest, I never spent time digging into the pixel repeating details,
>> so I am not an expert on this at all.
>>
> +
> + fps = (htot * vtot) > 0 ? div_u64((100 * pclk), (htot * vtot)) : 0;
> +
> + rational_best_approximation(fps, 100, mask, mask, , );
 I think you can just use fps, 100 instead of mask, mask.

 What is returned if fps == 0?
>>> I will add a check for this.
>>>
 I don't have a problem as such with this function, but just be aware that 
 the
 pixelclock is never precise: there are HDMI receivers that are unable to 
 report
 the pixelclock with enough precision to even detect if it is 60 vs 59.94 
 Hz.

 And even for those that can, it is often not reliable.
>>> My initial intention for this function was that it should be used
>>> with v4l2_find_dv_timings_cea861_vic, when possible. That is,
>>> HDMI receivers have access to AVI infoframe contents. Then they
>>> should get the vic, call v4l2_find_dv_timings_cea861_vic, get
>>> timings and then call v4l2_calc_fps to get fps. If no AVI
>>> infoframe is available then it should resort to pixel clock and
>>> H/V measures as last resort.
>> Right, but 

Re: [PATCH RFC] dvb: af9035.c: Logilink vg0022a to device id table

[Andreas Kemnade]

On Thu,  9 Mar 2017 17:51:14 +0100
Andreas Kemnade  wrote:

> Ths adds the logilink VG00022a dvb-t dongle to the device table.
> The dongle contains (checked by removing the case)
> IT9303
> SI2168
>   214730
> 
> The result is in cold state:
> 
>  usb 1-6: new high-speed USB device number 15 using xhci_hcd
>  usb 1-6: New USB device found, idVendor=1d19, idProduct=0100
>  usb 1-6: New USB device strings: Mfr=1, Product=2, SerialNumber=3
>  usb 1-6: Product: TS Aggregator
>  usb 1-6: Manufacturer: ITE Tech., Inc.
>  usb 1-6: SerialNumber: 
>  dvb_usb_af9035 1-6:1.0: prechip_version=83 chip_version=01 chip_type=9306
>  dvb_usb_af9035 1-6:1.0: ts mode=5 not supported, defaulting to single tuner 
> mode!
>  usb 1-6: dvb_usb_v2: found a 'Logilink VG0022A' in cold state
>  usb 1-6: dvb_usb_v2: downloading firmware from file 'dvb-usb-it9303-01.fw'
>  dvb_usb_af9035 1-6:1.0: firmware version=1.4.0.0
>  usb 1-6: dvb_usb_v2: found a 'Logilink VG0022A' in warm state
>  usb 1-6: dvb_usb_v2: will pass the complete MPEG2 transport stream to the 
> software demuxer
>  dvbdev: DVB: registering new adapter (Logilink VG0022A)
>  si2168: probe of 6-0067 failed with error -5
> 
> when warmed up by connecing it via  a powered usb hub to win7 and
> then attaching the same usb hub to a linux machine:
> 
with some fixes in af9035.c I already get the same state as with warm
up by win7. I just need to find out which changes are really necessary
and convert it into a clean patch.

> so firmware uploading to the si2168 somehow messes things up
> 
I experimented a lot here and I found this:
If 0101 is not sent to the si2168 you can get answers from the
Si2147-A30. 
After the 0101 is sent to the si2147-A30 it will still execute
commands but you will not get the answer back through the si2168.
You just get ff.

After moving the chip id readout from si2157_init to si2157_probe,
scanning for stations works. So the si2147-A30 seems to react on
commands. 

Regards,
Andreas Kemnade


pgp27dH4ipAAt.pgp
Description: OpenPGP digital signature