From: Sean Paul
[ Upstream commit db735fc4036bbe1fbe606819b5f0ff26cc76cdff ]
Turning on CONFIG_DMA_API_DEBUG_SG results in the following error:
[ 12.078665] msm ae0.mdss: DMA-API: mapping sg segment longer than device
claims to support [len=3526656] [max=65536]
[ 12.089870] WARNING:
From: Sean Paul
[ Upstream commit db735fc4036bbe1fbe606819b5f0ff26cc76cdff ]
Turning on CONFIG_DMA_API_DEBUG_SG results in the following error:
[ 12.078665] msm ae0.mdss: DMA-API: mapping sg segment longer than device
claims to support [len=3526656] [max=65536]
[ 12.089870] WARNING:
From: Yongqiang Sun
[ Upstream commit 6c81917a0485ee2a1be0dc23321ac10ecfd9578b ]
[Why]
Underflow is observed when plug in a 4K@60 monitor with
1366x768 eDP due to DPPCLK is too low.
[How]
Limit minimum DPPCLK to 100MHz.
Signed-off-by: Yongqiang Sun
Reviewed-by: Eric Yang
Acked-by:
From: Sean Paul
[ Upstream commit db735fc4036bbe1fbe606819b5f0ff26cc76cdff ]
Turning on CONFIG_DMA_API_DEBUG_SG results in the following error:
[ 12.078665] msm ae0.mdss: DMA-API: mapping sg segment longer than device
claims to support [len=3526656] [max=65536]
[ 12.089870] WARNING:
From: Isabel Zhang
[ Upstream commit c134c3cabae46a56ab2e1f5e5fa49405e1758838 ]
[Why]
Starting from 14nm, the PLL is built into the PHY and the PLL is mapped
to PHY on 1 to 1 basis. In the code, the DP port is mapped to a PLL that was not
initialized. This causes DP to HDMI dongle to not light
From: Daniel Kolesa
[ Upstream commit 416611d9b6eebaeae58ed26cc7d23131c69126b1 ]
On PowerPC, the compiler will tag object files with whether they
use hard or soft float FP ABI and whether they use 64 or 128-bit
long double ABI. On systems with 64-bit long double ABI, a tag
will get emitted
From: Aric Cyr
[ Upstream commit 2b63d0ec0daf79ba503fa8bfa25e07dc3da274f3 ]
[Why]
Engine can be NULL in some cases, so we must not acquire it.
[How]
Check for NULL engine before acquiring.
Signed-off-by: Aric Cyr
Reviewed-by: Harry Wentland
Acked-by: Bhawanpreet Lakha
Signed-off-by: Alex
From: Sung Lee
[ Upstream commit df36f6cf23ada812930afa8ee76681d4ad307c61 ]
[WHY]
The optimized_require flag is needed to set watermarks and clocks lower
in certain conditions. This flag is set to true and then set to false
while programming front end in dcn20.
[HOW]
Do not set the flag to
From: Sung Lee
[ Upstream commit df36f6cf23ada812930afa8ee76681d4ad307c61 ]
[WHY]
The optimized_require flag is needed to set watermarks and clocks lower
in certain conditions. This flag is set to true and then set to false
while programming front end in dcn20.
[HOW]
Do not set the flag to
From: Sean Paul
[ Upstream commit db735fc4036bbe1fbe606819b5f0ff26cc76cdff ]
Turning on CONFIG_DMA_API_DEBUG_SG results in the following error:
[ 12.078665] msm ae0.mdss: DMA-API: mapping sg segment longer than device
claims to support [len=3526656] [max=65536]
[ 12.089870] WARNING:
From: Yongqiang Sun
[ Upstream commit 6c81917a0485ee2a1be0dc23321ac10ecfd9578b ]
[Why]
Underflow is observed when plug in a 4K@60 monitor with
1366x768 eDP due to DPPCLK is too low.
[How]
Limit minimum DPPCLK to 100MHz.
Signed-off-by: Yongqiang Sun
Reviewed-by: Eric Yang
Acked-by:
From: Daniel Kolesa
[ Upstream commit 416611d9b6eebaeae58ed26cc7d23131c69126b1 ]
On PowerPC, the compiler will tag object files with whether they
use hard or soft float FP ABI and whether they use 64 or 128-bit
long double ABI. On systems with 64-bit long double ABI, a tag
will get emitted
From: Aric Cyr
[ Upstream commit 2b63d0ec0daf79ba503fa8bfa25e07dc3da274f3 ]
[Why]
Engine can be NULL in some cases, so we must not acquire it.
[How]
Check for NULL engine before acquiring.
Signed-off-by: Aric Cyr
Reviewed-by: Harry Wentland
Acked-by: Bhawanpreet Lakha
Signed-off-by: Alex
From: Sean Paul
[ Upstream commit db735fc4036bbe1fbe606819b5f0ff26cc76cdff ]
Turning on CONFIG_DMA_API_DEBUG_SG results in the following error:
[ 12.078665] msm ae0.mdss: DMA-API: mapping sg segment longer than device
claims to support [len=3526656] [max=65536]
[ 12.089870] WARNING:
From: Isabel Zhang
[ Upstream commit c134c3cabae46a56ab2e1f5e5fa49405e1758838 ]
[Why]
Starting from 14nm, the PLL is built into the PHY and the PLL is mapped
to PHY on 1 to 1 basis. In the code, the DP port is mapped to a PLL that was not
initialized. This causes DP to HDMI dongle to not light
Hi Qiang,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[cannot apply to drm-exynos/exynos-drm-next drm-intel/for-linux-next
tegra-drm/drm/tegra/for-next linus/master v5.6-rc2 next-20200221]
[if your patch is applied to the wrong git tree, please drop
Hi Kevin/tang.
Thanks for the quick and detailed feedback.
Your questions are addressed below.
Sam
> > > +static int sprd_drm_bind(struct device *dev)
> > > +{
> > > + struct drm_device *drm;
> > > + struct sprd_drm *sprd;
> > > + int err;
> > > +
> > > + drm =
On 2020-02-21 09:20, Daniel Vetter wrote:
On Thu, Feb 20, 2020 at 01:24:00PM -0800, jsa...@codeaurora.org wrote:
On 2020-02-20 12:14, Daniel Vetter wrote:
> On Thu, Feb 20, 2020 at 10:45:57AM -0800, jsa...@codeaurora.org wrote:
> > Hello All,
> >
> > I am seeking recommendations for DRM
On Sat, Feb 22, 2020 at 05:24:30PM +0200, Laurent Pinchart wrote:
> The drm_driver structure is never modified, make it const. The improves
> security by avoiding writable function pointers.
>
> Signed-off-by: Laurent Pinchart
I wonder whether there's some magic somewhere we could do to enlist
On Sat, Feb 22, 2020 at 05:24:29PM +0200, Laurent Pinchart wrote:
> The drm_driver structure contains pointers to functions, which can be an
> attack vector if an attacker can corrupt the structure. The DRM core
> however never modifies the structure, so it could be declared as const
> in drivers.
On Sat, Feb 22, 2020 at 05:24:28PM +0200, Laurent Pinchart wrote:
> The drm_driver structure contains a single field (legacy_dev_list) that
> is modified by the DRM core, used to store a linked list of legacy DRM
> devices associated with the driver. In order to make the structure
> const, move
Only user left is the shadow attach for legacy drivers.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_pci.c | 22 +++---
include/drm/drm_pci.h | 11 ---
2 files changed, 3 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/drm_pci.c
It's the last user, and more importantly, it's the last non-legacy
user of anything in drm_pci.c.
The only tricky bit is the agp initialization. But a close look shows
that radeon does not use the drm_agp midlayer (the main use of that is
drm_bufs for legacy drivers), and instead could use the
This doesn't do anything except auto-init drm_agp support when you
call drm_get_pci_dev(). Which amdgpu stopped doing with
commit b58c11314a1706bf094c489ef5cb28f76478c704
Author: Alex Deucher
Date: Fri Jun 2 17:16:31 2017 -0400
drm/amdgpu: drop deprecated drm_get_pci_dev and drm_put_dev
On Sat, Feb 22, 2020 at 10:00:03AM +0100, Mauro Carvalho Chehab wrote:
> Several references got broken due to txt to ReST conversion.
>
> Several of them can be automatically fixed with:
>
> scripts/documentation-file-ref-check --fix
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
>
Most bridge drivers create a DRM connector to model the connector at the
output of the bridge. This model is historical and has worked pretty
well so far, but causes several issues:
- It prevents supporting more complex display pipelines where DRM
connector operations are split over multiple
Most bridge drivers create a DRM connector to model the connector at the
output of the bridge. This model is historical and has worked pretty
well so far, but causes several issues:
- It prevents supporting more complex display pipelines where DRM
connector operations are split over multiple
Clean up the drm_bridge overview documentation, and expand the
operations documentation to provide more details on API usage.
Signed-off-by: Laurent Pinchart
Reviewed-by: Daniel Vetter
---
Change since v7:
- Detail how bridge operations are used by atomic helpers
---
On Sat, Feb 22, 2020 at 4:01 PM Laurent Pinchart
wrote:
>
> Most bridge drivers create a DRM connector to model the connector at the
> output of the bridge. This model is historical and has worked pretty
> well so far, but causes several issues:
>
> - It prevents supporting more complex display
On Sat, Feb 22, 2020 at 4:01 PM Laurent Pinchart
wrote:
>
> To support implementation of DRM connectors on top of DRM bridges
> instead of by bridges, the drm_bridge needs to expose new operations and
> data:
>
> - Output detection, hot-plug notification, mode retrieval and EDID
> retrieval
Hi Daniel,
On Sat, Feb 22, 2020 at 04:32:58PM +0100, Daniel Vetter wrote:
> On Sat, Feb 22, 2020 at 4:01 PM Laurent Pinchart wrote:
> >
> > Clean up the drm_bridge overview documentation, and expand the
> > operations documentation to provide more details on API usage.
> >
> > Signed-off-by:
On Sat, Feb 22, 2020 at 4:01 PM Laurent Pinchart
wrote:
>
> Clean up the drm_bridge overview documentation, and expand the
> operations documentation to provide more details on API usage.
>
> Signed-off-by: Laurent Pinchart
> ---
> Documentation/gpu/drm-kms-helpers.rst | 6 +--
>
The drm_driver structure contains a single field (legacy_dev_list) that
is modified by the DRM core, used to store a linked list of legacy DRM
devices associated with the driver. In order to make the structure
const, move the field out to a global variable. This requires locking
access to the
The drm_driver structure is never modified, make it const. The improves
security by avoiding writable function pointers.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Hello,
This patch series makes it possible for DRM drivers to declare their
struct drm_driver as a static const. This improves security by avoiding
function pointers in writable memory.
The change turned out to be fairly easy, with preparation in patch 1/3
that moves the only non-const field out
The drm_driver structure contains pointers to functions, which can be an
attack vector if an attacker can corrupt the structure. The DRM core
however never modifies the structure, so it could be declared as const
in drivers. Modify the DRM core to take const struct drm_driver
pointers in all APIs.
On Fri, Feb 21, 2020 at 10:02:46PM +0100, Daniel Vetter wrote:
> These are the leftover drivers that didn't have a ->release hook that
> needed to be updated.
>
> Signed-off-by: Daniel Vetter
> Cc: "James (Qian) Wang"
> Cc: Liviu Dudau
> Cc: Mihail Atanassov
> Cc: Russell King
> Cc: Hans de
The omap_connector implementation is now used for DSI only. Hardcode its
type and drop unused code.
Signed-off-by: Laurent Pinchart
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian Reichel
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/base.c | 23 --
The omap_dss_device .pre_enable(), .post_disable() and .set_timings()
are not used anymore. Remove them.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/dss/base.c | 26 ---
When the DSS initialises its output DPI and SDI ports, failures don't
clean up previous successfully initialised ports. This can lead to
resource leak or memory corruption. Fix it.
Reported-by: Hans Verkuil
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Acked-by: Sam Ravnborg
The omapdss_of_find_connected_device() function isn't used anymore,
remove it.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/dss/Makefile | 2 +-
drivers/gpu/drm/omapdrm/dss/dss-of.c | 28
Inline the omapdss_display_get() in its only caller to simplify the
code.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/dss/display.c | 9 -
drivers/gpu/drm/omapdrm/dss/omapdss.h | 1
Due to the removal of several omapdrm display drivers, the omapdss HPD,
detected and EDID operations are not used anymore. Remove them and all
related code.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian Reichel
---
The TPD12S015, OPA362 and analog and HDMI connectors are now supported
by DRM bridge drivers, and the omapdrm HDMI and VENC outputs can be
handled through the drm_bridge API. Switch the outputs to drm_bridge by
making the next bridge mandatory and removing the related
omapdrm-specific display
Most bridge drivers create a DRM connector to model the connector at the
output of the bridge. This model is historical and has worked pretty
well so far, but causes several issues:
- It prevents supporting more complex display pipelines where DRM
connector operations are split over multiple
Move the omap_dss_device .set_timings(), .enable() and .disable()
operations to the drm_bridge functions. As the drm_bridge for the HDMI
encoder is unconditionally registered and attached, those operations
will be called at the appropriate time.
The omapdss device .set_infoframe() and
In order to integrate with a chain of drm_bridge, the internal DPI
output has to expose its operations through the drm_bridge API.
Register a bridge at initialisation time to do so and remove the
omap_dss_device operations that are now unused.
Signed-off-by: Laurent Pinchart
Tested-by: Sebastian
In order to integrate with a chain of drm_bridge, the internal SDI
output has to expose its operations through the drm_bridge API.
Register a bridge at initialisation time to do so and remove the
omap_dss_device operations that are now unused.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi
Move the code that computes the DRM connector type for the
omapdss_device display type to a new omapdss_device_connector_type()
function for later reuse.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Acked-by: Sam Ravnborg
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian
Now that the omap_dss_device EDID read operation has been removed,
simplify the bridge-based EDID access by merging multiple functions
together.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian Reichel
---
Now that the omap_dss_device EDID read operation has been removed,
simplify the bridge-based EDID access by merging multiple functions
together.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian Reichel
---
This makes it easier to quickly locate duplicate includes.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/dss/sdi.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
Move the omap_dss_device .set_timings(), .enable() and .disable()
operations to the drm_bridge functions. As the drm_bridge for the HDMI
encoder is unconditionally registered and attached, those operations
will be called at the appropriate time.
The omapdss device .set_infoframe() and
The HDMI4 encoder is transitioning to the drm_bridge API, implement the
last missing operation.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 10 ++
1 file changed, 10
Use the drm_bridge_connector helper to create a connector for pipelines
that use drm_bridge. This allows splitting connector operations across
multiple bridges when necessary, instead of having the last bridge in
the chain creating the connector and handling all connector operations
internally.
Now that the VENC output is driven fully through the drm_bridge API its
omap_dss_device operations are not used anymore. Remove them.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/dss/venc.c
In order to integrate with a chain of drm_bridge, the internal HDMI5
encoder has to expose the EDID read operation through the drm_bridge
API. Register a bridge at initialisation time to do so.
For the time being make the next bridge in the chain optional as the
HDMI output is still based on
This makes it easier to quickly locate duplicate includes.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/dss/dpi.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff
In preparation of adding DRM bridge support to the hdmi5 encoder code,
rework the EDID read to isolate data read.
The hdmi_read_edid() function is the main entry point. It performs all
initialisation steps required prior to reading the EDID (such as
ensuring the device is powered on), as well as
In order to integrate with a chain of drm_bridge, the internal HDMI4
encoder has to expose the EDID read operation through the drm_bridge
API. Register a bridge at initialisation time to do so.
For the time being make the next bridge in the chain optional as the
HDMI output is still based on
Replace the manual panel handling code by a drm_panel_bridge. This
simplifies the driver and allows all components in the display pipeline
to be treated as bridges, paving the way to generic connector handling.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Tested-by: Sebastian
In order to integrate with a chain of drm_bridge, the internal VENC
encoder has to expose the mode valid, fixup and set, the enable and
disable and the get modes operations through the drm_bridge API.
Register a bridge at initialisation time to do so.
Most of those operations are removed from the
In preparation for a connector creation helper based on a chain of
bridges, add a flag to the drm_bridge structure to report support for
interlaced modes. This will be used to set the connector's
interlace_allowed flag.
Signed-off-by: Laurent Pinchart
Tested-by: Sebastian Reichel
Reviewed-by:
Group functions based on their purpose and split them in sections to
make the source code easier to navigate.
No functional change is included.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian Reichel
---
In order to support drm_bridge-based pipeline, the internal HDMI
encoders will need to expose the EDID read operation through the
drm_bridge API, and thus to expose a drm_bridge instance corresponding
to the encoder. The HDMI encoders are however handled as omap_dss_device
instances, which
Remove the omap_connector_get_hdmi_mode() function as the HDMI mode can
be accessed directly from the connector's display info.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Acked-by: Sam Ravnborg
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian Reichel
---
The dpi_set_pll_clk() and dpi_set_dispc_clk() return various information
through pointer arguments that are never used by the callers. Remove
them to simplify the clock setting API.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian
The DSS core looks up the next device connected to an output by
traversing the OF graph. It currently hardcodes the local port number to
0, which breaks any output with a different port number (SDI on OMAP3
and any DPI output but the first one). Fix this by repurposing the
currently unused
The omapdss_hdmi_ops .set_hdmi_mode() and .set_infoframe() operations
operations are not used anymore, remove them.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian Reichel
---
drivers/gpu/drm/omapdrm/dss/omapdss.h | 3 ---
The TI TPD12S015 is an HDMI level shifter and ESD protector controlled
through GPIOs. Add a DRM bridge driver for the device.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Acked-by: Sam Ravnborg
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian Reichel
---
Changes since v2:
The tfp410 driver can operate as part of a pipeline where the
drm_connector is created by the display controller. Enable this mode of
operation by skipping creation of a drm_connector internally.
Signed-off-by: Laurent Pinchart
Reviewed-by: Boris Brezillon
Acked-by: Sam Ravnborg
Tested-by:
Create a new simple_bridge_info structure that stores information about
the bridge model, and store the bridge timings in there, along with the
connector type. Use that new structure for of_device_id data. This
enables support for non-VGA bridges.
Signed-off-by: Laurent Pinchart
Reviewed-by:
Implement the newly added bridge connector operations, allowing the
usage of drm_bridge_panel with drm_bridge_connector.
Signed-off-by: Laurent Pinchart
Reviewed-by: Boris Brezillon
Reviewed-by: Sam Ravnborg
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian Reichel
---
Changes since v2:
-
Bring the omapdss-specific .read_edid() operation in sync with the
drm_bridge .get_edid() operation to ease code reuse.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian Reichel
---
Changes since v1:
- Keep MAX_EDID macro
---
The drm_display_info structure contains many fields related to HDMI
sinks, but none that identifies if a sink compliant with CEA-861 (EDID)
shall be treated as an HDMI sink or a DVI sink. Add such a flag, and
populate it according to section 8.3.3 ("DVI/HDMI Device
Discrimination") of the HDMI
drm_connector.c contains a map of connector types (DRM_MODE_CONNECTOR_*)
to name strings, but doesn't expose it. This leads to drivers having to
store a similar map.
Add a new drm_get_connector_type_name() helper function that return a
name string for a connector type.
Signed-off-by: Laurent
In preparation of adding DRM bridge support to the hdmi4 encoder code,
rework the EDID read to isolate data read.
The hdmi_read_edid() function is the main entry point. It performs all
initialisation steps required prior to reading the EDID (such as
ensuring the device is powered on), as well as
Now that the HDMI outputs are driven fully through the drm_bridge API
their omap_dss_device operations are not used anymore. Remove them.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Tested-by: Sebastian Reichel
Reviewed-by: Sebastian Reichel
---
Hello,
This patch series is the sixth attempt to (nearly, see [1]) complete the
rework of the omapdrm driver to move to drm_bridge and drm_panel.
Version 2, available at [2], explains in its long cover letter the
rationale for the changes. I won't duplicate it here as it is still
valid as-is.
The dumb-vga-dac driver can support simple DRM bridges without being
limited to VGA DACs. Rename it to simple-bridge.
Signed-off-by: Laurent Pinchart
Reviewed-by: Andrzej Hajda
Reviewed-by: Boris Brezillon
Acked-by: Maxime Ripard
Acked-by: Sam Ravnborg
Tested-by: Sebastian Reichel
Clean up the drm_bridge overview documentation, and expand the
operations documentation to provide more details on API usage.
Signed-off-by: Laurent Pinchart
---
Documentation/gpu/drm-kms-helpers.rst | 6 +--
drivers/gpu/drm/drm_bridge.c | 76 ---
2 files
Most bridge drivers create a DRM connector to model the connector at the
output of the bridge. This model is historical and has worked pretty
well so far, but causes several issues:
- It prevents supporting more complex display pipelines where DRM
connector operations are split over multiple
To support implementation of DRM connectors on top of DRM bridges
instead of by bridges, the drm_bridge needs to expose new operations and
data:
- Output detection, hot-plug notification, mode retrieval and EDID
retrieval operations
- Bitmask of supported operations
- Bridge output type
- I2C
As part of the move to drm_bridge ops, the dssdev ops will become empty
for some of the internal encoders. Make them optional in the driver to
allow them to be removed completely, easing the transition.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
Tested-by: Sebastian Reichel
The TI OPA362 is an analog video amplifier controlled through a GPIO. Add
support for it to the simple-bridge driver.
Signed-off-by: Laurent Pinchart
Reviewed-by: Andrzej Hajda
Reviewed-by: Boris Brezillon
Reviewed-by: Maxime Ripard
Reviewed-by: Tomi Valkeinen
Acked-by: Sam Ravnborg
Now that a driver is available for display connectors, replace the
manual connector handling code with usage of the DRM bridge API. The
tfp410 driver doesn't deal with the display connector directly anymore,
but still delegates drm_connector operations to the next bridge. This
brings us one step
Display connectors are modelled in DT as a device node, but have so far
been handled manually in several bridge drivers. This resulted in
duplicate code in several bridge drivers, with slightly different (and
thus confusing) logics.
In order to fix this, implement a bridge driver for display
The hdmi_avi_infoframe_init() never needs to return an error, change its
return type to void.
Signed-off-by: Laurent Pinchart
Reviewed-by: Andrzej Hajda
Acked-by: Bartlomiej Zolnierkiewicz
Reviewed-by: Boris Brezillon
Acked-by: Sam Ravnborg
Tested-by: Sebastian Reichel
Reviewed-by:
The drm_encoder.bridge_chain is not meant to be touched manually by
drivers. Make this clear in the documentation.
Signed-off-by: Laurent Pinchart
---
include/drm/drm_encoder.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/drm/drm_encoder.h
The dumb-vga-dac driver is a simple DRM bridge driver for simple VGA
DACs that don't require configuration. Other non-VGA bridges fall in a
similar category, and would benefit from a common driver. Prepare for
this by renaming the internal symbols from dumb-vga-dac to
simple-bridge.
If an enable GPIO is declared in the firmware, assert it when enabling
the bridge and deassert it when disabling it.
Signed-off-by: Laurent Pinchart
Reviewed-by: Andrzej Hajda
Reviewed-by: Stefan Agner
Reviewed-by: Boris Brezillon
Reviewed-by: Maxime Ripard
Acked-by: Sam Ravnborg
Tested-by:
The drm_bridge_funcs atomic_state_duplicate and atomic_state_destroy
operations are erroneously documented as having a default implementation
if not implemented in bridge drivers. This isn't correct, fix the
documentation.
Signed-off-by: Laurent Pinchart
---
include/drm/drm_bridge.h | 20
Quoting Colin King (2020-02-22 13:47:55)
> From: Colin Ian King
>
> Variable dw is being initialized with a value that is never read,
> it is assigned a new value later on. The assignment is redundant
> and can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King
From: Colin Ian King
Variable dw is being initialized with a value that is never read,
it is assigned a new value later on. The assignment is redundant
and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
On Sat, Feb 22, 2020 at 1:30 PM Hans de Goede wrote:
>
> Hi,
>
> On 2/21/20 10:03 PM, Daniel Vetter wrote:
> > Instead of having a work item that never stops (which really should be
> > a kthread), with a dedicated workqueue to not upset anyone else, use a
> > delayed work. A bunch of changes:
>
Hi Ville.
Nice patch - and diffstat looks good:
> 63 files changed, 217 insertions(+), 392 deletions(-)
There is an item in the Documentation/gpu/todo.rst that
describes this.
Could you drop this from todo.rst in this patch too.
> diff --git a/drivers/gpu/drm/mcde/mcde_dsi.c
Hi,
On 2/21/20 10:03 PM, Daniel Vetter wrote:
Instead of having a work item that never stops (which really should be
a kthread), with a dedicated workqueue to not upset anyone else, use a
delayed work. A bunch of changes:
- We can throw out all the custom wakeup and requeue logic and state
Hi Marek.
On Thu, Feb 20, 2020 at 01:07:00PM +0100, Marek Szyprowski wrote:
> Add proper MODULE_DEVICE_TABLE structure with SPI IDs to allow proper
> creation of SPI modalias string and fix autoloading module for this driver.
>
> Signed-off-by: Marek Szyprowski
Thanks,
applied to
Hi Tomi.
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -2397,7 +2397,8 @@ static const struct panel_desc
> osddisplays_osd070t1718_19ts = {
> .height = 91,
> },
> .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
> -
Hi,
On 2/21/20 10:03 PM, Daniel Vetter wrote:
Also there's a race in the disconnect implemenation. First shut
down, then unplug, leaves a window where userspace could sneak
in and restart the entire machinery.
With this we can also delete the very un-atomic global pipe_enabled
tracking.
1 - 100 of 113 matches
Mail list logo
