Right now the host is only unregistered when the driver is used via the
bridge api and not via the component api, leading to the host staying
registered in cases like probe deferral.
So move the host unregister to the general remove function, so that it
gets cleaned up in all cases.
From: Nickey Yang
This patch update describe panel/port links, including
unit addresses in documentation of device tree bindings
for the rockchip DSI controller based on the Synopsys
DesignWare MIPI DSI host controller.
Signed-off-by: Nickey Yang
Reviewed-by: Brian Norris
Signed-off-by: Heiko
From: Nickey Yang
Add the ROCKCHIP DSI controller driver that uses the Synopsys DesignWare
MIPI DSI host controller bridge and remove the old separate one.
changes:
v2:
add err_pllref, remove unnecessary encoder.enable & disable
correct spelling mistakes
v3:
call dw_mipi_dsi_unbind()
__dw_mipi_dsi_probe() does all the grabbing of resources and does it using
devm-helpers. So this is happening on each try of master bringup possibly
slowing down things a lot.
Drivers using the component framework may instead want call dw_mipi_dsi_probe
separately in their probe function setup
When the panel-driver is build as a module it currently fails hard as the
panel cannot be probed directly:
dw_mipi_dsi_bind()
__dw_mipi_dsi_probe()
creates dsi bus
creates panel device
triggers panel module load
panel not probed (module not loaded or panel probe slow)
The Rockchip DSI driver was separate till now, not using the common
bridge driver that was introduced a bit later. So this series migrates
over to use that common bridge driver and then also adds support for
dual-dsi to both the bridge and Rockchip glue code.
The bridge-migration itself is v8
From: Nickey Yang
Allow to also drive a slave dw-mipi-dsi controller in a dual-dsi
setup. This will require additional implementation-specific
code to look up the slave instance and do specific setup.
Also will probably need code in the specific crtcs as dual-dsi
does not equal two separate dsi
From a specified output port of one dsi controller this function allows to
iterate over the list of registered dsi controllers trying to find a second
instance connected to the same display, like it is used in dual-dsi setups.
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/drm_mipi_dsi.c |
Add the Rockchip-sepcific dual-dsi setup and hook it into the VOP as well.
As described in the general dual-dsi devicetree binding, the panel should
define two input ports and point each of them to one of the used dsi-
controllers, as well as declare one of them as clock-master.
This is used to
Hi Andrzej et all,
just so we don't discuss in a theoretic way much longer I've just
sent a RFC with my current state of work for the dw-mipi-dsi dual-dsi
support - aka the old "let code speak" ;-)
I've found a somewhat nice way to get from one dsi-controller node
to the node of the other
Hi,
On Wed, Jun 06, 2018 at 12:36:30PM +0300, Laurent Pinchart wrote:
> The .probe(), .remove(), .run_test(), .get_rotate() and .set_rotate()
> omap_dss_driver operations are not used. Remove them.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
>
Hi,
On Wed, Jun 06, 2018 at 12:36:31PM +0300, Laurent Pinchart wrote:
> The .get_mirror() and .set_mirror() omap_dss_driver operations are
> implemented by the panel-tpo-td043mtea1 driver but are never used.
> Remove them.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian
Hi,
On Wed, Jun 06, 2018 at 12:36:32PM +0300, Laurent Pinchart wrote:
> The omapdrm driver checks at suspend and resume time whether the
> displays it operates on have their driver operations set. This check is
> unneeded, as all display drivers set the driver operations field at
> probe time and
Hi,
On Wed, Jun 06, 2018 at 12:36:34PM +0300, Laurent Pinchart wrote:
> The GPIO descriptor API is favoured over the plain GPIO API for consumer
> drivers. Using it simplifies the driver code.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
>
Hi,
On Wed, Jun 06, 2018 at 12:36:35PM +0300, Laurent Pinchart wrote:
> The GPIO descriptor API is favoured over the plain GPIO API for consumer
> drivers. Using it simplifies the driver code.
>
> As the descriptor API handles the active-low flag internally we need to
> invert the polarity of
Hi,
On Wed, Jun 06, 2018 at 12:36:36PM +0300, Laurent Pinchart wrote:
> The GPIO descriptor API is favoured over the plain GPIO API for consumer
> drivers. Using it simplifies the driver code.
>
> The reset GPIO is mandatory, so drop conditional tests through the
> driver. The qvga GPIO is
Hi,
On Wed, Jun 06, 2018 at 12:36:37PM +0300, Laurent Pinchart wrote:
> The GPIO descriptor API is favoured over the plain GPIO API for consumer
> drivers. Using it simplifies the driver code.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
>
Hi,
On Wed, Jun 06, 2018 at 12:36:38PM +0300, Laurent Pinchart wrote:
> The driver doesn't use GPIOs and thus doesn't need to include the
> linux/gpio.h header.
>
> Signed-off-by: Laurent Pinchart
> ---
Reviewed-by: Sebastian Reichel
-- Sebastian
>
https://bugzilla.kernel.org/show_bug.cgi?id=199959
--- Comment #14 from Christian König (christian.koe...@amd.com) ---
Created attachment 276471
--> https://bugzilla.kernel.org/attachment.cgi?id=276471=edit
Testing patch
Please test if this patch helps as well.
It limits the work done during
Hi,
On Wed, Jun 06, 2018 at 12:36:39PM +0300, Laurent Pinchart wrote:
> The GPIO descriptor API is favoured over the plain GPIO API for consumer
> drivers. Using it simplifies the driver code.
>
> As the descriptor API handles the active-low flag internally we need to
> invert the polarity of
On Fri, Jun 08, 2018 at 11:56:04AM +0530, Sharat Masetty wrote:
> This series re-factors the devfreq code a bit in preparation for the upcoming
> A6x related devfreq changes. The code applies cleanly on 4.17 and has been
> verified on DB820C.
>
> V2: Addressed code review comments from Jordan
On Wed, Jun 06, 2018 at 05:39:42PM +0200, Enric Balletbo i Serra wrote:
> Trivial fix to spelling mistake in tilcdc.txt devicetree documentation.
>
> Signed-off-by: Enric Balletbo i Serra
> ---
>
> Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt | 2 +-
> 1 file changed, 1
Hi,
On Wed, Jun 06, 2018 at 12:36:40PM +0300, Laurent Pinchart wrote:
> omap_dss_device instances have two ops structures, omap_dss_driver and
> omap_dss_device_ops. The former is used for devices at the end of the
> pipeline (a.k.a. display devices), and the latter for intermediate
> devices.
>
From: Colin Ian King
The check for level being less than zero is redundant as level
is an unsigned u32 and hence will never be less than zero.
Remove this redundant check.
Detected by CoverityScan, CID#1468363 ("Macro compares unsigned to 0")
Signed-off-by: Colin Ian King
---
Hi,
On Wed, Jun 06, 2018 at 12:36:41PM +0300, Laurent Pinchart wrote:
> When an omap_dss_device operation can be implemented in multiple places
> in a chain of devices, it is important to find out which device to
> address to perfom the operation. This is currently done by calling the
> operation
Hi,
On Wed, Jun 06, 2018 at 12:36:42PM +0300, Laurent Pinchart wrote:
> Instead of calling the .detect() operation recursively from the display
> device back to the first device that provides hot plug detection
> support, iterate over the devices manually in the DRM connector
> .detect()
On Mon, Jun 11, 2018 at 05:00:37PM +0100, Colin King wrote:
> From: Colin Ian King
>
> The check for level being less than zero is redundant as level
> is an unsigned u32 and hence will never be less than zero.
> Remove this redundant check.
>
> Detected by CoverityScan, CID#1468363 ("Macro
101 - 127 of 127 matches
Mail list logo
