Re: [PATCH] media: entity: Catch unbalanced media_pipeline_stop calls

[Sakari Ailus]

Hi Kieran / Mauro,

On Fri, May 05, 2017 at 06:33:22PM +0100, Kieran Bingham wrote:
> Hi Sakari,
> 
> On 04/01/17 08:57, Sakari Ailus wrote:
> > Hi Kieran,
> > 
> > Thanks for the patch!
> > 
> > On Tue, Jan 03, 2017 at 05:05:58PM +, Kieran Bingham wrote:
> >> On 03/01/17 13:36, Laurent Pinchart wrote:
> >>> Hi Kieran,
> >>>
> >>> Thank you for the patch.
> >>>
> >>> On Tuesday 03 Jan 2017 13:12:11 Kieran Bingham wrote:
>  Drivers must not perform unbalanced calls to stop the entity pipeline,
>  however if they do they will fault in the core media code, as the
>  entity->pipe will be set as NULL. We handle this gracefully in the core
>  with a WARN for the developer.
> 
>  Replace the erroneous check on zero streaming counts, with a check on
>  NULL pipe elements instead, as this is the symptom of unbalanced
>  media_pipeline_stop calls.
> 
>  Signed-off-by: Kieran Bingham 
> >>>
> >>> This looks good to me,
> >>>
> >>> Acked-by: Laurent Pinchart 
> >>>
> >>> I'll let Sakari review and merge the patch.
> >>
> >> Ahh, yes - I forgot to mention, although perhaps it will be obvious for
> >> Sakari - but this patch is based on top of Sakari's pending media
> >> pipeline and graph walk cleanup series :D
> > 
> > I've applied this on top of the other patches.
> > 
> > It's always good to mention dependencies to other patches, that's very
> > relevant for reviewers.
> 
> I've just been going through my old branches doing some clean up - and I can't
> see that this patch [0] made it to integration anywhere.
> 
> Did it get lost?
>  It looks like the cleanup series it was based on made it through...

What I think happened was that I had applied it to the correct branch BUT I
already had sent a pull request on it. My apologies.

> 
> Mauro, perhaps you could pick this one up now ?

The patchwork link is here:



-- 
Regards,

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

Re: [PATCH v3] pinctrl: sh-pfc: r8a7794: add R8A7745 support

[Rob Herring]

On Fri, Apr 28, 2017 at 09:52:35PM +0300, Sergei Shtylyov wrote:
> Renesas RZ/G1E (R8A7745) is pin compatible with R-Car E2 (R8A7794),
> however it doesn't have several automotive specific peripherals.
> Annotate all the items that only exist on the R-Car SoCs...
> 
> Signed-off-by: Sergei Shtylyov 
> 
> ---
> This patch is  against the 'devel' branch of Linus Walleij's 
> 'linux-pinctrl.git'
> repo plus 3 R8A7794 PFC driver fixes/cleanups posted today and  the R8A7743 
> PFC
> support patch posted last week...
> 
> Changes in version 3:
> - resolved rejects atop of the new R8A7794 driver patches renaming the IIC0/1
>   signals and removing reserved groups/signals;
> - undid splitting of 'pinmux_{groups|functions}' arrays into the common and
>   R8A7794 specfic parts, updated the patch description accordingly;
> - kill double spaces in the patch description.
> 
> Changes in version 2:
> - fixed indentation to use tabs instead of spaces;
> - updated the PFC bindings.
> 
>  Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt |1 

Acked-by: Rob Herring 

>  drivers/pinctrl/sh-pfc/Kconfig|5 
>  drivers/pinctrl/sh-pfc/Makefile   |1 
>  drivers/pinctrl/sh-pfc/core.c |6 
>  drivers/pinctrl/sh-pfc/pfc-r8a7794.c  |  640 
> +-
>  drivers/pinctrl/sh-pfc/sh_pfc.h   |1 
>  6 files changed, 369 insertions(+), 285 deletions(-)

Re: [PATCH] media: entity: Catch unbalanced media_pipeline_stop calls

[Kieran Bingham]

Hi Sakari,

On 04/01/17 08:57, Sakari Ailus wrote:
> Hi Kieran,
> 
> Thanks for the patch!
> 
> On Tue, Jan 03, 2017 at 05:05:58PM +, Kieran Bingham wrote:
>> On 03/01/17 13:36, Laurent Pinchart wrote:
>>> Hi Kieran,
>>>
>>> Thank you for the patch.
>>>
>>> On Tuesday 03 Jan 2017 13:12:11 Kieran Bingham wrote:
 Drivers must not perform unbalanced calls to stop the entity pipeline,
 however if they do they will fault in the core media code, as the
 entity->pipe will be set as NULL. We handle this gracefully in the core
 with a WARN for the developer.

 Replace the erroneous check on zero streaming counts, with a check on
 NULL pipe elements instead, as this is the symptom of unbalanced
 media_pipeline_stop calls.

 Signed-off-by: Kieran Bingham 
>>>
>>> This looks good to me,
>>>
>>> Acked-by: Laurent Pinchart 
>>>
>>> I'll let Sakari review and merge the patch.
>>
>> Ahh, yes - I forgot to mention, although perhaps it will be obvious for
>> Sakari - but this patch is based on top of Sakari's pending media
>> pipeline and graph walk cleanup series :D
> 
> I've applied this on top of the other patches.
> 
> It's always good to mention dependencies to other patches, that's very
> relevant for reviewers.

I've just been going through my old branches doing some clean up - and I can't
see that this patch [0] made it to integration anywhere.

Did it get lost?
 It looks like the cleanup series it was based on made it through...

Mauro, perhaps you could pick this one up now ?

Regards

Kieran


[0] https://www.spinics.net/lists/linux-media/msg109715.html

[PATCH v4 0/4] RCAR-DU, VSP1: Prevent pre-emptive frame flips on VSP1-DRM pipelines

[Kieran Bingham]

The RCAR-DU utilises a running VSPD pipeline to perform processing for the
display pipeline. This presents the opportunity for some race conditions to
affect the quality of the display output.

To prevent reporting page flips early, we must track this timing through the
VSP1, and only allow the rcar-du object to report the page-flip completion
event after the VSP1 has processed.

This series ensures that tearing and flicker is prevented, without introducing
any (substantial) performance impact.

These patches have been tested by introducing artificial delays in the commit
code paths and verifying that no visual tearing or flickering occurs.

Extensive testing around the race window has been performed by dynamically
adapting the artificial delay between 15, and 17 seconds in 100uS increments
for periods of 5 seconds on each delay test. These tests have successfully run
for 3 hours.

Manual start/stop testing has also been performed.

Mauro: As this patchset covers two subsystems, and the DRM/DU side is dependant
upon the media/VSP side, If you are happy with these patches, Would it be
possible to get acks from you for integration through the DRM tree please?

Regards

Kieran

Kieran Bingham (3):
  v4l: vsp1: Postpone frame end handling in event of display list race
  v4l: vsp1: Extend VSP1 module API to allow DRM callbacks
  drm: rcar-du: Register a completion callback with VSP1

Laurent Pinchart (1):
  drm: rcar-du: Arm the page flip event after queuing the page flip

 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  | 30 ++
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h  |  1 +-
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c   |  9 -
 drivers/media/platform/vsp1/vsp1_dl.c   | 19 ++--
 drivers/media/platform/vsp1/vsp1_dl.h   |  2 +-
 drivers/media/platform/vsp1/vsp1_drm.c  | 17 +++-
 drivers/media/platform/vsp1/vsp1_drm.h  | 11 ++-
 drivers/media/platform/vsp1/vsp1_pipe.c | 13 ++-
 include/media/vsp1.h|  7 ++-
 9 files changed, 92 insertions(+), 17 deletions(-)

base-commit: 4df0f635a142c7498d20de9356851fb989c7f653
-- 
git-series 0.9.1

[PATCH v4 4/4] drm: rcar-du: Register a completion callback with VSP1

[Kieran Bingham]

Currently we process page flip events on every display interrupt,
however this does not take into consideration the processing time needed
by the VSP1 utilised in the pipeline.

Register a callback with the VSP driver to obtain completion events, and
track them so that we only perform page flips when the full display
pipeline has completed for the frame.

Signed-off-by: Kieran Bingham 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c |  8 ++--
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h |  1 +
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c  |  9 +
 3 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 5f0664bcd12d..345eff72f581 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -378,7 +378,7 @@ static void rcar_du_crtc_update_planes(struct rcar_du_crtc 
*rcrtc)
  * Page Flip
  */
 
-static void rcar_du_crtc_finish_page_flip(struct rcar_du_crtc *rcrtc)
+void rcar_du_crtc_finish_page_flip(struct rcar_du_crtc *rcrtc)
 {
struct drm_pending_vblank_event *event;
struct drm_device *dev = rcrtc->crtc.dev;
@@ -650,6 +650,7 @@ static const struct drm_crtc_funcs crtc_funcs = {
 static irqreturn_t rcar_du_crtc_irq(int irq, void *arg)
 {
struct rcar_du_crtc *rcrtc = arg;
+   struct rcar_du_device *rcdu = rcrtc->group->dev;
irqreturn_t ret = IRQ_NONE;
u32 status;
 
@@ -658,7 +659,10 @@ static irqreturn_t rcar_du_crtc_irq(int irq, void *arg)
 
if (status & DSSR_FRM) {
drm_crtc_handle_vblank(>crtc);
-   rcar_du_crtc_finish_page_flip(rcrtc);
+
+   if (rcdu->info->gen < 3)
+   rcar_du_crtc_finish_page_flip(rcrtc);
+
ret = IRQ_HANDLED;
}
 
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
index 15871fae7445..b199ed5adf36 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
@@ -73,5 +73,6 @@ void rcar_du_crtc_resume(struct rcar_du_crtc *rcrtc);
 
 void rcar_du_crtc_route_output(struct drm_crtc *crtc,
   enum rcar_du_output output);
+void rcar_du_crtc_finish_page_flip(struct rcar_du_crtc *rcrtc);
 
 #endif /* __RCAR_DU_CRTC_H__ */
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index b0ff304ce3dc..c7bb96fbfab1 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -28,6 +28,13 @@
 #include "rcar_du_kms.h"
 #include "rcar_du_vsp.h"
 
+static void rcar_du_vsp_complete(void *private)
+{
+   struct rcar_du_crtc *crtc = private;
+
+   rcar_du_crtc_finish_page_flip(crtc);
+}
+
 void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
 {
const struct drm_display_mode *mode = >crtc.state->adjusted_mode;
@@ -35,6 +42,8 @@ void rcar_du_vsp_enable(struct rcar_du_crtc *crtc)
struct vsp1_du_lif_config cfg = {
.width = mode->hdisplay,
.height = mode->vdisplay,
+   .callback = rcar_du_vsp_complete,
+   .callback_data = crtc,
};
struct rcar_du_plane_state state = {
.state = {
-- 
git-series 0.9.1

[PATCH v4 1/4] drm: rcar-du: Arm the page flip event after queuing the page flip

[Kieran Bingham]

From: Laurent Pinchart 

The page flip event is armed in the atomic begin handler, creating a
race condition with the frame end interrupt that could send the event
before the atomic operation actually completes. To avoid that, arm the
event in the atomic flush handler after queuing the page flip.

This change doesn't fully close the race window, as the frame end
interrupt could be generated before the page flip is committed to
hardware but only handled after the event is armed. However, the race
window is now much smaller.

Signed-off-by: Laurent Pinchart 
Reviewed-by: Kieran Bingham 
Signed-off-by: Kieran Bingham 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 4ed6f2340af0..5f0664bcd12d 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -581,17 +581,6 @@ static void rcar_du_crtc_atomic_begin(struct drm_crtc 
*crtc,
  struct drm_crtc_state *old_crtc_state)
 {
struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
-   struct drm_device *dev = rcrtc->crtc.dev;
-   unsigned long flags;
-
-   if (crtc->state->event) {
-   WARN_ON(drm_crtc_vblank_get(crtc) != 0);
-
-   spin_lock_irqsave(>event_lock, flags);
-   rcrtc->event = crtc->state->event;
-   crtc->state->event = NULL;
-   spin_unlock_irqrestore(>event_lock, flags);
-   }
 
if (rcar_du_has(rcrtc->group->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
rcar_du_vsp_atomic_begin(rcrtc);
@@ -601,9 +590,20 @@ static void rcar_du_crtc_atomic_flush(struct drm_crtc 
*crtc,
  struct drm_crtc_state *old_crtc_state)
 {
struct rcar_du_crtc *rcrtc = to_rcar_crtc(crtc);
+   struct drm_device *dev = rcrtc->crtc.dev;
+   unsigned long flags;
 
rcar_du_crtc_update_planes(rcrtc);
 
+   if (crtc->state->event) {
+   WARN_ON(drm_crtc_vblank_get(crtc) != 0);
+
+   spin_lock_irqsave(>event_lock, flags);
+   rcrtc->event = crtc->state->event;
+   crtc->state->event = NULL;
+   spin_unlock_irqrestore(>event_lock, flags);
+   }
+
if (rcar_du_has(rcrtc->group->dev, RCAR_DU_FEATURE_VSP1_SOURCE))
rcar_du_vsp_atomic_flush(rcrtc);
 }
-- 
git-series 0.9.1

[PATCH v4 2/4] v4l: vsp1: Postpone frame end handling in event of display list race

[Kieran Bingham]

If we try to commit the display list while an update is pending, we have
missed our opportunity. The display list manager will hold the commit
until the next interrupt.

In this event, we skip the pipeline completion callback handler so that
the pipeline will not mistakenly report frame completion to the user.

Signed-off-by: Kieran Bingham 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Laurent Pinchart 
---
 drivers/media/platform/vsp1/vsp1_dl.c   | 19 +--
 drivers/media/platform/vsp1/vsp1_dl.h   |  2 +-
 drivers/media/platform/vsp1/vsp1_pipe.c | 13 -
 3 files changed, 30 insertions(+), 4 deletions(-)

diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
b/drivers/media/platform/vsp1/vsp1_dl.c
index 7d8f37772b56..85fe2b4ae310 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -561,9 +561,19 @@ void vsp1_dlm_irq_display_start(struct vsp1_dl_manager 
*dlm)
spin_unlock(>lock);
 }
 
-void vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
+/**
+ * vsp1_dlm_irq_frame_end - Display list handler for the frame end interrupt
+ * @dlm: the display list manager
+ *
+ * Return true if the previous display list has completed at frame end, or 
false
+ * if it has been delayed by one frame because the display list commit raced
+ * with the frame end interrupt. The function always returns true in header 
mode
+ * as display list processing is then not continuous and races never occur.
+ */
+bool vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
 {
struct vsp1_device *vsp1 = dlm->vsp1;
+   bool completed = false;
 
spin_lock(>lock);
 
@@ -575,8 +585,10 @@ void vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
 * perform any operation as there can't be any new display list queued
 * in that case.
 */
-   if (dlm->mode == VSP1_DL_MODE_HEADER)
+   if (dlm->mode == VSP1_DL_MODE_HEADER) {
+   completed = true;
goto done;
+   }
 
/*
 * The UPD bit set indicates that the commit operation raced with the
@@ -594,6 +606,7 @@ void vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
if (dlm->queued) {
dlm->active = dlm->queued;
dlm->queued = NULL;
+   completed = true;
}
 
/*
@@ -614,6 +627,8 @@ void vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
 
 done:
spin_unlock(>lock);
+
+   return completed;
 }
 
 /* Hardware Setup */
diff --git a/drivers/media/platform/vsp1/vsp1_dl.h 
b/drivers/media/platform/vsp1/vsp1_dl.h
index 7131aa3c5978..6ec1380a10af 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.h
+++ b/drivers/media/platform/vsp1/vsp1_dl.h
@@ -28,7 +28,7 @@ struct vsp1_dl_manager *vsp1_dlm_create(struct vsp1_device 
*vsp1,
 void vsp1_dlm_destroy(struct vsp1_dl_manager *dlm);
 void vsp1_dlm_reset(struct vsp1_dl_manager *dlm);
 void vsp1_dlm_irq_display_start(struct vsp1_dl_manager *dlm);
-void vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm);
+bool vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm);
 
 struct vsp1_dl_list *vsp1_dl_list_get(struct vsp1_dl_manager *dlm);
 void vsp1_dl_list_put(struct vsp1_dl_list *dl);
diff --git a/drivers/media/platform/vsp1/vsp1_pipe.c 
b/drivers/media/platform/vsp1/vsp1_pipe.c
index edebf3fa926f..e817623b84e0 100644
--- a/drivers/media/platform/vsp1/vsp1_pipe.c
+++ b/drivers/media/platform/vsp1/vsp1_pipe.c
@@ -330,10 +330,21 @@ bool vsp1_pipeline_ready(struct vsp1_pipeline *pipe)
 
 void vsp1_pipeline_frame_end(struct vsp1_pipeline *pipe)
 {
+   bool completed;
+
if (pipe == NULL)
return;
 
-   vsp1_dlm_irq_frame_end(pipe->output->dlm);
+   completed = vsp1_dlm_irq_frame_end(pipe->output->dlm);
+   if (!completed) {
+   /*
+* If the DL commit raced with the frame end interrupt, the
+* commit ends up being postponed by one frame. Return
+* immediately without calling the pipeline's frame end handler
+* or incrementing the sequence number.
+*/
+   return;
+   }
 
if (pipe->hgo)
vsp1_hgo_frame_end(pipe->hgo);
-- 
git-series 0.9.1

Re: [PATCH V8 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error

[Geert Uytterhoeven]

Hi Sricharan, Robin,

On Wed, May 3, 2017 at 12:24 PM, Sricharan R  wrote:
> On 5/3/2017 3:24 PM, Robin Murphy wrote:
>> On 02/05/17 19:35, Geert Uytterhoeven wrote:
>>> On Fri, Feb 3, 2017 at 4:48 PM, Sricharan R  
>>> wrote:
 From: Laurent Pinchart 

 Failures to look up an IOMMU when parsing the DT iommus property need to
 be handled separately from the .of_xlate() failures to support deferred
 probing.

 The lack of a registered IOMMU can be caused by the lack of a driver for
 the IOMMU, the IOMMU device probe not having been performed yet, having
 been deferred, or having failed.

 The first case occurs when the device tree describes the bus master and
 IOMMU topology correctly but no device driver exists for the IOMMU yet
 or the device driver has not been compiled in. Return NULL, the caller
 will configure the device without an IOMMU.

 The second and third cases are handled by deferring the probe of the bus
 master device which will eventually get reprobed after the IOMMU.

 The last case is currently handled by deferring the probe of the bus
 master device as well. A mechanism to either configure the bus master
 device without an IOMMU or to fail the bus master device probe depending
 on whether the IOMMU is optional or mandatory would be a good
 enhancement.

 Tested-by: Marek Szyprowski 
 Signed-off-by: Laurent Pichart 
 Signed-off-by: Sricharan R 
>>>
>>> This patch broke Renesas R-Car Gen3 platforms in renesas-drivers.
>>> As the IOMMU nodes in DT are not yet enabled, all devices having iommus
>>> properties in DT now fail to probe.
>>
>> How exactly do they fail to probe? Per d7b0558230e4, if there are no ops
>> registered then they should merely defer until we reach the point of
>> giving up and ignoring the IOMMU. Is it just that you have no other
>> late-probing drivers or post-init module loads to kick the deferred
>> queue after that point? I did try to find a way to explicitly kick it
>> from a suitably late initcall, but there didn't seem to be any obvious
>> public interface - anyone have any suggestions?
>>
>> I think that's more of a general problem with the probe deferral
>> mechanism itself (I've seen the same thing happen with some of the
>> CoreSight stuff on Juno due to the number of inter-component
>> dependencies) rather than any specific fault of this series.

I had a deeper look into the issue.

What changed, is that of_dma_configure() now returns an error code,
and dma_configure() looks at it.

Actually there are two failure modes:
  1. Devices with an iommus property pointing to a disabled IOMMU node.
 These return -EPROBE_DEFER, and are now retried forever.
  2. Devices that are blacklisted in the IPMMU driver, as we don't want to
 use them with an IOMMU yet.
 These return -ENODEV, due to ipmmu_of_xlate_dma().

> I was thinking of an additional check like below to avoid the
> situation ?
>
> From 499b6e662f60f23740b8880882b0a16f16434501 Mon Sep 17 00:00:00 2001
> From: Sricharan R 
> Date: Wed, 3 May 2017 13:16:59 +0530
> Subject: [PATCH] iommu: of: Fix check for returning EPROBE_DEFER
>
> While returning EPROBE_DEFER for iommu masters
> take in to account of iommu nodes that could be
> marked in DT as 'status=disabled', in which case
> simply return NULL and let the master's probe
> continue rather than deferring.
>
> Signed-off-by: Sricharan R 
> ---
>  drivers/iommu/of_iommu.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index 9f44ee8..e6e9bec 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -118,6 +118,7 @@ static bool of_iommu_driver_present(struct device_node 
> *np)
>
> ops = iommu_ops_from_fwnode(fwnode);
> if ((ops && !ops->of_xlate) ||
> +   !of_device_is_available(iommu_spec->np) ||
> (!ops && !of_iommu_driver_present(iommu_spec->np)))
> return NULL;

Thanks, this fixes the first class of failures.

The second class can be worked around using:

--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -196,6 +196,11 @@ static const struct iommu_ops
ops = of_iommu_xlate(dev, _spec);
of_node_put(iommu_spec.np);
idx++;
+   if (PTR_ERR(ops) == -ENODEV) {
+   dev_info(dev, "%s: Ignoring -ENODEV => NULL\n",
+__func__);
+   return NULL;
+   }
if (IS_ERR_OR_NULL(ops))
break;
}

but obviously that's too hackish to apply...
Magnus, do you have a suggestion?

Thanks!

RE: [PATCH v5 10/10] arm: dts: genmai: Add ethernet pin group

[Chris Brandt]

On Friday, May 05, 2017, Linus Walleij wrote:
> > This is the part of the whole "DT is for hardware description only" that
> doesn't really make sense to me.
> 
> OK yeah we do hardware description AND configuration.
> 
> And we never do interpreted languages.
> 
> And then there is a bunch of grayzone things. For example we have a
> linux,input binding for connecting keypresses to certain Linux input codes.
> That is really grayzone, but very useful.

Ah

compatible = "linux,grayzone";


Thanks for the reply. I'll stop ranting now.
Of course, I'll still probably screw it up again on a future patch somehow...

Cheers

Chris

Re: [PATCH v5 10/10] arm: dts: genmai: Add ethernet pin group

[Geert Uytterhoeven]

Hi Linus,

On Fri, May 5, 2017 at 2:06 PM, Linus Walleij  wrote:
> On Fri, Apr 28, 2017 at 4:48 PM, Chris Brandt  
> wrote:
>
> I think this was written by me, not Geert...
>
>>> DT describes hardware, not software limitations.

Na, I did write it.

I can understand you sometimes mix up things, esp. when you're
enjoying LLC ;-)

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v4 0/7] Add V4L2 SDR (DRIF & MAX2175) driver

[Hans Verkuil]

Hi Ramesh,

Looks good. I replied to patch 3/7 requesting a small change, but otherwise
I'm OK.

The only thing missing is an Ack from Rob for patch 6/7 (R-car DRIF bindings).

Once I have that + an updated patch 3/7 I can make a pull request for this.

Regards,

Hans

On 05/02/17 15:26, Ramesh Shanmugasundaram wrote:
> Hi Media, DT maintainers, All,
> 
> This patch set contains two drivers
>  - Renesas R-Car Digital Radio Interface (DRIF) driver
>  - Maxim's MAX2175 RF to Bits tuner driver
> 
> These patches were based on top of media-next repo
> commit:6d95b3f24881c0fd0f345eca959a2a803a040930
> 
> These two drivers combined together expose a V4L2 SDR device that is 
> compliant with the V4L2 framework [1]. Agreed review comments are 
> incorporated in this series.
> 
> The rcar_drif device is modelled using "renesas,bonding" property. The 
> discussion on this property is available here [2].
> 
> Change history:
> 
> v3 -> v4:
>  - Added ACKs
> rcar_drif:
>  - Incorporated a number of review comments from Laurent on DRIF driver.
>  - Addressed comments from Rob and Laurent on bindings.
> max2175:
>  - Minor changes addressing Hans and Laurent's comments
> 
> v2 -> v3:
> rcar_drif:
>  - Reduced DRIF DT properties to expose tested I2S mode only (Hans - 
> discussion on #v4l)
>  - Fixed error path clean up of ctrl_hdl on rcar_drif
> 
> v1 -> v2:
>  - SDR formats renamed as "planar" instead of sliced (Hans)
>  - Documentation formatting correction (Laurent)
> 
>  rcar_drif:
>  - DT model using "bonding" property
>  - Addressed Laurent's coments on bindings - DT optional parameters rename & 
> rework
>  - Addressed Han's comments on driver
>  - Addressed Geert's comments on DT
> 
>  max2175:
>  - Avoided scaling using method proposed by Antti. Thanks
>  - Bindings is a separate patch (Rob)
>  - Addressed Rob's comment on bindings
>  - Added Custom controls documentation (Laurent)
> 
> [1] v4l2-compliance report:
> root@salvator-x:~# v4l2-compliance -S /dev/swradio0
> v4l2-compliance SHA   : b514d615166bdc0901a4c71261b87db31e89f464
> 
> Driver Info:
> Driver name   : rcar_drif
> Card type : R-Car DRIF
> Bus info  : platform:R-Car DRIF
> Driver version: 4.11.0
> Capabilities  : 0x8531
> SDR Capture
> Tuner
> Read/Write
> Streaming
> Extended Pix Format
> Device Capabilities
> Device Caps   : 0x0531
> SDR Capture
> Tuner
> Read/Write
> Streaming
> Extended Pix Format
> 
> Compliance test for device /dev/swradio0 (not using libv4l2):
> 
> Required ioctls:
> test VIDIOC_QUERYCAP: OK
> 
> Allow for multiple opens:
> test second sdr open: OK
> test VIDIOC_QUERYCAP: OK
> test VIDIOC_G/S_PRIORITY: OK
> test for unlimited opens: OK
> 
> Debug ioctls:
> test VIDIOC_DBG_G/S_REGISTER: OK
> test VIDIOC_LOG_STATUS: OK
> 
> Input ioctls:
> test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK
> test VIDIOC_G/S_FREQUENCY: OK
> test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
> test VIDIOC_ENUMAUDIO: OK (Not Supported)
> test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
> test VIDIOC_G/S_AUDIO: OK (Not Supported)
> Inputs: 0 Audio Inputs: 0 Tuners: 1
> 
> Output ioctls:
> test VIDIOC_G/S_MODULATOR: OK (Not Supported)
> test VIDIOC_G/S_FREQUENCY: OK
> test VIDIOC_ENUMAUDOUT: OK (Not Supported)
> test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
> test VIDIOC_G/S_AUDOUT: OK (Not Supported)
> Outputs: 0 Audio Outputs: 0 Modulators: 0
> 
> Input/Output configuration ioctls:
> test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
> test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
> test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
> test VIDIOC_G/S_EDID: OK (Not Supported)
> 
> Control ioctls:
> test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
> test VIDIOC_QUERYCTRL: OK
> test VIDIOC_G/S_CTRL: OK
> test VIDIOC_G/S/TRY_EXT_CTRLS: OK
> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
> test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> Standard Controls: 5 Private Controls: 3
> 
> Format ioctls:
> test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
> test VIDIOC_G/S_PARM: OK (Not Supported)
> test VIDIOC_G_FBUF: OK (Not Supported)
> test VIDIOC_G_FMT: OK
> test VIDIOC_TRY_FMT: OK
> test VIDIOC_S_FMT: OK
> test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
> test Cropping: OK (Not Supported)
> test Composing: OK (Not Supported)
> test Scaling: OK (Not 

Re: [PATCH v4 3/7] media: i2c: max2175: Add MAX2175 support

[Hans Verkuil]

On 05/02/17 15:26, Ramesh Shanmugasundaram wrote:
> This patch adds driver support for the MAX2175 chip. This is Maxim
> Integrated's RF to Bits tuner front end chip designed for software-defined
> radio solutions. This driver exposes the tuner as a sub-device instance
> with standard and custom controls to configure the device.
> 
> Signed-off-by: Ramesh Shanmugasundaram 
> 
> ---
> v4:
>  - Addressed v4l2_ctrl name string convention (Hans)
>   - "HSLS above/below" to "HSLS Above/Below"
>   - "RX MODE" to "RX Mode"
> ---
>  Documentation/media/v4l-drivers/index.rst   |1 +
>  Documentation/media/v4l-drivers/max2175.rst |   60 ++
>  drivers/media/i2c/Kconfig   |4 +
>  drivers/media/i2c/Makefile  |2 +
>  drivers/media/i2c/max2175/Kconfig   |8 +
>  drivers/media/i2c/max2175/Makefile  |4 +
>  drivers/media/i2c/max2175/max2175.c | 1437 
> +++
>  drivers/media/i2c/max2175/max2175.h |  108 ++
>  8 files changed, 1624 insertions(+)
>  create mode 100644 Documentation/media/v4l-drivers/max2175.rst
>  create mode 100644 drivers/media/i2c/max2175/Kconfig
>  create mode 100644 drivers/media/i2c/max2175/Makefile
>  create mode 100644 drivers/media/i2c/max2175/max2175.c
>  create mode 100644 drivers/media/i2c/max2175/max2175.h
> 
> diff --git a/Documentation/media/v4l-drivers/index.rst 
> b/Documentation/media/v4l-drivers/index.rst
> index a606d1cdac13..d8cade53d496 100644
> --- a/Documentation/media/v4l-drivers/index.rst
> +++ b/Documentation/media/v4l-drivers/index.rst
> @@ -42,6 +42,7 @@ For more details see the file COPYING in the source 
> distribution of Linux.
>   davinci-vpbe
>   fimc
>   ivtv
> +max2175
>   meye
>   omap3isp
>   omap4_camera
> diff --git a/Documentation/media/v4l-drivers/max2175.rst 
> b/Documentation/media/v4l-drivers/max2175.rst
> new file mode 100644
> index ..201af8f217e9
> --- /dev/null
> +++ b/Documentation/media/v4l-drivers/max2175.rst
> @@ -0,0 +1,60 @@
> +Maxim Integrated MAX2175 RF to bits tuner driver
> +
> +
> +The MAX2175 driver implements the following driver-specific controls:
> +
> +``V4L2_CID_MAX2175_I2S_ENABLE``
> +---
> +Enable/Disable I2S output of the tuner.
> +
> +.. flat-table::
> +:header-rows:  0
> +:stub-columns: 0
> +:widths:   1 4
> +
> +* - ``(0)``
> +  - I2S output is disabled.
> +* - ``(1)``
> +  - I2S output is enabled.
> +
> +``V4L2_CID_MAX2175_HSLS``
> +-
> +The high-side/low-side (HSLS) control of the tuner for a given band.
> +
> +.. flat-table::
> +:header-rows:  0
> +:stub-columns: 0
> +:widths:   1 4
> +
> +* - ``(0)``
> +  - The LO frequency position is below the desired frequency.
> +* - ``(1)``
> +  - The LO frequency position is above the desired frequency.
> +
> +``V4L2_CID_MAX2175_RX_MODE (menu)``
> +---
> +The Rx mode controls a number of preset parameters of the tuner like sck

'sck' is short of 'sample clock' or something like that? I recommend that you
write this in full at least once in this documentation.

> +rate, sampling rate etc. These multiple settings are provided under one
> +single label called Rx mode in the datasheet. The list below shows the
> +supported modes with a brief description.
> +
> +.. flat-table::
> +:header-rows:  0
> +:stub-columns: 0
> +:widths:   1 4
> +
> +* - ``"Europe modes"``
> +* - ``"FM 1.2" (0)``
> +  - This configures FM band with a sample rate of 0.512 million
> +samples/sec with a 10.24 MHz sck.
> +* - ``"DAB 1.2" (1)``
> +  - This configures VHF band with a sample rate of 2.048 million
> +samples/sec with a 32.768 MHz sck.
> +
> +* - ``"North America modes"``
> +* - ``"FM 1.0" (0)``
> +  - This configures FM band with a sample rate of 0.7441875 million
> +samples/sec with a 14.88375 MHz sck.
> +* - ``"DAB 1.2" (1)``
> +  - This configures FM band with a sample rate of 0.372 million
> +samples/sec with a 7.441875 MHz sck.

Regards,

Hans

Re: [PATCH v3 4/6] spi: sh-msiof: Add slave mode support

[Geert Uytterhoeven]

On Thu, May 4, 2017 at 7:45 PM, Geert Uytterhoeven
 wrote:
> From: Hisashi Nakamura 
>
> Add slave mode support to the MSIOF driver, in both PIO and DMA mode.
>
> For now this only supports the transmission of messages with a size
> that is known in advance.
>
> Signed-off-by: Hisashi Nakamura 
> Signed-off-by: Hiromitsu Yamasaki 
> [geert: Timeout handling cleanup, spi core integration, cancellation,
> rewording]
> Signed-off-by: Geert Uytterhoeven 

> index 2ce15ca977828668..7c4e8c4f3a9bddfd 100644
> --- a/drivers/spi/spi-sh-msiof.c
> +++ b/drivers/spi/spi-sh-msiof.c

> +static int sh_msiof_slave_abort(struct spi_master *master)
> +{
> +   struct sh_msiof_spi_priv *p = spi_master_get_devdata(master);
> +   unsigned long flags;
> +
> +   spin_lock_irqsave(>done.wait.lock, flags);
> +   if (!p->done.done) {
> +   wait_queue_t *curr, *next;
> +
> +   list_for_each_entry_safe(curr, next, >done.wait.task_list,
> +task_list) {
> +   signal_wake_up(curr->private, 1);

0day reported a build failure in the modular case (thanks!):

ERROR: "signal_wake_up_state" [drivers/spi/spi-sh-msiof.ko] undefined!

signal_wake_up() is a static inline function calling signal_wake_up_state(),
but the latter is not exported to modules.

I'll bring it up with the scheduler people...

> +   break;
> +   }
> +   }
> +   spin_unlock_irqrestore(>done.wait.lock, flags);
> +   return 0;
> +}

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds