Re: [PATCH v13 00/33] rcar-vin: Add Gen3 with media controller

Hi Hans, On 2018-04-04 12:28:30 +0200, Hans Verkuil wrote: > Hi Niklas, > > It might be a good idea if you can rebase the patch series on the latest > master (we've just synced to Linus' master tree) and incorporate the few > comments that Laurent had. I have now rebased this and incorporate

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

On Thu, Apr 5, 2018 at 1:53 PM, Laurent Pinchart wrote: > Hi Rob, > > On Thursday, 5 April 2018 19:33:33 EEST Rob Herring wrote: >> On Mon, Apr 2, 2018 at 8:36 AM, Laurent Pinchart wrote: >> > On Tuesday, 27 March 2018 14:03:25 EEST Vladimir Zapolskiy wrote: >>

Re: [PATCH v13 16/33] rcar-vin: simplify how formats are set and reset

Hi Laurent, Thanks for your feedback. I have incorporated your suggestions for the next and hopefully last version of this patch-set, a few followups on your review bellow. On 2018-04-04 01:09:29 +0300, Laurent Pinchart wrote: > Hi Niklas, > > Thank you for the patch. > > On Tuesday, 27

Re: [PATCH v13 2/2] rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver

Hi Niklas, thanks for the VIN and CSI-2 effort! On Tue, Feb 13, 2018 at 12:01:32AM +0100, Niklas Söderlund wrote: > A V4L2 driver for Renesas R-Car MIPI CSI-2 receiver. The driver > supports the R-Car Gen3 SoCs where separate CSI-2 hardware blocks are > connected between the video sources

RE: [PATCH] gpio: dwapb: Add support for 32 interrupts

Hi Andy, On 30 March 2018 22:26 Andy Shevchenko wrote: > On Wed, Mar 28, 2018 at 5:22 PM, Phil Edworthy wrote: > > The DesignWare GPIO IP can be configured for either 1 or 32 > > interrupts, > > 1 to 32, or just a choice between two? Just a choice of 1 or 32. Note that by 'configured' I am

Re: [PATCH] dt-bindings: irqchip: renesas-irqc: Document r8a77470 support

On 29/03/18 11:17, Biju Das wrote: > Renesas RZ/G SoC have the R-Car gen2 compatible IRQC interrupt > controllers. Document RZ/G1C (also known as R8A77470) SoC bindings. > > Signed-off-by: Biju Das > Reviewed-by: Fabrizio Castro > --- >

[PATCH v2 15/15] v4l: vsp1: Rename BRU to BRx

Some VSP instances have two blending units named BRU (Blend/ROP Unit) and BRS (Blend/ROP Sub unit). The BRS is a smaller version of the BRU with only two inputs, but otherwise offers similar features and offers the same register interface. The BRU and BRS can be used exchangeably in VSP pipelines

[PATCH v2 10/15] v4l: vsp1: Turn frame end completion status into a bitfield

We will soon need to return more than a boolean completion status from the vsp1_dlm_irq_frame_end() IRQ handler. Turn the return value into a bitfield to prepare for that. No functional change is introduced here. Signed-off-by: Laurent Pinchart ---

[PATCH v2 09/15] v4l: vsp1: Move DRM pipeline output setup code to a function

In order to make the vsp1_du_setup_lif() easier to read, and for symmetry with the DRM pipeline input setup, move the pipeline output setup code to a separate function. Signed-off-by: Laurent Pinchart Reviewed-by: Kieran Bingham

[PATCH v2 13/15] v4l: vsp1: Assign BRU and BRS to pipelines dynamically

The VSPDL variant drives two DU channels through two LIF and two blenders, BRU and BRS. The DU channels thus share the five available VSPDL inputs and expose them as five KMS planes. The current implementation assigns the BRS to the second LIF and thus artificially limits the number of planes for

[PATCH v2 12/15] v4l: vsp1: Generalize detection of entity removal from DRM pipeline

When disabling a DRM plane, the corresponding RPF is only marked as removed from the pipeline in the atomic update handler, with the actual removal happening when configuring the pipeline at atomic commit time. This is required as the RPF has to be disabled in the hardware, which can't be done

[PATCH v2 06/15] v4l: vsp1: Move DRM atomic commit pipeline setup to separate function

The DRM pipeline setup code used at atomic commit time is similar to the setup code used when enabling the pipeline. Move it to a separate function in order to share it. Signed-off-by: Laurent Pinchart Reviewed-by: Kieran Bingham

[PATCH v2 02/15] v4l: vsp1: Remove unused field from vsp1_drm_pipeline structure

The vsp1_drm_pipeline enabled field is set but never used. Remove it. Signed-off-by: Laurent Pinchart Reviewed-by: Kieran Bingham --- drivers/media/platform/vsp1/vsp1_drm.c | 4

[PATCH v2 04/15] v4l: vsp1: Use vsp1_entity.pipe to check if entity belongs to a pipeline

The DRM pipeline handling code uses the entity's pipe list head to check whether the entity is already included in a pipeline. This method is a bit fragile in the sense that it uses list_empty() on a list_head that is a list member. Replace it by a simpler check for the entity pipe pointer.

[PATCH v2 07/15] v4l: vsp1: Setup BRU at atomic commit time

To implement fully dynamic plane assignment to pipelines, we need to reassign the BRU and BRS to the DRM pipelines in the atomic commit handler. In preparation for this setup factor out the BRU source pad code and call it both at LIF setup and atomic commit time. Signed-off-by: Laurent Pinchart

[PATCH v2 01/15] v4l: vsp1: Don't start/stop media pipeline for DRM

The DRM support code manages a pipeline of VSP entities, each backed by a media entity. When starting or stopping the pipeline, it starts and stops the media pipeline through the media API in order to store the pipeline pointer in every entity. The driver doesn't use the pipe pointer in media

[PATCH v2 14/15] v4l: vsp1: Add BRx dynamic assignment debugging messages

Dynamic assignment of the BRU and BRS to pipelines is prone to regressions, add messages to make debugging easier. Keep it as a separate commit to ease removal of those messages once the code will deem to be completely stable. Signed-off-by: Laurent Pinchart

[PATCH v2 03/15] v4l: vsp1: Store pipeline pointer in vsp1_entity

Various types of objects subclassing vsp1_entity currently store a pointer to the pipeline. Move the pointer to vsp1_entity to simplify the code and avoid storing the pipeline in more entity subclasses later. Signed-off-by: Laurent Pinchart Reviewed-by:

[PATCH v2 08/15] v4l: vsp1: Replace manual DRM pipeline input setup in vsp1_du_setup_lif

The vsp1_du_setup_lif() function sets up the DRM pipeline input manually. This duplicates the code from the vsp1_du_pipeline_setup_input() function. Replace the manual implementation by a call to the function. As the pipeline has no enabled input in vsp1_du_setup_lif(), the

[PATCH v2 00/15] R-Car VSP1: Dynamically assign blend units to display pipelines

the expertise of the DRM/KMS community from that point of view. The patches are based on top of the latest Linux media master branch. For convenience their are available from git://linuxtv.org/pinchartl/media.git v4l2-vsp1-bru-brs-v2-20180405 The series passes the DU test suite with the new

[PATCH v2 05/15] v4l: vsp1: Share duplicated DRM pipeline configuration code

Move the duplicated DRM pipeline configuration code to a function and call it from vsp1_du_setup_lif() and vsp1_du_atomic_flush(). Signed-off-by: Laurent Pinchart Reviewed-by: Kieran Bingham ---

[PATCH v2 11/15] v4l: vsp1: Add per-display list internal completion notification support

Display list completion is already reported to the frame end handler, but that mechanism is global to all display lists. In order to implement BRU and BRS reassignment in DRM pipelines we will need to commit a display list and wait for its completion internally, without reporting it to the DRM

Re: [RFC PATCH] mmc: renesas_sdhi_internal_dmac: limit DMA RX for old SoCs

On 4 April 2018 at 18:45, Wolfram Sang wrote: > From: Wolfram Sang > > Early revisions of certain SoCs cannot do multiple DMA RX streams in > parallel. To avoid data corruption, only allow one DMA RX channel and > fall back to PIO, if needed.

Re: [PATCH v13 2/2] rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver

On Wed, Apr 4, 2018 at 5:26 PM, Laurent Pinchart wrote: > On Thursday, 29 March 2018 14:30:39 EEST Maxime Ripard wrote: >> On Tue, Feb 13, 2018 at 12:01:32AM +0100, Niklas Söderlund wrote: >> > + switch (priv->lanes) { >> > + case 1: >> > + phycnt

Re: [RFC PATCH] mmc: renesas_sdhi_internal_dmac: fall back to PIO if scatterlist doesn't match

On 4 April 2018 at 19:00, Wolfram Sang wrote: > From: Wolfram Sang > > If we detect an incompatible scatterlist, we should fall back to PIO, > too. > > Signed-off-by: Wolfram Sang > --- > > I found this

Re: [PATCH v13 2/2] rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver

Hi Geert, On Thursday, 5 April 2018 10:33:55 EEST Geert Uytterhoeven wrote: > On Wed, Apr 4, 2018 at 5:26 PM, Laurent Pinchart wrote: > > On Thursday, 29 March 2018 14:30:39 EEST Maxime Ripard wrote: > >> On Tue, Feb 13, 2018 at 12:01:32AM +0100, Niklas Söderlund wrote: > >> > + switch

Re: [PATCH 11/15] v4l: vsp1: Add per-display list completion notification support

Hi Laurent, On 04/04/18 22:43, Laurent Pinchart wrote: > Hi Kieran, > > On Wednesday, 4 April 2018 19:16:46 EEST Kieran Bingham wrote: >> On 26/02/18 21:45, Laurent Pinchart wrote: >>> >>> -void vsp1_dl_list_commit(struct vsp1_dl_list *dl) >>> +void vsp1_dl_list_commit(struct vsp1_dl_list

Re: [PATCH v3 0/2] mmc: renesas_sdhi: add eMMC HS400 mode support

On 27 March 2018 at 13:12, Simon Horman wrote: > On Tue, Feb 27, 2018 at 02:02:23PM +0100, Wolfram Sang wrote: >> >> > Perhaps someone need to explain in more detail what the HW controller >> > needs to manage tuning for HS400? I don't like that we may end up >> > getting it

Re: [PATCH v13 2/2] rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver

A few corrections, On Thu, Apr 05, 2018 at 11:10:01AM +0200, jacopo mondi wrote: > Hi Niklas, > thanks for the VIN and CSI-2 effort! > > On Tue, Feb 13, 2018 at 12:01:32AM +0100, Niklas Söderlund wrote: > > A V4L2 driver for Renesas R-Car MIPI CSI-2 receiver. The driver > > supports the

Re: [RFC PATCH] mmc: renesas_sdhi_internal_dmac: fall back to PIO if scatterlist doesn't match

> > - /* This DMAC cannot handle if sg_len is not 1 */ > > - WARN_ON(host->sg_len > 1); > > - > > - /* This DMAC cannot handle if buffer is not 8-bytes alignment */ > > - if (!IS_ALIGNED(sg->offset, 8)) > > + if (WARN_ON(host->sg_len > 1) || !IS_ALIGNED(sg->offset,

Re: [RFC PATCH] mmc: renesas_sdhi_internal_dmac: limit DMA RX for old SoCs

> > Shimoda-san: what do you think of this approach? Please note that I didn't > > remove the 'revision' from the whitelist yet. This will be done > > incrementally. > > I thought to first fix the data corruption issue. > > I assume this is material for stable as well, right? Yes. But I'd like

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

On Mon, Apr 2, 2018 at 8:36 AM, Laurent Pinchart wrote: > Hi Vladimir, > > On Tuesday, 27 March 2018 14:03:25 EEST Vladimir Zapolskiy wrote: >> On 03/27/2018 01:10 PM, jacopo mondi wrote: >> > On Tue, Mar 27, 2018 at 12:37:31PM +0300, Vladimir Zapolskiy wrote:

[RFC PATCH] mmc: renesas_sdhi_internal_dmac: use more generic whitelisting

From: Wolfram Sang Whitelisting every ES version does not scale. So, we whitelist whole SoCs independent of ES version. If we need specific handling for an ES version, we put it to the front, so it will be matched first. Signed-off-by: Wolfram Sang

[PATCH] pwm: rcar: simplify getting .drvdata

We should get drvdata from struct device directly. Going via platform_device is an unneeded step back and forth. Signed-off-by: Wolfram Sang --- Only build tested. Fixed numerous times in other drivers, however... drivers/pwm/pwm-rcar.c | 3 +-- 1 file

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

Hi Rob, On Thursday, 5 April 2018 19:33:33 EEST Rob Herring wrote: > On Mon, Apr 2, 2018 at 8:36 AM, Laurent Pinchart wrote: > > On Tuesday, 27 March 2018 14:03:25 EEST Vladimir Zapolskiy wrote: > >> On 03/27/2018 01:10 PM, jacopo mondi wrote: > >>> On Tue, Mar 27, 2018 at 12:37:31PM +0300,