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; linux-renesas-soc@v
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)
^~~
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 dynamic parts when a new EDID appears. Let's make life easier by
> s
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 :)
> >
> > O
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
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 mult
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 t
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 terms.
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
---
This
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
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 fra
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 bu
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, vs
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 both
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 it
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",
> we now have everything we needed f
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
>>
> 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, watch
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 br
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
> > boot CPUs run a routine desig
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 Septembe
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 an
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
On Wed, Feb 28, 2018 at 10:13:00AM +0100, Geert Uytterhoeven wrote:
> 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
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 is not initialized by a WDT
> trig
On Mon, Feb 26, 2018 at 9:54 PM, Sergei Shtylyov
wrote:
> Define the generic R8A77970 parts of the I2C[0-4] device node.
>
> Based on the original (and large) patch by Daisuke Matsushita
> .
>
> Signed-off-by: Vladimir Barinov
> Signed-off-by: Sergei Shtylyov
>
> ---
> Changes in version 2:
> -
On Mon, Feb 26, 2018 at 9:55 PM, Sergei Shtylyov
wrote:
> Define the Eagle board dependent part of the I2C0 device node.
>
> The I2C0 bus is populated by ON Semiconductor PCA9653 I/O expander and
> Analog Devices ADV7511W HDMI transmitter (but we're only describing the
> former chip now).
>
> Base
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 make life easier by
> splitting the
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: shm
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 difficult to repopulate
the dynamic parts when a new EDID ap
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 the same pin. If so, the
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 @@ Boards:
>> compatible = "renesas,sk-r
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 'drm-intel-next-fixes-2018-02-07' of
> git://
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 before calling driver tx
34 matches
Mail list logo