[PATCH v6 7/9] v4l: vsp1: Adapt entities to configure into a body

Currently the entities store their configurations into a display list. Adapt this such that the code can be configured into a body directly, allowing greater flexibility and control of the content. All users of vsp1_dl_list_write() are removed in this process, thus it too is removed. A helper,

[PATCH v6 6/9] v4l: vsp1: Refactor display list configure operations

The entities provide a single .configure operation which configures the object into the target display list, based on the vsp1_entity_params selection. This restricts us to a single function prototype for both static configuration (the pre-stream INIT stage) and the dynamic runtime stages for

[PATCH v6 2/9] v4l: vsp1: Protect bodies against overflow

The body write function relies on the code never asking it to write more than the entries available in the list. Currently with each list body containing 256 entries, this is fine, but we can reduce this number greatly saving memory. In preparation of this add a level of protection to catch any

[PATCH v6 1/9] v4l: vsp1: Reword uses of 'fragment' as 'body'

Throughout the codebase, the term 'fragment' is used to represent a display list body. This term duplicates the 'body' which is already in use. The datasheet references these objects as a body, therefore replace all mentions of a fragment with a body, along with the corresponding pluralised

[PATCH v6 8/9] v4l: vsp1: Move video configuration to a cached dlb

We are now able to configure a pipeline directly into a local display list body. Take advantage of this fact, and create a cacheable body to store the configuration of the pipeline in the video object. vsp1_video_pipeline_run() is now the last user of the pipe->dl object. Convert this function to

[PATCH v6 5/9] v4l: vsp1: Use reference counting for bodies

Extend the display list body with a reference count, allowing bodies to be kept as long as a reference is maintained. This provides the ability to keep a cached copy of bodies which will not change, so that they can be re-applied to multiple display lists. Signed-off-by: Kieran Bingham

[PATCH v6 3/9] v4l: vsp1: Provide a body pool

Each display list allocates a body to store register values in a dma accessible buffer from a dma_alloc_wc() allocation. Each of these results in an entry in the TLB, and a large number of display list allocations adds pressure to this resource. Reduce TLB pressure on the IPMMUs by allocating

[PATCH v6 4/9] v4l: vsp1: Convert display lists to use new body pool

Adapt the dl->body0 object to use an object from the body pool. This greatly reduces the pressure on the TLB for IPMMU use cases, as all of the lists use a single allocation for the main body. The CLU and LUT objects pre-allocate a pool containing three bodies, allowing a userspace update before

[PATCH v6 0/9] vsp1: TLB optimisation and DL caching

Each display list currently allocates an area of DMA memory to store register settings for the VSP1 to process. Each of these allocations adds pressure to the IPMMU TLB entries. We can reduce the pressure by pre-allocating larger areas and dividing the area across multiple bodies represented as a

[PATCH v6 9/9] v4l: vsp1: Reduce display list body size

The display list originally allocated a body of 256 entries to store all of the register lists required for each frame. This has now been separated into fragments for constant stream setup, and runtime updates. Empirical testing shows that the body0 now uses a maximum of 41 registers for each

Re: [PATCH v2 5/8] v4l: vsp1: Refactor display list configure operations

Hi Kieran, On Wednesday, 28 February 2018 18:41:31 EET Kieran Bingham wrote: > Hi Laurent, > > This series has a pending question below: > > On 17/11/17 15:07, Kieran Bingham wrote: > > Hi Laurent, > > > > Just a query on your bikeshedding here. > > > > Choose your colours wisely :) > > > >

Re: [RFC][PATCH 04/11] drm: Split the display info into static and dynamic parts

On Tue, Feb 27, 2018 at 7:56 AM, Ville Syrjala wrote: > From: Ville Syrjälä > > Currently we have a mix of static and dynamic information stored in > the display info structure. That makes it rather difficult to repopulate > the

Re: [PATCH v5 12/26] watchdog: renesas_wdt: Add R-Car Gen2 support

Hi Fabrizio, On Mon, Feb 12, 2018 at 6:44 PM, Fabrizio Castro wrote: > Due to commits: > * "ARM: shmobile: Add watchdog support", > * "ARM: shmobile: rcar-gen2: Add watchdog support", and > * "soc: renesas: rcar-rst: Enable watchdog as reset trigger for Gen2", >

RCar-H3-ES2.0: v4.16-rc1 (media tree) __handle_irq_event_percpu page fault

Hi Linux-ARM / Linux-Renesas-SoC I had this page fault occur once, during testing of my current series. It occurred once, and hasn't happened since, so perhaps just the direction the wind was blowing. Posting to see if there is a known regression - or if anyone else has hit similar, or so that

[PATCH] media: renesas-ceu: mark PM functions as __maybe_unused

The PM runtime operations are unused when CONFIG_PM is disabled, leading to a harmless warning: drivers/media/platform/renesas-ceu.c:1003:12: error: 'ceu_runtime_suspend' defined but not used [-Werror=unused-function] static int ceu_runtime_suspend(struct device *dev)

RE: [PATCH] dmaengine: rcar-dmac: Check the done lists in rcar_dmac_chan_get_residue()

Hi Vinod, Would you review this patch? Or, should I rebase this on the latest your repo? Best regards, Yoshihiro Shimoda > -Original Message- > From: Yoshihiro Shimoda > Sent: Friday, February 2, 2018 7:05 PM > To: vinod.k...@intel.com > Cc: dmaeng...@vger.kernel.org;

Re: [GIT PULL FOR renesas-drivers] d3/i2c-conflict/drm

Hi Kieran, On Thu, Feb 15, 2018 at 7:35 PM, Kieran Bingham wrote: > Please consider including this branch in renesas-drivers. > > -- > Regards > > Kieran > > The following changes since commit 94fc27ac487a80daf42f97b1a0503d029f3c1325: > > Merge tag

Re: [GIT PULL FOR renesas-drivers] d3/i2c-conflict/media

Hi Kieran, On Thu, Feb 15, 2018 at 7:35 PM, Kieran Bingham wrote: > Please consider including this branch in renesas-drivers. > > -- > Regards > > Kieran > > The following changes since commit 29422737017b866d4a51014cc7522fa3a99e8852: > > media: rc: get start time just

Re: [PATCH v2 0/5] Add R8A77970/V3MSK LVDS/HDMI support

On Tue, Feb 27, 2018 at 11:23:39PM +0300, Sergei Shtylyov wrote: > On 02/27/2018 11:06 PM, Sergei Shtylyov wrote: > > > Here's the set of 5 patches against Simon Horman's 'renesas.git' repo's > > 'renesas-devel-20180227-v4.16-rc3' tag. We're adding the R8A77970 > > FCPVD/VSPD/ > > DU/LVDS device

Re: [PATCH v5 01/26] ARM: shmobile: Add watchdog support

Hi Fabrizio, On Mon, Feb 12, 2018 at 6:44 PM, Fabrizio Castro wrote: > On R-Car Gen2 and RZ/G1 platforms, we use the SBAR registers to make non > boot CPUs run a routine designed to bring up SMP and deal with hot plug. > The value contained in the SBAR registers

Re: [RFC][PATCH 04/11] drm: Split the display info into static and dynamic parts

for I915: Acked-by: Shashank Sharma Regards Shashank On 2/27/2018 6:26 PM, Ville Syrjala wrote: From: Ville Syrjälä Currently we have a mix of static and dynamic information stored in the display info structure. That makes it rather

[PATCH] ARM: shmobile: rcar-gen2: Fix error check in regulator quirk

On systems with two regulators, a bogus error message is printed on success: i2c 6-0058: i2c error 2 While adding support for Stout, the number of messages to send was made variable, but the corresponding return value check of i2c_transfer() wasn't updated. Fixes: ff938cd14d67a704 ("ARM:

Re: [RFC][PATCH 04/11] drm: Split the display info into static and dynamic parts

On 27.02.2018 13:56, Ville Syrjala wrote: > From: Ville Syrjälä > > Currently we have a mix of static and dynamic information stored in > the display info structure. That makes it rather difficult to repopulate > the dynamic parts when a new EDID appears. Let's

Re: [RFC][PATCH] ARM: shmobile: Rework the PMIC IRQ line quirk

Hi Marek, On Mon, Feb 26, 2018 at 11:17 AM, Marek Vasut wrote: > Rather than hard-coding the quirk topology, which stopped scaling, > parse the information from DT. The code looks for all compatible > PMICs -- da9036 and da9210 -- and checks if their IRQ line is tied > to

Re: [PATCH 2/4] dt-bindings: arm: Document Renesas V3MSK and Wheat board part numbers

Hi Sergei, On Wed, Feb 28, 2018 at 8:38 AM, Sergei Shtylyov wrote: > On 2/28/2018 9:49 AM, Simon Horman wrote: >> --- a/Documentation/devicetree/bindings/arm/shmobile.txt >> +++ b/Documentation/devicetree/bindings/arm/shmobile.txt >> @@ -120,9 +120,9 @@

renesas-drivers-2018-02-28-v4.16-rc3

I have pushed renesas-drivers-2018-02-28-v4.16-rc3 to https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git This tree is meant to ease development of platform support and drivers for Renesas ARM SoCs. It is created by merging (a) the for-next branches of various subsystem trees

Re: [PATCH v2 5/8] v4l: vsp1: Refactor display list configure operations

Hi Laurent, This series has a pending question below: On 17/11/17 15:07, Kieran Bingham wrote: > Hi Laurent, > > Just a query on your bikeshedding here. > > Choose your colours wisely :) > > -- > Kieran > > On 12/09/17 20:19, Laurent Pinchart wrote: >> Hi Kieran, >> >> On Tuesday, 12

RE: [PATCH v5 01/26] ARM: shmobile: Add watchdog support

Hi Geert, thank you for your feedback! > Subject: Re: [PATCH v5 01/26] ARM: shmobile: Add watchdog support > > Hi Fabrizio, > > On Mon, Feb 12, 2018 at 6:44 PM, Fabrizio Castro > wrote: > > On R-Car Gen2 and RZ/G1 platforms, we use the SBAR registers to make non

[PATCH v6 01/26] ARM: shmobile: Add watchdog support

On R-Car Gen2 and RZ/G1 platforms, we use the SBAR registers to make non boot CPUs run a routine designed to bring up SMP and deal with hot plug. The value contained in the SBAR registers is not initialized by a WDT triggered reset, which means that after a WDT triggered reset we jump to the SMP

RE: [PATCH] watchdog: renesas_wdt: Blacklist early R-Car Gen2 SoCs

> Subject: [PATCH] watchdog: renesas_wdt: Blacklist early R-Car Gen2 SoCs > > On early revisions of some R-Car Gen2 SoCs, and depending on SMP > configuration, the system may fail to restart on watchdog time-out, and > lock up instead. > > Specifically: > - On R-Car H2 ES1.0 and M2-W ES1.0,

Re: [PATCH v2 0/5] Add R8A77970/V3MSK LVDS/HDMI support

On 02/28/2018 04:27 PM, Simon Horman wrote: >>> Here's the set of 5 patches against Simon Horman's 'renesas.git' repo's >>> 'renesas-devel-20180227-v4.16-rc3' tag. We're adding the R8A77970 >>> FCPVD/VSPD/ >>> DU/LVDS device nodes and then describing the HDMI encoder connected to the >>> LVDS