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 wh
To be able to perform page flips in DRM without flicker we need to be
able to notify the rcar-du module when the VSP has completed its
processing.
We must not have bidirectional dependencies on the two components to
maintain support for loadable modules, thus we extend the API to allow
a callback
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 inform the vsp1 completion callback handler so that
the du will not perform a page flip out of turn.
Signed-of
The RCAR-DU utilises a running VSPD pipeline to perform processing
for the display pipeline.
Changes to this pipeline are performed with an atomic flush operation which
updates the state in the VSPD. Due to the way the running pipeline is
operated, any flush operation has an implicit latency of on
The driver is already made of 5 separate source files. Move it to a
newly created directory named synopsys where more Synopsys bridge
drivers can be added later (for the DisplayPort controller for
instance).
Suggested-by: Jose Abreu
Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
---
Ch
Hi Laurent,
Thanks for the review,
On 03/03/17 01:57, Laurent Pinchart wrote:
> Hi Kieran,
>
> Thank you for the patch.
>
> On Wednesday 01 Mar 2017 13:12:54 Kieran Bingham wrote:
>> The DRM object does not register the pipe with the WPF object. This is
>> used internally throughout the driver
On Fri, Mar 3, 2017 at 8:03 PM, Geert Uytterhoeven wrote:
>>> +Optional properties:
>>> + - resets: A list of phandles + reset-specifier pairs, one for each entry
>>> in
>>
>> s/phandlers/phandle/
>
> You're seeing typos that do not exist ;-)
Ah, you mean plural vs. singular?
You're right, but I
Hi Jose,
(CC'ing Archit)
On Friday 03 Mar 2017 15:57:57 Jose Abreu wrote:
> On 02-03-2017 15:38, Laurent Pinchart wrote:
> > On Thursday 02 Mar 2017 14:50:02 Jose Abreu wrote:
> >> On 02-03-2017 13:41, Laurent Pinchart wrote:
> Hmm, this is kind of confusing. Why do you need a phy_ops and
>
Hi Laurent,
On Fri, Mar 3, 2017 at 8:17 PM, Laurent Pinchart
wrote:
> On Friday 03 Mar 2017 20:03:09 Geert Uytterhoeven wrote:
>> On Fri, Mar 3, 2017 at 3:41 PM, Laurent Pinchart wrote:
>> > What's in the reset specifier ?
>>
>> That depends on the reset provider.
>>
>> See "[v2,1/4] dt-bindings:
Hi Laurent,
On Fri, Mar 3, 2017 at 3:41 PM, Laurent Pinchart
wrote:
> On Friday 03 Mar 2017 14:30:35 Geert Uytterhoeven wrote:
>> Document the optional properties for describing module resets, to
>> support resetting display channels and LVDS encoders on R-Car Gen2 and
>> Gen3.
>>
>> Signed-off-b
Hi Geert,
On Friday 03 Mar 2017 20:03:09 Geert Uytterhoeven wrote:
> On Fri, Mar 3, 2017 at 3:41 PM, Laurent Pinchart wrote:
> > On Friday 03 Mar 2017 14:30:35 Geert Uytterhoeven wrote:
> >> Document the optional properties for describing module resets, to
> >> support resetting display channels a
Hi Geert,
On Friday 03 Mar 2017 20:04:26 Geert Uytterhoeven wrote:
> On Fri, Mar 3, 2017 at 8:03 PM, Geert Uytterhoeven wrote:
> >>> +Optional properties:
> >>> + - resets: A list of phandles + reset-specifier pairs, one for each
> >>> entry in
> >>
> >> s/phandlers/phandle/
> >
> > You're seei
Describe the WDT hardware in the RZ/A series.
Signed-off-by: Chris Brandt
Reviewed-by: Geert Uytterhoeven
Acked-by: Rob Herring
---
v3:
* Add Acked-by, Reviewed-by.
v2:
* added to renesas-wdt.txt instead of creating a new file
* changed commit title
* added "renesas,rza-wdt" as a fallback
* add
Adds a watchdog timer driver for the Renesas RZ/A Series SoCs. A reset
handler is also included since a WDT overflow is the only method for
restarting an RZ/A SoC.
Signed-off-by: Chris Brandt
---
v2:
* removed extra lines from file header comments
* changed (1<<#) to BIT(#)
* changed #define WTSC
Add watchdog timer support for RZ/A1.
For the RZ/A1, the only way to do a reset is to overflow the WDT, so this
is useful even if you don't need the watchdog functionality.
Signed-off-by: Chris Brandt
Reviewed-by: Geert Uytterhoeven
---
v4:
* changed from timer@ to watchdog@
v3:
* added Reviewed
Some Renesas SoCs do not have a reset register and the only way to do a SW
controlled reset is to use the watchdog timer. So while this series started
out by only adding a reset feature, now it's a full watchdog timer driver that
includes a reset handler.
The longest WDT overflow you can get with
From: Neil Armstrong
The Synopsys Designware HDMI TX Controller does not enforce register
access on platforms instanciating it. The current driver supports two
different types of memory-mapped flat register access, but in order to
support the Amlogic Meson SoCs integration, and provide a more gen
The driver is already made of 5 separate source files. Move it to a
newly created directory named synopsys where more Synopsys bridge
drivers can be added later (for the DisplayPort controller for
instance).
Suggested-by: Jose Abreu
Signed-off-by: Laurent Pinchart
Reviewed-by: Jose Abreu
---
Ch
From: Kieran Bingham
The device type isn't used anymore now that workarounds and PHY-specific
operations are performed based on version information read at runtime.
Remove it.
Signed-off-by: Kieran Bingham
Signed-off-by: Laurent Pinchart
Tested-by: Neil Armstrong
Reviewed-by: Jose Abreu
---
The color space converter isn't part of the PHY, move its configuration
out of PHY code.
Signed-off-by: Laurent Pinchart
Tested-by: Neil Armstrong
Reviewed-by: Jose Abreu
---
drivers/gpu/drm/bridge/dw-hdmi.c | 25 ++---
1 file changed, 10 insertions(+), 15 deletions(-)
dif
Hello,
This patch series refactors all the PHY handling code in order to allow
support of vendor PHYs and Synopsys DWC HDMI 2.0 TX PHYs.
The series starts with a few cleanups and small fixes. Patch 01/10 just
removes unused code, patch 02/10 moves the color converter code out of the PHY
configure
Most of the hdmi_phy_test_*() functions are unused. Remove them.
Signed-off-by: Laurent Pinchart
Tested-by: Neil Armstrong
Reviewed-by: Jose Abreu
Tested-by: Nickey Yang
---
drivers/gpu/drm/bridge/dw-hdmi.c | 26 --
1 file changed, 26 deletions(-)
diff --git a/drivers
From: Neil Armstrong
If the input pixel format is not RGB, the CSC must be enabled in order to
provide valid pixel to DVI sinks.
This patch removes the hdmi only dependency on the CSC enabling.
Reviewed-by: Jose Abreu
Reviewed-by: Laurent Pinchart
Signed-off-by: Neil Armstrong
Tested-by: Neil
The PHY requires us to wait for the PHY to switch to low power mode
after deasserting TXPWRON and before asserting PDDQ in the power down
sequence, otherwise power down will fail.
The PHY power down can be monitored though the TX_READY bit, available
through I2C in the PHY registers, or the TX_PHY
From: Kieran Bingham
The DWC HDMI TX controller interfaces with a companion PHY. While
Synopsys provides multiple standard PHYs, SoC vendors can also integrate
a custom PHY.
Modularize PHY configuration to support vendor PHYs through platform
data. The existing PHY configuration code was origina
When powering the PHY up we need to wait for the PLL to lock. This is
done by polling the TX_PHY_LOCK bit in the HDMI_PHY_STAT0 register
(interrupt-based wait could be implemented as well but is likely
overkill). The bit is asserted when the PLL locks, but the current code
incorrectly waits for the
The HDMI TX controller support different PHYs whose programming
interface can vary significantly, especially with vendor PHYs that are
not provided by Synopsys. To support them, create a PHY operation
structure that can be provided by the platform glue layer. The existing
PHY handling code (limited
Hi Laurent,
On 02-03-2017 15:38, Laurent Pinchart wrote:
> Hi Jose,
>
> On Thursday 02 Mar 2017 14:50:02 Jose Abreu wrote:
>> On 02-03-2017 13:41, Laurent Pinchart wrote:
Hmm, this is kind of confusing. Why do you need a phy_ops and
then a separate configure_phy function? Can't we just
Hi Geert,
Thank you for the patch.
On Friday 03 Mar 2017 14:30:35 Geert Uytterhoeven wrote:
> Document the optional properties for describing module resets, to
> support resetting display channels and LVDS encoders on R-Car Gen2 and
> Gen3.
>
> Signed-off-by: Geert Uytterhoeven
> ---
> Documen
Hi Jacopo,
On Friday 03 Mar 2017 13:37:56 jacopo mondi wrote:
> On 03/03/2017 12:26, Laurent Pinchart wrote:
> > On Friday 03 Mar 2017 09:09:38 Jacopo Mondi wrote:
> >> On Gen3 platforms compositing planes are allocated by VSP on behalf of
> >> DRM/KMS. If VSP support is not compiled in, vsp1 ini
Hi Jacopo,
Thank you for the patch.
On Friday 03 Mar 2017 13:58:56 Jacopo Mondi wrote:
> On Gen3 platforms compositing planes are allocated by VSP on behalf of
> DRM/KMS.
> If VSP support is not compiled in, vsp initialization stub routine is
> called. Return an error from that stub to fail expl
On Gen3 platforms compositing planes are allocated by VSP on behalf of
DRM/KMS.
If VSP support is not compiled in, vsp initialization stub routine is
called. Return an error from that stub to fail explicitly, otherwise
accessing planes leads to invalid memory errors.
Signed-off-by: Jacopo Mondi
Document the optional properties for describing module resets, to
support resetting display channels and LVDS encoders on R-Car Gen2 and
Gen3.
Signed-off-by: Geert Uytterhoeven
---
Documentation/devicetree/bindings/display/renesas,du.txt | 10 ++
1 file changed, 10 insertions(+)
diff --
Hi Geert,
On Friday, March 03, 2017, Geert Uytterhoeven wrote:
> > Is it possible to change the number of port pins in the board dts file?
> > For example:
> > RZ/A1H: P5_0 - P5_10
> > RZ/A1L: P5_0 - P5_16
>
> That's 17 pins, not 16?
Oops, I meant P5_15
Looking at the parts, here are the di
HI Laurent,
On 03/03/2017 12:26, Laurent Pinchart wrote:
Hi Jacopo,
Thank you for the patch.
On Friday 03 Mar 2017 09:09:38 Jacopo Mondi wrote:
On Gen3 platforms compositing planes are allocated by VSP on behalf of
DRM/KMS.
If VSP support is not compiled in, vsp1 initialization stub routine
The Cortex-A57/A53 cache controllers are integrated controllers, and
thus the device nodes representing them should not have unit-addresses
or reg properties.
Fixes: 6f7bf82cc912441f ("arm64: dts: r8a7795: Fix W=1 dtc warnings")
Signed-off-by: Geert Uytterhoeven
---
arch/arm64/boot/dts/renesas/r
The Cortex-A57 cache controller is an integrated controller, and thus
the device node representing it should not have a unit-addresses or reg
property.
Fixes: 1561f20760ec96db ("arm64: dts: r8a7796: Add Renesas R8A7796 SoC support")
Signed-off-by: Geert Uytterhoeven
---
arch/arm64/boot/dts/renes
Hi Simon, Magnus,
This patch series removes the bogus unit-addresses and reg properties
from the device nodes representing Cortex-A57/A53 cache controllers.
Note that the latter were added to remove warnings from dtc when using
W=1:
Warning (unit_address_vs_reg): Node /cache-controll
On 03/03/2017 02:58 PM, Geert Uytterhoeven wrote:
+ - "renesas,imr-lx4-v3m" for R-Car V3M.
"renesas,-EPROBE_DEFER-imr-lx4"
Huh? :-)
Do you know the part number of V3M?
No, but using the names from the manual I don't need it.
Gr{oetje,eeting}s,
Geert
On Fri, Mar 3, 2017 at 12:56 PM, Sergei Shtylyov
wrote:
>>> + - "renesas,imr-lx4-v3m" for R-Car V3M.
>>
>>
>> "renesas,-EPROBE_DEFER-imr-lx4"
>
>
>Huh? :-)
Do you know the part number of V3M?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux b
Hello!
On 03/03/2017 02:24 PM, Geert Uytterhoeven wrote:
--- /dev/null
+++ media_tree/Documentation/devicetree/bindings/media/rcar_imr.txt
+- compatible: "renesas,imr-lx4-", "renesas,imr-lx4" as a fallback for
"renesas,-imr-lx4"
+ the image renderer light extended 4 (IMR-LX4) found in t
Hi Simon,
On Thu, Mar 2, 2017 at 3:36 PM, Simon Horman wrote:
> On Tue, Feb 21, 2017 at 03:27:25PM +0100, Geert Uytterhoeven wrote:
>> On Wed, Dec 7, 2016 at 5:44 PM, Ulrich Hecht
>> wrote:
>> > Signed-off-by: Ulrich Hecht
>> > ---
>> > arch/arm64/boot/dts/renesas/r8a7796.dtsi | 13 +++
This patch fixes an issue that phy_create() never enables the pm_runtime.
And then, we can remove calling the pm_runtime_{en,dis}able from some
phy drivers.
Fixes: ff764963479a ("drivers: phy: add generic PHY framework")
Cc: sta...@vger.kernel.org # v3.13+
Signed-off-by: Yoshihiro Shimoda
---
dr
Hi Laurent,
On 03/03/17 02:17, Laurent Pinchart wrote:
> Hi Kieran,
>
> Thank you for the patch.
>
> On Wednesday 01 Mar 2017 13:12:56 Kieran Bingham wrote:
>> Updating the state in a running VSP1 requires two interrupts from the
>> VSP. Initially, the updated state will be committed - but only
Hi Jacopo,
Thank you for the patch.
On Friday 03 Mar 2017 09:09:38 Jacopo Mondi wrote:
> On Gen3 platforms compositing planes are allocated by VSP on behalf of
> DRM/KMS.
> If VSP support is not compiled in, vsp1 initialization stub routine is
> called, leading to invalid memory accesses later o
Hi Sergei,
On Thu, Mar 2, 2017 at 10:00 PM, Sergei Shtylyov
wrote:
> --- /dev/null
> +++ media_tree/Documentation/devicetree/bindings/media/rcar_imr.txt
> +- compatible: "renesas,imr-lx4-", "renesas,imr-lx4" as a fallback
> for
"renesas,-imr-lx4"
> + the image renderer light extended 4 (IMR-
From: Konstantin Kozhevnikov
The image renderer, or the distortion correction engine, is a drawing
processor with a simple instruction system capable of referencing video
capture data or data in an external memory as the 2D texture data and
performing texture mapping and drawing with respect to a
Hi Laurent,
On 03/03/17 02:11, Laurent Pinchart wrote:
> Hi Kieran,
>
> Thank you for the patch.
>
> On Wednesday 01 Mar 2017 13:12:55 Kieran Bingham wrote:
>> To be able to perform page flips in DRM without flicker we need to be
>> able to notify the rcar-du module when the VSP has completed it
Hi Chris,
On Thu, Mar 2, 2017 at 4:38 PM, Chris Brandt wrote:
>> > + /*
>> > +* Since the max possible timeout of our 8-bit count register is
>> less
>> > +* than a second, we must use max_hw_heartbeat_ms.
>> > +*/
>> > + priv->wdev.max_hw_heartbeat_ms = (1000 * U8_MAX)/rate;
>>
>
Hi Chris,
On Thu, Mar 2, 2017 at 9:17 PM, Chris Brandt wrote:
> On Tuesday, February 21, 2017, jacopo mondi wrote:
>> > + gpio-controller;
>> > + #gpio-cells = <2>;
>> > + gpio-ranges = <&pinctrl 0 0 16>;
>>
>> Not all ports have 16 pins avail
On Gen3 platforms compositing planes are allocated by VSP on behalf of
DRM/KMS.
If VSP support is not compiled in, vsp1 initialization stub routine is
called, leading to invalid memory accesses later on when un-initialized
planes are accessed.
Fail explicitly earlier if planes are not properly cr
51 matches
Mail list logo
