Hey,
Nothing major here, another TU1xx modesetting fix, and hooking up
ACR/GR support on TU11x now that NVIDIA have made the firmware
available.
Thanks,
Ben.
The following changes since commit 137c4ba7163ad9d5696b9fde78b1c0898a9c115b:
drm/nouveau/kms/gv100-: avoid sending a core update until
[AMD Public Use]
> -Original Message-
> From: Sean Paul
> Sent: Saturday, February 15, 2020 12:09 AM
> To: Lin, Wayne
> Cc: dri-devel@lists.freedesktop.org; ly...@redhat.com; Sean Paul
> ; Maarten Lankhorst
> ; Maxime Ripard ;
> David Airlie
> Subject: Re: [PATCH 3/3] drm/dp_mst:
Hi Andrzej:
Good work.
It's a real useful patch, with it seems most vendor-specific fb_create
can be simplified by these helper funcs.
On Fri, Dec 13, 2019 at 04:58:34PM +0100, Andrzej Pietrasiewicz wrote:
> Prepare tools for drivers which need to allocate a struct drm_framebuffer
> (or a
On Fri, Dec 13, 2019 at 04:58:33PM +0100, Andrzej Pietrasiewicz wrote:
> Add checking if a modifier is afbc and getting afbc block size.
>
> Signed-off-by: Andrzej Pietrasiewicz
> ---
> drivers/gpu/drm/drm_fourcc.c | 53
> include/drm/drm_fourcc.h | 4
Hi Andrzej:
Sorry for late due to the outbreak of coronavirus in china.
Reviewed-by: James Qian Wang
James.
On Fri, Dec 13, 2019 at 04:58:32PM +0100, Andrzej Pietrasiewicz wrote:
> modifier_info is a pointer to an optional modifier-related information.
> Managing the memory needed for that
On Mon, 2020-02-17 at 11:55 +0800, Tzung-Bi Shih wrote:
> On Mon, Feb 17, 2020 at 11:44 AM CK Hu wrote:
> > On Mon, 2020-02-17 at 11:16 +0800, Tzung-Bi Shih wrote:
> > > Fixes: 5d3c64477392 ("drm/mediatek: support HDMI jack status reporting")
> >
> > This patch looks good to me, but please merge
Hi, Tzhung-Bi:
On Mon, 2020-02-17 at 11:16 +0800, Tzung-Bi Shih wrote:
> hdmi_conn_detect and mtk_hdmi_audio_hook_plugged_cb would be called
> by different threads.
>
> Imaging the following calling sequence:
>Thread AThread B
>
applied to drm-misc-next.
On Mon, Feb 17, 2020 at 9:20 AM Qiang Yu wrote:
>
> Looks good for me, patch is:
> Reviewed-by: Qiang Yu
>
> Regards,
> Qiang
>
> On Sat, Feb 15, 2020 at 11:50 AM Vasily Khoruzhick wrote:
> >
> > It looks like on PLBU_OUT_OF_MEM interrupt we need to resume from where
20. 2. 12. 오전 1:22에 Ville Syrjala 이(가) 쓴 글:
> From: Ville Syrjälä
>
> Replace the hand rolled encoder bitmask thing with drm_encoder_mask()
>
> Cc: Inki Dae
> Cc: Joonyoung Shim
> Cc: Seung-Woo Kim
> Cc: Kyungmin Park
> Acked-by: Thomas Zimmermann
> Signed-off-by: Ville Syrjälä
Looks good for me, patch is:
Reviewed-by: Qiang Yu
Regards,
Qiang
On Sat, Feb 15, 2020 at 11:50 AM Vasily Khoruzhick wrote:
>
> It looks like on PLBU_OUT_OF_MEM interrupt we need to resume from where we
> stopped, i.e. new PLBU heap start is old end. Also update end address
> in GP frame to
https://bugzilla.kernel.org/show_bug.cgi?id=200695
babgozd (babgoz...@outlook.com) changed:
What|Removed |Added
CC||babgoz...@outlook.com
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
---
drivers/gpu/drm/omapdrm/dss/hdmi5.c | 86 -
1 file
This makes it easier to quickly locate duplicate includes.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/dpi.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/dpi.c
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
---
drivers/gpu/drm/omapdrm/dss/hdmi.h | 1 -
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 18
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
---
drivers/gpu/drm/omapdrm/dss/dpi.c | 146 --
1 file
Inline the omapdss_display_get() in its only caller to simplify the
code.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/display.c | 9 -
drivers/gpu/drm/omapdrm/dss/omapdss.h | 1 -
drivers/gpu/drm/omapdrm/omap_drv.c| 7 ---
3 files
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
---
drivers/gpu/drm/omapdrm/dss/venc.c | 45 --
1 file changed, 45
The HDMI4 encoder is transitioning to the drm_bridge API, implement the
last missing operation.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 10 ++
1 file changed, 10 insertions(+)
diff --git
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.
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
---
Changes since v1:
-
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
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
---
drivers/gpu/drm/omapdrm/omap_connector.c | 11 ---
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
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
---
Changes since v2:
- Control CT_CP_HPD GPIO from .hpd_enable() and .hpd_disable()
This makes it easier to quickly locate duplicate includes.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/sdi.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/sdi.c
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
---
drivers/gpu/drm/omapdrm/dss/dpi.c | 32
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
---
Changes since v1:
- Keep MAX_EDID macro
---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 36
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
---
The omapdss_of_find_connected_device() function isn't used anymore,
remove it.
Signed-off-by: Laurent Pinchart
Reviewed-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/dss/Makefile | 2 +-
drivers/gpu/drm/omapdrm/dss/dss-of.c | 28 ---
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
---
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
---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 61
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
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
---
The omap_connector implementation is now used for DSI only. Hardcode its
type and drop unused code.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/base.c | 23 --
drivers/gpu/drm/omapdrm/dss/omapdss.h| 1 -
drivers/gpu/drm/omapdrm/omap_connector.c |
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
---
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
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
---
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
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
---
drivers/gpu/drm/omapdrm/dss/omapdss.h | 3 ---
drivers/gpu/drm/omapdrm/omap_encoder.c | 26
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 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
---
drivers/gpu/drm/omapdrm/dss/base.c | 26 ---
drivers/gpu/drm/omapdrm/dss/omapdss.h | 6
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
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
---
Changes since
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:
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 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.
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
---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 96 -
1 file
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
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
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
---
drivers/gpu/drm/omapdrm/dss/base.c | 23
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
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
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
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
---
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 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
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
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
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
---
Changes since v2:
- Use the connector type from the panel instead of hardcoding
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.
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
---
include/drm/drm_bridge.h | 5 +
1
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
---
Changes since v1:
- Removed documentation of
Hi Dave,
Got a few more fixes this time around, so decided to send a dedicated
-fixes PR rather than try to route these all through -misc like we do
when there are only a couple misc fixes. It mostly boils down to
fixing fallout from new hw enablement (sc7180):
+ fix UBWC on GPU and display
RFC only - not tested yet!
The panel-dpi compatible is a fallback that
allows the DT to specify the timing.
When matching panel-dpi expect the device tree to include the
timing information for the display-panel.
Background for this change:
There are a lot of panels and new models hits the
This set of patches convert display-timing.txt to DT schema.
To do that add a panel-timing.yaml file that include all the
panel-timing properties and use this in panel-common and in display-timings.
panel-dpi was also converted so we have no .txt users left of panel-timing
in panel/
Everything
With panel-timing converted, now convert the single
remaining .txt user in panel/ of panel-timing to DT schema.
v2:
- Drop Thierry as maintainer, as this is not a general panel binding
and I have no acks.
- Drop requirement for a panel- specific binding - "panel-dpi" is enough
- Updated
Add meta-schema variant of panel-timing and
reference it from panel-common.yaml.
Part of this came form other files with other
licenses - original commits:
cc3f414cf2e4 ("video: add of helper for display timings/videomode")
86f46565dff3 ("dt-bindings: display: display-timing: Add property to
Add data-mapping property that can be used to specify
the media format used for the connection betwwen the
display controller (connector) and the panel.
Signed-off-by: Sam Ravnborg
---
.../devicetree/bindings/display/panel/panel-dpi.yaml | 12 +++-
1 file changed, 11 insertions(+), 1
Add display-timings.yaml - that references panel-timings.yaml.
display-timings.yaml will be used for display bindings
when they are converted to meta-schema format.
For now the old display-timing.txt points to the new
display-timings.yaml - and all users are left as-is.
v2:
- Updated
A Multifunction USB Device is a device that supports functions like gpio
and display or any other function that can be represented as a USB regmap.
Interrupts over USB is also supported if such an endpoint is present.
Signed-off-by: Noralf Trønnes
---
drivers/mfd/Kconfig | 8 +
The Multifunction USB Device has optional support for displays.
LZ4 compression is used if the device supports it.
The driver is MIT licensed in the hope that parts of it can be used on
the BSD's.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/Kconfig |2 +
Add optional gpio functionality to the Multifunction USB Device.
Signed-off-by: Noralf Trønnes
---
drivers/usb/gadget/Kconfig | 14 +
drivers/usb/gadget/function/Makefile | 2 +
drivers/usb/gadget/function/f_mud_pins.c | 962 +++
3 files changed, 978
This is the gadget side of the mfd host driver. It provides a USB
function that drivers can hook into providing functions like gpio and
display as regmaps to the host. These drivers are configured through
configfs.
Signed-off-by: Noralf Trønnes
---
drivers/usb/gadget/Kconfig | 10
drm_client_init_from_id() provides a way for clients to add a client based
on the minor. drm_client_modeset_set() provides a way to set the modeset
for clients that handles connectors and display mode on their own.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_client.c | 37
Add optional display functionality to the Multifunction USB Device.
The bulk of the code is placed in the drm subsystem since it's reaching
into the drm internals.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/mud/Kconfig | 3 +
drivers/gpu/drm/mud/Makefile| 1 +
The Multifunction USB Device has optional support for gpio and pin
configuration. Interrupts are supported if the device supports it.
Signed-off-by: Noralf Trønnes
---
drivers/pinctrl/Kconfig | 9 +
drivers/pinctrl/Makefile | 1 +
drivers/pinctrl/pinctrl-mud.c | 657
Hi,
A while back I had the idea to turn a Raspberry Pi Zero into a $5
USB to HDMI/SDTV/DSI/DPI display adapter.
Thinking about how to represent the display to the driver I realised
that hardware use registers as API. And Linux does have a generic
register abstraction: regmap. Furthermore this
Add support for regmap over USB for use with the Multifunction USB Device.
Two endpoints IN/OUT are used. Up to 255 regmaps are supported on one USB
interface. The register index width is always 32-bit, but the register
value can be 8, 16 or 32 bits wide. LZ4 compression is supported on bulk
When writing a 3MB buffer the unwritable check in _regmap_raw_write_impl()
adds a ~20ms overhead on a Raspberry Pi 4.
Amend this by avoiding the check if it's not necessary.
Signed-off-by: Noralf Trønnes
---
drivers/base/regmap/regmap.c | 10 ++
1 file changed, 6 insertions(+), 4
Hi Tomi,
On Tue, Jan 28, 2020 at 01:19:53PM +0200, Tomi Valkeinen wrote:
> On 24/01/2020 05:54, Laurent Pinchart wrote:
>
> > +struct drm_connector *drm_bridge_connector_init(struct drm_device *drm,
> > + struct drm_encoder *encoder)
> > +{
> > +
Hi Yuti,
Thank you for the patch.
On Wed, Feb 12, 2020 at 05:26:42AM +0100, Yuti Amonkar wrote:
> Document the bindings used for the Cadence MHDP DPI/DP bridge in
> yaml format.
>
> Signed-off-by: Yuti Amonkar
> Reviewed-by: Rob Herring
> ---
> .../bindings/display/bridge/cdns,mhdp.yaml|
Hi Yuti,
On Sun, Feb 16, 2020 at 05:28:40PM +0200, Laurent Pinchart wrote:
> On Thu, Feb 13, 2020 at 11:16:51AM +0200, Tomi Valkeinen wrote:
> > On 12/02/2020 06:26, Yuti Amonkar wrote:
> > > Document the bindings used for the Cadence MHDP DPI/DP bridge in
> > > yaml format.
> > >
> > >
Hi Yuti,
Thank you for the patch.
On Thu, Feb 13, 2020 at 11:16:51AM +0200, Tomi Valkeinen wrote:
> On 12/02/2020 06:26, Yuti Amonkar wrote:
> > Document the bindings used for the Cadence MHDP DPI/DP bridge in
> > yaml format.
> >
> > Signed-off-by: Yuti Amonkar
> > Reviewed-by: Rob Herring
>
https://bugzilla.kernel.org/show_bug.cgi?id=200695
--- Comment #37 from Adam (magicm...@magicmyth.com) ---
As several comments mention different behavior between the different connector
types I found a spare DVI cable and tried connecting to the same monitor via
that input and it worked! So once
On Sat, Feb 15, 2020 at 9:08 PM Sam Ravnborg wrote:
>
> Hi Daniel.
>
> > > I also checked private_flags - it is used in a few modules.
> > > And it looked legit.
> > >
> > Iirc i915 used this, before we went full overdrive with entire atomic
> > state structure subclassing :-)
>
> $ git grep -l
86 matches
Mail list logo
