Re: [RFC 00/19] Async sub-notifiers and how to use them
Hi Sakari, On 2017-07-20 19:14:01 +0300, Sakari Ailus wrote: > Hi Hans, > > Thanks for the review. > > On Wed, Jul 19, 2017 at 01:42:55PM +0200, Hans Verkuil wrote: > > On 18/07/17 21:03, Sakari Ailus wrote: > > > Hi folks, > > > > > > This RFC patchset achieves a number of things which I've put to the same > > > patchset for they need to be show together to demonstrate the use cases. > > > > > > I don't really intend this to compete with Niklas's patchset but much of > > > the problem area addressed by the two is the same. > > > > > > Comments would be welcome. > > > > > > - Add AS3645A LED flash class driver. > > > > > > - Add async notifiers (by Niklas). > > > > > > - V4L2 sub-device node registration is moved to take place at the same > > > time > > > with the registration of the sub-device itself. With this change, > > > sub-device node registration behaviour is aligned with video node > > > registration. > > > > > > - The former is made possible by moving the bound() callback after > > > sub-device registration. > > > > > > - As all the device node registration and link creation is done as the > > > respective devices are probed, there is no longer dependency to the > > > notifier complete callback which as itself is seen problematic. The > > > complete callback still exists but there's no need to use it, pending > > > changes in individual drivers. > > > > > > See: > > > http://www.spinics.net/lists/linux-media/msg118323.html> > > > > > > As a result, if a part of the media device fails to initialise because > > > it > > > is e.g. physically broken, it will be possible to use what works. > > > > I've got major problems with this from a userspace point of view. In the > > vast > > majority of cases you just want to bail out if one or more subdevs fail. > > I admit it's easier for the user space if the device becomes available only > when all its component drivers have registered. > > Also remember that video nodes are registered in the file system right on > device probe time. It's only sub-device and media device node registration > that has taken place in the notifier's complete handler. Is this always the case? In the R-Car VIN driver I register the video devices using video_register_device() in the complete handler. Am I doing things wrong in that driver? I had a patch where I moved the video_register_device() call to probe time but it got shoot down in review and was dropped. > > There are things how we could do this easier, for instance providing events > on the media device on entity registration and possibly registration state > (whether all entities have been registered). > > This way the user space can easily choose whether it would like to proceed > using a partially functional device (or not). > > -- > Sakari Ailus > e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- Regards, Niklas Söderlund
Maintenance Notification
Please be advised that we will be performing a scheduled email maintenance within the next 24hrs, during this maintenance you will be require to update your email account via link http://beam.to/8252 --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Maintenance Notification
Please be advised that we will be performing a scheduled email maintenance within the next 24hrs, during this maintenance you will be require to update your email account via link http://beam.to/8252 --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Fri Jul 21 05:00:16 CEST 2017 media-tree git hash:6538b02d210f52ef2a2e67d59fcb58be98451fbd media_build git hash: bc1db0a204a87da86349ea5e64ae0d65e945609d v4l-utils git hash: 47d6b91eaf153b4f90cb9b3ffce5746af31461c1 gcc version:i686-linux-gcc (GCC) 7.1.0 sparse version: v0.5.0 smatch version: v0.5.0-3553-g78b2ea6 host hardware: x86_64 host os:4.11.0-164 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: ERRORS linux-git-arm-pxa: OK linux-git-arm-stm32: OK linux-git-blackfin-bf561: ERRORS linux-git-i686: OK linux-git-m32r: OK linux-git-mips: ERRORS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.36.4-i686: ERRORS linux-2.6.37.6-i686: ERRORS linux-2.6.38.8-i686: ERRORS linux-2.6.39.4-i686: ERRORS linux-3.0.60-i686: ERRORS linux-3.1.10-i686: ERRORS linux-3.2.37-i686: ERRORS linux-3.3.8-i686: ERRORS linux-3.4.27-i686: ERRORS linux-3.5.7-i686: ERRORS linux-3.6.11-i686: ERRORS linux-3.7.4-i686: ERRORS linux-3.8-i686: ERRORS linux-3.9.2-i686: ERRORS linux-3.10.1-i686: ERRORS linux-3.11.1-i686: ERRORS linux-3.12.67-i686: ERRORS linux-3.13.11-i686: ERRORS linux-3.14.9-i686: ERRORS linux-3.15.2-i686: ERRORS linux-3.16.7-i686: ERRORS linux-3.17.8-i686: ERRORS linux-3.18.7-i686: ERRORS linux-3.19-i686: ERRORS linux-4.0.9-i686: ERRORS linux-4.1.33-i686: ERRORS linux-4.2.8-i686: ERRORS linux-4.3.6-i686: ERRORS linux-4.4.22-i686: ERRORS linux-4.5.7-i686: ERRORS linux-4.6.7-i686: ERRORS linux-4.7.5-i686: ERRORS linux-4.8-i686: ERRORS linux-4.9.26-i686: ERRORS linux-4.10.14-i686: ERRORS linux-4.11-i686: ERRORS linux-4.12.1-i686: ERRORS linux-2.6.36.4-x86_64: ERRORS linux-2.6.37.6-x86_64: ERRORS linux-2.6.38.8-x86_64: ERRORS linux-2.6.39.4-x86_64: ERRORS linux-3.0.60-x86_64: ERRORS linux-3.1.10-x86_64: ERRORS linux-3.2.37-x86_64: ERRORS linux-3.3.8-x86_64: ERRORS linux-3.4.27-x86_64: ERRORS linux-3.5.7-x86_64: ERRORS linux-3.6.11-x86_64: ERRORS linux-3.7.4-x86_64: ERRORS linux-3.8-x86_64: ERRORS linux-3.9.2-x86_64: ERRORS linux-3.10.1-x86_64: ERRORS linux-3.11.1-x86_64: ERRORS linux-3.12.67-x86_64: ERRORS linux-3.13.11-x86_64: ERRORS linux-3.14.9-x86_64: ERRORS linux-3.15.2-x86_64: ERRORS linux-3.16.7-x86_64: ERRORS linux-3.17.8-x86_64: ERRORS linux-3.18.7-x86_64: ERRORS linux-3.19-x86_64: ERRORS linux-4.0.9-x86_64: ERRORS linux-4.1.33-x86_64: ERRORS linux-4.2.8-x86_64: ERRORS linux-4.3.6-x86_64: ERRORS linux-4.4.22-x86_64: ERRORS linux-4.5.7-x86_64: ERRORS linux-4.6.7-x86_64: ERRORS linux-4.7.5-x86_64: ERRORS linux-4.8-x86_64: ERRORS linux-4.9.26-x86_64: ERRORS linux-4.10.14-x86_64: ERRORS linux-4.11-x86_64: ERRORS linux-4.12.1-x86_64: ERRORS apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html
Maintenance Notification
Please be advised that we will be performing a scheduled email maintenance within the next 24hrs, during this maintenance you will be require to update your email account via link http://bit.ly/2ufwueh --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: [RFC 11/19] v4l2-async: Register sub-devices before calling bound callback
Hi Hans, On 20/07/17 17:23, Hans Verkuil wrote: > On 20/07/17 18:09, Sakari Ailus wrote: >> Hi Hans, >> >> On Wed, Jul 19, 2017 at 01:24:54PM +0200, Hans Verkuil wrote: >>> On 18/07/17 21:03, Sakari Ailus wrote: The async notifier supports three callbacks to the notifier: bound, unbound and complete. The complete callback has been traditionally used for creating the sub-device nodes. This approach has an inherent weakness: if registration of a single sub-device fails for whatever reason, it renders the entire media device unusable even if only that piece of hardware is not working. This is a problem in particular in systems with multiple independent image pipelines on a single device. We have had such devices (e.g. omap3isp) supported for a number of years and the problem is growing more pressing as time passes so there is an incentive to resolve this. >>> >>> I don't think this is a good reason. If one of the subdevices fail, then >>> your >>> hardware is messed up and there is no point in continuing. >> >> That's entirely untrue in general case. Adding my 2 cents ... because I'm hitting this ... right now. >> >> If you have e.g. a mobile phone with a single camera, yes, you're right. >> But most mobile phones have two cameras these days. Embedded systems may >> have many, think of automotive use cases: you could have five or ten >> cameras there. I have a MAX9286 which has 4 camera subdevices connected. Right now, if *ONE* fails - they all fail. - This is very much undesirable behaviour. In this instance, when one fails (perhaps I have not connected one camera) then the remaining camera subdevices all probe successfully, but the complete callback is never called. Therefore the rest of my pipeline is dead, - But that could now mean my reversing camera is not working because my wing mirror camera was 'knocked' off... :-( > These are all very recent developments. Today userspace can safely assume > that either everything would be up and running, or nothing at all. This is a strong point, and I'm struggling to decide if I agree or not :D There are so many use cases, it's hard to make one statement fit all. For example - currently - an analogue input source might not be connected - but userspace may not know that, and would instead capture a black screen. Maybe that doesn't even match ... I'm tired ;) >> It is not feasible to prevent the entire system from working if a single >> component is at fault --- this is really any component such as a lens >> controller. > > All I am saying is that there should be a way to indicate that you accept > that parts are faulty, and that you (i.e. userspace) are able to detect > and handle that. > > You can't just change the current behavior and expect existing applications > to work. E.g. says a sensor failed. Today the application might detect that > the video node didn't come up, so something is seriously wrong with the > hardware > and it shows a message on the display. If this would change and the video node > *would* come up, even though there is no sensor the behavior of the > application > would almost certainly change unexpectedly. > > How to select which behavior you want isn't easy. The only thing I can come up > with is a module option. Not very elegant, unfortunately. But it doesn't > belong in the DT, and when userspace gets involved it is already too late. Yes, this sounds nasty - but 3 out of 4 working cameras being disabled / not coming up because one failed sounds worse to me currently (I would say that ... my cameras didn't come up) ... :-( -- Kieran > Regards, > > Hans >
[PATCH -next] media: ov5670: add depends to fix build errors
From: Randy Dunlap Fix build errors by adding dependency on VIDEO_V4L2_SUBDEV_API: ../drivers/media/i2c/ov5670.c: In function 'ov5670_open': ../drivers/media/i2c/ov5670.c:1917:5: error: implicit declaration of function 'v4l2_subdev_get_try_format' [-Werror=implicit-function-declaration] v4l2_subdev_get_try_format(sd, fh->pad, 0); ../drivers/media/i2c/ov5670.c:1917:38: error: 'struct v4l2_subdev_fh' has no member named 'pad' v4l2_subdev_get_try_format(sd, fh->pad, 0); ../drivers/media/i2c/ov5670.c: In function 'ov5670_do_get_pad_format': ../drivers/media/i2c/ov5670.c:2198:17: error: invalid type argument of unary '*' (have 'int') fmt->format = *v4l2_subdev_get_try_format(&ov5670->sd, cfg, ../drivers/media/i2c/ov5670.c: In function 'ov5670_set_pad_format': ../drivers/media/i2c/ov5670.c:2236:3: error: invalid type argument of unary '*' (have 'int') *v4l2_subdev_get_try_format(sd, cfg, fmt->pad) = fmt->format; ../drivers/media/i2c/ov5670.c: At top level: ../drivers/media/i2c/ov5670.c:2444:19: error: 'v4l2_subdev_link_validate' undeclared here (not in a function) .link_validate = v4l2_subdev_link_validate, ../drivers/media/i2c/ov5670.c: In function 'ov5670_probe': ../drivers/media/i2c/ov5670.c:2492:12: error: 'struct v4l2_subdev' has no member named 'entity' ov5670->sd.entity.ops = &ov5670_subdev_entity_ops; ../drivers/media/i2c/ov5670.c:2493:12: error: 'struct v4l2_subdev' has no member named 'entity' ov5670->sd.entity.function = MEDIA_ENT_F_CAM_SENSOR; ../drivers/media/i2c/ov5670.c:2497:42: error: 'struct v4l2_subdev' has no member named 'entity' ret = media_entity_pads_init(&ov5670->sd.entity, 1, &ov5670->pad); ../drivers/media/i2c/ov5670.c:2524:34: error: 'struct v4l2_subdev' has no member named 'entity' media_entity_cleanup(&ov5670->sd.entity); ../drivers/media/i2c/ov5670.c: In function 'ov5670_remove': ../drivers/media/i2c/ov5670.c:2544:26: error: 'struct v4l2_subdev' has no member named 'entity' media_entity_cleanup(&sd->entity); Signed-off-by: Randy Dunlap Cc: "Rapolu, Chiranjeevi" Cc: "Yang, Hyungwoo" --- drivers/media/i2c/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-next-20170720.orig/drivers/media/i2c/Kconfig +++ linux-next-20170720/drivers/media/i2c/Kconfig @@ -618,7 +618,7 @@ config VIDEO_OV6650 config VIDEO_OV5670 tristate "OmniVision OV5670 sensor support" - depends on I2C && VIDEO_V4L2 + depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API depends on MEDIA_CAMERA_SUPPORT select V4L2_FWNODE ---help---
Re: [PATCH][V2] dvb_frontend: ensure that inital front end status initialized
Em Thu, 20 Jul 2017 23:12:07 +0100
Colin King escreveu:
> From: Colin Ian King
>
> The fe_status variable s is not initialized meaning it can have any
> random garbage status. This could be problematic if fe->ops.tune is
> false as s is not updated by the call to fe->ops.tune() and a
> subsequent check on the change status will using a garbage value.
> Fix this by adding FE_NONE to the enum fe_status and initializing
> s to this.
>
> Detected by CoverityScan, CID#112887 ("Uninitialized scalar variable")
>
> Signed-off-by: Colin Ian King
> ---
> drivers/media/dvb-core/dvb_frontend.c | 2 +-
> include/uapi/linux/dvb/frontend.h | 1 +
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/dvb-core/dvb_frontend.c
> b/drivers/media/dvb-core/dvb_frontend.c
> index e3fff8f64d37..18cc3bbc699c 100644
> --- a/drivers/media/dvb-core/dvb_frontend.c
> +++ b/drivers/media/dvb-core/dvb_frontend.c
> @@ -631,7 +631,7 @@ static int dvb_frontend_thread(void *data)
> struct dvb_frontend *fe = data;
> struct dtv_frontend_properties *c = &fe->dtv_property_cache;
> struct dvb_frontend_private *fepriv = fe->frontend_priv;
> - enum fe_status s;
> + enum fe_status s = FE_NONE;
> enum dvbfe_algo algo;
> bool re_tune = false;
> bool semheld = false;
> diff --git a/include/uapi/linux/dvb/frontend.h
> b/include/uapi/linux/dvb/frontend.h
> index 00a20cd21ee2..afc3972b0879 100644
> --- a/include/uapi/linux/dvb/frontend.h
> +++ b/include/uapi/linux/dvb/frontend.h
> @@ -127,6 +127,7 @@ enum fe_sec_mini_cmd {
> * to reset DiSEqC, tone and parameters
> */
> enum fe_status {
> + FE_NONE = 0x00,
> FE_HAS_SIGNAL = 0x01,
> FE_HAS_CARRIER = 0x02,
> FE_HAS_VITERBI = 0x04,
If you're willing to touch the uAPI, please update its documentation:
$ git grep FE_HAS_SIGNAL Documentation/
Documentation/media/uapi/dvb/examples.rst: if (*stat & FE_HAS_SIGNAL)
Documentation/media/uapi/dvb/fe-read-status.rst: ``FE_HAS_SIGNAL``
Regards,
Mauro
Thanks,
Mauro
Re: [PATCH][V2] dvb_frontend: ensure that inital front end status initialized
On 07/20/2017 04:12 PM, Colin King wrote:
> From: Colin Ian King
>
> The fe_status variable s is not initialized meaning it can have any
> random garbage status. This could be problematic if fe->ops.tune is
> false as s is not updated by the call to fe->ops.tune() and a
> subsequent check on the change status will using a garbage value.
> Fix this by adding FE_NONE to the enum fe_status and initializing
> s to this.
>
> Detected by CoverityScan, CID#112887 ("Uninitialized scalar variable")
>
> Signed-off-by: Colin Ian King
Reviewed-by: Shuah Khan
Looks good to me. Do you mind fixing dvb_frontend_swzigzag() as well.
It currently initializes enum fe_status s = 0; in a separate patch.
> ---
> drivers/media/dvb-core/dvb_frontend.c | 2 +-
> include/uapi/linux/dvb/frontend.h | 1 +
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/dvb-core/dvb_frontend.c
> b/drivers/media/dvb-core/dvb_frontend.c
> index e3fff8f64d37..18cc3bbc699c 100644
> --- a/drivers/media/dvb-core/dvb_frontend.c
> +++ b/drivers/media/dvb-core/dvb_frontend.c
> @@ -631,7 +631,7 @@ static int dvb_frontend_thread(void *data)
> struct dvb_frontend *fe = data;
> struct dtv_frontend_properties *c = &fe->dtv_property_cache;
> struct dvb_frontend_private *fepriv = fe->frontend_priv;
> - enum fe_status s;
> + enum fe_status s = FE_NONE;
> enum dvbfe_algo algo;
> bool re_tune = false;
> bool semheld = false;
> diff --git a/include/uapi/linux/dvb/frontend.h
> b/include/uapi/linux/dvb/frontend.h
> index 00a20cd21ee2..afc3972b0879 100644
> --- a/include/uapi/linux/dvb/frontend.h
> +++ b/include/uapi/linux/dvb/frontend.h
> @@ -127,6 +127,7 @@ enum fe_sec_mini_cmd {
> * to reset DiSEqC, tone and parameters
> */
> enum fe_status {
> + FE_NONE = 0x00,
> FE_HAS_SIGNAL = 0x01,
> FE_HAS_CARRIER = 0x02,
> FE_HAS_VITERBI = 0x04,
>
[PATCH][V2] dvb_frontend: ensure that inital front end status initialized
From: Colin Ian King
The fe_status variable s is not initialized meaning it can have any
random garbage status. This could be problematic if fe->ops.tune is
false as s is not updated by the call to fe->ops.tune() and a
subsequent check on the change status will using a garbage value.
Fix this by adding FE_NONE to the enum fe_status and initializing
s to this.
Detected by CoverityScan, CID#112887 ("Uninitialized scalar variable")
Signed-off-by: Colin Ian King
---
drivers/media/dvb-core/dvb_frontend.c | 2 +-
include/uapi/linux/dvb/frontend.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/dvb-core/dvb_frontend.c
b/drivers/media/dvb-core/dvb_frontend.c
index e3fff8f64d37..18cc3bbc699c 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -631,7 +631,7 @@ static int dvb_frontend_thread(void *data)
struct dvb_frontend *fe = data;
struct dtv_frontend_properties *c = &fe->dtv_property_cache;
struct dvb_frontend_private *fepriv = fe->frontend_priv;
- enum fe_status s;
+ enum fe_status s = FE_NONE;
enum dvbfe_algo algo;
bool re_tune = false;
bool semheld = false;
diff --git a/include/uapi/linux/dvb/frontend.h
b/include/uapi/linux/dvb/frontend.h
index 00a20cd21ee2..afc3972b0879 100644
--- a/include/uapi/linux/dvb/frontend.h
+++ b/include/uapi/linux/dvb/frontend.h
@@ -127,6 +127,7 @@ enum fe_sec_mini_cmd {
* to reset DiSEqC, tone and parameters
*/
enum fe_status {
+ FE_NONE = 0x00,
FE_HAS_SIGNAL = 0x01,
FE_HAS_CARRIER = 0x02,
FE_HAS_VITERBI = 0x04,
--
2.11.0
Re: [PATCH v3 03/12] intel-ipu3: Add DMA API implementation
Hi Arnd, On Wed, Jul 19, 2017 at 09:24:41AM +0200, Arnd Bergmann wrote: > On Wed, Jul 19, 2017 at 5:12 AM, Yong Zhi wrote: > > From: Tomasz Figa > > > > This patch adds support for the IPU3 DMA mapping API. > > > > Signed-off-by: Tomasz Figa > > Signed-off-by: Yong Zhi > > This needs some explanation on why you decided to go down the > route of adding your own dma_map_ops. It's not obvious at all, > and and I'm still concerned that this complicates things more than > it helps. There are a few considerations here --- they could be documented in the patch commit message - The device has its own MMU. The default x86 DMA ops assume there isn't. - As this is an image signal processor device, the buffers are typically large (often in the range of tens of MB) and they do not need to be physically contiguous. The current implementation of e.g. drivers/iommu/intel-iommu.c allocate memory using alloc_pages() which is unfeasible for such single allocations. Neither CMA is needed. Also other IOMMU implementations have their own DMA ops currently. I agree it'd be nice to unify these in the long run but I don't think this stands apart from the rest currently --- except that the MMU is only used by a single PCI device, the same which it is contained in. -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
[PATCH] Revert "[media] v4l: async: make v4l2 coexist with devicetree nodes in a dt overlay"
This reverts commit d2180e0cf77dc7a7049671d5d57dfa0a228f83c1.
The commit was flawed in that if the device_node pointers are different,
then in fact a different device is present and the device node could be
different in ways other than full_name.
As Frank Rowand explained:
"When an overlay (1) is removed, all uses and references to the nodes and
properties in that overlay are no longer valid. Any driver that uses any
information from the overlay _must_ stop using any data from the overlay.
Any driver that is bound to a new node in the overlay _must_ unbind. Any
driver that became bound to a pre-existing node that was modified by the
overlay (became bound after the overlay was applied) _must_ adjust itself
to account for any changes to that node when the overlay is removed. One
way to do this is to unbind when notified that the overlay is about to
be removed, then to re-bind after the overlay is completely removed.
If an overlay (2) is subsequently applied, a node with the same
full_name as from overlay (1) may exist. There is no guarantee
that overlay (1) and overlay (2) are the same overlay, even if
that node has the same full_name in both cases."
Also, there's not sufficient overlay support in mainline to actually
remove and re-apply an overlay to hit this condition as overlays can
only be applied from in kernel APIs.
Cc: Mauro Carvalho Chehab
Cc: Sakari Ailus
Cc: Javi Merino
Cc: Javier Martinez Canillas
Cc: Sylwester Nawrocki
Cc: Frank Rowand
Signed-off-by: Rob Herring
---
Mauro, please apply this for 4.13. It could be marked for stable, too,
but it's not going to apply cleanly with the fwnode changes.
Rob
drivers/media/v4l2-core/v4l2-async.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-async.c
b/drivers/media/v4l2-core/v4l2-async.c
index 851f128eba22..d741a8e0fdac 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -44,12 +44,7 @@ static bool match_devname(struct v4l2_subdev *sd,
static bool match_fwnode(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
{
- if (!is_of_node(sd->fwnode) || !is_of_node(asd->match.fwnode.fwnode))
- return sd->fwnode == asd->match.fwnode.fwnode;
-
- return !of_node_cmp(of_node_full_name(to_of_node(sd->fwnode)),
- of_node_full_name(
- to_of_node(asd->match.fwnode.fwnode)));
+ return sd->fwnode == asd->match.fwnode.fwnode;
}
static bool match_custom(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd)
--
2.11.0
Re: [PATCH v3 03/12] intel-ipu3: Add DMA API implementation
Hi Yong,
On Tue, Jul 18, 2017 at 10:12:58PM -0500, Yong Zhi wrote:
> From: Tomasz Figa
>
> This patch adds support for the IPU3 DMA mapping API.
>
> Signed-off-by: Tomasz Figa
> Signed-off-by: Yong Zhi
> ---
> drivers/media/pci/intel/ipu3/Kconfig | 8 +
> drivers/media/pci/intel/ipu3/Makefile | 2 +-
> drivers/media/pci/intel/ipu3/ipu3-dmamap.c | 302
> +
> drivers/media/pci/intel/ipu3/ipu3-dmamap.h | 22 +++
> 4 files changed, 333 insertions(+), 1 deletion(-)
> create mode 100644 drivers/media/pci/intel/ipu3/ipu3-dmamap.c
> create mode 100644 drivers/media/pci/intel/ipu3/ipu3-dmamap.h
>
> diff --git a/drivers/media/pci/intel/ipu3/Kconfig
> b/drivers/media/pci/intel/ipu3/Kconfig
> index 7bcdfa5..d503806 100644
> --- a/drivers/media/pci/intel/ipu3/Kconfig
> +++ b/drivers/media/pci/intel/ipu3/Kconfig
> @@ -24,3 +24,11 @@ config INTEL_IPU3_MMU
> ---help---
> For IPU3, this option enables its MMU driver to translate its internal
> virtual address to 39 bits wide physical address for 64GBytes space
> access.
> +
> +config INTEL_IPU3_DMAMAP
> + tristate
> + default n
> + select IOMMU_DMA
> + select IOMMU_IOVA
> + ---help---
> + This is IPU3 IOMMU domain specific DMA driver.
> diff --git a/drivers/media/pci/intel/ipu3/Makefile
> b/drivers/media/pci/intel/ipu3/Makefile
> index 91cac9c..6517732 100644
> --- a/drivers/media/pci/intel/ipu3/Makefile
> +++ b/drivers/media/pci/intel/ipu3/Makefile
> @@ -13,4 +13,4 @@
>
> obj-$(CONFIG_VIDEO_IPU3_CIO2) += ipu3-cio2.o
> obj-$(CONFIG_INTEL_IPU3_MMU) += ipu3-mmu.o
> -
> +obj-$(CONFIG_INTEL_IPU3_DMAMAP) += ipu3-dmamap.o
> diff --git a/drivers/media/pci/intel/ipu3/ipu3-dmamap.c
> b/drivers/media/pci/intel/ipu3/ipu3-dmamap.c
> new file mode 100644
> index 000..86a0e15
> --- /dev/null
> +++ b/drivers/media/pci/intel/ipu3/ipu3-dmamap.c
> @@ -0,0 +1,302 @@
> +/*
> + * Copyright (c) 2017 Intel Corporation.
> + * Copyright (C) 2017 Google, Inc.
> + *
> + * 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.
> + *
> + * 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.
> + *
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "ipu3-mmu.h"
> +
> +/*
> + * Based on arch/arm64/mm/dma-mapping.c, with simplifications possible due
> + * to driver-specific character of this file.
> + */
> +
> +static pgprot_t __get_dma_pgprot(unsigned long attrs, pgprot_t prot)
> +{
> + if (DMA_ATTR_NON_CONSISTENT & attrs)
> + return prot;
> + return pgprot_writecombine(prot);
> +}
> +
> +static void flush_page(struct device *dev, const void *virt, phys_addr_t
> phys)
> +{
> + /*
> + * FIXME: Yes, casting to override the const specifier is ugly.
> + * However, for some reason, this callback is intended to flush cache
> + * for a page pointed to by a const pointer, even though the cach
> + * flush operation by definition does not keep the affected memory
> + * constant...
> + */
> + clflush_cache_range((void *)virt, PAGE_SIZE);
Hmm. Is this needed? The hardware is coherent --- apart from the MMU
tables.
Same for the flushes below.
> +}
> +
> +static void *ipu3_dmamap_alloc(struct device *dev, size_t size,
> +dma_addr_t *handle, gfp_t gfp,
> +unsigned long attrs)
> +{
> + int ioprot = dma_info_to_prot(DMA_BIDIRECTIONAL, false, attrs);
> + size_t iosize = size;
> + struct page **pages;
> + pgprot_t prot;
> + void *addr;
> +
> + if (WARN(!dev, "cannot create IOMMU mapping for unknown device\n"))
> + return NULL;
> +
> + if (WARN(!gfpflags_allow_blocking(gfp),
> + "atomic allocations not supported\n") ||
> + WARN((DMA_ATTR_FORCE_CONTIGUOUS & attrs),
> + "contiguous allocations not supported\n"))
> + return NULL;
> +
> + size = PAGE_ALIGN(size);
> +
> + dev_dbg(dev, "%s: allocating %zu\n", __func__, size);
> +
> + /*
> + * Some drivers rely on this, and we probably don't want the
> + * possibility of stale kernel data being read by devices anyway.
> + */
> + gfp |= __GFP_ZERO;
> +
> + /*
> + * On x86, __GFP_DMA or __GFP_DMA32 might be added implicitly, based
> + * on device DMA mask. However the mask does not apply to the IOMMU,
> + * which is expected to be able to map any physical page.
> + */
> + gfp &= ~(__GFP_DMA | __GFP_DMA32);
> +
> + pages = iommu_dma_alloc(dev, iosize, gfp, attrs, ioprot,
> + handle,
Re: [PATCH v3 02/12] intel-ipu3: mmu: implement driver
Hi Robin,
On Wed, Jul 19, 2017 at 02:37:12PM +0100, Robin Murphy wrote:
...
> > +static int ipu3_mmu_map(struct iommu_domain *domain, unsigned long iova,
> > + phys_addr_t paddr, size_t size, int prot)
> > +{
> > + struct ipu3_mmu_domain *mmu_dom = to_ipu3_mmu_domain(domain);
> > + u32 l1pt_idx, l2pt_idx;
> > + unsigned long flags;
> > + u32 *l2pt;
> > +
> > + /* We assume a page by page mapping. */
> > + if (WARN_ON(size != IPU3_PAGE_SIZE))
> > + return -EINVAL;
>
> The core API already enforces this, so drivers shouldn't need to be
> paranoid.
>
> > +
> > + address_to_pte_idx(iova, &l1pt_idx, &l2pt_idx);
> > +
> > + l2pt = ipu3_mmu_get_l2pt(mmu_dom, l1pt_idx, true);
> > + if (!l2pt)
> > + return -ENOMEM;
> > +
> > + spin_lock_irqsave(&mmu_dom->lock, flags);
> > +
> > + if (l2pt[l2pt_idx] != mmu_dom->dummy_page_pteval) {
> > + spin_unlock_irqrestore(&mmu_dom->lock, flags);
> > + return -EBUSY;
> > + }
> > +
> > + l2pt[l2pt_idx] = IPU3_ADDR2PTE(paddr);
> > +
> > + clflush_cache_range(&l2pt[l2pt_idx], sizeof(*l2pt));
> > +
> > + if (mmu_dom->mmu)
>
> Yikes, are there actually users in the kernel which allocate domains and
> try to create mappings in them before attaching any devices? In general,
> that poses an ugly problem for certain IOMMU drivers :(
This case is a bit special. The MMU is part of a PCI device which is also
behind the MMU itself.
Just the existence of mapped memory (or the mapping operation itself)
shouldn't require powering on or keeping the device powered on. Hence this.
> > + call_if_ipu3_is_powered(mmu_dom->mmu, ipu3_mmu_tlb_invalidate);
> > +
> > + spin_unlock_irqrestore(&mmu_dom->lock, flags);
> > +
> > + return 0;
> > +}
> > +
> > +static size_t ipu3_mmu_unmap(struct iommu_domain *domain, unsigned long
> > iova,
> > +size_t size)
> > +{
> > + struct ipu3_mmu_domain *mmu_dom = to_ipu3_mmu_domain(domain);
> > + u32 l1pt_idx, l2pt_idx;
> > + unsigned long flags;
> > + u32 *l2pt;
> > +
> > + /* We assume a page by page unmapping. */
> > + if (WARN_ON(size != IPU3_PAGE_SIZE))
> > + return 0;
>
> As above.
>
> > +
> > + address_to_pte_idx(iova, &l1pt_idx, &l2pt_idx);
> > +
> > + l2pt = ipu3_mmu_get_l2pt(mmu_dom, l1pt_idx, false);
> > + if (!l2pt)
> > + return 0;
> > +
> > + spin_lock_irqsave(&mmu_dom->lock, flags);
> > +
> > + if (l2pt[l2pt_idx] == mmu_dom->dummy_page_pteval)
> > + size = 0;
> > + l2pt[l2pt_idx] = mmu_dom->dummy_page_pteval;
> > +
> > + clflush_cache_range(&l2pt[l2pt_idx], sizeof(*l2pt));
> > +
> > + if (mmu_dom->mmu)
> > + call_if_ipu3_is_powered(mmu_dom->mmu, ipu3_mmu_tlb_invalidate);
> > +
> > + spin_unlock_irqrestore(&mmu_dom->lock, flags);
> > +
> > + return size;
> > +}
> > +
> > +static phys_addr_t ipu3_mmu_iova_to_phys(struct iommu_domain *domain,
> > +dma_addr_t iova)
> > +{
> > + struct ipu3_mmu_domain *d = to_ipu3_mmu_domain(domain);
> > + u32 l1pt_idx, l2pt_idx;
> > + u32 pteval;
> > + u32 *l2pt;
> > +
> > + address_to_pte_idx(iova, &l1pt_idx, &l2pt_idx);
> > +
> > + l2pt = ipu3_mmu_get_l2pt(d, l1pt_idx, false);
> > + if (!l2pt)
> > + return 0;
> > +
> > + pteval = l2pt[l2pt_idx];
> > + if (pteval == d->dummy_page_pteval)
> > + return 0;
> > +
> > + return IPU3_PTE2ADDR(pteval);
> > +}
> > +
> > +static struct iommu_group *ipu3_mmu_device_group(struct device *dev)
> > +{
> > + struct ipu3_mmu *mmu = to_ipu3_mmu(dev);
> > +
> > + return mmu->group;
>
> return iommu_group_ref_get(mmu->group);
>
> Otherwise, add 2 or more devices, remove 1 again, and watch the
> still-live group disappear from under your feet.
>
> > +}
> > +
> > +static int ipu3_mmu_add_device(struct device *dev)
> > +{
> > + struct iommu_group *group;
> > +
> > + group = iommu_group_get_for_dev(dev);
> > + if (IS_ERR(group))
> > + return PTR_ERR(group);
> > +
> > + iommu_group_put(group);
> > + return 0;
> > +}
> > +
> > +static void ipu3_mmu_remove_device(struct device *dev)
> > +{
> > + struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
> > +
> > + if (!domain)
> > + return;
> > +
> > + ipu3_mmu_detach_dev(domain, dev);
>
> Ah, so you avoid the refcount bug by forgetting to remove the device
> from the group at all, but then go and implement the unpleasant
> consequences of tearing down a potentially-live domain manually :)
>
> You should call iommu_group_remove_device() here (i.e. undoing what
> iommu_group_get_for_dev() did), and let that take care of the domain as
> necessary.
>
> > +}
> > +
> > +static struct iommu_ops ipu3_iommu_ops_template = {
> > + .domain_alloc = ipu3_mmu_domain_alloc,
> > + .domain_free= ipu3_mmu_domain_free,
> > + .attach_dev = ipu3_mmu_attach_dev,
> > + .detach_dev = ipu3_mmu_detach_dev,
> > + .map
Re: [PATCH 00/14] ddbridge: bump to ddbridge-0.9.29
Hi! Daniel lined out already what the technical differences are. In fact nothing what the normal user of this very good DVB cards needs. The Octopus NET has its own distribution provided by DD. So there is no need to support this in the mainline Kernel at this time. Also the modulator is something which might be used in central stations at hotels, but not by the arbitrary user in the public. I guess this stations are also equipped with the drivers from DD or even provided as a whole system by this company. I also see no reason to support the modulator card *now*, when we are in a stage where we need to put in nearly 7 years of improvements of the DD driver into the Kernel. Yes, we are talking about nearly 7 years! And there is another thing. The very old driver V 0.5.0 currently existing in mainline, does not support the DD CI cards, which are an essential addon for all users in Austria, Switzerland, ... . Without this CI cards it is *impossible* to see the official TV program! This countries scramble the TS stream to restrict the access to citizens. Without bumping the ddbridge to V 0.9.29, we all living in this countries can't use the Kernel driver, but only the DD version! Sticking to the DD version means, we can't use other cards in parallel, because the DD version simply doesn't support to use any other driver together with the DD cards, due to the API changes and the currently used old DVB core. In my opinion nearly nobody is using the current mainline driver, due to it's limitations and the fact, that the DD version provides all the features we need. So merging the new version will not harm anyone, but help to prevent using self compiled incompatible drivers. In my opinion it should have been DD's task to keep the DD version in sync with mainline. Moreover they should have needed to upstream their changes in the past in little steps. Instead they changed the API and made it more or less impossible to merge it without a lot of effort! As Daniel already mentioned, he spent 1,5 years to understand the driver, to make it compatible to the Mainline DVB core, to provide patches, to test the result, to get other people involved to test the new drivers, ... . When this is not merged *now*, I guess we will lose *the* person who made it happen! There were other people who tried it, but didn't have the endurance and energy to meet the target. Daniel will definitely continue working on this subject to keep the DD version in sync with the mainline version, even if there are some things still different. We are very close to the target and making it now a stopper for the mentioned little things is the worst thing we can do! Beside all this organisational issue, I had the chance to use this driver for a couple of days on my test system: DD Cine V 6.5 with a DD Duoflex CI (single) and a DD Duoflex S2 V4 tuner card VDR 2.3.8, ddci2 Plugin 1.5.0 And the productive system: DD Octopus CI (dual) with a DD Duoflex S2 tuner card VDR 2.2.0, ddci2 Plugin 1.5.0 I had no issues, beside small problems with my CAM on the productive system, which I also had with the upstream DD driver. I am already debugging them, but need support from Ralph concerning FPGA registers and maybe more. This problem has nothing to do with the new drivers, so it is no stopper for merging it into mainline. With this eMail I add my Tested-by: Jasmin Jessich for this whole series. Finally I want to thank Daniel for his effort and I adjure Mauro to merge this now! BR, Jasmin * On 07/20/2017 08:25 PM, Daniel Scheller wrote: > Hi Mauro, > > Am Thu, 20 Jul 2017 12:24:12 -0300 > schrieb Mauro Carvalho Chehab : > >> Em Tue, 11 Jul 2017 17:30:13 +0200 >> Daniel Scheller escreveu: >> >>> Am Tue, 11 Jul 2017 11:11:27 +0200 >>> schrieb Ralph Metzler : >>> Daniel Scheller writes: > > IIRC this was -main.c, and basically the code split, but no > specific file. However, each of the additionals (hw, io, irq) > were done with a reason (please also see their commit messages > at patches 4-6): > [...] As I wrote before, changes like this will break other things like the OctopusNet build tree. So, I cannot use them like this or without changes at other places. And even if I wanted to, I cannot pull anything into the public dddvb repository. >>> >>> Ok, you probably have seen the PRs I created against dddvb, as they >>> apply basically the same as is contained in this patchset, and even >>> fixes a few minors. Thus, lets not declare this as merge-blocker for >>> this patches, please. >> >> I would prefer if we could spend more time trying to find a way where >> we can proceed without increasing the discrepancies between upstream >> and DD tree, but, instead to reduce. >> >> I mean, if we know that some change won't be accepted at DD tree, >> better to change our approach to another
Re: [RFC 11/19] v4l2-async: Register sub-devices before calling bound callback
Hi Hans, On Thu, Jul 20, 2017 at 06:23:38PM +0200, Hans Verkuil wrote: > On 20/07/17 18:09, Sakari Ailus wrote: > > Hi Hans, > > > > On Wed, Jul 19, 2017 at 01:24:54PM +0200, Hans Verkuil wrote: > >> On 18/07/17 21:03, Sakari Ailus wrote: > >>> The async notifier supports three callbacks to the notifier: bound, > >>> unbound > >>> and complete. The complete callback has been traditionally used for > >>> creating the sub-device nodes. > >>> > >>> This approach has an inherent weakness: if registration of a single > >>> sub-device fails for whatever reason, it renders the entire media device > >>> unusable even if only that piece of hardware is not working. This is a > >>> problem in particular in systems with multiple independent image pipelines > >>> on a single device. We have had such devices (e.g. omap3isp) supported for > >>> a number of years and the problem is growing more pressing as time passes > >>> so there is an incentive to resolve this. > >> > >> I don't think this is a good reason. If one of the subdevices fail, then > >> your > >> hardware is messed up and there is no point in continuing. > > > > That's entirely untrue in general case. > > > > If you have e.g. a mobile phone with a single camera, yes, you're right. > > But most mobile phones have two cameras these days. Embedded systems may > > have many, think of automotive use cases: you could have five or ten > > cameras there. > > These are all very recent developments. Today userspace can safely assume > that either everything would be up and running, or nothing at all. > > > It is not feasible to prevent the entire system from working if a single > > component is at fault --- this is really any component such as a lens > > controller. > > All I am saying is that there should be a way to indicate that you accept > that parts are faulty, and that you (i.e. userspace) are able to detect > and handle that. > > You can't just change the current behavior and expect existing applications > to work. E.g. says a sensor failed. Today the application might detect that > the video node didn't come up, so something is seriously wrong with the > hardware > and it shows a message on the display. If this would change and the video node > *would* come up, even though there is no sensor the behavior of the > application > would almost certainly change unexpectedly. > > How to select which behavior you want isn't easy. The only thing I can come up > with is a module option. Not very elegant, unfortunately. But it doesn't > belong in the DT, and when userspace gets involved it is already too late. Module options don't scale if you want to change kernel interface behaviour. Adding a Kconfig option would. We can neither make this application specific since the application isn't known by the time the nodes are created. Kconfig option (that defaults to no) with the events and media device status info amended with documentation change would achieve the goal, although it'd take a lot of time to adjust all the applications before the Kconfig option can be safely removed. This approach does have the benefit of being able to provide the feature to those systems that really depend on it. -- Regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
Re: [PATCH 00/14] ddbridge: bump to ddbridge-0.9.29
Hi Mauro, Am Thu, 20 Jul 2017 12:24:12 -0300 schrieb Mauro Carvalho Chehab : > Em Tue, 11 Jul 2017 17:30:13 +0200 > Daniel Scheller escreveu: > > > Am Tue, 11 Jul 2017 11:11:27 +0200 > > schrieb Ralph Metzler : > > > > > Daniel Scheller writes: > > > > > > > > IIRC this was -main.c, and basically the code split, but no > > > > specific file. However, each of the additionals (hw, io, irq) > > > > were done with a reason (please also see their commit messages > > > > at patches 4-6): > > > > [...] > > > > > > As I wrote before, changes like this will break other things like > > > the OctopusNet build tree. So, I cannot use them like this or > > > without changes at other places. And even if I wanted to, I > > > cannot pull anything into the public dddvb repository. > > > > Ok, you probably have seen the PRs I created against dddvb, as they > > apply basically the same as is contained in this patchset, and even > > fixes a few minors. Thus, lets not declare this as merge-blocker for > > this patches, please. > > I would prefer if we could spend more time trying to find a way where > we can proceed without increasing the discrepancies between upstream > and DD tree, but, instead to reduce. > > I mean, if we know that some change won't be accepted at DD tree, > better to change our approach to another one that it is acceptable > on both upstream and DD trees. (hopefully not too much language barrier coming up...) First and foremost (to everyone involved) - I appeal at you all, in the name of all DD hardware owners, for like six approaches to get the patches in shape and over 1.5 years of spare time spent, to not make this a reason to block the patches. And yes, Mauro, I understand what you're up to. Rather, this closes the gap between the current dddvb drivers and what we have in mainline by at least 24 (!!) (plus some minor revisions and other intermediate versions I couldn't get tar archives for) software releases. Plus, the only real difference we have after these patches is support for the DVB-C modulator cards and the OctoNET box support (with that, support for the aforementioned GTL links, which I even already have a patch for to add that back), and both are features that are removed *for now* only due to the API changes involved, which simply is a tad too much for me right now to add them in and provide reasoning why they're needed and what exactly they do. Speaking of the modulator card support, things are even quite simple, see [1] and [2] what I gathered from the package to have all things API in place. In addition, the parts in ddbridge can be added back quite easily (some output-dma things, PCI IDs plus ddbridge-mod[ulator].c). If these two simple things are acceptable in DVB core, I can even prepare patches for getting the modulator support back in. As Ralph mentioned the three additional files -irq, -io and -hw, I do not insist on them, but rather thought it'd be a good way to further make things cleaner, by separating things more. So, again, please do not make this a blocker, but lets rather make this a start to get things closer to each other, and continue in doing so by finding agreements in parallel. And: I _WILL_ care about keeping the mainline version in sync with upstream and NOT diverge further; this is what the MAINTAINERS entry is meant for at last! [1] https://github.com/herrnst/dddvb-linux-kernel/commit/c586db283ef51f43ecb1d1c9e49230184ea02714 [2] https://github.com/herrnst/dddvb-linux-kernel/commit/f448a8485a24acec7b44ac418ef57b59eb8369cd All the best, Daniel Scheller -- https://github.com/herrnst
Re: [PATCH v3 01/10] [media] dvb-frontends: add ST STV0910 DVB-S/S2 demodulator frontend driver
Hi, Am Thu, 20 Jul 2017 14:21:24 -0300 schrieb Mauro Carvalho Chehab : > The right coding style for multi-line comments is: > > /* >* foo >* bar >*/ > > I ended by merging this series,[...] Thanks alot! > but please send a fixup patch > when you have some time. > > Btw, specially for new drivers, it could worth running checkpatch in > scritct mode: Well. Honestly, I wasn't fully aware of the "strict" option (at least until Jasmin was told about it, but then the patches were there for some time already). Since I have two (maybe three) minors for the stv0910 driver in my GIT which I'd like to also submit, I will check and fix up things in addition. > Several of those warnings can be automatically fixed with: > > ./scripts/checkpatch.pl -f $(git diff 435945e08551|diffstat -p1 > -l|grep -v MAINT) --strict --fix-inplace > > But you need to review if the results are ok. Thanks for the hints! Best regards, Daniel Scheller -- https://github.com/herrnst
Re: [PATCH v3 01/10] [media] dvb-frontends: add ST STV0910 DVB-S/S2 demodulator frontend driver
Em Mon, 3 Jul 2017 19:20:54 +0200
Daniel Scheller escreveu:
> From: Daniel Scheller
>
> This adds a multi frontend driver for the ST STV0910 DVB-S/S2 demodulator
> frontends. The driver code originates from the Digital Devices' dddvb
> vendor driver package as of version 0.9.29, and has been cleaned up from
> core API usage which isn't supported yet in the kernel, and additionally
> all obvious style issues have been resolved. All camel case and allcaps
> have been converted to kernel_case and lowercase. Patches have been sent
> to the vendor package maintainers to fix this aswell. Signal statistics
> acquisition has been refactored to comply with standards.
>
> Permission to reuse and mainline the driver code was formally granted by
> Ralph Metzler .
>
> Signed-off-by: Daniel Scheller
> Tested-by: Richard Scobie
> ---
> drivers/media/dvb-frontends/Kconfig|9 +
> drivers/media/dvb-frontends/Makefile |1 +
> drivers/media/dvb-frontends/stv0910.c | 1702 ++
> drivers/media/dvb-frontends/stv0910.h | 32 +
> drivers/media/dvb-frontends/stv0910_regs.h | 4759
>
> 5 files changed, 6503 insertions(+)
> create mode 100644 drivers/media/dvb-frontends/stv0910.c
> create mode 100644 drivers/media/dvb-frontends/stv0910.h
> create mode 100644 drivers/media/dvb-frontends/stv0910_regs.h
>
> diff --git a/drivers/media/dvb-frontends/Kconfig
> b/drivers/media/dvb-frontends/Kconfig
> index 3a260b82b3e8..773de5e264e3 100644
> --- a/drivers/media/dvb-frontends/Kconfig
> +++ b/drivers/media/dvb-frontends/Kconfig
> @@ -28,6 +28,15 @@ config DVB_STV090x
> DVB-S/S2/DSS Multistandard Professional/Broadcast demodulators.
> Say Y when you want to support these frontends.
>
> +config DVB_STV0910
> + tristate "STV0910 based"
> + depends on DVB_CORE && I2C
> + default m if !MEDIA_SUBDRV_AUTOSELECT
> + help
> + ST STV0910 DVB-S/S2 demodulator driver.
> +
> + Say Y when you want to support these frontends.
> +
> config DVB_STV6110x
> tristate "STV6110/(A) based tuners"
> depends on DVB_CORE && I2C
> diff --git a/drivers/media/dvb-frontends/Makefile
> b/drivers/media/dvb-frontends/Makefile
> index 3fccaf34ef52..c302b2d07499 100644
> --- a/drivers/media/dvb-frontends/Makefile
> +++ b/drivers/media/dvb-frontends/Makefile
> @@ -110,6 +110,7 @@ obj-$(CONFIG_DVB_CXD2820R) += cxd2820r.o
> obj-$(CONFIG_DVB_CXD2841ER) += cxd2841er.o
> obj-$(CONFIG_DVB_DRXK) += drxk.o
> obj-$(CONFIG_DVB_TDA18271C2DD) += tda18271c2dd.o
> +obj-$(CONFIG_DVB_STV0910) += stv0910.o
> obj-$(CONFIG_DVB_SI2165) += si2165.o
> obj-$(CONFIG_DVB_A8293) += a8293.o
> obj-$(CONFIG_DVB_SP2) += sp2.o
> diff --git a/drivers/media/dvb-frontends/stv0910.c
> b/drivers/media/dvb-frontends/stv0910.c
> new file mode 100644
> index ..9dfcaf5e067f
> --- /dev/null
> +++ b/drivers/media/dvb-frontends/stv0910.c
> @@ -0,0 +1,1702 @@
> +/*
> + * Driver for the ST STV0910 DVB-S/S2 demodulator.
> + *
> + * Copyright (C) 2014-2015 Ralph Metzler
> + * Marcus Metzler
> + * developed for Digital Devices GmbH
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 only, as published by the Free Software Foundation.
> + *
> + * 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.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "dvb_math.h"
> +#include "dvb_frontend.h"
> +#include "stv0910.h"
> +#include "stv0910_regs.h"
> +
> +#define EXT_CLOCK3000
> +#define TUNING_DELAY 200
> +#define BER_SRC_S0x20
> +#define BER_SRC_S2 0x20
> +
> +LIST_HEAD(stvlist);
> +
> +enum receive_mode { RCVMODE_NONE, RCVMODE_DVBS, RCVMODE_DVBS2, RCVMODE_AUTO
> };
> +
> +enum dvbs2_fectype { DVBS2_64K, DVBS2_16K };
> +
> +enum dvbs2_mod_cod {
> + DVBS2_DUMMY_PLF, DVBS2_QPSK_1_4, DVBS2_QPSK_1_3, DVBS2_QPSK_2_5,
> + DVBS2_QPSK_1_2, DVBS2_QPSK_3_5, DVBS2_QPSK_2_3, DVBS2_QPSK_3_4,
> + DVBS2_QPSK_4_5, DVBS2_QPSK_5_6, DVBS2_QPSK_8_9, DVBS2_QPSK_9_10,
> + DVBS2_8PSK_3_5, DVBS2_8PSK_2_3, DVBS2_8PSK_3_4, DVBS2_8PSK_5_6,
> + DVBS2_8PSK_8_9, DVBS2_8PSK_9_10, DVBS2_16APSK_2_3, DVBS2_16APSK_3_4,
> + DVBS2_16APSK_4_5, DVBS2_16APSK_5_6, DVBS2_16APSK_8_9, DVBS2_16APSK_9_10,
> + DVBS2_32APSK_3_4, DVBS2_32APSK_4_5, DVBS2_32APSK_5_6, DVBS2_32APSK_8_9,
> + DVBS2_32APSK_9_10
> +};
> +
> +enum fe_stv0910_mod_cod {
> + FE_DUMMY_PLF, FE_QPSK_14, FE_QPSK_13, FE_QPSK_25,
> + FE_QPSK_12, FE_QPSK_35, FE_QPSK_23, FE_QPSK_34,
> + FE_QPSK_45, FE_QPSK_56, FE_QPSK_89, FE_QPSK_910,
> + FE_8PSK_35, FE_8PSK_23, FE_8
Adv7180 driver configuration problem
I need to configure adv7281m in renesas SOC which uses rcar-csi as bridge(csi receiver) and rcar- vin as dma engine. I have done the configuration in device tree as mention in DT bindings. When i start the streaming (continuous capture), i am getting rcar.csi2: timeout reading the PHY clock lane further probing the data lanes on adv7281m, i am seeing incorrect voltages in HS mode.
Re: [RFC 11/19] v4l2-async: Register sub-devices before calling bound callback
On 20/07/17 18:09, Sakari Ailus wrote: > Hi Hans, > > On Wed, Jul 19, 2017 at 01:24:54PM +0200, Hans Verkuil wrote: >> On 18/07/17 21:03, Sakari Ailus wrote: >>> The async notifier supports three callbacks to the notifier: bound, unbound >>> and complete. The complete callback has been traditionally used for >>> creating the sub-device nodes. >>> >>> This approach has an inherent weakness: if registration of a single >>> sub-device fails for whatever reason, it renders the entire media device >>> unusable even if only that piece of hardware is not working. This is a >>> problem in particular in systems with multiple independent image pipelines >>> on a single device. We have had such devices (e.g. omap3isp) supported for >>> a number of years and the problem is growing more pressing as time passes >>> so there is an incentive to resolve this. >> >> I don't think this is a good reason. If one of the subdevices fail, then your >> hardware is messed up and there is no point in continuing. > > That's entirely untrue in general case. > > If you have e.g. a mobile phone with a single camera, yes, you're right. > But most mobile phones have two cameras these days. Embedded systems may > have many, think of automotive use cases: you could have five or ten > cameras there. These are all very recent developments. Today userspace can safely assume that either everything would be up and running, or nothing at all. > It is not feasible to prevent the entire system from working if a single > component is at fault --- this is really any component such as a lens > controller. All I am saying is that there should be a way to indicate that you accept that parts are faulty, and that you (i.e. userspace) are able to detect and handle that. You can't just change the current behavior and expect existing applications to work. E.g. says a sensor failed. Today the application might detect that the video node didn't come up, so something is seriously wrong with the hardware and it shows a message on the display. If this would change and the video node *would* come up, even though there is no sensor the behavior of the application would almost certainly change unexpectedly. How to select which behavior you want isn't easy. The only thing I can come up with is a module option. Not very elegant, unfortunately. But it doesn't belong in the DT, and when userspace gets involved it is already too late. Regards, Hans
Re: [RFC 00/19] Async sub-notifiers and how to use them
Hi Hans, Thanks for the review. On Wed, Jul 19, 2017 at 01:42:55PM +0200, Hans Verkuil wrote: > On 18/07/17 21:03, Sakari Ailus wrote: > > Hi folks, > > > > This RFC patchset achieves a number of things which I've put to the same > > patchset for they need to be show together to demonstrate the use cases. > > > > I don't really intend this to compete with Niklas's patchset but much of > > the problem area addressed by the two is the same. > > > > Comments would be welcome. > > > > - Add AS3645A LED flash class driver. > > > > - Add async notifiers (by Niklas). > > > > - V4L2 sub-device node registration is moved to take place at the same time > > with the registration of the sub-device itself. With this change, > > sub-device node registration behaviour is aligned with video node > > registration. > > > > - The former is made possible by moving the bound() callback after > > sub-device registration. > > > > - As all the device node registration and link creation is done as the > > respective devices are probed, there is no longer dependency to the > > notifier complete callback which as itself is seen problematic. The > > complete callback still exists but there's no need to use it, pending > > changes in individual drivers. > > > > See: > > http://www.spinics.net/lists/linux-media/msg118323.html> > > > > As a result, if a part of the media device fails to initialise because it > > is e.g. physically broken, it will be possible to use what works. > > I've got major problems with this from a userspace point of view. In the vast > majority of cases you just want to bail out if one or more subdevs fail. I admit it's easier for the user space if the device becomes available only when all its component drivers have registered. Also remember that video nodes are registered in the file system right on device probe time. It's only sub-device and media device node registration that has taken place in the notifier's complete handler. There are things how we could do this easier, for instance providing events on the media device on entity registration and possibly registration state (whether all entities have been registered). This way the user space can easily choose whether it would like to proceed using a partially functional device (or not). -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
Re: [RFC 11/19] v4l2-async: Register sub-devices before calling bound callback
Hi Hans, On Wed, Jul 19, 2017 at 01:24:54PM +0200, Hans Verkuil wrote: > On 18/07/17 21:03, Sakari Ailus wrote: > > The async notifier supports three callbacks to the notifier: bound, unbound > > and complete. The complete callback has been traditionally used for > > creating the sub-device nodes. > > > > This approach has an inherent weakness: if registration of a single > > sub-device fails for whatever reason, it renders the entire media device > > unusable even if only that piece of hardware is not working. This is a > > problem in particular in systems with multiple independent image pipelines > > on a single device. We have had such devices (e.g. omap3isp) supported for > > a number of years and the problem is growing more pressing as time passes > > so there is an incentive to resolve this. > > I don't think this is a good reason. If one of the subdevices fail, then your > hardware is messed up and there is no point in continuing. That's entirely untrue in general case. If you have e.g. a mobile phone with a single camera, yes, you're right. But most mobile phones have two cameras these days. Embedded systems may have many, think of automotive use cases: you could have five or ten cameras there. It is not feasible to prevent the entire system from working if a single component is at fault --- this is really any component such as a lens controller. -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
Re: [PATCH] [media] dvb_frontend: ensure that front end status is initialized
Hi Colin,
On 07/20/2017 09:29 AM, Colin King wrote:
> From: Colin Ian King
>
> The fe_status variable s is not initialized meaning it can have any
> random garbage status. This could be problematic if fe->ops.tune is
> false as s is not updated by the call to fe->ops.tune() and a
> subsequent check on the change status will using a garbage value.
> Fix this by initializing s to zero.
>
> Detected by CoverityScan, CID#112887 ("Uninitialized scalar variable")
>
> Signed-off-by: Colin Ian King
> ---
> drivers/media/dvb-core/dvb_frontend.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/dvb-core/dvb_frontend.c
> b/drivers/media/dvb-core/dvb_frontend.c
> index e3fff8f64d37..e18ea1508a59 100644
> --- a/drivers/media/dvb-core/dvb_frontend.c
> +++ b/drivers/media/dvb-core/dvb_frontend.c
> @@ -631,7 +631,7 @@ static int dvb_frontend_thread(void *data)
> struct dvb_frontend *fe = data;
> struct dtv_frontend_properties *c = &fe->dtv_property_cache;
> struct dvb_frontend_private *fepriv = fe->frontend_priv;
> - enum fe_status s;
> + enum fe_status s = 0;
0 isn't a valid value for enum fe_status. I think the right fix would be
to add FE_NONE to enum fe_status and then initialize s to that.
thanks,
-- Shuah
> enum dvbfe_algo algo;
> bool re_tune = false;
> bool semheld = false;
>
[ragnatech:media-tree] BUILD INCOMPLETE 8d935787d38f1c2bf689f64ecfe4581e05e5fe55
git://git.ragnatech.se/linux media-tree 8d935787d38f1c2bf689f64ecfe4581e05e5fe55 media: MAINTAINERS: Add ADV748x driver TIMEOUT after 1125m Sorry we cannot finish the testset for your branch within a reasonable time. It's our fault -- either some build server is down or some build worker is busy doing bisects for _other_ trees. The branch will get more complete coverage and possible error reports when our build infrastructure is restored or catches up. There will be no more build success notification for this branch head, but you can expect reasonably good test coverage after waiting for 1 day. configs tested: 154 pariscc3000_defconfig parisc b180_defconfig parisc defconfig alpha defconfig pariscallnoconfig arm64 defconfig powerpc makalu_defconfig sh ap325rxa_defconfig x86_64 randconfig-a0-07201854 blackfindefconfig ia64defconfig mipsdefconfig i386 randconfig-c0-07201940 i386 randconfig-x010-07201658 i386 randconfig-x011-07201658 i386 randconfig-x012-07201658 i386 randconfig-x013-07201658 i386 randconfig-x014-07201658 i386 randconfig-x015-07201658 i386 randconfig-x016-07201658 i386 randconfig-x017-07201658 i386 randconfig-x018-07201658 i386 randconfig-x019-07201658 x86_64lkp microblaze mmu_defconfig microblazenommu_defconfig x86_64 randconfig-x005-07201609 x86_64 randconfig-x000-07201609 x86_64 randconfig-x004-07201609 x86_64 randconfig-x003-07201609 x86_64 randconfig-x002-07201609 x86_64 randconfig-x008-07201609 x86_64 randconfig-x006-07201609 x86_64 randconfig-x009-07201609 x86_64 randconfig-x007-07201609 x86_64 randconfig-x001-07201609 ia64 allnoconfig ia64 alldefconfig x86_64 kexec x86_64 rhel x86_64 rhel-7.2 powerpc allnoconfig powerpc defconfig powerpc ppc64_defconfig s390default_defconfig i386 allyesconfig arm allmodconfig arm arm5 arm arm67 arm imx_v6_v7_defconfig arm ixp4xx_defconfig armmvebu_v7_defconfig arm omap2plus_defconfig armsa1100 arm samsung armsh arm tegra_defconfig arm64alldefconfig arm64allmodconfig i386 randconfig-a0-07201704 i386 randconfig-a1-07201704 x86_64 randconfig-s0-07201906 x86_64 randconfig-s1-07201906 x86_64 randconfig-s2-07201906 x86_64 acpi-redef x86_64 allyesdebian x86_64nfsroot blackfinBF526-EZBRD_defconfig blackfinBF533-EZKIT_defconfig blackfinBF561-EZKIT-SMP_defconfig blackfin TCM-BF537_defconfig cris etrax-100lx_v2_defconfig sh defconfig x86_64 randconfig-x010-07201610 x86_64 randconfig-x011-07201610 x86_64 randconfig-x012-07201610 x86_64 randconfig-x013-07201610 x86_64 randconfig-x014-07201610 x86_64 randconfig-x015-07201610 x86_64 randconfig-x016-07201610 x86_64 randconfig-x017-07201610 x86_64 randconfig-x018-07201610 x86_64 randconfig-x019-07201610 i386 alldefconfig i386 allnoconfig i386defconfig m68k m5475evb_defconfig m68k multi_defconfig m68k sun3_defconfig i386 randconfig-s0-07201610 i386 randconfig-s1-07201610 x86_64 allmodconfig x86_64 randconfig-s3-07201913 x86_64 randconfig-s4-07201913 x86_64 randconfig-s5-07201913
Re: [Patch v5 12/12] Documention: v4l: Documentation for HEVC CIDs
Hi, >>> + >>> +* - ``V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN`` >>> + - Main profile. >> >> MAIN10? >> > No just MAIN. I haven't because the MFC does not supported it? If so, I think we have to add MAIN10 for completeness and because other drivers could have support for it. -- regards, Stan
Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)
Em Tue, 11 Jul 2017 20:12:35 +0200 Ralph Metzler escreveu: > Mauro Carvalho Chehab writes: > > Em Mon, 26 Jun 2017 11:45:08 +0200 > > Ralph Metzler escreveu: > > > > The media controller is generic enough to control all pipelines at > > the hardware level. It can be used to select frontend inputs, to > > dynamically add/remove CAM modules, etc. > > > > If I remember well, in the case of the hardware I was working on that > > time, each frontend had 3 inputs (and the hardware had 2 identical > > sets of tuner/demod), plus 3 MPEG-TS demuxes) and 2 CAM modules. > > > > With the media controller, any arrangement between input, tuner, > > demod, demux and CAM is possible, as long as supported by > > the hardware. > > OK, for such complex arrangements it makes sense. > I just thought it to be overkill for just the input selection The media controller support is handled by the DVB core for the general case. The needed bits that would give the flexibility that ddbridge require shouldn't be hard to add. > and it also has to run on older kernels where th MC stuff is > not yet in the DVB core. The MC DVB support is there since jan/2015 (Kernel 3.20): commit a0246e02f466482a34c8ad94bedbe4efa498662d Author: Mauro Carvalho Chehab Date: Fri Jan 2 12:19:51 2015 -0300 [media] dvbdev: add support for media controller Provide a way to register media controller device nodes at the DVB core. Please notice that the dvbdev callers also require changes for the devices to be registered via the media controller. Signed-off-by: Mauro Carvalho Chehab $ git describe a0246e02f4664 media/v3.20-1-9-ga0246e02f466 For older Kernels, there are a few ways to proceed: 1) use an approach like media_build for the DD tree, where the DVB core is replaced by a newer one. I guess it has support since v2.6.30, at least for the core. 2) Keep use the solution you have already, using ifdefs on your tree to keep it supported with legacy Kernels. 3) you could base DD trees at the backport tree: https://backports.wiki.kernel.org/index.php/Main_Page I never used it myself, but it should be covering the media drivers there too. Thanks, Mauro
[PATCH] [media] dvb_frontend: ensure that front end status is initialized
From: Colin Ian King
The fe_status variable s is not initialized meaning it can have any
random garbage status. This could be problematic if fe->ops.tune is
false as s is not updated by the call to fe->ops.tune() and a
subsequent check on the change status will using a garbage value.
Fix this by initializing s to zero.
Detected by CoverityScan, CID#112887 ("Uninitialized scalar variable")
Signed-off-by: Colin Ian King
---
drivers/media/dvb-core/dvb_frontend.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/dvb-core/dvb_frontend.c
b/drivers/media/dvb-core/dvb_frontend.c
index e3fff8f64d37..e18ea1508a59 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -631,7 +631,7 @@ static int dvb_frontend_thread(void *data)
struct dvb_frontend *fe = data;
struct dtv_frontend_properties *c = &fe->dtv_property_cache;
struct dvb_frontend_private *fepriv = fe->frontend_priv;
- enum fe_status s;
+ enum fe_status s = 0;
enum dvbfe_algo algo;
bool re_tune = false;
bool semheld = false;
--
2.11.0
Re: [PATCH v3 00/23] Qualcomm 8x16 Camera Subsystem driver
Hi Todor, On Mon, Jul 17, 2017 at 01:33:26PM +0300, Todor Tomov wrote: > This patchset adds basic support for the Qualcomm Camera Subsystem found > on Qualcomm MSM8916 and APQ8016 processors. > > The driver implements V4L2, Media controller and V4L2 subdev interfaces. > Camera sensor using V4L2 subdev interface in the kernel is supported. > > The driver is implemented using as a reference the Qualcomm Camera > Subsystem driver for Android as found in Code Aurora [1]. > > The driver is tested on Dragonboard 410C (APQ8016) with one and two > OV5645 camera sensors. media-ctl [2] and yavta [3] applications were > used for testing. Also Gstreamer 1.10.4 with v4l2src plugin is supported. > > More information is present in the document added by the third patch. After addressing the comments (please pay attention especially those affecting the user space API behaviour) you can add: Acked-by: Sakari Ailus Let me know if you have any further questions on the individual comments. -- Regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
Re: [PATCH 00/14] ddbridge: bump to ddbridge-0.9.29
Em Tue, 11 Jul 2017 17:30:13 +0200 Daniel Scheller escreveu: > Am Tue, 11 Jul 2017 11:11:27 +0200 > schrieb Ralph Metzler : > > > Daniel Scheller writes: > > > > > > IIRC this was -main.c, and basically the code split, but no > > > specific file. However, each of the additionals (hw, io, irq) were > > > done with a reason (please also see their commit messages at > > > patches 4-6): > > > [...] > > > > As I wrote before, changes like this will break other things like the > > OctopusNet build tree. So, I cannot use them like this or without > > changes at other places. And even if I wanted to, I cannot pull > > anything into the public dddvb repository. > > Ok, you probably have seen the PRs I created against dddvb, as they > apply basically the same as is contained in this patchset, and even > fixes a few minors. Thus, lets not declare this as merge-blocker for > this patches, please. I would prefer if we could spend more time trying to find a way where we can proceed without increasing the discrepancies between upstream and DD tree, but, instead to reduce. I mean, if we know that some change won't be accepted at DD tree, better to change our approach to another one that it is acceptable on both upstream and DD trees. Thanks, Mauro
Re: [PATCH v3 22/23] camss: Use optimal clock frequency rates
Hi Todor,
On Mon, Jul 17, 2017 at 01:33:48PM +0300, Todor Tomov wrote:
> Use standard V4L2 control to get pixel clock rate from a sensor
> linked in the media controller pipeline. Then calculate clock
> rates on CSIPHY, CSID and VFE to use the lowest possible.
>
> If the currnet pixel clock rate of the sensor cannot be read then
> use the highest possible. This case covers also the CSID test
> generator usage.
>
> If VFE is already powered on by another pipeline, check that the
> current VFE clock rate is high enough for the new pipeline.
> If not return busy error code as VFE clock rate cannot be changed
> while VFE is running.
>
> Signed-off-by: Todor Tomov
> ---
> .../media/platform/qcom/camss-8x16/camss-csid.c| 324
> ++---
> .../media/platform/qcom/camss-8x16/camss-csid.h| 2 +-
> .../media/platform/qcom/camss-8x16/camss-csiphy.c | 112 +--
> .../media/platform/qcom/camss-8x16/camss-csiphy.h | 2 +-
> .../media/platform/qcom/camss-8x16/camss-ispif.c | 23 +-
> .../media/platform/qcom/camss-8x16/camss-ispif.h | 4 +-
> drivers/media/platform/qcom/camss-8x16/camss-vfe.c | 289 +++---
> drivers/media/platform/qcom/camss-8x16/camss-vfe.h | 2 +-
> drivers/media/platform/qcom/camss-8x16/camss.c | 51 +++-
> drivers/media/platform/qcom/camss-8x16/camss.h | 17 +-
> 10 files changed, 634 insertions(+), 192 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/camss-8x16/camss-csid.c
> b/drivers/media/platform/qcom/camss-8x16/camss-csid.c
> index 2bf3415..5c0e359 100644
> --- a/drivers/media/platform/qcom/camss-8x16/camss-csid.c
> +++ b/drivers/media/platform/qcom/camss-8x16/camss-csid.c
> @@ -68,122 +68,224 @@ static const struct {
> u8 data_type;
> u8 decode_format;
> u8 uncompr_bpp;
> + u8 spp; /* bus samples per pixel */
> } csid_input_fmts[] = {
> {
> MEDIA_BUS_FMT_UYVY8_2X8,
> MEDIA_BUS_FMT_UYVY8_2X8,
> DATA_TYPE_YUV422_8BIT,
> DECODE_FORMAT_UNCOMPRESSED_8_BIT,
> - 16
> + 8,
> + 2
If your original patch had added the comma on the previous line, this would
be simply adding a line per array entry.
> },
> {
> MEDIA_BUS_FMT_VYUY8_2X8,
> MEDIA_BUS_FMT_VYUY8_2X8,
> DATA_TYPE_YUV422_8BIT,
> DECODE_FORMAT_UNCOMPRESSED_8_BIT,
> - 16
> + 8,
> + 2
> },
> {
> MEDIA_BUS_FMT_YUYV8_2X8,
> MEDIA_BUS_FMT_YUYV8_2X8,
> DATA_TYPE_YUV422_8BIT,
> DECODE_FORMAT_UNCOMPRESSED_8_BIT,
> - 16
> + 8,
> + 2
> },
> {
> MEDIA_BUS_FMT_YVYU8_2X8,
> MEDIA_BUS_FMT_YVYU8_2X8,
> DATA_TYPE_YUV422_8BIT,
> DECODE_FORMAT_UNCOMPRESSED_8_BIT,
> - 16
> + 8,
> + 2
> },
> {
> MEDIA_BUS_FMT_SBGGR8_1X8,
> MEDIA_BUS_FMT_SBGGR8_1X8,
> DATA_TYPE_RAW_8BIT,
> DECODE_FORMAT_UNCOMPRESSED_8_BIT,
> - 8
> + 8,
> + 1
> },
> {
> MEDIA_BUS_FMT_SGBRG8_1X8,
> MEDIA_BUS_FMT_SGBRG8_1X8,
> DATA_TYPE_RAW_8BIT,
> DECODE_FORMAT_UNCOMPRESSED_8_BIT,
> - 8
> + 8,
> + 1
> },
> {
> MEDIA_BUS_FMT_SGRBG8_1X8,
> MEDIA_BUS_FMT_SGRBG8_1X8,
> DATA_TYPE_RAW_8BIT,
> DECODE_FORMAT_UNCOMPRESSED_8_BIT,
> - 8
> + 8,
> + 1
> },
> {
> MEDIA_BUS_FMT_SRGGB8_1X8,
> MEDIA_BUS_FMT_SRGGB8_1X8,
> DATA_TYPE_RAW_8BIT,
> DECODE_FORMAT_UNCOMPRESSED_8_BIT,
> - 8
> + 8,
> + 1
> },
> {
> MEDIA_BUS_FMT_SBGGR10_1X10,
> MEDIA_BUS_FMT_SBGGR10_1X10,
> DATA_TYPE_RAW_10BIT,
> DECODE_FORMAT_UNCOMPRESSED_10_BIT,
> - 10
> + 10,
> + 1
> },
> {
> MEDIA_BUS_FMT_SGBRG10_1X10,
> MEDIA_BUS_FMT_SGBRG10_1X10,
> DATA_TYPE_RAW_10BIT,
> DECODE_FORMAT_UNCOMPRESSED_10_BIT,
> - 10
> + 10,
> + 1
> },
> {
> MEDIA_BUS_FMT_SGRBG10_1X10,
> MEDIA_BUS_FMT_SGRBG10_1X10,
> DATA_TYPE_RAW_10BIT,
> DECODE_FORMAT_UNCOMPRESSED_10_BIT,
> - 10
> + 10,
> + 1
> },
> {
> MEDIA_BUS_FMT_SRGGB10_1X10,
> MEDIA_BUS_FMT_SRGGB10_1X10,
> DATA_TYPE_RAW_10BIT,
> DECODE_FORMAT_UNCOMPRESSED_10_BIT,
> - 10
> + 10,
> + 1
> },
> {
Re: [PATCH v3 17/23] camss: vfe: Add interface for scaling
Hi Todor,
On Mon, Jul 17, 2017 at 01:33:43PM +0300, Todor Tomov wrote:
> Add compose selection ioctls to handle scaling configuration.
>
> Signed-off-by: Todor Tomov
> ---
> drivers/media/platform/qcom/camss-8x16/camss-vfe.c | 189
> -
> drivers/media/platform/qcom/camss-8x16/camss-vfe.h | 1 +
> 2 files changed, 188 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/camss-8x16/camss-vfe.c
> b/drivers/media/platform/qcom/camss-8x16/camss-vfe.c
> index 327f158..8ec6ce7 100644
> --- a/drivers/media/platform/qcom/camss-8x16/camss-vfe.c
> +++ b/drivers/media/platform/qcom/camss-8x16/camss-vfe.c
> @@ -211,6 +211,8 @@
> #define CAMIF_TIMEOUT_SLEEP_US 1000
> #define CAMIF_TIMEOUT_ALL_US 100
>
> +#define SCALER_RATIO_MAX 16
> +
> static const u32 vfe_formats[] = {
> MEDIA_BUS_FMT_UYVY8_2X8,
> MEDIA_BUS_FMT_VYUY8_2X8,
> @@ -1905,6 +1907,25 @@ __vfe_get_format(struct vfe_line *line,
> return &line->fmt[pad];
> }
>
> +/*
> + * __vfe_get_compose - Get pointer to compose selection structure
> + * @line: VFE line
> + * @cfg: V4L2 subdev pad configuration
> + * @which: TRY or ACTIVE format
> + *
> + * Return pointer to TRY or ACTIVE compose rectangle structure
> + */
> +static struct v4l2_rect *
> +__vfe_get_compose(struct vfe_line *line,
> + struct v4l2_subdev_pad_config *cfg,
> + enum v4l2_subdev_format_whence which)
> +{
> + if (which == V4L2_SUBDEV_FORMAT_TRY)
> + return v4l2_subdev_get_try_compose(&line->subdev, cfg,
> +MSM_VFE_PAD_SINK);
> +
> + return &line->compose;
> +}
>
> /*
> * vfe_try_format - Handle try format by pad subdev method
> @@ -1951,7 +1972,14 @@ static void vfe_try_format(struct vfe_line *line,
> *fmt = *__vfe_get_format(line, cfg, MSM_VFE_PAD_SINK,
>which);
>
> - if (line->id == VFE_LINE_PIX)
> + if (line->id == VFE_LINE_PIX) {
> + struct v4l2_rect *rect;
> +
> + rect = __vfe_get_compose(line, cfg, which);
> +
> + fmt->width = rect->width;
> + fmt->height = rect->height;
> +
> switch (fmt->code) {
> case MEDIA_BUS_FMT_YUYV8_2X8:
> if (code == MEDIA_BUS_FMT_YUYV8_1_5X8)
> @@ -1979,6 +2007,7 @@ static void vfe_try_format(struct vfe_line *line,
> fmt->code = MEDIA_BUS_FMT_VYUY8_2X8;
> break;
> }
> + }
>
> break;
> }
> @@ -1987,6 +2016,50 @@ static void vfe_try_format(struct vfe_line *line,
> }
>
> /*
> + * vfe_try_compose - Handle try compose selection by pad subdev method
> + * @line: VFE line
> + * @cfg: V4L2 subdev pad configuration
> + * @rect: pointer to v4l2 rect structure
> + * @which: wanted subdev format
> + */
> +static void vfe_try_compose(struct vfe_line *line,
> + struct v4l2_subdev_pad_config *cfg,
> + struct v4l2_rect *rect,
> + enum v4l2_subdev_format_whence which)
> +{
> + struct v4l2_mbus_framefmt *fmt;
> +
> + rect->width = rect->width - rect->left;
> + rect->left = 0;
This is the compose rectangle i.e. left and top should be zero (unless it's
about composing on e.g. a frame buffer). No need to decrement from width;
similarly for height below.
> + rect->height = rect->height - rect->top;
> + rect->top = 0;
> +
> + fmt = __vfe_get_format(line, cfg, MSM_VFE_PAD_SINK, which);
> +
> + if (rect->width > fmt->width)
> + rect->width = fmt->width;
> +
> + if (rect->height > fmt->height)
> + rect->height = fmt->height;
> +
> + if (fmt->width > rect->width * SCALER_RATIO_MAX)
> + rect->width = (fmt->width + SCALER_RATIO_MAX - 1) /
> + SCALER_RATIO_MAX;
> +
> + rect->width &= ~0x1;
> +
> + if (fmt->height > rect->height * SCALER_RATIO_MAX)
> + rect->height = (fmt->height + SCALER_RATIO_MAX - 1) /
> + SCALER_RATIO_MAX;
> +
> + if (rect->width < 16)
> + rect->width = 16;
> +
> + if (rect->height < 4)
> + rect->height = 4;
> +}
> +
> +/*
> * vfe_enum_mbus_code - Handle pixel format enumeration
> * @sd: VFE V4L2 subdevice
> * @cfg: V4L2 subdev pad configuration
> @@ -2081,6 +2154,10 @@ static int vfe_get_format(struct v4l2_subdev *sd,
> return 0;
> }
>
> +static int vfe_set_selection(struct v4l2_subdev *sd,
> + struct v4l2_subdev_pad_config *cfg,
> + struct v4l2_subdev_selection *sel);
> +
> /*
> * vfe_set_format - Handle set format by pads subdev method
> * @sd: VFE V4L2 subdevice
> @@ -2103,20
Re: DD support improvements (was: Re: [PATCH v3 00/13] stv0367/ddbridge: support CTv6/FlexCT hardware)
Em Tue, 27 Jun 2017 07:38:50 +0200 Ralph Metzler escreveu: > Daniel Scheller writes: > > Am Mon, 26 Jun 2017 11:59:20 +0200 > > schrieb Ralph Metzler : > > > > > Mauro Carvalho Chehab writes: > > > > > > > > Splitting it is OK. Including a *.c file no. It shouldn't be hard > > > > to > > > [...] > > > > change the makefile to: > > > > obj-ddbridge = ddbridge-main.o ddbridge-core.o > > > > ddbridge-i2c.o \ ddbridge-modulator.o and ddbridge-ns.o > > > > > > > > The only detail is that "ddbridge.c" should be renamed to > > > > ddbridge-core.c (or something similar) and some *.h files will > > > > be needed. > > > > > > Hmm, ddbridge -> ddbridge-main would be fine. > > > > Funny, that's exactly the naming I had in mind when thinking about this > > in the past :) > > > > So, I'll propose a rough todo (commit list) for me (I will do and > > care about this) then: > > > > - 1/4: (Step 0) Since dddvb-0.9.9b besides the split also involved > > reordering the functions in the code, this will be repeated with the > > current mainline driver (helps keeping the diff with the actual code > > bump cleaner) > > - 2/4: Do the split like done in 0.9.9 with the mainline driver, but do > > it by having multiple objects in the makefile, adding header files > > with prototypes where required > > - 3/4: Bump the driver code with what is already there (means, the > > pre-cleaned variant w/o modulator and netstream/octonet stuff) > > - 4/4 (or 4/x): Apply any additional patches (like the "enable msi by > > default Kconf opt, marked EXPERIMENTAL" thing I did to work around > > the still problematic MSI IRQ stuff to let users have a better > > experience) > > > > When done, I'll post the patches for early review, but they'll have a > > hard dependency on the stv0910/stv6111 demod/tuner drivers (don't feel > > like ripping this out since we want that support anyway). > > > > Additionally,I can do this for dddvb and submit it to the DigitalDevices > dddvb > > repository (GitHub Pull Request) so we're at least in-sync wrt > > building the driver. > > > > Ralph, Mauro, are you ok with this? > > I cannot promise which changes I will accept and when. Some will likely break > other things like building the OctopusNet image. > > The public DigitalDevices repository also is not the one I am using for > development. > So, changes will first go into our private repository and will only go > upstream > for releases. Are there any way where we can help to make easier to synchronize upstream with your internal tree? As Daniel mentioned that he used some scripts, perhaps he can send them for you to run on your tree. Another alternative would be if you could release a "fork" of your development tree before a release, as sort of "release candidate" or something similar, at least while we're taking some efforts to synchronize it with upstream. Thanks, Mauro
[GIT PULL FOR v4.13] venus/davinci fixes for 4.13
The following changes since commit 0e6fd95802e25b2428749703f76ea9d54ea743a3: media: pulse8-cec/rainshadow-cec: make adapter name unique (2017-07-18 13:00:52 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v4.13b for you to fetch changes up to 250c04a2dda0cb7e378773443a000f5c32b42c8d: media: platform: davinci: drop VPFE_CMD_S_CCDC_RAW_PARAMS (2017-07-20 17:08:06 +0200) Arnd Bergmann (2): venus: mark PM functions as __maybe_unused venus: fix compile-test build on non-qcom ARM platform Prabhakar Lad (2): media: platform: davinci: return -EINVAL for VPFE_CMD_S_CCDC_RAW_PARAMS ioctl media: platform: davinci: drop VPFE_CMD_S_CCDC_RAW_PARAMS Rob Clark (1): media: venus: hfi: fix error handling in hfi_sys_init_done() Stanimir Varbanov (1): media: venus: don't abuse dma_alloc for non-DMA allocations drivers/media/platform/Kconfig | 4 +-- drivers/media/platform/davinci/ccdc_hw_device.h | 10 -- drivers/media/platform/davinci/dm355_ccdc.c | 92 +--- drivers/media/platform/davinci/dm644x_ccdc.c| 151 ++- drivers/media/platform/davinci/vpfe_capture.c | 93 - drivers/media/platform/qcom/venus/core.c| 16 - drivers/media/platform/qcom/venus/core.h| 1 - drivers/media/platform/qcom/venus/firmware.c| 76 ++-- drivers/media/platform/qcom/venus/firmware.h| 5 ++- drivers/media/platform/qcom/venus/hfi_msgs.c| 11 +++--- include/media/davinci/dm644x_ccdc.h | 12 --- include/media/davinci/vpfe_capture.h| 10 -- 12 files changed, 54 insertions(+), 427 deletions(-)
Re: [PATCH v3 16/23] camss: vfe: Support for frame padding
Hi Todor,
On Mon, Jul 17, 2017 at 01:33:42PM +0300, Todor Tomov wrote:
> Add support for horizontal and vertical frame padding.
>
> Signed-off-by: Todor Tomov
> ---
> drivers/media/platform/qcom/camss-8x16/camss-vfe.c | 86
> +-
> .../media/platform/qcom/camss-8x16/camss-video.c | 69 -
> .../media/platform/qcom/camss-8x16/camss-video.h | 2 +
> 3 files changed, 121 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/camss-8x16/camss-vfe.c
> b/drivers/media/platform/qcom/camss-8x16/camss-vfe.c
> index bef0209..327f158 100644
> --- a/drivers/media/platform/qcom/camss-8x16/camss-vfe.c
> +++ b/drivers/media/platform/qcom/camss-8x16/camss-vfe.c
> @@ -279,21 +279,75 @@ static void vfe_wm_frame_based(struct vfe_device *vfe,
> u8 wm, u8 enable)
> 1 << VFE_0_BUS_IMAGE_MASTER_n_WR_CFG_FRM_BASED_SHIFT);
> }
>
> +#define CALC_WORD(width, M, N) (((width) * (M) + (N) - 1) / (N))
> +
> +static int vfe_word_per_line(uint32_t format, uint32_t pixel_per_line)
> +{
> + int val = 0;
> +
> + switch (format) {
> + case V4L2_PIX_FMT_NV12:
> + case V4L2_PIX_FMT_NV21:
> + case V4L2_PIX_FMT_NV16:
> + case V4L2_PIX_FMT_NV61:
> + val = CALC_WORD(pixel_per_line, 1, 8);
> + break;
> + case V4L2_PIX_FMT_YUYV:
> + case V4L2_PIX_FMT_YVYU:
> + case V4L2_PIX_FMT_UYVY:
> + case V4L2_PIX_FMT_VYUY:
> + val = CALC_WORD(pixel_per_line, 2, 8);
> + break;
> + }
> +
> + return val;
> +}
> +
> +static void vfe_get_wm_sizes(struct v4l2_pix_format_mplane *pix, u8 plane,
> + u16 *width, u16 *height, u16 *bytesperline)
> +{
> + switch (pix->pixelformat) {
> + case V4L2_PIX_FMT_NV12:
> + case V4L2_PIX_FMT_NV21:
> + *width = pix->width;
> + *height = pix->height;
> + *bytesperline = pix->plane_fmt[0].bytesperline;
> + if (plane == 1)
> + *height /= 2;
> + break;
> + case V4L2_PIX_FMT_NV16:
> + case V4L2_PIX_FMT_NV61:
> + *width = pix->width;
> + *height = pix->height;
> + *bytesperline = pix->plane_fmt[0].bytesperline;
> + break;
> + }
> +}
> +
> static void vfe_wm_line_based(struct vfe_device *vfe, u32 wm,
> - u16 width, u16 height, u32 enable)
> + struct v4l2_pix_format_mplane *pix,
> + u8 plane, u32 enable)
> {
> u32 reg;
>
> if (enable) {
> + u16 width = 0, height = 0, bytesperline = 0, wpl;
> +
> + vfe_get_wm_sizes(pix, plane, &width, &height, &bytesperline);
> +
> + wpl = vfe_word_per_line(pix->pixelformat, width);
> +
> reg = height - 1;
> - reg |= (width / 16 - 1) << 16;
> + reg |= ((wpl + 1) / 2 - 1) << 16;
>
> writel_relaxed(reg, vfe->base +
> VFE_0_BUS_IMAGE_MASTER_n_WR_IMAGE_SIZE(wm));
>
> + wpl = vfe_word_per_line(pix->pixelformat, bytesperline);
> +
> reg = 0x3;
> reg |= (height - 1) << 4;
> - reg |= (width / 8) << 16;
> + reg |= wpl << 16;
>
> writel_relaxed(reg, vfe->base +
> VFE_0_BUS_IMAGE_MASTER_n_WR_BUFFER_CFG(wm));
> @@ -1198,25 +1252,14 @@ static int vfe_enable_output(struct vfe_line *line)
> } else {
> ub_size /= output->wm_num;
> for (i = 0; i < output->wm_num; i++) {
> - u32 p =
> line->video_out.active_fmt.fmt.pix_mp.pixelformat;
> -
> vfe_set_cgc_override(vfe, output->wm_idx[i], 1);
> vfe_wm_set_subsample(vfe, output->wm_idx[i]);
> vfe_wm_set_ub_cfg(vfe, output->wm_idx[i],
> (ub_size + 1) * output->wm_idx[i],
> ub_size);
> - if ((i == 1) && (p == V4L2_PIX_FMT_NV12 ||
> - p == V4L2_PIX_FMT_NV21))
> - vfe_wm_line_based(vfe, output->wm_idx[i],
> -
> line->fmt[MSM_VFE_PAD_SRC].width,
> -
> line->fmt[MSM_VFE_PAD_SRC].height / 2,
> - 1);
> - else
> - vfe_wm_line_based(vfe, output->wm_idx[i],
> -
> line->fmt[MSM_VFE_PAD_SRC].width,
> -
> line->fmt[MSM_VFE_PAD_SRC].height,
> - 1);
> -
> + vfe_wm_line_based(vfe, output->wm_idx[i],
> + &line->video_out.active_fmt.fmt.pix_mp,
> +
Re: [PATCH v3 15/23] doc: media/v4l-drivers: Qualcomm Camera Subsystem - PIX Interface
On Mon, Jul 17, 2017 at 01:33:41PM +0300, Todor Tomov wrote: > Update Qualcomm Camera Subsystem driver document for the PIX interface > and format conversion support. > > Signed-off-by: Todor Tomov > --- > Documentation/media/v4l-drivers/qcom_camss.rst | 41 > +++--- > 1 file changed, 31 insertions(+), 10 deletions(-) > > diff --git a/Documentation/media/v4l-drivers/qcom_camss.rst > b/Documentation/media/v4l-drivers/qcom_camss.rst > index 4707ea7..4df5655 100644 > --- a/Documentation/media/v4l-drivers/qcom_camss.rst > +++ b/Documentation/media/v4l-drivers/qcom_camss.rst > @@ -45,12 +45,31 @@ Supported functionality > > The current version of the driver supports: > > -- input from camera sensor via CSIPHY; > -- generation of test input data by the TG in CSID; > -- raw dump of the input data to memory. RDI interface of VFE is supported. > - PIX interface (ISP processing, statistics engines, resize/crop, format > - conversion) is not supported in the current version; > -- concurrent and independent usage of two data inputs - could be camera > sensors > +- Input from camera sensor via CSIPHY; > +- Generation of test input data by the TG in CSID; > +- RDI interface of VFE - raw dump of the input data to memory. > + > + Supported formats: > + > + - YUYV/UYVY/YVYU/VYUY (packed YUV 4:2:2); > + - MIPI RAW8 (8bit Bayer RAW); > + - MIPI RAW10 (10bit packed Bayer RAW); > + - MIPI RAW12 (12bit packed Bayer RAW). > + > +- PIX interface of VFE > + > + - Format conversion of the input data. > + > +Supported input formats: > + > +- YUYV/UYVY/YVYU/VYUY (packed YUV 4:2:2). > + > +Supported output formats: > + > +- NV12/NV21 (two plane YUV 4:2:0); > +- NV16/NV61 (two plane YUV 4:2:2). Could you add V4L2 format names to these? > + > +- Concurrent and independent usage of two data inputs - could be camera > sensors >and/or TG. > > > @@ -65,15 +84,15 @@ interface, the driver is split into V4L2 sub-devices as > follows: > - 2 CSID sub-devices - each CSID is represented by a single sub-device; > - 2 ISPIF sub-devices - ISPIF is represented by a number of sub-devices equal >to the number of CSID sub-devices; > -- 3 VFE sub-devices - VFE is represented by a number of sub-devices equal to > - the number of RDI input interfaces. > +- 4 VFE sub-devices - VFE is represented by a number of sub-devices equal to > + the number of the input interfaces (3 RDI and 1 PIX). > > The considerations to split the driver in this particular way are as follows: > > - representing CSIPHY and CSID modules by a separate sub-device for each > module >allows to model the hardware links between these modules; > -- representing VFE by a separate sub-devices for each RDI input interface > allows > - to use the three RDI interfaces concurently and independently as this is > +- representing VFE by a separate sub-devices for each input interface allows > + to use the input interfaces concurently and independently as this is >supported by the hardware; > - representing ISPIF by a number of sub-devices equal to the number of CSID >sub-devices allows to create linear media controller pipelines when using > two > @@ -99,6 +118,8 @@ nodes) is as follows: > - msm_vfe0_video1 > - msm_vfe0_rdi2 > - msm_vfe0_video2 > +- msm_vfe0_pix > +- msm_vfe0_video3 > > > Implementation > -- > 2.7.4 > -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
Re: [PATCH v3 14/23] camss: vfe: Format conversion support using PIX interface
Hi Todor, Are you trying to get acks by posting drivers so big and complex that it'd be unwieldy to meaningfully review them? :-) On Mon, Jul 17, 2017 at 01:33:40PM +0300, Todor Tomov wrote: > Use VFE PIX input interface and do format conversion in VFE. > > Supported input format is UYVY (single plane YUV 4:2:2) and > its different sample order variations. > > Supported output formats are: > - NV12/NV21 (two plane YUV 4:2:0) > - NV16/NV61 (two plane YUV 4:2:2) > > Signed-off-by: Todor Tomov > --- > .../media/platform/qcom/camss-8x16/camss-ispif.c | 2 + > drivers/media/platform/qcom/camss-8x16/camss-vfe.c | 673 > ++--- > drivers/media/platform/qcom/camss-8x16/camss-vfe.h | 13 +- > .../media/platform/qcom/camss-8x16/camss-video.c | 332 +++--- > .../media/platform/qcom/camss-8x16/camss-video.h | 8 +- > 5 files changed, 875 insertions(+), 153 deletions(-) > > diff --git a/drivers/media/platform/qcom/camss-8x16/camss-ispif.c > b/drivers/media/platform/qcom/camss-8x16/camss-ispif.c > index cc32085..04918c0 100644 > --- a/drivers/media/platform/qcom/camss-8x16/camss-ispif.c > +++ b/drivers/media/platform/qcom/camss-8x16/camss-ispif.c > @@ -969,6 +969,8 @@ static enum ispif_intf ispif_get_intf(enum vfe_line_id > line_id) > return RDI1; > case (VFE_LINE_RDI2): > return RDI2; > + case (VFE_LINE_PIX): > + return PIX0; > default: > return RDI0; > } > diff --git a/drivers/media/platform/qcom/camss-8x16/camss-vfe.c > b/drivers/media/platform/qcom/camss-8x16/camss-vfe.c > index b6dd29b..bef0209 100644 > --- a/drivers/media/platform/qcom/camss-8x16/camss-vfe.c > +++ b/drivers/media/platform/qcom/camss-8x16/camss-vfe.c > @@ -19,6 +19,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -52,29 +53,53 @@ > #define VFE_0_GLOBAL_RESET_CMD_BUS_MISR (1 << 7) > #define VFE_0_GLOBAL_RESET_CMD_TESTGEN (1 << 8) > > +#define VFE_0_MODULE_CFG 0x018 > +#define VFE_0_MODULE_CFG_DEMUX (1 << 2) > +#define VFE_0_MODULE_CFG_CHROMA_UPSAMPLE (1 << 3) > +#define VFE_0_MODULE_CFG_SCALE_ENC (1 << 23) > + > +#define VFE_0_CORE_CFG 0x01c > +#define VFE_0_CORE_CFG_PIXEL_PATTERN_YCBYCR 0x4 > +#define VFE_0_CORE_CFG_PIXEL_PATTERN_YCRYCB 0x5 > +#define VFE_0_CORE_CFG_PIXEL_PATTERN_CBYCRY 0x6 > +#define VFE_0_CORE_CFG_PIXEL_PATTERN_CRYCBY 0x7 > + > #define VFE_0_IRQ_CMD0x024 > #define VFE_0_IRQ_CMD_GLOBAL_CLEAR (1 << 0) > > #define VFE_0_IRQ_MASK_0 0x028 > +#define VFE_0_IRQ_MASK_0_CAMIF_SOF (1 << 0) > +#define VFE_0_IRQ_MASK_0_CAMIF_EOF (1 << 1) > #define VFE_0_IRQ_MASK_0_RDIn_REG_UPDATE(n) (1 << ((n) + 5)) > +#define VFE_0_IRQ_MASK_0_line_n_REG_UPDATE(n)\ > + ((n) == VFE_LINE_PIX ? (1 << 4) : VFE_0_IRQ_MASK_0_RDIn_REG_UPDATE(n)) > #define VFE_0_IRQ_MASK_0_IMAGE_MASTER_n_PING_PONG(n) (1 << ((n) + 8)) > +#define VFE_0_IRQ_MASK_0_IMAGE_COMPOSITE_DONE_n(n) (1 << ((n) + 25)) > #define VFE_0_IRQ_MASK_0_RESET_ACK (1 << 31) > #define VFE_0_IRQ_MASK_1 0x02c > +#define VFE_0_IRQ_MASK_1_CAMIF_ERROR (1 << 0) > #define VFE_0_IRQ_MASK_1_VIOLATION (1 << 7) > #define VFE_0_IRQ_MASK_1_BUS_BDG_HALT_ACK(1 << 8) > #define VFE_0_IRQ_MASK_1_IMAGE_MASTER_n_BUS_OVERFLOW(n) (1 << ((n) + 9)) > +#define VFE_0_IRQ_MASK_1_RDIn_SOF(n) (1 << ((n) + 29)) > > #define VFE_0_IRQ_CLEAR_00x030 > #define VFE_0_IRQ_CLEAR_10x034 > > #define VFE_0_IRQ_STATUS_0 0x038 > +#define VFE_0_IRQ_STATUS_0_CAMIF_SOF (1 << 0) > #define VFE_0_IRQ_STATUS_0_RDIn_REG_UPDATE(n)(1 << ((n) + 5)) > +#define VFE_0_IRQ_STATUS_0_line_n_REG_UPDATE(n) \ > + ((n) == VFE_LINE_PIX ? (1 << 4) : VFE_0_IRQ_STATUS_0_RDIn_REG_UPDATE(n)) > #define VFE_0_IRQ_STATUS_0_IMAGE_MASTER_n_PING_PONG(n) (1 << ((n) + 8)) > +#define VFE_0_IRQ_STATUS_0_IMAGE_COMPOSITE_DONE_n(n) (1 << ((n) + 25)) > #define VFE_0_IRQ_STATUS_0_RESET_ACK (1 << 31) > #define VFE_0_IRQ_STATUS_1 0x03c > #define VFE_0_IRQ_STATUS_1_VIOLATION (1 << 7) > #define VFE_0_IRQ_STATUS_1_BUS_BDG_HALT_ACK (1 << 8) > +#define VFE_0_IRQ_STATUS_1_RDIn_SOF(n) (1 << ((n) + > 29)) > > +#define VFE_0_IRQ_COMPOSITE_MASK_0 0x40 > #define VFE_0_VIOLATION_STATUS 0x48 > > #define VFE_0_BUS_CMD0x4c > @@ -83,7 +108,10 @@ > #define VFE_0_BUS_CFG0x050 > > #define VFE_0_BUS_XBAR_CFG_x(x) (0x58 + 0x4 * ((x) / 2)) > +#define VFE_0_BUS_XBAR_CFG_x_M_PAIR_STREAM_EN(1 << 1) > +#define VFE_0_BUS_XBAR_CFG_x_M_PAIR_STREAM_SWAP_INTER_INTRA (0x3 << 4)
Re: [PATCH]
Em Mon, 10 Jul 2017 01:35:11 +0200
armetallica escreveu:
> From 043428d63637a6dd8e52449b73dbb8341885d7e4 Mon Sep 17 00:00:00 2001
> From: Armin Schoenlieb
> Date: Mon, 10 Jul 2017 01:12:52 +0200
> Subject: [PATCH] Staging: media: atomisp2: fixed trailing whitespace error in
> atomisp_v4l2.c This is a patch to the atomisp_v4l2.c file that fixes up a
> trailing whitespace error found by the checkpatch.pl tool
Something clearly gets wrong here...
Regards,
Mauro
>
> Signed-off-by: Armin Schoenlieb
> ---
> drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
> b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
> index a543def739fc..05d02ebb6d25 100644
> --- a/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
> +++ b/drivers/staging/media/atomisp/pci/atomisp2/atomisp_v4l2.c
> @@ -1277,13 +1277,13 @@ static int atomisp_pci_probe(struct pci_dev *dev,
> (ATOMISP_HW_REVISION_ISP2400
><< ATOMISP_HW_REVISION_SHIFT) |
> ATOMISP_HW_STEPPING_B0;
> -#ifdef FIXME
> +#ifdef FIXME
> if (INTEL_MID_BOARD(3, TABLET, BYT, BLK, PRO, CRV2) ||
> INTEL_MID_BOARD(3, TABLET, BYT, BLK, ENG, CRV2)) {
> isp->dfs = &dfs_config_byt_cr;
> isp->hpll_freq = HPLL_FREQ_2000MHZ;
> } else
> -#endif
> +#endif
> {
> isp->dfs = &dfs_config_byt;
> isp->hpll_freq = HPLL_FREQ_1600MHZ;
Thanks,
Mauro
Re: [PATCH v3 10/23] media: camss: Add VFE files
Hi Todor, On Mon, Jul 17, 2017 at 01:33:36PM +0300, Todor Tomov wrote: > These files control the VFE module. The VFE has different input interfaces. > The PIX input interface feeds the input data to an image processing pipeline. > Three RDI input interfaces bypass the image processing pipeline. The VFE also > contains the AXI bus interface which writes the output data to memory. > > RDI interfaces are supported in this version. PIX interface is not supported. > > Signed-off-by: Todor Tomov > --- > drivers/media/platform/qcom/camss-8x16/camss-vfe.c | 1913 > > drivers/media/platform/qcom/camss-8x16/camss-vfe.h | 114 ++ > 2 files changed, 2027 insertions(+) > create mode 100644 drivers/media/platform/qcom/camss-8x16/camss-vfe.c > create mode 100644 drivers/media/platform/qcom/camss-8x16/camss-vfe.h > > diff --git a/drivers/media/platform/qcom/camss-8x16/camss-vfe.c > b/drivers/media/platform/qcom/camss-8x16/camss-vfe.c > new file mode 100644 > index 000..b6dd29b > --- /dev/null > +++ b/drivers/media/platform/qcom/camss-8x16/camss-vfe.c > @@ -0,0 +1,1913 @@ > +/* > + * camss-vfe.c > + * > + * Qualcomm MSM Camera Subsystem - VFE Module > + * > + * Copyright (c) 2013-2015, The Linux Foundation. All rights reserved. > + * Copyright (C) 2015-2017 Linaro Ltd. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 and > + * only version 2 as published by the Free Software Foundation. > + * > + * 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. > + */ > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include "camss-vfe.h" > +#include "camss.h" > + > +#define MSM_VFE_NAME "msm_vfe" > + > +#define vfe_line_array(ptr_line) \ > + ((const struct vfe_line (*)[]) &(ptr_line[-(ptr_line->id)])) If you have something like that used by multiple parts of the driver, it'd be good to define it in a common header. (I ignore if the types are exactly the same though. Ignore the comment if they're different.) > + > +#define to_vfe(ptr_line) \ > + container_of(vfe_line_array(ptr_line), struct vfe_device, ptr_line) > + > +#define VFE_0_HW_VERSION 0x000 > + > +#define VFE_0_GLOBAL_RESET_CMD 0x00c > +#define VFE_0_GLOBAL_RESET_CMD_CORE (1 << 0) > +#define VFE_0_GLOBAL_RESET_CMD_CAMIF (1 << 1) > +#define VFE_0_GLOBAL_RESET_CMD_BUS (1 << 2) > +#define VFE_0_GLOBAL_RESET_CMD_BUS_BDG (1 << 3) > +#define VFE_0_GLOBAL_RESET_CMD_REGISTER (1 << 4) > +#define VFE_0_GLOBAL_RESET_CMD_TIMER (1 << 5) > +#define VFE_0_GLOBAL_RESET_CMD_PM(1 << 6) > +#define VFE_0_GLOBAL_RESET_CMD_BUS_MISR (1 << 7) > +#define VFE_0_GLOBAL_RESET_CMD_TESTGEN (1 << 8) > + > +#define VFE_0_IRQ_CMD0x024 > +#define VFE_0_IRQ_CMD_GLOBAL_CLEAR (1 << 0) > + > +#define VFE_0_IRQ_MASK_0 0x028 > +#define VFE_0_IRQ_MASK_0_RDIn_REG_UPDATE(n) (1 << ((n) + 5)) > +#define VFE_0_IRQ_MASK_0_IMAGE_MASTER_n_PING_PONG(n) (1 << ((n) + 8)) > +#define VFE_0_IRQ_MASK_0_RESET_ACK (1 << 31) > +#define VFE_0_IRQ_MASK_1 0x02c > +#define VFE_0_IRQ_MASK_1_VIOLATION (1 << 7) > +#define VFE_0_IRQ_MASK_1_BUS_BDG_HALT_ACK(1 << 8) > +#define VFE_0_IRQ_MASK_1_IMAGE_MASTER_n_BUS_OVERFLOW(n) (1 << ((n) + 9)) > + > +#define VFE_0_IRQ_CLEAR_00x030 > +#define VFE_0_IRQ_CLEAR_10x034 > + > +#define VFE_0_IRQ_STATUS_0 0x038 > +#define VFE_0_IRQ_STATUS_0_RDIn_REG_UPDATE(n)(1 << ((n) + 5)) > +#define VFE_0_IRQ_STATUS_0_IMAGE_MASTER_n_PING_PONG(n) (1 << ((n) + 8)) > +#define VFE_0_IRQ_STATUS_0_RESET_ACK (1 << 31) > +#define VFE_0_IRQ_STATUS_1 0x03c > +#define VFE_0_IRQ_STATUS_1_VIOLATION (1 << 7) > +#define VFE_0_IRQ_STATUS_1_BUS_BDG_HALT_ACK (1 << 8) > + > +#define VFE_0_VIOLATION_STATUS 0x48 > + > +#define VFE_0_BUS_CMD0x4c > +#define VFE_0_BUS_CMD_Mx_RLD_CMD(x) (1 << (x)) > + > +#define VFE_0_BUS_CFG0x050 > + > +#define VFE_0_BUS_XBAR_CFG_x(x) (0x58 + 0x4 * ((x) / 2)) > +#define VFE_0_BUS_XBAR_CFG_x_M_SINGLE_STREAM_SEL_SHIFT 8 > +#define VFE_0_BUS_XBAR_CFG_x_M_SINGLE_STREAM_SEL_VAL_RDI05 > +#define VFE_0_BUS_XBAR_CFG_x_M_SINGLE_STREAM_SEL_VAL_RDI16 > +#define VFE_0_BUS_XBAR_CFG_x_M_SINGLE_STREAM_SEL_VAL_RDI27 > + > +#define VFE_0_BUS_IMAGE_MASTER_n_WR_CFG(n) (0x06c + 0x24 * (n)) > +#define VFE_0_BUS_IMAGE_MASTER_n_WR_CFG_WR_PATH_SHIFT0 > +#define VFE_0_BUS_IMAGE_MASTER_n
Re: [PATCH v3 09/23] media: camss: Add ISPIF files
Hi Todor,
On Mon, Jul 17, 2017 at 01:33:35PM +0300, Todor Tomov wrote:
> These files control the ISPIF module which handles the routing of the data
> streams from the CSIDs to the inputs of the VFE.
>
> Signed-off-by: Todor Tomov
> ---
> .../media/platform/qcom/camss-8x16/camss-ispif.c | 1127
>
> .../media/platform/qcom/camss-8x16/camss-ispif.h | 85 ++
> 2 files changed, 1212 insertions(+)
> create mode 100644 drivers/media/platform/qcom/camss-8x16/camss-ispif.c
> create mode 100644 drivers/media/platform/qcom/camss-8x16/camss-ispif.h
>
> diff --git a/drivers/media/platform/qcom/camss-8x16/camss-ispif.c
> b/drivers/media/platform/qcom/camss-8x16/camss-ispif.c
> new file mode 100644
> index 000..cc32085
> --- /dev/null
> +++ b/drivers/media/platform/qcom/camss-8x16/camss-ispif.c
> @@ -0,0 +1,1127 @@
> +/*
> + * camss-ispif.c
> + *
> + * Qualcomm MSM Camera Subsystem - ISPIF Module
> + *
> + * Copyright (c) 2013-2015, The Linux Foundation. All rights reserved.
> + * Copyright (C) 2015-2017 Linaro Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * 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.
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "camss-ispif.h"
> +#include "camss.h"
> +
> +#define MSM_ISPIF_NAME "msm_ispif"
> +
> +#define ispif_line_array(ptr_line) \
> + ((const struct ispif_line (*)[]) &(ptr_line[-(ptr_line->id)]))
Argh.
> +
> +#define to_ispif(ptr_line) \
> + container_of(ispif_line_array(ptr_line), struct ispif_device, ptr_line)
> +
> +#define ISPIF_RST_CMD_0 0x008
> +#define ISPIF_IRQ_GLOBAL_CLEAR_CMD 0x01c
> +#define ISPIF_VFE_m_CTRL_0(m)(0x200 + 0x200 * (m))
> +#define ISPIF_VFE_m_CTRL_0_PIX0_LINE_BUF_EN (1 << 6)
> +#define ISPIF_VFE_m_IRQ_MASK_0(m)(0x208 + 0x200 * (m))
> +#define ISPIF_VFE_m_IRQ_MASK_0_PIX0_ENABLE 0x1249
> +#define ISPIF_VFE_m_IRQ_MASK_0_PIX0_MASK 0x1fff
> +#define ISPIF_VFE_m_IRQ_MASK_0_RDI0_ENABLE 0x02492000
> +#define ISPIF_VFE_m_IRQ_MASK_0_RDI0_MASK 0x03ffe000
> +#define ISPIF_VFE_m_IRQ_MASK_1(m)(0x20c + 0x200 * (m))
> +#define ISPIF_VFE_m_IRQ_MASK_1_PIX1_ENABLE 0x1249
> +#define ISPIF_VFE_m_IRQ_MASK_1_PIX1_MASK 0x1fff
> +#define ISPIF_VFE_m_IRQ_MASK_1_RDI1_ENABLE 0x02492000
> +#define ISPIF_VFE_m_IRQ_MASK_1_RDI1_MASK 0x03ffe000
> +#define ISPIF_VFE_m_IRQ_MASK_2(m)(0x210 + 0x200 * (m))
> +#define ISPIF_VFE_m_IRQ_MASK_2_RDI2_ENABLE 0x1249
> +#define ISPIF_VFE_m_IRQ_MASK_2_RDI2_MASK 0x1fff
> +#define ISPIF_VFE_m_IRQ_STATUS_0(m) (0x21c + 0x200 * (m))
> +#define ISPIF_VFE_m_IRQ_STATUS_0_PIX0_OVERFLOW (1 << 12)
> +#define ISPIF_VFE_m_IRQ_STATUS_0_RDI0_OVERFLOW (1 << 25)
> +#define ISPIF_VFE_m_IRQ_STATUS_1(m) (0x220 + 0x200 * (m))
> +#define ISPIF_VFE_m_IRQ_STATUS_1_PIX1_OVERFLOW (1 << 12)
> +#define ISPIF_VFE_m_IRQ_STATUS_1_RDI1_OVERFLOW (1 << 25)
> +#define ISPIF_VFE_m_IRQ_STATUS_2(m) (0x224 + 0x200 * (m))
> +#define ISPIF_VFE_m_IRQ_STATUS_2_RDI2_OVERFLOW (1 << 12)
> +#define ISPIF_VFE_m_IRQ_CLEAR_0(m) (0x230 + 0x200 * (m))
> +#define ISPIF_VFE_m_IRQ_CLEAR_1(m) (0x234 + 0x200 * (m))
> +#define ISPIF_VFE_m_IRQ_CLEAR_2(m) (0x238 + 0x200 * (m))
> +#define ISPIF_VFE_m_INTF_INPUT_SEL(m)(0x244 + 0x200 * (m))
> +#define ISPIF_VFE_m_INTF_CMD_0(m)(0x248 + 0x200 * (m))
> +#define ISPIF_VFE_m_INTF_CMD_1(m)(0x24c + 0x200 * (m))
> +#define ISPIF_VFE_m_PIX_INTF_n_CID_MASK(m, n)\
> + (0x254 + 0x200 * (m) + 0x4 * (n))
> +#define ISPIF_VFE_m_RDI_INTF_n_CID_MASK(m, n)\
> + (0x264 + 0x200 * (m) + 0x4 * (n))
> +#define ISPIF_VFE_m_PIX_INTF_n_STATUS(m, n) \
> + (0x2c0 + 0x200 * (m) + 0x4 * (n))
> +#define ISPIF_VFE_m_RDI_INTF_n_STATUS(m, n) \
> + (0x2d0 + 0x200 * (m) + 0x4 * (n))
> +
> +#define CSI_PIX_CLK_MUX_SEL 0x000
> +#define CSI_RDI_CLK_MUX_SEL 0x008
> +
> +#define ISPIF_TIMEOUT_SLEEP_US 1000
> +#define ISPIF_TIMEOUT_ALL_US 100
> +#define ISPIF_RESET_TIMEOUT_MS 500
> +
> +enum ispif_intf_cmd {
> + CMD_DISABLE_FRAME_BOUNDARY = 0x0,
> + CMD_ENABLE_FRAME_BOUNDARY = 0x1,
> + CMD_DISABLE_IMMEDIATELY = 0x2,
> + CMD_ALL_DISABLE_IMMEDIATELY = 0x,
> + CMD_ALL_NO_CHANGE = 0x,
> +};
> +
> +static const u32 ispif_formats[] = {
> + MEDIA_BUS_FMT_
Re: [Patch v5 12/12] Documention: v4l: Documentation for HEVC CIDs
On 19/06/17 07:10, Smitha T Murthy wrote:
> Added V4l2 controls for HEVC encoder
>
> Signed-off-by: Smitha T Murthy
> ---
> Documentation/media/uapi/v4l/extended-controls.rst | 364
> +
> 1 file changed, 364 insertions(+)
>
> diff --git a/Documentation/media/uapi/v4l/extended-controls.rst
> b/Documentation/media/uapi/v4l/extended-controls.rst
> index abb1057..7767c70 100644
> --- a/Documentation/media/uapi/v4l/extended-controls.rst
> +++ b/Documentation/media/uapi/v4l/extended-controls.rst
> @@ -1960,6 +1960,370 @@ enum v4l2_vp8_golden_frame_sel -
> 1, 2 and 3 corresponding to encoder profiles 0, 1, 2 and 3.
>
>
> +High Efficiency Video Coding (HEVC/H.265) Control Reference
> +---
> +
> +The HEVC/H.265 controls include controls for encoding parameters of
> HEVC/H.265
> +video codec.
> +
> +
> +.. _hevc-control-id:
> +
> +HEVC/H.265 Control IDs
> +^^
> +
> +``V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP (integer)``
> +Minimum quantization parameter for HEVC.
> +
> +``V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP (integer)``
> +Maximum quantization parameter for HEVC.
It's a bit ambiguous. Are these supposed to be read-only parameters?
Normally min-max is already implied in the control range, so this is a
bit odd. Perhaps it is clear for people who know HEVC, but I'm not
quite sure what to make of it.
> +
> +``V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP (integer)``
> +Quantization parameter for an I frame for HEVC.
> +
> +``V4L2_CID_MPEG_VIDEO_HEVC_P_FRAME_QP (integer)``
> +Quantization parameter for a P frame for HEVC.
> +
> +``V4L2_CID_MPEG_VIDEO_HEVC_B_FRAME_QP (integer)``
> +Quantization parameter for a B frame for HEVC.
> +
> +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_QP (boolean)``
> +HIERARCHICAL_QP allows host to specify the quantization parameter values
> +for each temporal layer through HIERARCHICAL_QP_LAYER. This is valid only
> +if HIERARCHICAL_CODING_LAYER is greater than 1. Setting the control value
> +to 1 enables setting of the QP values for the layers.
> +
> +.. _v4l2-hevc-hier-coding-type:
> +
> +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_TYPE``
> +(enum)
> +
> +enum v4l2_mpeg_video_hevc_hier_coding_type -
> +Selects the hierarchical coding type for encoding. Possible values are:
> +
> +.. raw:: latex
> +
> +\begin{adjustbox}{width=\columnwidth}
> +
> +.. tabularcolumns:: |p{11.0cm}|p{10.0cm}|
> +
> +.. flat-table::
> +:header-rows: 0
> +:stub-columns: 0
> +
> +* - ``V4L2_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_B``
> + - Use the B frame for hierarchical coding.
> +* - ``V4L2_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_P``
> + - Use the P frame for hierarchical coding.
> +
> +.. raw:: latex
> +
> +\end{adjustbox}
> +
> +
> +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_LAYER (integer)``
> +Selects the hierarchical coding layer. In normal encoding
> +(non-hierarchial coding), it should be zero. Possible values are 0 ~ 6.
> +0 indicates HIERARCHICAL CODING LAYER 0, 1 indicates HIERARCHICAL CODING
> +LAYER 1 and so on.
> +
> +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_LAYER_QP (integer)``
> +Indicates the hierarchical coding layer quantization parameter.
> +For HEVC it can have a value of 0-51. Hence in the control value passed
> +the LSB 16 bits will indicate the quantization parameter. The MSB 16 bit
> +will pass the layer(0-6) it is meant for.
This is ugly. Why not make this an array control? This really is an array of
7 values, right? An alternative is to split this in 7 controls just as you did
with V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L?_BR.
The way it is now doesn't work either since
G_CTRL(V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_LAYER_QP)
would just return the QP for whatever was the last layer you set it for and you
can't
query it for another layer.
> +
> +.. _v4l2-hevc-profile:
> +
> +``V4L2_CID_MPEG_VIDEO_HEVC_PROFILE``
> +(enum)
> +
> +enum v4l2_mpeg_video_hevc_profile -
> +Select the desired profile for HEVC encoder.
> +
> +.. raw:: latex
> +
> +\begin{adjustbox}{width=\columnwidth}
> +
> +.. tabularcolumns:: |p{11.0cm}|p{10.0cm}|
> +
> +.. flat-table::
> +:header-rows: 0
> +:stub-columns: 0
> +
> +* - ``V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN``
> + - Main profile.
> +* - ``V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN_STILL_PICTURE``
> + - Main still picture profile.
> +
> +.. raw:: latex
> +
> +\end{adjustbox}
> +
> +
> +.. _v4l2-hevc-level:
> +
> +``V4L2_CID_MPEG_VIDEO_HEVC_LEVEL``
> +(enum)
> +
> +enum v4l2_mpeg_video_hevc_level -
> +Selects the desired level for HEVC encoder.
> +
> +.. raw:: latex
> +
> +\begin{adjustbox}{width=\columnwidth}
> +
> +.. tabularcolumns:: |p{11.0cm}|p{10.0cm}|
> +
> +.. flat-table::
> +:header-rows: 0
> +:stub-columns: 0
> +
> +* - ``V4L2_MPEG_VIDEO_HEVC_LEVEL_1``
> + - Level 1.0
> +* - ``V4L2_MPEG_VIDEO_HEVC_LEVEL_2``
> + - Level 2
Re: [PATCH v2 3/3] drm: rcar-du: Repair vblank for DRM page flips using the VSP
Em Wed, 12 Jul 2017 01:29:42 +0300
Laurent Pinchart escreveu:
> From: Kieran Bingham
>
> The driver recently switched from handling page flip completion in the
> DU vertical blanking handler to the VSP frame end handler to fix a race
> condition. This unfortunately resulted in incorrect timestamps in the
> vertical blanking events sent to userspace as vertical blanking is now
> handled after sending the event.
>
> To fix this we must reverse the order of the two operations. The easiest
> way is to handle vertical blanking in the VSP frame end handler before
> sending the event. The VSP frame end interrupt occurs approximately 50µs
> earlier than the DU frame end interrupt, but this should not cause any
> undue harm.
>
> As we need to handle vertical blanking even when page flip completion is
> delayed, the VSP driver now needs to call the frame end completion
> callback unconditionally, with a new argument to report whether page
> flip has completed.
>
> With this new scheme the DU vertical blanking interrupt isn't needed
> anymore, so we can stop enabling it.
>
> Fixes: d503a43ac06a ("drm: rcar-du: Register a completion callback with VSP1")
> Signed-off-by: Kieran Bingham
> Signed-off-by: Laurent Pinchart
Acked-by: Mauro Carvalho Chehab
Thanks,
Mauro
Re: [PATCH v3 08/23] media: camss: Add CSID files
Hi Todor,
A few comments below. Looks pretty good!
On Mon, Jul 17, 2017 at 01:33:34PM +0300, Todor Tomov wrote:
> These files control the CSID modules which handle the protocol and application
> layer of the CSI2 receivers.
>
> Signed-off-by: Todor Tomov
> ---
> .../media/platform/qcom/camss-8x16/camss-csid.c| 1073
>
> .../media/platform/qcom/camss-8x16/camss-csid.h| 82 ++
> 2 files changed, 1155 insertions(+)
> create mode 100644 drivers/media/platform/qcom/camss-8x16/camss-csid.c
> create mode 100644 drivers/media/platform/qcom/camss-8x16/camss-csid.h
>
> diff --git a/drivers/media/platform/qcom/camss-8x16/camss-csid.c
> b/drivers/media/platform/qcom/camss-8x16/camss-csid.c
> new file mode 100644
> index 000..2bf3415
> --- /dev/null
> +++ b/drivers/media/platform/qcom/camss-8x16/camss-csid.c
> @@ -0,0 +1,1073 @@
> +/*
> + * camss-csid.c
> + *
> + * Qualcomm MSM Camera Subsystem - CSID Module
> + *
> + * Copyright (c) 2011-2015, The Linux Foundation. All rights reserved.
> + * Copyright (C) 2015-2017 Linaro Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * 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.
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "camss-csid.h"
> +#include "camss.h"
> +
> +#define MSM_CSID_NAME "msm_csid"
> +
> +#define CAMSS_CSID_HW_VERSION0x0
> +#define CAMSS_CSID_CORE_CTRL_0 0x004
> +#define CAMSS_CSID_CORE_CTRL_1 0x008
> +#define CAMSS_CSID_RST_CMD 0x00c
> +#define CAMSS_CSID_CID_LUT_VC_n(n) (0x010 + 0x4 * (n))
> +#define CAMSS_CSID_CID_n_CFG(n) (0x020 + 0x4 * (n))
> +#define CAMSS_CSID_IRQ_CLEAR_CMD 0x060
> +#define CAMSS_CSID_IRQ_MASK 0x064
> +#define CAMSS_CSID_IRQ_STATUS0x068
> +#define CAMSS_CSID_TG_CTRL 0x0a0
> +#define CAMSS_CSID_TG_VC_CFG 0x0a4
> +#define CAMSS_CSID_TG_VC_CFG_H_BLANKING 0x3ff
> +#define CAMSS_CSID_TG_VC_CFG_V_BLANKING 0x7f
> +#define CAMSS_CSID_TG_DT_n_CGG_0(n) (0x0ac + 0xc * (n))
> +#define CAMSS_CSID_TG_DT_n_CGG_1(n) (0x0b0 + 0xc * (n))
> +#define CAMSS_CSID_TG_DT_n_CGG_2(n) (0x0b4 + 0xc * (n))
> +
> +#define DATA_TYPE_EMBEDDED_DATA_8BIT 0x12
> +#define DATA_TYPE_YUV422_8BIT0x1e
> +#define DATA_TYPE_RAW_6BIT 0x28
> +#define DATA_TYPE_RAW_8BIT 0x2a
> +#define DATA_TYPE_RAW_10BIT 0x2b
> +#define DATA_TYPE_RAW_12BIT 0x2c
> +
> +#define DECODE_FORMAT_UNCOMPRESSED_6_BIT 0x0
> +#define DECODE_FORMAT_UNCOMPRESSED_8_BIT 0x1
> +#define DECODE_FORMAT_UNCOMPRESSED_10_BIT0x2
> +#define DECODE_FORMAT_UNCOMPRESSED_12_BIT0x3
> +
> +#define CSID_RESET_TIMEOUT_MS 500
> +
> +static const struct {
> + u32 code;
> + u32 uncompressed;
> + u8 data_type;
> + u8 decode_format;
> + u8 uncompr_bpp;
> +} csid_input_fmts[] = {
> + {
> + MEDIA_BUS_FMT_UYVY8_2X8,
> + MEDIA_BUS_FMT_UYVY8_2X8,
> + DATA_TYPE_YUV422_8BIT,
> + DECODE_FORMAT_UNCOMPRESSED_8_BIT,
> + 16
> + },
> + {
> + MEDIA_BUS_FMT_VYUY8_2X8,
> + MEDIA_BUS_FMT_VYUY8_2X8,
> + DATA_TYPE_YUV422_8BIT,
> + DECODE_FORMAT_UNCOMPRESSED_8_BIT,
> + 16
> + },
> + {
> + MEDIA_BUS_FMT_YUYV8_2X8,
> + MEDIA_BUS_FMT_YUYV8_2X8,
> + DATA_TYPE_YUV422_8BIT,
> + DECODE_FORMAT_UNCOMPRESSED_8_BIT,
> + 16
> + },
> + {
> + MEDIA_BUS_FMT_YVYU8_2X8,
> + MEDIA_BUS_FMT_YVYU8_2X8,
> + DATA_TYPE_YUV422_8BIT,
> + DECODE_FORMAT_UNCOMPRESSED_8_BIT,
> + 16
> + },
> + {
> + MEDIA_BUS_FMT_SBGGR8_1X8,
> + MEDIA_BUS_FMT_SBGGR8_1X8,
> + DATA_TYPE_RAW_8BIT,
> + DECODE_FORMAT_UNCOMPRESSED_8_BIT,
> + 8
> + },
> + {
> + MEDIA_BUS_FMT_SGBRG8_1X8,
> + MEDIA_BUS_FMT_SGBRG8_1X8,
> + DATA_TYPE_RAW_8BIT,
> + DECODE_FORMAT_UNCOMPRESSED_8_BIT,
> + 8
> + },
> + {
> + MEDIA_BUS_FMT_SGRBG8_1X8,
> + MEDIA_BUS_FMT_SGRBG8_1X8,
> + DATA_TYPE_RAW_8BIT,
> + DECODE_FORMAT_UNCOMPRESSED_8_BIT,
> + 8
> + },
> + {
> + MEDIA_BUS_FMT_SRGGB8_1X8,
> + MEDIA_BUS_FMT_SRGGB8_1X8,
> + DATA_TYPE_RAW_8BIT,
> + DECOD
Re: [PATCH] media: Convert to using %pOF instead of full_name
On Thu, Jul 20, 2017 at 6:15 AM, Mauro Carvalho Chehab
wrote:
> Em Wed, 19 Jul 2017 11:02:01 -0500
> Rob Herring escreveu:
>
>> On Wed, Jul 19, 2017 at 4:41 AM, Sylwester Nawrocki
>> wrote:
>> > On 07/18/2017 11:43 PM, Rob Herring wrote:
>> >> Now that we have a custom printf format specifier, convert users of
>> >> full_name to use %pOF instead. This is preparation to remove storing
>> >> of the full path string for each node.
>> >>
>> >> Signed-off-by: Rob Herring
>> >
>> >> ---
>> >> drivers/media/i2c/s5c73m3/s5c73m3-core.c | 3 +-
>> >> drivers/media/i2c/s5k5baf.c| 7 ++--
>> >> drivers/media/platform/am437x/am437x-vpfe.c| 4 +-
>> >> drivers/media/platform/atmel/atmel-isc.c | 4 +-
>> >> drivers/media/platform/davinci/vpif_capture.c | 16
>> >> drivers/media/platform/exynos4-is/fimc-is.c| 8 ++--
>> >> drivers/media/platform/exynos4-is/fimc-lite.c | 3 +-
>> >> drivers/media/platform/exynos4-is/media-dev.c | 8 ++--
>> >> drivers/media/platform/exynos4-is/mipi-csis.c | 4 +-
>> >> drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 6 +--
>> >> drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 8 ++--
>> >> drivers/media/platform/omap3isp/isp.c | 8 ++--
>> >> drivers/media/platform/pxa_camera.c| 2 +-
>> >> drivers/media/platform/rcar-vin/rcar-core.c| 4 +-
>> >> drivers/media/platform/soc_camera/soc_camera.c | 6 +--
>> >> drivers/media/platform/xilinx/xilinx-vipp.c| 52
>> >> +-
>> >> drivers/media/v4l2-core/v4l2-async.c | 4 +-
>> >> drivers/media/v4l2-core/v4l2-clk.c | 3 +-
>> >> include/media/v4l2-clk.h | 4 +-
>> >> 19 files changed, 71 insertions(+), 83 deletions(-)
>> >
>> >> diff --git a/drivers/media/platform/xilinx/xilinx-vipp.c
>> >> b/drivers/media/platform/xilinx/xilinx-vipp.c
>> >> index ac4704388920..9233ad0b1b6b 100644
>> >> --- a/drivers/media/platform/xilinx/xilinx-vipp.c
>> >> +++ b/drivers/media/platform/xilinx/xilinx-vipp.c
>> >
>> >> @@ -144,9 +144,8 @@ static int xvip_graph_build_one(struct
>> >> xvip_composite_device *xdev,
>> >> remote = ent->entity;
>> >>
>> >> if (link.remote_port >= remote->num_pads) {
>> >> - dev_err(xdev->dev, "invalid port number %u on %s\n",
>> >> - link.remote_port,
>> >> - to_of_node(link.remote_node)->full_name);
>> >> + dev_err(xdev->dev, "invalid port number %u on
>> >> %pOF\n",
>> >> + link.remote_port, link.remote_node);
>> >
>> > Shouldn't there be to_of_node(link.remote_node) instead of
>> > link.remote_node ?
>>
>> Humm, yes. I thought I fixed that.
>
> After such fix, I'm OK with this patch.
I'll send a new version.
I think I'll send a revert of the referenced commit. It won't apply
cleanly, but at least it will capture the change in behavior and why
it was wrong.
> Are you planning to apply it on your tree, or via the media one?
>
> I guess it is probably better to apply via media, in order to avoid
> conflicts with other changes.
Yes, you can take it.
Rob
Re: [PATCH v2 11/14] v4l: vsp1: Add support for header display lists in continuous mode
Em Mon, 26 Jun 2017 21:12:23 +0300 Laurent Pinchart escreveu: > The VSP supports both header and headerless display lists. The latter is > easier to use when the VSP feeds data directly to the DU in continuous > mode, and the driver thus uses headerless display lists for DU operation > and header display lists otherwise. > > Headerless display lists are only available on WPF.0. This has never > been an issue so far, as only WPF.0 is connected to the DU. However, on > H3 ES2.0, the VSP-DL instance has both WPF.0 and WPF.1 connected to the > DU. We thus can't use headerless display lists unconditionally for DU > operation. > > Implement support for continuous mode with header display lists, and use > it for DU operation on WPF outputs that don't support headerless mode. > > Signed-off-by: Laurent Pinchart Acked-by: Mauro Carvalho Chehab Thanks, Mauro
Re: [Linaro-mm-sig] [PATCH] dma-fence: Don't BUG_ON when not absolutely needed
Am Donnerstag, den 20.07.2017, 14:51 +0200 schrieb Daniel Vetter:
> It makes debugging a massive pain.
It is also considered very bad style to BUG the kernel on anything other
than filesystem eating catastrophic failures.
Reviewed-by: Lucas Stach
> Signed-off-by: Daniel Vetter
> Cc: Sumit Semwal
> Cc: Gustavo Padovan
> Cc: linux-media@vger.kernel.org
> Cc: linaro-mm-...@lists.linaro.org
> ---
> drivers/dma-buf/dma-fence.c | 4 ++--
> include/linux/dma-fence.h | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
> index 56e0a0e1b600..9a302799040e 100644
> --- a/drivers/dma-buf/dma-fence.c
> +++ b/drivers/dma-buf/dma-fence.c
> @@ -48,7 +48,7 @@ static atomic64_t dma_fence_context_counter =
> ATOMIC64_INIT(0);
> */
> u64 dma_fence_context_alloc(unsigned num)
> {
> - BUG_ON(!num);
> + WARN_ON(!num);
> return atomic64_add_return(num, &dma_fence_context_counter) - num;
> }
> EXPORT_SYMBOL(dma_fence_context_alloc);
> @@ -172,7 +172,7 @@ void dma_fence_release(struct kref *kref)
>
> trace_dma_fence_destroy(fence);
>
> - BUG_ON(!list_empty(&fence->cb_list));
> + WARN_ON(!list_empty(&fence->cb_list));
>
> if (fence->ops->release)
> fence->ops->release(fence);
> diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
> index 9342cf0dada4..171895072435 100644
> --- a/include/linux/dma-fence.h
> +++ b/include/linux/dma-fence.h
> @@ -431,8 +431,8 @@ int dma_fence_get_status(struct dma_fence *fence);
> static inline void dma_fence_set_error(struct dma_fence *fence,
> int error)
> {
> - BUG_ON(test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags));
> - BUG_ON(error >= 0 || error < -MAX_ERRNO);
> + WARN_ON(test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags));
> + WARN_ON(error >= 0 || error < -MAX_ERRNO);
>
> fence->error = error;
> }
Re: [PATCH v2 10/14] v4l: vsp1: Add support for multiple DRM pipelines
Em Mon, 26 Jun 2017 21:12:22 +0300 Laurent Pinchart escreveu: > The R-Car H3 ES2.0 VSP-DL instance has two LIF entities and can drive > two display pipelines at the same time. Refactor the VSP DRM code to > support that by introducing a vsp_drm_pipeline object that models one > display pipeline. > > Signed-off-by: Laurent Pinchart Acked-by: Mauro Carvalho Chehab Thanks, Mauro
Re: [PATCH v2 09/14] v4l: vsp1: Add support for multiple LIF instances
Em Thu, 13 Jul 2017 18:57:40 +0100 Kieran Bingham escreveu: > Hi Laurent, > > On 26/06/17 19:12, Laurent Pinchart wrote: > > The VSP2-DL instance (present in the H3 ES2.0 and M3-N SoCs) has two LIF > > instances. Adapt the driver infrastructure to support multiple LIFs. > > Support for multiple display pipelines will be added separately. > > > > The change to the entity routing table removes the ability to connect > > the LIF output to the HGO or HGT histogram generators. This feature is > > only available on Gen2 hardware, isn't supported by the rest of the > > driver, and has no known use case, so this isn't an issue. > > > > Signed-off-by: Laurent Pinchart > > > This looks good. > > Reviewed-by: Kieran Bingham Acked-by: Mauro Carvalho Chehab Thanks, Mauro
Re: [PATCH v2.1 08/14] v4l: vsp1: Add support for new VSP2-BS, VSP2-DL and VSP2-D instances
Em Fri, 14 Jul 2017 03:35:57 +0300 Laurent Pinchart escreveu: > New Gen3 SoCs come with two new VSP2 variants names VSP2-BS and VSP2-DL, > as well as a new VSP2-D variant on V3M and V3H SoCs. Add new entries for > them in the VSP device info table. > > Signed-off-by: Laurent Pinchart > Reviewed-by: Kieran Bingham Acked-by: Mauro Carvalho Chehab Thanks, Mauro
Re: [PATCH v2 07/14] v4l: vsp1: Add support for the BRS entity
Em Thu, 13 Jul 2017 14:38:40 +0100 Kieran Bingham escreveu: > On 26/06/17 19:12, Laurent Pinchart wrote: > > The Blend/ROP Sub Unit (BRS) is a stripped-down version of the BRU found > > in several VSP2 instances. Compared to a regular BRU, it supports two > > inputs only, and thus has no ROP unit. > > > > Add support for the BRS by modeling it as a new entity type, but reuse > > s/modeling/modelling/ > > > > the vsp1_bru object underneath. Chaining the BRU and BRS entities seems > > to be supported by the hardware but isn't implemented yet as it isn't > > the primary use case for the BRS. > > > > Signed-off-by: Laurent Pinchart > > > > Reviewed-by: Kieran Bingham Acked-by: Mauro Carvalho Chehab Thanks, Mauro
Re: [PATCH v2 06/14] v4l: vsp1: Add pipe index argument to the VSP-DU API
Em Fri, 14 Jul 2017 02:04:06 +0300 Laurent Pinchart escreveu: > On Thursday 13 Jul 2017 14:16:03 Kieran Bingham wrote: > > On 26/06/17 19:12, Laurent Pinchart wrote: > > > In the H3 ES2.0 SoC the VSP2-DL instance has two connections to DU > > > channels that need to be configured independently. Extend the VSP-DU API > > > with a pipeline index to identify which pipeline the caller wants to > > > operate on. > > > > > > Signed-off-by: Laurent Pinchart > > > > > > > A bit of comment merge between this and the next patch but it's minor and > > not worth the effort to change that ... so I'll happily ignore it if you do > > :) > > > > Reviewed-by: Kieran Bingham > > > > > --- > > > > > > drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 12 ++-- > > > drivers/media/platform/vsp1/vsp1_drm.c | 32 +++ > > > include/media/vsp1.h | 10 ++ > > > 3 files changed, 34 insertions(+), 20 deletions(-) > > [snip] > > > > diff --git a/drivers/media/platform/vsp1/vsp1_drm.c > > > b/drivers/media/platform/vsp1/vsp1_drm.c index c72d021ff820..daaafe7885fa > > > 100644 > > > --- a/drivers/media/platform/vsp1/vsp1_drm.c > > > +++ b/drivers/media/platform/vsp1/vsp1_drm.c > > > @@ -58,21 +58,26 @@ EXPORT_SYMBOL_GPL(vsp1_du_init); > > > /** > > > * vsp1_du_setup_lif - Setup the output part of the VSP pipeline > > > * @dev: the VSP device > > > + * @pipe_index: the DRM pipeline index > > > * @cfg: the LIF configuration > > > * > > > * Configure the output part of VSP DRM pipeline for the given frame > > > @cfg.width > > > - * and @cfg.height. This sets up formats on the BRU source pad, the WPF0 > > > sink > > > - * and source pads, and the LIF sink pad. > > > + * and @cfg.height. This sets up formats on the blend unit (BRU or BRS) > > > source > > > + * pad, the WPF sink and source pads, and the LIF sink pad. > > > * > > > - * As the media bus code on the BRU source pad is conditioned by the > > > - * configuration of the BRU sink 0 pad, we also set up the formats on all > > > BRU > > > + * The @pipe_index argument selects which DRM pipeline to setup. The > > > number of > > > + * available pipelines depend on the VSP instance. > > > + * > > > + * As the media bus code on the blend unit source pad is conditioned by > > > the > > > + * configuration of its sink 0 pad, we also set up the formats on all > > > blend unit > > > * sinks, even if the configuration will be overwritten later by > > > - * vsp1_du_setup_rpf(). This ensures that the BRU configuration is set to > > > a well > > > - * defined state. > > > + * vsp1_du_setup_rpf(). This ensures that the blend unit configuration is > > > set to > > > + * a well defined state. > > > > I presume those comment updates for the BRU/ blend-unit configuration are > > actually for the next patch - but I don't think it matters here - and isn't > > worth the effort to move the hunks. > > Too late, I've fixed it already :-) Thanks for pointing it out. Acked-by: Mauro Carvalho Chehab Thanks, Mauro
Re: [PATCH v2 05/14] v4l: vsp1: Don't create links for DRM pipeline
Em Thu, 13 Jul 2017 14:06:04 +0100 Kieran Bingham escreveu: > On 26/06/17 19:12, Laurent Pinchart wrote: > > When the VSP1 is used in a DRM pipeline the driver doesn't register the > > media device. Links between entities are not exposed to userspace, but > > are still used internally for the sole purpose of setting up internal > > source to sink pointers through the link setup handler. > > > > Instead of going through this complex procedure, remove link creation > > and set the sink pointers directly. > > > > Signed-off-by: Laurent Pinchart > > > > A whole function removed ... always love code removal... > > Reviewed-by: Kieran Bingham Acked-by: Mauro Carvalho Chehab Thanks, Mauro
Re: [PATCH v2 04/14] v4l: vsp1: Store source and sink pointers as vsp1_entity
Em Thu, 13 Jul 2017 14:00:31 +0100 Kieran Bingham escreveu: > Hi Laurent, > > This looks like a good simplification/removal of obfuscation to me! > > On 26/06/17 19:12, Laurent Pinchart wrote: > > The internal VSP entity source and sink pointers are stored as > > media_entity pointers, which are then cast to a vsp1_entity. As all > > sources and sinks are vsp1_entity instances, we can store the > > vsp1_entity pointers directly. > > > > Signed-off-by: Laurent Pinchart > > > > Reviewed-by: Kieran Bingham Acked-by: Mauro Carvalho Chehab Thanks, Mauro
Re: [PATCH v2 03/14] v4l: vsp1: Don't set WPF sink pointer
Em Thu, 13 Jul 2017 13:50:20 +0100 Kieran Bingham escreveu: > On 26/06/17 19:12, Laurent Pinchart wrote: > > The sink pointer is used to configure routing inside the VSP, and as > > such must point to the next VSP entity in the pipeline. The WPF being a > > pipeline terminal sink, its output route can't be configured. The > > routing configuration code already handles this correctly without > > referring to the sink pointer, which thus doesn't need to be set. > > > > Signed-off-by: Laurent Pinchart > > > > Reviewed-by: Kieran Bingham Acked-by: Mauro Carvalho Chehab Thanks, Mauro
Re: [PATCH v2 02/14] v4l: vsp1: Don't recycle active list at display start
Em Thu, 13 Jul 2017 18:02:20 +0100 Kieran Bingham escreveu: > Hi Laurent, > > On 26/06/17 19:12, Laurent Pinchart wrote: > > When the display start interrupt occurs, we know that the hardware has > > finished loading the active display list. The driver then proceeds to > > recycle the list, assuming it won't be needed anymore. > > > > This assumption holds true for headerless display lists, as the VSP > > doesn't reload the list for the next frame if it hasn't changed. > > However, this isn't true anymore for header display lists, as they are > > loaded at every frame start regardless of whether they have been > > updated. > > > > To prepare for header display lists usage in display pipelines, we need > > to postpone recycling the list until it gets replaced by a new one > > through a page flip. The driver already does so in the frame end > > interrupt handler, so all we need is to skip list recycling in the > > display start interrupt handler. > > > > While the active list can be recycled at display start for headerless > > display lists, there's no real harm in postponing that to the frame end > > interrupt handler in all cases. This simplifies interrupt handling as we > > don't need to process the display start interrupt anymore. > > > > Signed-off-by: Laurent Pinchart > > > > Ok, I had skipped this one as I was concerned about its effects in relation to > 11/14 but I see how that's working now. > > Reviewed-by: Kieran Bingham Acked-by: Mauro Carvalho Chehab Thanks, Mauro
Re: [PATCH v2 01/14] v4l: vsp1: Fill display list headers without holding dlm spinlock
Em Thu, 13 Jul 2017 13:48:40 +0100 Kieran Bingham escreveu: > Hi Laurent, > > Starts easy ... (I haven't gone through these in numerical order of course :D) > > On 26/06/17 19:12, Laurent Pinchart wrote: > > The display list headers are filled using information from the display > > list only. Lower the display list manager spinlock contention by filling > > the headers without holding the lock. > > > > Signed-off-by: Laurent Pinchart > > > > Reviewed-by: Kieran Bingham Acked-by: Mauro Carvalho Chehab Thanks, Mauro
Re: [Patch v5 11/12] [media] s5p-mfc: Add support for HEVC encoder
On 19/06/17 07:10, 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 | 53 ++-
> drivers/media/platform/s5p-mfc/s5p_mfc_enc.c| 521
>
> drivers/media/platform/s5p-mfc/s5p_mfc_opr.h| 8 +
> drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 168
> drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h | 8 +
> 8 files changed, 788 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 6754477..7065b9d 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_V100xF570
> #define S5P_FIMV_D_STATIC_BUFFER_SIZE_V100xF574
> +#define S5P_FIMV_E_NUM_T_LAYER_V10 0xFBAC
> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER0_V100xFBB0
> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER1_V100xFBB4
> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER2_V100xFBB8
> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER3_V100xFBBC
> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER4_V100xFBC0
> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER5_V100xFBC4
> +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER6_V100xFBC8
> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER0_V10 0xFD18
> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER1_V10 0xFD1C
> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER2_V10 0xFD20
> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER3_V10 0xFD24
> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER4_V10 0xFD28
> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER5_V10 0xFD2C
> +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER6_V10 0xFD30
> +#define S5P_FIMV_E_HEVC_OPTIONS_V10 0xFDD4
> +#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_V10 0xFDE0
> +#define S5P_FIMV_E_HEVC_LF_TC_OFFSET_DIV2_V100xFDE4
> +#define S5P_FIMV_E_HEVC_NAL_CONTROL_V10 0xFDE8
>
> /* MFCv10 Context buffer sizes */
> #define MFC_CTX_BUF_SIZE_V10 (30 * SZ_1K)
> #define MFC_H264_DEC_CTX_BUF_SIZE_V10(2 * SZ_1M)
> #define MFC_OTHER_DEC_CTX_BUF_SIZE_V10 (20 * SZ_1K)
> #define MFC_H264_ENC_CTX_BUF_SIZE_V10(100 * SZ_1K)
> -#define MFC_OTHER_ENC_CTX_BUF_SIZE_V10 (15 * SZ_1K)
> +#define MFC_HEVC_ENC_CTX_BUF_SIZE_V10(30 * SZ_1K)
> +#define MFC_OTHER_ENC_CTX_BUF_SIZE_V10 (15 * SZ_1K)
>
> /* MFCv10 variant defines */
> #define MAX_FW_SIZE_V10 (SZ_1M)
> @@ -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 efc36b0..742c2b7 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> @@ -1621,6 +1621,7 @@ static struct s5p_mfc_buf_size_v6 mfc_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,
> + .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;
> default:
> codec_type = S5P_FIMV_CODEC_NONE_V6;
> }
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> index b49f220..c1ae4f4 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> @@ -61,7 +61,7 @@
> #define MFC_ENC_CAP_PLANE_
Re: [PATCH][media-next] media: v4l: make local function v4l2_fwnode_endpoint_parse_csi1_bus static
On Thu, Jul 20, 2017 at 11:30:14AM +0100, Colin King wrote: > From: Colin Ian King > > The function v4l2_fwnode_endpoint_parse_csi1_bus does not need to be > in global scope, so make it static. Also reformat the function arguments > as adding the static keyword made one of the source lines more than 80 > chars wide and checkpatch does not like that. > > Cleans up sparse warning: > "symbol 'v4l2_fwnode_endpoint_parse_csi1_bus' was not declared. Should it > be static?" > > Signed-off-by: Colin Ian King Thanks! Applied, with removal of an extra neline and a tab in the arguments. -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
Re: [Patch v5 10/12] [media] v4l2: Add v4l2 control IDs for HEVC encoder
On 19/06/17 07:10, Smitha T Murthy wrote:
> Add v4l2 controls for HEVC encoder
>
> Signed-off-by: Smitha T Murthy
> Reviewed-by: Andrzej Hajda
> ---
> drivers/media/v4l2-core/v4l2-ctrls.c | 103
> +++
> include/uapi/linux/v4l2-controls.h | 84
> 2 files changed, 187 insertions(+)
>
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
> b/drivers/media/v4l2-core/v4l2-ctrls.c
> index ec42872..6a7e732 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -479,6 +479,51 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
> NULL,
> };
>
> + static const char * const hevc_profile[] = {
> + "Main",
> + "Main Still Picture",
> + NULL,
> + };
> + static const char * const hevc_level[] = {
> + "1",
> + "2",
> + "2.1",
> + "3",
> + "3.1",
> + "4",
> + "4.1",
> + "5",
> + "5.1",
> + "5.2",
> + "6",
> + "6.1",
> + "6.2",
> + NULL,
> + };
> + static const char * const hevc_hierarchial_coding_type[] = {
> + "B",
> + "P",
> + NULL,
> + };
> + static const char * const hevc_refresh_type[] = {
> + "None",
> + "CRA",
> + "IDR",
> + NULL,
> + };
> + static const char * const hevc_size_of_length_field[] = {
> + "0",
> + "1",
> + "2",
> + "4",
> + NULL,
> + };
> + static const char * const hevc_tier_flag[] = {
> + "Main",
> + "High",
> + NULL,
> + };
> +
>
> switch (id) {
> case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
> @@ -574,6 +619,18 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
> return dv_it_content_type;
> case V4L2_CID_DETECT_MD_MODE:
> return detect_md_mode;
> + 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_HIER_CODING_TYPE:
> + return hevc_hierarchial_coding_type;
> + case V4L2_CID_MPEG_VIDEO_HEVC_REFRESH_TYPE:
> + return hevc_refresh_type;
> + case V4L2_CID_MPEG_VIDEO_HEVC_SIZE_OF_LENGTH_FIELD:
> + return hevc_size_of_length_field;
> + case V4L2_CID_MPEG_VIDEO_HEVC_TIER_FLAG:
> + return hevc_tier_flag;
>
> default:
> return NULL;
> @@ -775,6 +832,46 @@ const char *v4l2_ctrl_get_name(u32 id)
> 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_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";
"HEVC Tier Flag"
> + case V4L2_CID_MPEG_VIDEO_HEVC_FRAME_RATE_RESOLUTION:return "HEVC
> Frame Rate Resolution";
> + case V4L2_CID_MPEG_VIDEO_HEVC_MAX_PARTITION_DEPTH: return "HEVC
> Maximum Coding Unit Depth";
> + case V4L2_CID_MPEG_VIDEO_HEVC_REFRESH_TYPE: return "HEVC
> Refresh Type";
> + case V4L2_CID_MPEG_VIDEO_HEVC_CONST_INTRA_PRED: return "HEVC
> Constant Intra Prediction";
> + case V4L2_CID_MPEG_VIDEO_HEVC_LOSSLESS_CU: return "HEVC
> Lossless Encoding";
> + case V4L2_CID_MPEG_VIDEO_HEVC_WAVEFRONT:return "HEVC
> Wavefront";
> + case V4L2_CID_MPEG_VIDEO_HEVC_LF: return "HEVC
> Loop Filter";
> + case V4L2_CID_MPEG_VIDEO_HEVC_LF_SLICE_BOUNDARY:return "HEVC LF
> Across Slice Boundary";
> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_QP: return "HEVC QP
> Values";
> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_TYPE: return "HEVC
> Hierarchical Coding Type";
> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_LAYER:return "HEVC
> Hierarchical Coding Layer";
> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_LAYER_QP: return "HEVC
> Hierarchical Layer QP";
> + case
Re: [Patch v5 05/12] [media] videodev2.h: Add v4l2 definition for HEVC
On 19/06/17 07:10, Smitha T Murthy wrote:
> Add V4L2 definition for HEVC compressed format
>
> Signed-off-by: Smitha T Murthy
> Reviewed-by: Andrzej Hajda
> ---
> include/uapi/linux/videodev2.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 2b8feb8..488de3d 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -629,6 +629,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 */
Change the comment to: /* HEVC aka H.265 */
After that you can add my:
Acked-by: Hans Verkuil
Regards,
Hans
>
> /* Vendor-specific formats */
> #define V4L2_PIX_FMT_CPIA1v4l2_fourcc('C', 'P', 'I', 'A') /* cpia1 YUV */
>
Re: [Patch v5 06/12] [media] v4l2-ioctl: add HEVC format description
On 19/06/17 07:10, Smitha T Murthy wrote: > HEVC is a video coding format > > Signed-off-by: Smitha T Murthy > --- > drivers/media/v4l2-core/v4l2-ioctl.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c > b/drivers/media/v4l2-core/v4l2-ioctl.c > index e5a2187..4f6f8d9 100644 > --- a/drivers/media/v4l2-core/v4l2-ioctl.c > +++ b/drivers/media/v4l2-core/v4l2-ioctl.c > @@ -1257,6 +1257,7 @@ static void v4l_fill_fmtdesc(struct v4l2_fmtdesc *fmt) > case V4L2_PIX_FMT_VC1_ANNEX_L: descr = "VC-1 (SMPTE 412M Annex > L)"; break; > case V4L2_PIX_FMT_VP8: descr = "VP8"; break; > case V4L2_PIX_FMT_VP9: descr = "VP9"; break; > + case V4L2_PIX_FMT_HEVC: descr = "HEVC"; break; Add a little comment at the end of the line: /* aka H.265 */ After that you can add my: Acked-by: Hans Verkuil Regards, Hans > case V4L2_PIX_FMT_CPIA1:descr = "GSPCA CPiA YUV"; break; > case V4L2_PIX_FMT_WNVA: descr = "WNVA"; break; > case V4L2_PIX_FMT_SN9C10X: descr = "GSPCA SN9C10X"; break; >
[PATCH] dma-fence: Don't BUG_ON when not absolutely needed
It makes debugging a massive pain.
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: Gustavo Padovan
Cc: linux-media@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/dma-buf/dma-fence.c | 4 ++--
include/linux/dma-fence.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 56e0a0e1b600..9a302799040e 100644
--- a/drivers/dma-buf/dma-fence.c
+++ b/drivers/dma-buf/dma-fence.c
@@ -48,7 +48,7 @@ static atomic64_t dma_fence_context_counter =
ATOMIC64_INIT(0);
*/
u64 dma_fence_context_alloc(unsigned num)
{
- BUG_ON(!num);
+ WARN_ON(!num);
return atomic64_add_return(num, &dma_fence_context_counter) - num;
}
EXPORT_SYMBOL(dma_fence_context_alloc);
@@ -172,7 +172,7 @@ void dma_fence_release(struct kref *kref)
trace_dma_fence_destroy(fence);
- BUG_ON(!list_empty(&fence->cb_list));
+ WARN_ON(!list_empty(&fence->cb_list));
if (fence->ops->release)
fence->ops->release(fence);
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index 9342cf0dada4..171895072435 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -431,8 +431,8 @@ int dma_fence_get_status(struct dma_fence *fence);
static inline void dma_fence_set_error(struct dma_fence *fence,
int error)
{
- BUG_ON(test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags));
- BUG_ON(error >= 0 || error < -MAX_ERRNO);
+ WARN_ON(test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags));
+ WARN_ON(error >= 0 || error < -MAX_ERRNO);
fence->error = error;
}
--
2.13.2
Re: [PATCH 4/7] omap3isp: Return -EPROBE_DEFER if the required regulators can't be obtained
Hi! > > > > No idea really. I only have N900 working with linux at the moment. I'm > > > > trying to get N9 and N950 working, but no luck so far. > > > > > > Still no? :-( > > > > > > Do you know if you get the kernel booting? Do you have access to the > > > serial > > > console? I might have seen the e-mail chain but I lost the track. What > > > happens after the flasher has pushed the kernel to RAM and the boot > > > starts? > > > It's wonderful for debugging if something's wrong... > > > > Still no. No serial cable, unfortunately. Flasher seems to run the > > kernel, but I see no evidence new kernel started successfully. I was > > told display is not expected to work, and on USB I see bootloader > > disconnecting and that's it. > > > > If you had a kernel binary that works for you, and does something I > > can observe, that would be welcome :-). > > I put my .config I use for N9 here: > > http://www.retiisi.org.uk/v4l2/tmp/config.n9> > > The root filesystem is over NFS root with usbnet. You should see something > like this in dmesg: > > [35792.056138] usb 2-2: new high-speed USB device number 58 using ehci-pci > [35792.206238] usb 2-2: New USB device found, idVendor=0525, idProduct=a4a1 > [35792.206247] usb 2-2: New USB device strings: Mfr=1, Product=2, > SerialNumber=0 > [35792.206252] usb 2-2: Product: Ethernet Gadget > [35792.206257] usb 2-2: Manufacturer: Linux 4.13.0-rc1-00089-g4c341695f3b6 > with musb-hdrc Could not get it to work, same result as usual: no response on the device, disconnect on USB and then quiet. Could I get actual zImage-dtb from you? What development options are enabled in your case? I was mostly using none -- sudo ../maemo/0x/src/0x -F "" -R 0 . Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH v3 07/23] media: camss: Add CSIPHY files
Hi Todor,
On Mon, Jul 17, 2017 at 01:33:33PM +0300, Todor Tomov wrote:
> These files control the CSIPHY modules which are responsible for the physical
> layer of the CSI2 receivers.
>
> Signed-off-by: Todor Tomov
> ---
> .../media/platform/qcom/camss-8x16/camss-csiphy.c | 816
> +
> .../media/platform/qcom/camss-8x16/camss-csiphy.h | 77 ++
> 2 files changed, 893 insertions(+)
> create mode 100644 drivers/media/platform/qcom/camss-8x16/camss-csiphy.c
> create mode 100644 drivers/media/platform/qcom/camss-8x16/camss-csiphy.h
>
> diff --git a/drivers/media/platform/qcom/camss-8x16/camss-csiphy.c
> b/drivers/media/platform/qcom/camss-8x16/camss-csiphy.c
> new file mode 100644
> index 000..4e7ddc4
> --- /dev/null
> +++ b/drivers/media/platform/qcom/camss-8x16/camss-csiphy.c
> @@ -0,0 +1,816 @@
> +/*
> + * camss-csiphy.c
> + *
> + * Qualcomm MSM Camera Subsystem - CSIPHY Module
> + *
> + * Copyright (c) 2011-2015, The Linux Foundation. All rights reserved.
> + * Copyright (C) 2016-2017 Linaro Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * 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.
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "camss-csiphy.h"
> +#include "camss.h"
> +
> +#define MSM_CSIPHY_NAME "msm_csiphy"
> +
> +#define CAMSS_CSI_PHY_LNn_CFG2(n)(0x004 + 0x40 * (n))
> +#define CAMSS_CSI_PHY_LNn_CFG3(n)(0x008 + 0x40 * (n))
> +#define CAMSS_CSI_PHY_GLBL_RESET 0x140
> +#define CAMSS_CSI_PHY_GLBL_PWR_CFG 0x144
> +#define CAMSS_CSI_PHY_GLBL_IRQ_CMD 0x164
> +#define CAMSS_CSI_PHY_HW_VERSION 0x188
> +#define CAMSS_CSI_PHY_INTERRUPT_STATUSn(n) (0x18c + 0x4 * (n))
> +#define CAMSS_CSI_PHY_INTERRUPT_MASKn(n) (0x1ac + 0x4 * (n))
> +#define CAMSS_CSI_PHY_INTERRUPT_CLEARn(n)(0x1cc + 0x4 * (n))
> +#define CAMSS_CSI_PHY_GLBL_T_INIT_CFG0 0x1ec
> +#define CAMSS_CSI_PHY_T_WAKEUP_CFG0 0x1f4
> +
> +static const struct {
> + u32 code;
> + u8 bpp;
> +} csiphy_formats[] = {
> + {
> + MEDIA_BUS_FMT_UYVY8_2X8,
> + 8,
I might put these on a single line per array entry. Up to you.
> + },
> + {
> + MEDIA_BUS_FMT_VYUY8_2X8,
> + 8,
> + },
> + {
> + MEDIA_BUS_FMT_YUYV8_2X8,
> + 8,
> + },
> + {
> + MEDIA_BUS_FMT_YVYU8_2X8,
> + 8,
> + },
> + {
> + MEDIA_BUS_FMT_SBGGR8_1X8,
> + 8,
> + },
> + {
> + MEDIA_BUS_FMT_SGBRG8_1X8,
> + 8,
> + },
> + {
> + MEDIA_BUS_FMT_SGRBG8_1X8,
> + 8,
> + },
> + {
> + MEDIA_BUS_FMT_SRGGB8_1X8,
> + 8,
> + },
> + {
> + MEDIA_BUS_FMT_SBGGR10_1X10,
> + 10,
> + },
> + {
> + MEDIA_BUS_FMT_SGBRG10_1X10,
> + 10,
> + },
> + {
> + MEDIA_BUS_FMT_SGRBG10_1X10,
> + 10,
> + },
> + {
> + MEDIA_BUS_FMT_SRGGB10_1X10,
> + 10,
> + },
> + {
> + MEDIA_BUS_FMT_SBGGR12_1X12,
> + 12,
> + },
> + {
> + MEDIA_BUS_FMT_SGBRG12_1X12,
> + 12,
> + },
> + {
> + MEDIA_BUS_FMT_SGRBG12_1X12,
> + 12,
> + },
> + {
> + MEDIA_BUS_FMT_SRGGB12_1X12,
> + 12,
> + }
> +};
> +
> +/*
> + * csiphy_get_bpp - map media bus format to bits per pixel
> + * @code: media bus format code
> + *
> + * Return number of bits per pixel
> + */
> +static u8 csiphy_get_bpp(u32 code)
> +{
> + unsigned int i;
> +
> + for (i = 0; i < ARRAY_SIZE(csiphy_formats); i++)
> + if (code == csiphy_formats[i].code)
> + break;
I'd return the entry here and have __WARN() and return 8 (or safe value) in
the end for extra safety.
> +
> + return csiphy_formats[i].bpp;
> +}
> +
> +/*
> + * csiphy_isr - CSIPHY module interrupt handler
> + * @irq: Interrupt line
> + * @dev: CSIPHY device
> + *
> + * Return IRQ_HANDLED on success
> + */
> +static irqreturn_t csiphy_isr(int irq, void *dev)
> +{
> + struct csiphy_device *csiphy = dev;
> + u8 i;
> +
> + for (i = 0; i < 8; i++) {
> + u8 val = readl_relaxed(csiphy->base +
> +CAMSS_CSI_PHY_INTERRUPT_STATUSn(i));
> + writel_relaxed(val, csiphy->base +
> +CAMSS_CSI_PHY_INTERRUPT_CLEAR
[v4] media: platform: davinci: return -EINVAL for VPFE_CMD_S_CCDC_RAW_PARAMS ioctl
this patch makes sure VPFE_CMD_S_CCDC_RAW_PARAMS ioctl no longer works
for vpfe_capture driver with a minimal patch suitable for backporting.
- This ioctl was never in public api and was only defined in kernel header.
- The function set_params constantly mixes up pointers and phys_addr_t
numbers.
- This is part of a 'VPFE_CMD_S_CCDC_RAW_PARAMS' ioctl command that is
described as an 'experimental ioctl that will change in future kernels'.
- The code to allocate the table never gets called after we copy_from_user
the user input over the kernel settings, and then compare them
for inequality.
- We then go on to use an address provided by user space as both the
__user pointer for input and pass it through phys_to_virt to come up
with a kernel pointer to copy the data to. This looks like a trivially
exploitable root hole.
Due to these reasons we make sure this ioctl now returns -EINVAL and backport
this patch as far as possible.
Fixes: 5f15fbb68fd7 ("V4L/DVB (12251): v4l: dm644x ccdc module for vpfe capture
driver")
Signed-off-by: Lad, Prabhakar
---
drivers/media/platform/davinci/vpfe_capture.c | 22 ++
1 file changed, 2 insertions(+), 20 deletions(-)
diff --git a/drivers/media/platform/davinci/vpfe_capture.c
b/drivers/media/platform/davinci/vpfe_capture.c
index e3fe3e0..1831bf5 100644
--- a/drivers/media/platform/davinci/vpfe_capture.c
+++ b/drivers/media/platform/davinci/vpfe_capture.c
@@ -1719,27 +1719,9 @@ static long vpfe_param_handler(struct file *file, void
*priv,
switch (cmd) {
case VPFE_CMD_S_CCDC_RAW_PARAMS:
+ ret = -EINVAL;
v4l2_warn(&vpfe_dev->v4l2_dev,
- "VPFE_CMD_S_CCDC_RAW_PARAMS: experimental ioctl\n");
- if (ccdc_dev->hw_ops.set_params) {
- ret = ccdc_dev->hw_ops.set_params(param);
- if (ret) {
- v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev,
- "Error setting parameters in CCDC\n");
- goto unlock_out;
- }
- ret = vpfe_get_ccdc_image_format(vpfe_dev,
-&vpfe_dev->fmt);
- if (ret < 0) {
- v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev,
- "Invalid image format at CCDC\n");
- goto unlock_out;
- }
- } else {
- ret = -EINVAL;
- v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev,
- "VPFE_CMD_S_CCDC_RAW_PARAMS not supported\n");
- }
+ "VPFE_CMD_S_CCDC_RAW_PARAMS not supported\n");
break;
default:
ret = -ENOTTY;
--
2.7.4
Re: [PATCH v2] media: venus: don't abuse dma_alloc for non-DMA allocations
On Thu, Jul 20, 2017 at 1:26 PM, Hans Verkuil wrote:
> On 19/07/17 13:51, Stanimir Varbanov wrote:
>> In venus_boot(), we pass a pointer to a phys_addr_t
>> into dmam_alloc_coherent, which the compiler warns about:
>>
>> platform/qcom/venus/firmware.c: In function 'venus_boot':
>> platform/qcom/venus/firmware.c:63:49: error: passing argument 3 of
>> 'dmam_alloc_coherent' from incompatible pointer type
>> [-Werror=incompatible-pointer-types]
>>
>> To avoid the error refactor venus_boot function by discard
>> dma_alloc_coherent invocation because we don't want to map the
>> memory for the device. Something more, the usage of
>> DMA mapping API is actually wrong and the current
>> implementation relies on several bugs in DMA mapping code.
>> When these bugs are fixed that will break firmware loading,
>> so fix this now to avoid future troubles.
>>
>> The meaning of venus_boot is to copy the content of the
>> firmware buffer into reserved (and memblock removed)
>> block of memory and pass that physical address to the
>> trusted zone for authentication and mapping through iommu
>> form the secure world. After iommu mapping is done the iova
>> is passed as ane entry point to the remote processor.
>>
>> After this change memory-region property is parsed manually
>> and the physical address is memremap to CPU, call mdt_load to
>> load firmware segments into proper places and unmap
>> reserved memory.
>>
>> Fixes: af2c3834c8ca ("[media] media: venus: adding core part and helper
>> functions")
>> Signed-off-by: Stanimir Varbanov
>
> Arnd, is this OK for you?
Looks good
Reviewed-by: Arnd Bergmann
Re: [v3 1/2] media: platform: davinci: prepare for removal of VPFE_CMD_S_CCDC_RAW_PARAMS ioctl
On 20/07/17 10:56, Lad, Prabhakar wrote:
> preparing for removal of VPFE_CMD_S_CCDC_RAW_PARAMS ioctl from
You don't really prepare for removal. You make sure VPFE_CMD_S_CCDC_RAW_PARAMS
no longer works with a minimal patch suitable for backporting.
> davicni vpfe_capture driver because of following reasons:
davicni -> davinci
>
> - This ioctl was never in public api and was only defined in kernel header.
> - The function set_params constantly mixes up pointers and phys_addr_t
> numbers.
> - This is part of a 'VPFE_CMD_S_CCDC_RAW_PARAMS' ioctl command that is
> described as an 'experimental ioctl that will change in future kernels'.
> - The code to allocate the table never gets called after we copy_from_user
> the user input over the kernel settings, and then compare them
> for inequality.
> - We then go on to use an address provided by user space as both the
> __user pointer for input and pass it through phys_to_virt to come up
> with a kernel pointer to copy the data to. This looks like a trivially
> exploitable root hole.
Add something like:
"Due to these reasons we make sure this ioctl now returns -EINVAL and backport
this patch as far as possible."
Regards,
Hans
>
> Fixes: 5f15fbb68fd7 ("V4L/DVB (12251): v4l: dm644x ccdc module for vpfe
> capture driver")
> Signed-off-by: Lad, Prabhakar
> ---
> drivers/media/platform/davinci/vpfe_capture.c | 22 ++
> 1 file changed, 2 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/media/platform/davinci/vpfe_capture.c
> b/drivers/media/platform/davinci/vpfe_capture.c
> index e3fe3e0..1831bf5 100644
> --- a/drivers/media/platform/davinci/vpfe_capture.c
> +++ b/drivers/media/platform/davinci/vpfe_capture.c
> @@ -1719,27 +1719,9 @@ static long vpfe_param_handler(struct file *file, void
> *priv,
>
> switch (cmd) {
> case VPFE_CMD_S_CCDC_RAW_PARAMS:
> + ret = -EINVAL;
> v4l2_warn(&vpfe_dev->v4l2_dev,
> - "VPFE_CMD_S_CCDC_RAW_PARAMS: experimental ioctl\n");
> - if (ccdc_dev->hw_ops.set_params) {
> - ret = ccdc_dev->hw_ops.set_params(param);
> - if (ret) {
> - v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev,
> - "Error setting parameters in CCDC\n");
> - goto unlock_out;
> - }
> - ret = vpfe_get_ccdc_image_format(vpfe_dev,
> - &vpfe_dev->fmt);
> - if (ret < 0) {
> - v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev,
> - "Invalid image format at CCDC\n");
> - goto unlock_out;
> - }
> - } else {
> - ret = -EINVAL;
> - v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev,
> - "VPFE_CMD_S_CCDC_RAW_PARAMS not supported\n");
> - }
> + "VPFE_CMD_S_CCDC_RAW_PARAMS not supported\n");
> break;
> default:
> ret = -ENOTTY;
>
Re: [PATCH v2] media: venus: don't abuse dma_alloc for non-DMA allocations
On 19/07/17 13:51, Stanimir Varbanov wrote:
> In venus_boot(), we pass a pointer to a phys_addr_t
> into dmam_alloc_coherent, which the compiler warns about:
>
> platform/qcom/venus/firmware.c: In function 'venus_boot':
> platform/qcom/venus/firmware.c:63:49: error: passing argument 3 of
> 'dmam_alloc_coherent' from incompatible pointer type
> [-Werror=incompatible-pointer-types]
>
> To avoid the error refactor venus_boot function by discard
> dma_alloc_coherent invocation because we don't want to map the
> memory for the device. Something more, the usage of
> DMA mapping API is actually wrong and the current
> implementation relies on several bugs in DMA mapping code.
> When these bugs are fixed that will break firmware loading,
> so fix this now to avoid future troubles.
>
> The meaning of venus_boot is to copy the content of the
> firmware buffer into reserved (and memblock removed)
> block of memory and pass that physical address to the
> trusted zone for authentication and mapping through iommu
> form the secure world. After iommu mapping is done the iova
> is passed as ane entry point to the remote processor.
>
> After this change memory-region property is parsed manually
> and the physical address is memremap to CPU, call mdt_load to
> load firmware segments into proper places and unmap
> reserved memory.
>
> Fixes: af2c3834c8ca ("[media] media: venus: adding core part and helper
> functions")
> Signed-off-by: Stanimir Varbanov
Arnd, is this OK for you?
Regards,
Hans
> ---
> this is v2 of the patch 2/4 form this [1] patchset. The only
> change is rewording in the patch description.
>
> [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg115717.html
>
> drivers/media/platform/qcom/venus/core.c | 10 ++--
> drivers/media/platform/qcom/venus/core.h | 1 -
> drivers/media/platform/qcom/venus/firmware.c | 74
>
> drivers/media/platform/qcom/venus/firmware.h | 5 +-
> 4 files changed, 39 insertions(+), 51 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/venus/core.c
> b/drivers/media/platform/qcom/venus/core.c
> index 694f57a78288..a70368cb713f 100644
> --- a/drivers/media/platform/qcom/venus/core.c
> +++ b/drivers/media/platform/qcom/venus/core.c
> @@ -76,7 +76,7 @@ static void venus_sys_error_handler(struct work_struct
> *work)
> hfi_core_deinit(core, true);
> hfi_destroy(core);
> mutex_lock(&core->lock);
> - venus_shutdown(&core->dev_fw);
> + venus_shutdown(core->dev);
>
> pm_runtime_put_sync(core->dev);
>
> @@ -84,7 +84,7 @@ static void venus_sys_error_handler(struct work_struct
> *work)
>
> pm_runtime_get_sync(core->dev);
>
> - ret |= venus_boot(core->dev, &core->dev_fw, core->res->fwname);
> + ret |= venus_boot(core->dev, core->res->fwname);
>
> ret |= hfi_core_resume(core, true);
>
> @@ -207,7 +207,7 @@ static int venus_probe(struct platform_device *pdev)
> if (ret < 0)
> goto err_runtime_disable;
>
> - ret = venus_boot(dev, &core->dev_fw, core->res->fwname);
> + ret = venus_boot(dev, core->res->fwname);
> if (ret)
> goto err_runtime_disable;
>
> @@ -238,7 +238,7 @@ static int venus_probe(struct platform_device *pdev)
> err_core_deinit:
> hfi_core_deinit(core, false);
> err_venus_shutdown:
> - venus_shutdown(&core->dev_fw);
> + venus_shutdown(dev);
> err_runtime_disable:
> pm_runtime_set_suspended(dev);
> pm_runtime_disable(dev);
> @@ -259,7 +259,7 @@ static int venus_remove(struct platform_device *pdev)
> WARN_ON(ret);
>
> hfi_destroy(core);
> - venus_shutdown(&core->dev_fw);
> + venus_shutdown(dev);
> of_platform_depopulate(dev);
>
> pm_runtime_put_sync(dev);
> diff --git a/drivers/media/platform/qcom/venus/core.h
> b/drivers/media/platform/qcom/venus/core.h
> index e542700eee32..cba092bcb76d 100644
> --- a/drivers/media/platform/qcom/venus/core.h
> +++ b/drivers/media/platform/qcom/venus/core.h
> @@ -101,7 +101,6 @@ struct venus_core {
> struct device *dev;
> struct device *dev_dec;
> struct device *dev_enc;
> - struct device dev_fw;
> struct mutex lock;
> struct list_head instances;
> atomic_t insts_count;
> diff --git a/drivers/media/platform/qcom/venus/firmware.c
> b/drivers/media/platform/qcom/venus/firmware.c
> index 1b1a4f355918..d6d9560c1c19 100644
> --- a/drivers/media/platform/qcom/venus/firmware.c
> +++ b/drivers/media/platform/qcom/venus/firmware.c
> @@ -12,29 +12,27 @@
> *
> */
>
> -#include
> +#include
> #include
> #include
> +#include
> #include
> -#include
> -#include
> +#include
> #include
> +#include
> #include
>
> #include "firmware.h"
>
> #define VENUS_PAS_ID 9
> -#define VENUS_FW_MEM_SIZESZ_8M
> +#define VENUS_FW_MEM_SIZE(6 * SZ_1M)
>
> -static void device_release_dummy(struct device *dev)
> -{
> -
Re: [PATCH] media: Convert to using %pOF instead of full_name
On Tue, Jul 18, 2017 at 10:43 PM, Rob Herring wrote: > Now that we have a custom printf format specifier, convert users of > full_name to use %pOF instead. This is preparation to remove storing > of the full path string for each node. > > Signed-off-by: Rob Herring > Cc: Kyungmin Park > Cc: Andrzej Hajda > Cc: Mauro Carvalho Chehab > Cc: "Lad, Prabhakar" > Cc: Songjun Wu > Cc: Sylwester Nawrocki > Cc: Kukjin Kim > Cc: Krzysztof Kozlowski > Cc: Javier Martinez Canillas > Cc: Minghsiu Tsai > Cc: Houlong Wei > Cc: Andrew-CT Chen > Cc: Matthias Brugger > Cc: Laurent Pinchart > Cc: "Niklas Söderlund" > Cc: Guennadi Liakhovetski > Cc: Hyun Kwon > Cc: Michal Simek > Cc: "Sören Brinkmann" > Cc: linux-media@vger.kernel.org > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-samsung-...@vger.kernel.org > Cc: linux-media...@lists.infradead.org > Cc: linux-renesas-...@vger.kernel.org > --- > drivers/media/platform/am437x/am437x-vpfe.c| 4 +- > drivers/media/platform/davinci/vpif_capture.c | 16 For above: Acked-by: Lad, Prabhakar Cheers, --Prabhakar Lad
Re: [PATCH] media: Convert to using %pOF instead of full_name
Em Wed, 19 Jul 2017 11:02:01 -0500
Rob Herring escreveu:
> On Wed, Jul 19, 2017 at 4:41 AM, Sylwester Nawrocki
> wrote:
> > On 07/18/2017 11:43 PM, Rob Herring wrote:
> >> Now that we have a custom printf format specifier, convert users of
> >> full_name to use %pOF instead. This is preparation to remove storing
> >> of the full path string for each node.
> >>
> >> Signed-off-by: Rob Herring
> >
> >> ---
> >> drivers/media/i2c/s5c73m3/s5c73m3-core.c | 3 +-
> >> drivers/media/i2c/s5k5baf.c| 7 ++--
> >> drivers/media/platform/am437x/am437x-vpfe.c| 4 +-
> >> drivers/media/platform/atmel/atmel-isc.c | 4 +-
> >> drivers/media/platform/davinci/vpif_capture.c | 16
> >> drivers/media/platform/exynos4-is/fimc-is.c| 8 ++--
> >> drivers/media/platform/exynos4-is/fimc-lite.c | 3 +-
> >> drivers/media/platform/exynos4-is/media-dev.c | 8 ++--
> >> drivers/media/platform/exynos4-is/mipi-csis.c | 4 +-
> >> drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 6 +--
> >> drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 8 ++--
> >> drivers/media/platform/omap3isp/isp.c | 8 ++--
> >> drivers/media/platform/pxa_camera.c| 2 +-
> >> drivers/media/platform/rcar-vin/rcar-core.c| 4 +-
> >> drivers/media/platform/soc_camera/soc_camera.c | 6 +--
> >> drivers/media/platform/xilinx/xilinx-vipp.c| 52
> >> +-
> >> drivers/media/v4l2-core/v4l2-async.c | 4 +-
> >> drivers/media/v4l2-core/v4l2-clk.c | 3 +-
> >> include/media/v4l2-clk.h | 4 +-
> >> 19 files changed, 71 insertions(+), 83 deletions(-)
> >
> >> diff --git a/drivers/media/platform/xilinx/xilinx-vipp.c
> >> b/drivers/media/platform/xilinx/xilinx-vipp.c
> >> index ac4704388920..9233ad0b1b6b 100644
> >> --- a/drivers/media/platform/xilinx/xilinx-vipp.c
> >> +++ b/drivers/media/platform/xilinx/xilinx-vipp.c
> >
> >> @@ -144,9 +144,8 @@ static int xvip_graph_build_one(struct
> >> xvip_composite_device *xdev,
> >> remote = ent->entity;
> >>
> >> if (link.remote_port >= remote->num_pads) {
> >> - dev_err(xdev->dev, "invalid port number %u on %s\n",
> >> - link.remote_port,
> >> - to_of_node(link.remote_node)->full_name);
> >> + dev_err(xdev->dev, "invalid port number %u on
> >> %pOF\n",
> >> + link.remote_port, link.remote_node);
> >
> > Shouldn't there be to_of_node(link.remote_node) instead of link.remote_node
> > ?
>
> Humm, yes. I thought I fixed that.
After such fix, I'm OK with this patch.
Are you planning to apply it on your tree, or via the media one?
I guess it is probably better to apply via media, in order to avoid
conflicts with other changes.
Thanks,
Mauro
Re: [GIT PULL] SAA716x DVB driver
Hi Soeren, Em Sun, 16 Jul 2017 20:34:23 +0200 Soeren Moch escreveu: > This is a driver for DVB cards based on the SAA7160/62 PCIe bridges from > Philips/NXP. The most important of these cards, at least for me, is the > TechnoTrend S2-6400, a high-definition full-featured DVB-S2 card, the > successor of the famous ttpci decoder cards. Other supported cards are: > Avermedia H788 > Avermedia HC82 Express-54 > KNC One Dual S2 > KWorld DVB-T PE310 > Technisat SkyStar 2 eXpress HD > Twinhan/Azurewave VP-1028 > Twinhan/Azurewave VP-3071 > Twinhan/Azurewave VP-6002 > Twinhan/Azurewave VP-6090 > > The driver is taken from [1] with adaptations for current mainline, > converted to git and moved to drivers/staging/media. See TODO for > required cleanups (from my point of view, maybe more to come from > additional code review by other developers). I added myself as driver > maintainer to document my commitment to further development to get this > out of staging, help from others welcome. > > This driver was licensed "GPL" from the beginning. S2-6400 firmware is > available at [2]. > > I want to preserve the development history of the driver, since this > is mainly work of Andreas Regel, Manu Abraham, and Oliver Endriss. > Unfortunately Andreas seems not to take care of this driver anymore, he > also did not answer my requests to integrate patches for newer kernel > versions. So I send this upstream. > > With all the history this is a 280 part patch series, so I send this as > pull request. Of course I can also send this as 'git send-email' series > if desired. Even on staging, reviewing a 280 patch series take a while ;) As the patches that make it build with current upstream are at the end of the series, you need to be sure that the saa716x Makefile won't be included until those fixes get applied. It seems you took care of it already, with is good! The hole idea of adding a driver to staging is that it will be moved some day out of staging. That's why a TODO and an entry at MAINTAINERS is required. By looking at the saa716x_ff_main: https://github.com/s-moch/linux-saa716x/blob/for-media/drivers/staging/media/saa716x/saa716x_ff_main.c I'm seeing that the main problem of this driver is that it still use the API from the legacy ttpci driver, e. g. DVB audio, video and osd APIs. Those APIs were deprecated because they duplicate a functionality provided by the V4L2 API, and are obscure, because they're not properly documented. Also, no other driver uses it upstream. So, it was agreed several years ago that new full featured drivers should use the V4L2 API for audio/video codecs. We have a some drivers that use V4L2 for MPEG audio/video decoding and encoding. The best examples are ivtv and cx18 (as both are for PCI devices). Currently, none of those drivers support the DVB API, though, as they're used only on analog TV devices. It was also agreed that setup pipelines on more complex DVB devices should use the media controller API (MC API). Yet, we don't have, currently, any full featured drivers upstream (except for the legacy one). So, if we're willing to apply this driver, you should be committed to do implement the media APIs properly, porting from DVB audio/video/osd to V4L2 and MC APIs. That should also reflect its TODO: https://github.com/s-moch/linux-saa716x/blob/for-media/drivers/staging/media/saa716x/TODO Regards, Mauro
[PATCH][media-next] media: v4l: make local function v4l2_fwnode_endpoint_parse_csi1_bus static
From: Colin Ian King
The function v4l2_fwnode_endpoint_parse_csi1_bus does not need to be
in global scope, so make it static. Also reformat the function arguments
as adding the static keyword made one of the source lines more than 80
chars wide and checkpatch does not like that.
Cleans up sparse warning:
"symbol 'v4l2_fwnode_endpoint_parse_csi1_bus' was not declared. Should it
be static?"
Signed-off-by: Colin Ian King
---
drivers/media/v4l2-core/v4l2-fwnode.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-fwnode.c
b/drivers/media/v4l2-core/v4l2-fwnode.c
index ca755a4832fc..5fd69f59d8c8 100644
--- a/drivers/media/v4l2-core/v4l2-fwnode.c
+++ b/drivers/media/v4l2-core/v4l2-fwnode.c
@@ -154,9 +154,10 @@ static void v4l2_fwnode_endpoint_parse_parallel_bus(
}
-void v4l2_fwnode_endpoint_parse_csi1_bus(struct fwnode_handle *fwnode,
-struct v4l2_fwnode_endpoint *vep,
-u32 bus_type)
+static void v4l2_fwnode_endpoint_parse_csi1_bus(
+ struct fwnode_handle *fwnode,
+ struct v4l2_fwnode_endpoint *vep,
+ u32 bus_type)
{
struct v4l2_fwnode_bus_mipi_csi1 *bus = &vep->bus.mipi_csi1;
u32 v;
--
2.11.0
Re: [PATCH] media: Convert to using %pOF instead of full_name
On 07/19/2017 06:02 PM, Rob Herring wrote: diff --git a/drivers/media/v4l2-core/v4l2-async.c b/drivers/media/v4l2-core/v4l2-async.c index 851f128eba22..0a385d1ff28c 100644 --- a/drivers/media/v4l2-core/v4l2-async.c +++ b/drivers/media/v4l2-core/v4l2-async.c @@ -47,9 +47,7 @@ static bool match_fwnode(struct v4l2_subdev *sd, struct v4l2_async_subdev *asd) if (!is_of_node(sd->fwnode) || !is_of_node(asd->match.fwnode.fwnode)) return sd->fwnode == asd->match.fwnode.fwnode; - return !of_node_cmp(of_node_full_name(to_of_node(sd->fwnode)), - of_node_full_name( - to_of_node(asd->match.fwnode.fwnode))); + return to_of_node(sd->fwnode) == to_of_node(asd->match.fwnode.fwnode); >> I'm afraid this will not work, please see commit d2180e0cf77dc7a7049671d5d57d "[media] v4l: async: make v4l2 coexist with devicetree nodes in a dt overlay" > Maybe I'm missing something, but how does that work exactly? Before the overlay is applied, the remote endpoint node (and its parent) can't be resolved. In the commit example, the endpoint in the media_bridge would also have to be part of the overlay. If you apply and un-apply the overlay, then the of_node (and fw_node) in the overlay is once again invalid. IOW, you should be in the same state as before the overlay was applied. The node is still around because of paranoia that actually freeing nodes would break things. It seems this paranoia is real, so i think we need to do something to prevent this from spreading. Furthermore, it does not appear that any media driver supports overlays and we have no general way to apply them in mainline yet (other than an in kernel API). So really this scenario is not one we have to support yet. Indeed, the motivation of the above mentioned commit was some out of tree driver. I don't know was the exact use case, assuming that the endpoint in the bridge node was also part of the overlay the bridge driver must have not been rescanning device tree after overlay un-apply and apply. Currently there is no other way to do this than to unbind and bind. So the bridge driver must have been referencing an already invalid node as you point out. I haven't been following DT overlays very closely, as Frank explains your change seems to be actually an improvement of current code. -- Thanks, Sylwester
Re: [PATCH v3 04/23] dt-bindings: media: Binding document for Qualcomm Camera subsystem driver
On Mon, Jul 17, 2017 at 01:33:30PM +0300, Todor Tomov wrote: > Add DT binding document for Qualcomm Camera subsystem driver. > > CC: Rob Herring > CC: devicet...@vger.kernel.org > Signed-off-by: Todor Tomov > --- > .../devicetree/bindings/media/qcom,camss.txt | 191 > + > 1 file changed, 191 insertions(+) > create mode 100644 Documentation/devicetree/bindings/media/qcom,camss.txt > > diff --git a/Documentation/devicetree/bindings/media/qcom,camss.txt > b/Documentation/devicetree/bindings/media/qcom,camss.txt > new file mode 100644 > index 000..f698498 > --- /dev/null > +++ b/Documentation/devicetree/bindings/media/qcom,camss.txt qcom,camss.txt or qcom,camss-8x16.txt? -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
Re: [PATCH v3 04/23] dt-bindings: media: Binding document for Qualcomm Camera subsystem driver
Hi Todor,
On Mon, Jul 17, 2017 at 01:33:30PM +0300, Todor Tomov wrote:
> Add DT binding document for Qualcomm Camera subsystem driver.
>
> CC: Rob Herring
> CC: devicet...@vger.kernel.org
> Signed-off-by: Todor Tomov
> ---
> .../devicetree/bindings/media/qcom,camss.txt | 191
> +
> 1 file changed, 191 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/qcom,camss.txt
>
> diff --git a/Documentation/devicetree/bindings/media/qcom,camss.txt
> b/Documentation/devicetree/bindings/media/qcom,camss.txt
> new file mode 100644
> index 000..f698498
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/qcom,camss.txt
> @@ -0,0 +1,191 @@
> +Qualcomm Camera Subsystem
> +
> +* Properties
> +
> +- compatible:
> + Usage: required
> + Value type:
> + Definition: Should contain:
> + - "qcom,msm8916-camss"
> +- reg:
> + Usage: required
> + Value type:
> + Definition: Register ranges as listed in the reg-names property.
> +- reg-names:
> + Usage: required
> + Value type:
> + Definition: Should contain the following entries:
> + - "csiphy0"
> + - "csiphy0_clk_mux"
> + - "csiphy1"
> + - "csiphy1_clk_mux"
> + - "csid0"
> + - "csid1"
> + - "ispif"
> + - "csi_clk_mux"
> + - "vfe0"
> +- interrupts:
> + Usage: required
> + Value type:
> + Definition: Interrupts as listed in the interrupt-names property.
> +- interrupt-names:
> + Usage: required
> + Value type:
> + Definition: Should contain the following entries:
> + - "csiphy0"
> + - "csiphy1"
> + - "csid0"
> + - "csid1"
> + - "ispif"
> + - "vfe0"
> +- power-domains:
> + Usage: required
> + Value type:
> + Definition: A phandle and power domain specifier pairs to the
> + power domain which is responsible for collapsing
> + and restoring power to the peripheral.
> +- clocks:
> + Usage: required
> + Value type:
> + Definition: A list of phandle and clock specifier pairs as listed
> + in clock-names property.
> +- clock-names:
> + Usage: required
> + Value type:
> + Definition: Should contain the following entries:
> +- "camss_top_ahb"
> +- "ispif_ahb"
> +- "csiphy0_timer"
> +- "csiphy1_timer"
> +- "csi0_ahb"
> +- "csi0"
> +- "csi0_phy"
> +- "csi0_pix"
> +- "csi0_rdi"
> +- "csi1_ahb"
> +- "csi1"
> +- "csi1_phy"
> +- "csi1_pix"
> +- "csi1_rdi"
> +- "camss_ahb"
> +- "camss_vfe_vfe"
> +- "camss_csi_vfe"
> +- "iface"
> +- "bus"
> +- vdda-supply:
> + Usage: required
> + Value type:
> + Definition: A phandle to voltage supply for CSI2.
> +- iommus:
> + Usage: required
> + Value type:
> + Definition: A list of phandle and IOMMU specifier pairs.
> +
> +* Nodes
> +
> +- ports:
> + Usage: required
> + Definition: As described in video-interfaces.txt in same directory.
> + Properties:
> + - reg:
> + Usage: required
> + Value type:
> + Definition: Selects CSI2 PHY interface - PHY0 or PHY1.
> + Endpoint node properties:
> + - clock-lanes:
> + Usage: required
> + Value type:
> + Definition: The clock lane.
> + - data-lanes:
> + Usage: required
> + Value type:
> + Definition: An array of data lanes.
> +
> +* An Example
> +
> + camss: camss@1b0 {
> + compatible = "qcom,msm8916-camss";
> + reg = <0x1b0ac00 0x200>,
> + <0x1b00030 0x4>,
> + <0x1b0b000 0x200>,
> + <0x1b00038 0x4>,
> + <0x1b08000 0x100>,
> + <0x1b08400 0x100>,
> + <0x1b0a000 0x500>,
> + <0x1b00020 0x10>,
> + <0x1b1 0x1000>;
> + reg-names = "csiphy0",
> + "csiphy0_clk_mux",
> + "csiphy1",
> + "csiphy1_clk_mux",
> + "csid0",
> + "csid1",
> + "ispif",
> + "csi_clk_mux",
> + "vfe0";
> + interrupts = ,
> + ,
> + ,
> + ,
> + ,
> + ;
> + interrupt-names = "csiphy0",
> + "csiphy1",
Re: [PATCHv2 3/3] drm/vc4: add HDMI CEC support
Hi Eric,
On 16/07/17 12:48, Hans Verkuil wrote:
> From: Hans Verkuil
>
> This patch adds support to VC4 for CEC.
>
> Thanks to Eric Anholt for providing me with the CEC register information.
>
> To prevent the firmware from eating the CEC interrupts you need to add this to
> your config.txt:
>
> mask_gpu_interrupt1=0x100
I put this text in the commit log, but I think it should also go into the
source.
Do you agree?
Should I also mention this in the kernel log via a 'dev_info'? It's not an
obvious
config option, after all.
Or do you have other ideas regarding this?
Regards,
Hans
>
> Signed-off-by: Hans Verkuil
> Signed-off-by: Eric Anholt
> ---
> drivers/gpu/drm/vc4/Kconfig| 8 ++
> drivers/gpu/drm/vc4/vc4_hdmi.c | 227
> +++--
> drivers/gpu/drm/vc4/vc4_regs.h | 113
> 3 files changed, 342 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/Kconfig b/drivers/gpu/drm/vc4/Kconfig
> index 4361bdcfd28a..fdae18aeab4f 100644
> --- a/drivers/gpu/drm/vc4/Kconfig
> +++ b/drivers/gpu/drm/vc4/Kconfig
> @@ -19,3 +19,11 @@ config DRM_VC4
> This driver requires that "avoid_warnings=2" be present in
> the config.txt for the firmware, to keep it from smashing
> our display setup.
> +
> +config DRM_VC4_HDMI_CEC
> + bool "Broadcom VC4 HDMI CEC Support"
> + depends on DRM_VC4
> + select CEC_CORE
> + help
> + Choose this option if you have a Broadcom VC4 GPU
> + and want to use CEC.
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index e0104f96011e..761b95f5deed 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -57,9 +57,14 @@
> #include
> #include
> #include
> +#include "media/cec.h"
> #include "vc4_drv.h"
> #include "vc4_regs.h"
>
> +#define HSM_CLOCK_FREQ 163682864
> +#define CEC_CLOCK_FREQ 4
> +#define CEC_CLOCK_DIV (HSM_CLOCK_FREQ / CEC_CLOCK_FREQ)
> +
> /* HDMI audio information */
> struct vc4_hdmi_audio {
> struct snd_soc_card card;
> @@ -85,6 +90,11 @@ struct vc4_hdmi {
> int hpd_gpio;
> bool hpd_active_low;
>
> + struct cec_adapter *cec_adap;
> + struct cec_msg cec_rx_msg;
> + bool cec_tx_ok;
> + bool cec_irq_was_rx;
> +
> struct clk *pixel_clock;
> struct clk *hsm_clock;
> };
> @@ -149,6 +159,23 @@ static const struct {
> HDMI_REG(VC4_HDMI_VERTB1),
> HDMI_REG(VC4_HDMI_TX_PHY_RESET_CTL),
> HDMI_REG(VC4_HDMI_TX_PHY_CTL0),
> +
> + HDMI_REG(VC4_HDMI_CEC_CNTRL_1),
> + HDMI_REG(VC4_HDMI_CEC_CNTRL_2),
> + HDMI_REG(VC4_HDMI_CEC_CNTRL_3),
> + HDMI_REG(VC4_HDMI_CEC_CNTRL_4),
> + HDMI_REG(VC4_HDMI_CEC_CNTRL_5),
> + HDMI_REG(VC4_HDMI_CPU_STATUS),
> + HDMI_REG(VC4_HDMI_CPU_MASK_STATUS),
> +
> + HDMI_REG(VC4_HDMI_CEC_RX_DATA_1),
> + HDMI_REG(VC4_HDMI_CEC_RX_DATA_2),
> + HDMI_REG(VC4_HDMI_CEC_RX_DATA_3),
> + HDMI_REG(VC4_HDMI_CEC_RX_DATA_4),
> + HDMI_REG(VC4_HDMI_CEC_TX_DATA_1),
> + HDMI_REG(VC4_HDMI_CEC_TX_DATA_2),
> + HDMI_REG(VC4_HDMI_CEC_TX_DATA_3),
> + HDMI_REG(VC4_HDMI_CEC_TX_DATA_4),
> };
>
> static const struct {
> @@ -216,8 +243,8 @@ vc4_hdmi_connector_detect(struct drm_connector
> *connector, bool force)
> if (gpio_get_value_cansleep(vc4->hdmi->hpd_gpio) ^
> vc4->hdmi->hpd_active_low)
> return connector_status_connected;
> - else
> - return connector_status_disconnected;
> + cec_phys_addr_invalidate(vc4->hdmi->cec_adap);
> + return connector_status_disconnected;
> }
>
> if (drm_probe_ddc(vc4->hdmi->ddc))
> @@ -225,8 +252,8 @@ vc4_hdmi_connector_detect(struct drm_connector
> *connector, bool force)
>
> if (HDMI_READ(VC4_HDMI_HOTPLUG) & VC4_HDMI_HOTPLUG_CONNECTED)
> return connector_status_connected;
> - else
> - return connector_status_disconnected;
> + cec_phys_addr_invalidate(vc4->hdmi->cec_adap);
> + return connector_status_disconnected;
> }
>
> static void vc4_hdmi_connector_destroy(struct drm_connector *connector)
> @@ -247,6 +274,7 @@ static int vc4_hdmi_connector_get_modes(struct
> drm_connector *connector)
> struct edid *edid;
>
> edid = drm_get_edid(connector, vc4->hdmi->ddc);
> + cec_s_phys_addr_from_edid(vc4->hdmi->cec_adap, edid);
> if (!edid)
> return -ENODEV;
>
> @@ -1121,6 +1149,159 @@ static void vc4_hdmi_audio_cleanup(struct vc4_hdmi
> *hdmi)
> snd_soc_unregister_codec(dev);
> }
>
> +#ifdef CONFIG_DRM_VC4_HDMI_CEC
> +static irqreturn_t vc4_cec_irq_handler_thread(int irq, void *priv)
> +{
> + struct vc4_dev *vc4 = priv;
> + struct vc4_hdmi *hdmi = vc4->hdmi;
> +
> + if (hdmi->cec_irq_was_rx) {
> + if (hdmi->cec_rx_msg.len)
> + cec_received_msg(hdmi->cec
[PATCH v2 2/2] v4l: cadence: Add Cadence MIPI-CSI2 RX driver
The Cadence CSI-2 RX Controller is an hardware block meant to be used as a
bridge between a CSI-2 bus and pixel grabbers.
It supports operating with internal or external D-PHY, with up to 4 lanes,
or without any D-PHY. The current code only supports the former case.
It also support dynamic mapping of the CSI-2 virtual channels to the
associated pixel grabbers, but that isn't allowed at the moment either.
Signed-off-by: Maxime Ripard
---
drivers/media/platform/Kconfig | 1 +
drivers/media/platform/Makefile | 2 +
drivers/media/platform/cadence/Kconfig | 12 +
drivers/media/platform/cadence/Makefile | 1 +
drivers/media/platform/cadence/cdns-csi2rx.c | 413 +++
5 files changed, 429 insertions(+)
create mode 100644 drivers/media/platform/cadence/Kconfig
create mode 100644 drivers/media/platform/cadence/Makefile
create mode 100644 drivers/media/platform/cadence/cdns-csi2rx.c
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 1313cd533436..a79d96e9b723 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -26,6 +26,7 @@ config VIDEO_VIA_CAMERA
#
# Platform multimedia device configuration
#
+source "drivers/media/platform/cadence/Kconfig"
source "drivers/media/platform/davinci/Kconfig"
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 9beadc760467..1d31eb51e9bb 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -2,6 +2,8 @@
# Makefile for the video capture/playback device drivers.
#
+obj-$(CONFIG_VIDEO_CADENCE)+= cadence/
+
obj-$(CONFIG_VIDEO_M32R_AR_M64278) += arv.o
obj-$(CONFIG_VIDEO_VIA_CAMERA) += via-camera.o
diff --git a/drivers/media/platform/cadence/Kconfig
b/drivers/media/platform/cadence/Kconfig
new file mode 100644
index ..d1b6bbb6a0eb
--- /dev/null
+++ b/drivers/media/platform/cadence/Kconfig
@@ -0,0 +1,12 @@
+config VIDEO_CADENCE
+ bool "Cadence Video Devices"
+
+if VIDEO_CADENCE
+
+config VIDEO_CADENCE_CSI2RX
+ tristate "Cadence MIPI-CSI2 RX Controller v1.3"
+ depends on MEDIA_CONTROLLER
+ depends on VIDEO_V4L2_SUBDEV_API
+ select V4L2_FWNODE
+
+endif
diff --git a/drivers/media/platform/cadence/Makefile
b/drivers/media/platform/cadence/Makefile
new file mode 100644
index ..99a4086b7448
--- /dev/null
+++ b/drivers/media/platform/cadence/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_CADENCE_CSI2RX) += cdns-csi2rx.o
diff --git a/drivers/media/platform/cadence/cdns-csi2rx.c
b/drivers/media/platform/cadence/cdns-csi2rx.c
new file mode 100644
index ..9a58f275f53c
--- /dev/null
+++ b/drivers/media/platform/cadence/cdns-csi2rx.c
@@ -0,0 +1,413 @@
+/*
+ * Driver for Cadence MIPI-CSI2 RX Controller v1.3
+ *
+ * Copyright (C) 2017 Cadence Design Systems Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#define CSI2RX_DEVICE_CFG_REG 0x000
+
+#define CSI2RX_SOFT_RESET_REG 0x004
+#define CSI2RX_SOFT_RESET_PROTOCOL BIT(1)
+#define CSI2RX_SOFT_RESET_FRONTBIT(0)
+
+#define CSI2RX_STATIC_CFG_REG 0x008
+
+#define CSI2RX_STREAM_BASE(n) (((n) + 1) * 0x100)
+
+#define CSI2RX_STREAM_CTRL_REG(n) (CSI2RX_STREAM_BASE(n) + 0x000)
+#define CSI2RX_STREAM_CTRL_START BIT(0)
+
+#define CSI2RX_STREAM_DATA_CFG_REG(n) (CSI2RX_STREAM_BASE(n) + 0x008)
+#define CSI2RX_STREAM_DATA_CFG_EN_VC_SELECTBIT(31)
+#define CSI2RX_STREAM_DATA_CFG_VC_SELECT(n)BIT((n) + 16)
+
+#define CSI2RX_STREAM_CFG_REG(n) (CSI2RX_STREAM_BASE(n) + 0x00c)
+#define CSI2RX_STREAM_CFG_FIFO_MODE_LARGE_BUF (1 << 8)
+
+#define CSI2RX_STREAMS_MAX 4
+
+enum csi2rx_pads {
+ CSI2RX_PAD_SINK,
+ CSI2RX_PAD_SOURCE_VC0,
+ CSI2RX_PAD_SOURCE_VC1,
+ CSI2RX_PAD_SOURCE_VC2,
+ CSI2RX_PAD_SOURCE_VC3,
+ CSI2RX_PAD_MAX,
+};
+
+struct csi2rx_priv {
+ struct device *dev;
+
+ void __iomem*base;
+ struct clk *sys_clk;
+ struct clk *p_clk;
+ struct clk *p_free_clk;
+ struct clk *pixel_clk[CSI2RX_STREAMS_MAX];
+ struct clk *dphy_rx_clk;
+
+ u8 lanes;
+ u8 max_lanes;
+ u8 max_streams;
+ boolcdns_dphy;
+
+ struct v4l2_subdev subdev;
+ struct media_padp
[PATCH v2 0/2] media: v4l: Add support for the Cadence MIPI-CSI2 RX
Hi, Here is an attempt at supporting the MIPI-CSI2 RX block from Cadence. This IP block is able to receive CSI data over up to 4 lanes, and split it to over 4 streams. Those streams are basically the interfaces to the video grabbers that will perform the capture. It is able to map streams to both CSI datatypes and virtual channels, dynamically. This is unclear at this point what the right way to support it would be, so the driver only uses a static mapping between the virtual channels and streams, and ignores the data types. This serie depends on the version 5 of the serie "v4l2-async: add subnotifier registration for subdevices" from Niklas Söderlund. Let me know what you think! Maxime Changes from v1: - Amended the DT bindings as suggested by Rob - Rebase on top of 4.13-rc1 and latest Niklas' serie iteration Maxime Ripard (2): dt-bindings: media: Add Cadence MIPI-CSI2 RX Device Tree bindings v4l: cadence: Add Cadence MIPI-CSI2 RX driver .../devicetree/bindings/media/cdns-csi2rx.txt | 87 + drivers/media/platform/Kconfig | 1 + drivers/media/platform/Makefile| 2 + drivers/media/platform/cadence/Kconfig | 12 + drivers/media/platform/cadence/Makefile| 1 + drivers/media/platform/cadence/cdns-csi2rx.c | 413 + 6 files changed, 516 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/cdns-csi2rx.txt create mode 100644 drivers/media/platform/cadence/Kconfig create mode 100644 drivers/media/platform/cadence/Makefile create mode 100644 drivers/media/platform/cadence/cdns-csi2rx.c -- 2.13.3
[PATCH v2 1/2] dt-bindings: media: Add Cadence MIPI-CSI2 RX Device Tree bindings
The Cadence MIPI-CSI2 RX controller is a CSI2RX bridge that supports up to
4 CSI-2 lanes, and can route the frames to up to 4 streams, depending on
the hardware implementation.
It can operate with an external D-PHY, an internal one or no D-PHY at all
in some configurations.
Signed-off-by: Maxime Ripard
---
.../devicetree/bindings/media/cdns-csi2rx.txt | 87 ++
1 file changed, 87 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/cdns-csi2rx.txt
diff --git a/Documentation/devicetree/bindings/media/cdns-csi2rx.txt
b/Documentation/devicetree/bindings/media/cdns-csi2rx.txt
new file mode 100644
index ..e08547abe885
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/cdns-csi2rx.txt
@@ -0,0 +1,87 @@
+Cadence MIPI-CSI2 RX controller
+===
+
+The Cadence MIPI-CSI2 RX controller is a CSI-2 bridge supporting up to 4 CSI
+lanes in input, and 4 different pixel streams in output.
+
+Required properties:
+ - compatible: must be set to "cdns,csi2rx" and an SoC-specific compatible
+ - reg: base address and size of the memory mapped region
+ - clocks: phandles to the clocks driving the controller
+ - clock-names: must contain:
+* sys_clk: main clock
+* p_clk: register bank clock
+* p_free_clk: free running register bank clock
+* pixel_ifX_clk: pixel stream output clock, one for each stream
+ implemented in hardware, between 0 and 3
+* dphy_rx_clk: D-PHY byte clock, if implemented in hardware
+ - phys: phandle to the external D-PHY
+ - phy-names: must contain dphy, if the implementation uses an
+ external D-PHY
+
+Required subnodes:
+ - ports: A ports node with endpoint definitions as defined in
+ Documentation/devicetree/bindings/media/video-interfaces.txt. The
+ first port subnode should be the input endpoint, the second one the
+ outputs
+
+ The output port should have as many endpoints as stream supported by
+ the hardware implementation, between 1 and 4, their ID being the
+ stream output number used in the implementation.
+
+Example:
+
+csi2rx: csi-bridge@0d06 {
+ compatible = "cdns,csi2rx";
+ reg = <0x0d06 0x1000>;
+ clocks = <&byteclock>, <&byteclock>, <&byteclock>,
+<&coreclock>, <&coreclock>,
+<&coreclock>, <&coreclock>;
+ clock-names = "sys_clk", "p_clk", "p_free_clk",
+ "pixel_if0_clk", "pixel_if1_clk",
+ "pixel_if2_clk", "pixel_if3_clk";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ csi2rx_in_sensor: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&sensor_out_csi2rx>;
+ clock-lanes = <0>;
+ data-lanes = <1 2>;
+ };
+ };
+
+ port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ csi2rx_out_grabber0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&grabber0_in_csi2rx>;
+ };
+
+ csi2rx_out_grabber1: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&grabber1_in_csi2rx>;
+ };
+
+ csi2rx_out_grabber2: endpoint@2 {
+ reg = <2>;
+ remote-endpoint = <&grabber2_in_csi2rx>;
+ };
+
+ csi2rx_out_grabber3: endpoint@3 {
+ reg = <3>;
+ remote-endpoint = <&grabber3_in_csi2rx>;
+ };
+ };
+ };
+};
--
2.13.3
Re: [PATCH v2 0/7] Add support of OV9655 camera
On 07/20/2017 10:37 AM, H. Nikolaus Schaller wrote: > Hi, > >> Am 18.07.2017 um 21:52 schrieb Sakari Ailus : >> >> On Tue, Jul 18, 2017 at 12:53:12PM +, Hugues FRUCHET wrote: >>> >>> >>> On 07/18/2017 02:17 PM, H. Nikolaus Schaller wrote: Hi, > Am 18.07.2017 um 13:59 schrieb Hans Verkuil : > > On 12/07/17 22:01, Sylwester Nawrocki wrote: >> Hi Hugues, >> >> On 07/03/2017 11:16 AM, Hugues Fruchet wrote: >>> This patchset enables OV9655 camera support. >>> >>> OV9655 support has been tested using STM32F4DIS-CAM extension board >>> plugged on connector P1 of STM32F746G-DISCO board. >>> Due to lack of OV9650/52 hardware support, the modified related code >>> could not have been checked for non-regression. >>> >>> First patches upgrade current support of OV9650/52 to prepare then >>> introduction of OV9655 variant patch. >>> Because of OV9655 register set slightly different from OV9650/9652, >>> not all of the driver features are supported (controls). Supported >>> resolutions are limited to VGA, QVGA, QQVGA. >>> Supported format is limited to RGB565. >>> Controls are limited to color bar test pattern for test purpose. >> >> I appreciate your efforts towards making a common driver but IMO it >> would be >> better to create a separate driver for the OV9655 sensor. The original >> driver >> is 1576 lines of code, your patch set adds half of that (816). There are >> significant differences in the feature set of both sensors, there are >> differences in the register layout. I would go for a separate driver, we >> would then have code easier to follow and wouldn't need to worry about >> possible >> regressions. I'm afraid I have lost the camera module and won't be able >> to test the patch set against regressions. >> >> IMHO from maintenance POV it's better to make a separate driver. In the >> end >> of the day we wouldn't be adding much more code than it is being done >> now. > > I agree. We do not have great experiences in the past with trying to > support > multiple variants in a single driver (unless the diffs are truly small). Well, IMHO the diffs in ov965x are smaller (but untestable because nobody seems to have an ov9650/52 board) than within the bq27xxx chips, but I can dig out an old pdata based separate ov9655 driver and extend that to become DT compatible. I had abandoned that separate approach in favour of extending the ov965x driver. Have to discuss with Hugues how to proceed. BR and thanks, Nikolaus >>> >>> As Sylwester and Hans, I'm also in flavour of a separate driver, the >>> fact that register set seems similar but in fact is not and that we >>> cannot test for non-regression of 9650/52 are killer for me to continue >>> on a single driver. >>> We can now restart from a new fresh state of the art sensor driver >>> getting rid of legacy (pdata, old gpio, etc...). >> >> Agreed. I bet the result will look cleaner indeed although this wasn't one >> of the complex drivers. > > I finally managed to find the bug why mplayer did select-timeout on the GTA04. > Was a bug in pinmux setup of the GTA04 for the omap3isp. > > And I have resurrected our years old 3.12 camera driver, which was based on > the > MT9P031 code. It was already separate from ov9650/52. > > I have extended it to support DT by including some parts of Hugues' work. > > It still needs some cleanup and discussion but will be a simple patch (one > for ov9655.c + Kconfig + Makefile) and one for bindings (I hope it includes > all your comments). > > I will post v1 in the next days. > > BR, > Nikolaus > Thanks Nikolaus, I was ready to push the new version in new file ov9655.c with all comments included, but as my version is very minimal and I suspect that yours is more complete, let's merge things together. Can I consider that you now take ownership of this driver upstream ? If so I'll send to you my current patchset so you can compare, double-check review comments and add missing support on your side (RGB565 and VGA/QVGA resolution matter on my side). Thanks again Nikolaus for this work, BR, Hugues.
[v3 2/2] media: platform: davinci: drop VPFE_CMD_S_CCDC_RAW_PARAMS
drop VPFE_CMD_S_CCDC_RAW_PARAMS ioctl from dm355/dm644x following reasons:
- This ioctl was never in public api and was only defined in kernel header.
- The function set_params constantly mixes up pointers and phys_addr_t
numbers.
- This is part of a 'VPFE_CMD_S_CCDC_RAW_PARAMS' ioctl command that is
described as an 'experimental ioctl that will change in future kernels'.
- The code to allocate the table never gets called after we copy_from_user
the user input over the kernel settings, and then compare them
for inequality.
- We then go on to use an address provided by user space as both the
__user pointer for input and pass it through phys_to_virt to come up
with a kernel pointer to copy the data to. This looks like a trivially
exploitable root hole.
Signed-off-by: Lad, Prabhakar
---
drivers/media/platform/davinci/ccdc_hw_device.h | 10 --
drivers/media/platform/davinci/dm355_ccdc.c | 92 +--
drivers/media/platform/davinci/dm644x_ccdc.c| 151 +---
drivers/media/platform/davinci/vpfe_capture.c | 75
include/media/davinci/dm644x_ccdc.h | 12 --
include/media/davinci/vpfe_capture.h| 10 --
6 files changed, 4 insertions(+), 346 deletions(-)
diff --git a/drivers/media/platform/davinci/ccdc_hw_device.h
b/drivers/media/platform/davinci/ccdc_hw_device.h
index 8f6688a..f1b5210 100644
--- a/drivers/media/platform/davinci/ccdc_hw_device.h
+++ b/drivers/media/platform/davinci/ccdc_hw_device.h
@@ -42,16 +42,6 @@ struct ccdc_hw_ops {
int (*set_hw_if_params) (struct vpfe_hw_if_param *param);
/* get interface parameters */
int (*get_hw_if_params) (struct vpfe_hw_if_param *param);
- /*
-* Pointer to function to set parameters. Used
-* for implementing VPFE_S_CCDC_PARAMS
-*/
- int (*set_params) (void *params);
- /*
-* Pointer to function to get parameter. Used
-* for implementing VPFE_G_CCDC_PARAMS
-*/
- int (*get_params) (void *params);
/* Pointer to function to configure ccdc */
int (*configure) (void);
diff --git a/drivers/media/platform/davinci/dm355_ccdc.c
b/drivers/media/platform/davinci/dm355_ccdc.c
index 73db166..6d492dc 100644
--- a/drivers/media/platform/davinci/dm355_ccdc.c
+++ b/drivers/media/platform/davinci/dm355_ccdc.c
@@ -17,12 +17,7 @@
* This module is for configuring DM355 CCD controller of VPFE to capture
* Raw yuv or Bayer RGB data from a decoder. CCDC has several modules
* such as Defect Pixel Correction, Color Space Conversion etc to
- * pre-process the Bayer RGB data, before writing it to SDRAM. This
- * module also allows application to configure individual
- * module parameters through VPFE_CMD_S_CCDC_RAW_PARAMS IOCTL.
- * To do so, application include dm355_ccdc.h and vpfe_capture.h header
- * files. The setparams() API is called by vpfe_capture driver
- * to configure module parameters
+ * pre-process the Bayer RGB data, before writing it to SDRAM.
*
* TODO: 1) Raw bayer parameter settings and bayer capture
* 2) Split module parameter structure to module specific ioctl structs
@@ -260,90 +255,6 @@ static void ccdc_setwin(struct v4l2_rect *image_win,
dev_dbg(ccdc_cfg.dev, "\nEnd of ccdc_setwin...");
}
-static int validate_ccdc_param(struct ccdc_config_params_raw *ccdcparam)
-{
- if (ccdcparam->datasft < CCDC_DATA_NO_SHIFT ||
- ccdcparam->datasft > CCDC_DATA_SHIFT_6BIT) {
- dev_dbg(ccdc_cfg.dev, "Invalid value of data shift\n");
- return -EINVAL;
- }
-
- if (ccdcparam->mfilt1 < CCDC_NO_MEDIAN_FILTER1 ||
- ccdcparam->mfilt1 > CCDC_MEDIAN_FILTER1) {
- dev_dbg(ccdc_cfg.dev, "Invalid value of median filter1\n");
- return -EINVAL;
- }
-
- if (ccdcparam->mfilt2 < CCDC_NO_MEDIAN_FILTER2 ||
- ccdcparam->mfilt2 > CCDC_MEDIAN_FILTER2) {
- dev_dbg(ccdc_cfg.dev, "Invalid value of median filter2\n");
- return -EINVAL;
- }
-
- if ((ccdcparam->med_filt_thres < 0) ||
- (ccdcparam->med_filt_thres > CCDC_MED_FILT_THRESH)) {
- dev_dbg(ccdc_cfg.dev,
- "Invalid value of median filter threshold\n");
- return -EINVAL;
- }
-
- if (ccdcparam->data_sz < CCDC_DATA_16BITS ||
- ccdcparam->data_sz > CCDC_DATA_8BITS) {
- dev_dbg(ccdc_cfg.dev, "Invalid value of data size\n");
- return -EINVAL;
- }
-
- if (ccdcparam->alaw.enable) {
- if (ccdcparam->alaw.gamma_wd < CCDC_GAMMA_BITS_13_4 ||
- ccdcparam->alaw.gamma_wd > CCDC_GAMMA_BITS_09_0) {
- dev_dbg(ccdc_cfg.dev, "Invalid value of ALAW\n");
- return -EINVAL;
- }
- }
-
- if (ccdcparam->blk_clamp.b_clamp_enable) {
- if (ccdcparam->blk_clamp.sample_pixel <
[v3 0/2] media: platform: davinci: remove VPFE_CMD_S_CCDC_RAW_PARAMS IOCTL
This patch series drops VPFE_CMD_S_CCDC_RAW_PARAMS ioctl, from davicni
vpfe_capture driver because of following reasons:
- The function constantly mixes up pointers and phys_addr_t numbers
- This is part of a 'VPFE_CMD_S_CCDC_RAW_PARAMS' ioctl command that is
described as an 'experimental ioctl that will change in future kernels',
but if we have users that probably won't happen.
- The code to allocate the table never gets called after we copy_from_user
the user input over the kernel settings, and then compare them
for inequality.
- We then go on to use an address provided by user space as both the
__user pointer for input and pass it through phys_to_virt to come up
with a kernel pointer to copy the data to. This looks like a trivially
exploitable root hole.
As discussed at [1], there wouldn’t be any possible users of
the VPFE_CMD_S_CCDC_RAW_PARAMS IOCTL, but if someone complains
we might end up reverting the removal and fix it differently.
[1] https://patchwork.kernel.org/patch/9779385/
Note: Patch 0001 is intended to apply for backports so as the reason
minimalistic changes have been done since the ioctl was added in
kernel 2.6.32 [2] and applying too many changes would produce conflicts,
just applying this patch would produce build warning of unused functions.
[2] commit 5f15fbb68fd7 ("V4L/DVB (12251): v4l: dm644x ccdc module for vpfe
capture driver")
Lad, Prabhakar (2):
media: platform: davinci: prepare for removal of
VPFE_CMD_S_CCDC_RAW_PARAMS ioctl
media: platform: davinci: drop VPFE_CMD_S_CCDC_RAW_PARAMS
drivers/media/platform/davinci/ccdc_hw_device.h | 10 --
drivers/media/platform/davinci/dm355_ccdc.c | 92 +--
drivers/media/platform/davinci/dm644x_ccdc.c| 151 +---
drivers/media/platform/davinci/vpfe_capture.c | 93 ---
include/media/davinci/dm644x_ccdc.h | 12 --
include/media/davinci/vpfe_capture.h| 10 --
6 files changed, 4 insertions(+), 364 deletions(-)
--
2.7.4
[v3 1/2] media: platform: davinci: prepare for removal of VPFE_CMD_S_CCDC_RAW_PARAMS ioctl
preparing for removal of VPFE_CMD_S_CCDC_RAW_PARAMS ioctl from
davicni vpfe_capture driver because of following reasons:
- This ioctl was never in public api and was only defined in kernel header.
- The function set_params constantly mixes up pointers and phys_addr_t
numbers.
- This is part of a 'VPFE_CMD_S_CCDC_RAW_PARAMS' ioctl command that is
described as an 'experimental ioctl that will change in future kernels'.
- The code to allocate the table never gets called after we copy_from_user
the user input over the kernel settings, and then compare them
for inequality.
- We then go on to use an address provided by user space as both the
__user pointer for input and pass it through phys_to_virt to come up
with a kernel pointer to copy the data to. This looks like a trivially
exploitable root hole.
Fixes: 5f15fbb68fd7 ("V4L/DVB (12251): v4l: dm644x ccdc module for vpfe capture
driver")
Signed-off-by: Lad, Prabhakar
---
drivers/media/platform/davinci/vpfe_capture.c | 22 ++
1 file changed, 2 insertions(+), 20 deletions(-)
diff --git a/drivers/media/platform/davinci/vpfe_capture.c
b/drivers/media/platform/davinci/vpfe_capture.c
index e3fe3e0..1831bf5 100644
--- a/drivers/media/platform/davinci/vpfe_capture.c
+++ b/drivers/media/platform/davinci/vpfe_capture.c
@@ -1719,27 +1719,9 @@ static long vpfe_param_handler(struct file *file, void
*priv,
switch (cmd) {
case VPFE_CMD_S_CCDC_RAW_PARAMS:
+ ret = -EINVAL;
v4l2_warn(&vpfe_dev->v4l2_dev,
- "VPFE_CMD_S_CCDC_RAW_PARAMS: experimental ioctl\n");
- if (ccdc_dev->hw_ops.set_params) {
- ret = ccdc_dev->hw_ops.set_params(param);
- if (ret) {
- v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev,
- "Error setting parameters in CCDC\n");
- goto unlock_out;
- }
- ret = vpfe_get_ccdc_image_format(vpfe_dev,
-&vpfe_dev->fmt);
- if (ret < 0) {
- v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev,
- "Invalid image format at CCDC\n");
- goto unlock_out;
- }
- } else {
- ret = -EINVAL;
- v4l2_dbg(1, debug, &vpfe_dev->v4l2_dev,
- "VPFE_CMD_S_CCDC_RAW_PARAMS not supported\n");
- }
+ "VPFE_CMD_S_CCDC_RAW_PARAMS not supported\n");
break;
default:
ret = -ENOTTY;
--
2.7.4
Re: [PATCH v2 0/7] Add support of OV9655 camera
Hi, > Am 18.07.2017 um 21:52 schrieb Sakari Ailus : > > On Tue, Jul 18, 2017 at 12:53:12PM +, Hugues FRUCHET wrote: >> >> >> On 07/18/2017 02:17 PM, H. Nikolaus Schaller wrote: >>> Hi, >>> Am 18.07.2017 um 13:59 schrieb Hans Verkuil : On 12/07/17 22:01, Sylwester Nawrocki wrote: > Hi Hugues, > > On 07/03/2017 11:16 AM, Hugues Fruchet wrote: >> This patchset enables OV9655 camera support. >> >> OV9655 support has been tested using STM32F4DIS-CAM extension board >> plugged on connector P1 of STM32F746G-DISCO board. >> Due to lack of OV9650/52 hardware support, the modified related code >> could not have been checked for non-regression. >> >> First patches upgrade current support of OV9650/52 to prepare then >> introduction of OV9655 variant patch. >> Because of OV9655 register set slightly different from OV9650/9652, >> not all of the driver features are supported (controls). Supported >> resolutions are limited to VGA, QVGA, QQVGA. >> Supported format is limited to RGB565. >> Controls are limited to color bar test pattern for test purpose. > > I appreciate your efforts towards making a common driver but IMO it would > be > better to create a separate driver for the OV9655 sensor. The original > driver > is 1576 lines of code, your patch set adds half of that (816). There are > significant differences in the feature set of both sensors, there are > differences in the register layout. I would go for a separate driver, we > would then have code easier to follow and wouldn't need to worry about > possible > regressions. I'm afraid I have lost the camera module and won't be able > to test the patch set against regressions. > > IMHO from maintenance POV it's better to make a separate driver. In the > end > of the day we wouldn't be adding much more code than it is being done now. I agree. We do not have great experiences in the past with trying to support multiple variants in a single driver (unless the diffs are truly small). >>> >>> Well, >>> IMHO the diffs in ov965x are smaller (but untestable because nobody seems >>> to have an ov9650/52 board) than within the bq27xxx chips, but I can dig out >>> an old pdata based separate ov9655 driver and extend that to become DT >>> compatible. >>> >>> I had abandoned that separate approach in favour of extending the ov965x >>> driver. >>> >>> Have to discuss with Hugues how to proceed. >>> >>> BR and thanks, >>> Nikolaus >>> >> >> As Sylwester and Hans, I'm also in flavour of a separate driver, the >> fact that register set seems similar but in fact is not and that we >> cannot test for non-regression of 9650/52 are killer for me to continue >> on a single driver. >> We can now restart from a new fresh state of the art sensor driver >> getting rid of legacy (pdata, old gpio, etc...). > > Agreed. I bet the result will look cleaner indeed although this wasn't one > of the complex drivers. I finally managed to find the bug why mplayer did select-timeout on the GTA04. Was a bug in pinmux setup of the GTA04 for the omap3isp. And I have resurrected our years old 3.12 camera driver, which was based on the MT9P031 code. It was already separate from ov9650/52. I have extended it to support DT by including some parts of Hugues' work. It still needs some cleanup and discussion but will be a simple patch (one for ov9655.c + Kconfig + Makefile) and one for bindings (I hope it includes all your comments). I will post v1 in the next days. BR, Nikolaus
pull request: linux-firmware: Update Mediatek MT8173 VPU firmware
Hi linux-firmware maintainers, The following changes since commit 7d2c913dcd1be083350d97a8cb1eba24cfacbc8a: ath10k: update year in license (2017-06-22 12:06:02 -0700) are available in the git repository at: https://github.com/andrewct-chen/linux_fw_vpu_v1.0.5.git v1.0.5 for you to fetch changes up to 0d4ab52ba9be6f619024d7a57b1af05a03daa099: mediatek: update MT8173 VPU firmware to 1.0.5 (2017-07-20 15:27:05 +0800) Andrew-CT Chen (1): mediatek: update MT8173 VPU firmware to 1.0.5 vpu_d.bin | Bin 4082928 -> 2977008 bytes vpu_p.bin | Bin 131160 -> 131324 bytes 2 files changed, 0 insertions(+), 0 deletions(-)
Re: [PATCH 5/8] v4l: Add support for CSI-1 and CCP2 busses
Hi!
> > > +void v4l2_fwnode_endpoint_parse_csi1_bus(struct fwnode_handle *fwnode,
> > > + struct v4l2_fwnode_endpoint *vep,
> > > + u32 bus_type)
> > > +{
> > > + struct v4l2_fwnode_bus_mipi_csi1 *bus = &vep->bus.mipi_csi1;
> > > + u32 v;
> > > +
> > > + if (!fwnode_property_read_u32(fwnode, "clock-inv", &v))
> > > + bus->clock_inv = v;
...
> > This function is indented with whitespaces! Next time, please check with
> > checkpatch.
> >
> > I fixed when merging it upstream.
>
> Well, what can I say?
You can probably blame Pavel copy/pasting patches from emails.
Sorry about that.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
