| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The TC358767/TC358867/TC9595 are all capable of operating in multiple
modes, DPI-to-(e)DP, DSI-to-(e)DP, DSI-to-DPI. Add support for the
DSI-to-DPI mode.
This requires skipping most of the (e)DP initialization code, which is
currently a large part of this driver, hence it is better to have far
simpler separate tc_dpi_bridge_funcs and their implementation.
The configuration of DPI output is also much simpler. The configuration
of the DSI input is rather similar to the other TC bridge chips.
The Pixel PLL in DPI output mode does not have the 65..150 MHz limitation
imposed on the (e)DP output mode, so this limitation is skipped to permit
operating panels with far slower pixel clock, even below 9 MHz. This mode
of operation of the PLL is valid and tested.
The detection of bridge mode is now added into tc_probe_bridge_mode(),
where in case a DPI panel is found on port@1 endpoint@1, the mode is
assumed to be DSI-to-DPI. If (e)DP is detected on port@2, the mode is
assumed to be DPI-to-(e)DP.
The DSI-to-(e)DP mode is not supported due to lack of proper hardware,
but this would be some sort of mix between the two aforementioned modes.
Reviewed-by: Lucas Stach <[email protected]>
Signed-off-by: Marek Vasut <[email protected]>
Cc: Jonas Karlman <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Maxime Ripard <[email protected]>
Cc: Neil Armstrong <[email protected]>
Cc: Sam Ravnborg <[email protected]>
Signed-off-by: Robert Foss <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The tc_set_video_mode() sets up both common and (e)DP video mode settings of
the bridge chip. Split the function into tc_set_common_video_mode() to set
the common settings and tc_set_edp_video_mode() to set the (e)DP specific
settings. No functional change.
Reviewed-by: Lucas Stach <[email protected]>
Tested-by: Lucas Stach <[email protected]> # In both DPI to eDP and DSI to DPI mode.
Signed-off-by: Marek Vasut <[email protected]>
Cc: Jonas Karlman <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Maxime Ripard <[email protected]>
Cc: Neil Armstrong <[email protected]>
Cc: Sam Ravnborg <[email protected]>
Signed-off-by: Robert Foss <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The TC358767/TC358867/TC9595 are all capable of operating in multiple
modes, DPI-to-(e)DP, DSI-to-(e)DP, DSI-to-DPI. Only the first mode is
currently supported. It is possible to find out the mode in which the
bridge should be operated by testing connected endpoints in DT.
Port allocation:
port@0 - DSI input
port@1 - DPI input/output
port@2 - eDP output
Possible connections:
DPI -> port@1 -> port@2 -> eDP :: [port@0 is not connected]
DSI -> port@0 -> port@2 -> eDP :: [port@1 is not connected]
DSI -> port@0 -> port@1 -> DPI :: [port@2 is not connected]
Add function to determine the bridge mode based on connected endpoints.
Reviewed-by: Lucas Stach <[email protected]>
Tested-by: Lucas Stach <[email protected]> # In both DPI to eDP and DSI to DPI mode.
Signed-off-by: Marek Vasut <[email protected]>
Cc: Jonas Karlman <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Maxime Ripard <[email protected]>
Cc: Neil Armstrong <[email protected]>
Cc: Sam Ravnborg <[email protected]>
Signed-off-by: Robert Foss <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The bridge ops are specific to the bridge configuration, move them
into tc_probe_edp_bridge_endpoint() to permit cleaner addition of
DSI-to-DPI mode. No functional change.
Reviewed-by: Lucas Stach <[email protected]>
Tested-by: Lucas Stach <[email protected]> # In both DPI to eDP and DSI to DPI mode.
Signed-off-by: Marek Vasut <[email protected]>
Cc: Jonas Karlman <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Maxime Ripard <[email protected]>
Cc: Neil Armstrong <[email protected]>
Cc: Sam Ravnborg <[email protected]>
Signed-off-by: Robert Foss <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This bit of code is (e)DP and aux I2C link specific, move it into
tc_aux_link_setup() to permit cleaner addition of DSI-to-DPI mode.
No functional change.
Reviewed-by: Lucas Stach <[email protected]>
Tested-by: Lucas Stach <[email protected]> # In both DPI to eDP and DSI to DPI mode.
Signed-off-by: Marek Vasut <[email protected]>
Cc: Jonas Karlman <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Maxime Ripard <[email protected]>
Cc: Neil Armstrong <[email protected]>
Cc: Sam Ravnborg <[email protected]>
Signed-off-by: Robert Foss <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The TC358767/TC358867/TC9595 are all capable of operating in multiple
modes, DPI-to-(e)DP, DSI-to-(e)DP, DSI-to-DPI. Only the first mode is
currently supported. In order to support the rest of the modes without
making the tc_probe() overly long, split the bridge endpoint parsing
into dedicated function, where the necessary logic to detect the bridge
mode based on which endpoints are connected, can be implemented.
Reviewed-by: Lucas Stach <[email protected]>
Tested-by: Lucas Stach <[email protected]> # In both DPI to eDP and DSI to DPI mode.
Signed-off-by: Marek Vasut <[email protected]>
Cc: Jonas Karlman <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Maxime Ripard <[email protected]>
Cc: Neil Armstrong <[email protected]>
Cc: Sam Ravnborg <[email protected]>
Signed-off-by: Robert Foss <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Implement .atomic_check callback which prevents user space from setting
unsupported mode. The tc_edp_common_atomic_check() variant is already
prepared for DSI-to-DPI mode addition, which has different frequency
limits.
Reviewed-by: Lucas Stach <[email protected]>
Tested-by: Lucas Stach <[email protected]> # In both DPI to eDP and DSI to DPI mode.
Signed-off-by: Marek Vasut <[email protected]>
Cc: Jonas Karlman <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Maxime Ripard <[email protected]>
Cc: Neil Armstrong <[email protected]>
Cc: Sam Ravnborg <[email protected]>
Signed-off-by: Robert Foss <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Use the atomic version of the enable/disable operations to continue the
transition to the atomic API. This will be needed to access the mode
from the atomic state.
Reviewed-by: Lucas Stach <[email protected]>
Tested-by: Lucas Stach <[email protected]> # In both DPI to eDP and DSI to DPI mode.
Signed-off-by: Marek Vasut <[email protected]>
Cc: Jonas Karlman <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Maxime Ripard <[email protected]>
Cc: Neil Armstrong <[email protected]>
Cc: Sam Ravnborg <[email protected]>
Signed-off-by: Robert Foss <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
These functions are specific to (e)DP output initialization and
operation, add specific tc_edp_ prefix to those functions to
discern them from DPI output functions that will be added later
in this series. No functional change.
Reviewed-by: Lucas Stach <[email protected]>
Tested-by: Lucas Stach <[email protected]> # In both DPI to eDP and DSI to DPI mode.
Signed-off-by: Marek Vasut <[email protected]>
Cc: Jonas Karlman <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Maxime Ripard <[email protected]>
Cc: Neil Armstrong <[email protected]>
Cc: Sam Ravnborg <[email protected]>
Signed-off-by: Robert Foss <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
struct drm_display_mode embeds a list head, so overwriting
the full struct with another one will corrupt the list
(if the destination mode is on a list). Use drm_mode_copy()
instead which explicitly preserves the list head of
the destination mode.
Even if we know the destination mode is not on any list
using drm_mode_copy() seems decent as it sets a good
example. Bad examples of not using it might eventually
get copied into code where preserving the list head
actually matters.
Obviously one case not covered here is when the mode
itself is embedded in a larger structure and the whole
structure is copied. But if we are careful when copying
into modes embedded in structures I think we can be a
little more reassured that bogus list heads haven't been
propagated in.
@is_mode_copy@
@@
drm_mode_copy(...)
{
...
}
@depends on !is_mode_copy@
struct drm_display_mode *mode;
expression E, S;
@@
(
- *mode = E
+ drm_mode_copy(mode, &E)
|
- memcpy(mode, E, S)
+ drm_mode_copy(mode, E)
)
@depends on !is_mode_copy@
struct drm_display_mode mode;
expression E;
@@
(
- mode = E
+ drm_mode_copy(&mode, &E)
|
- memcpy(&mode, E, S)
+ drm_mode_copy(&mode, E)
)
@@
struct drm_display_mode *mode;
@@
- &*mode
+ mode
Cc: Andrzej Hajda <[email protected]>
Cc: Neil Armstrong <[email protected]>
Cc: Robert Foss <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Jonas Karlman <[email protected]>
Cc: Jernej Skrabec <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Andrzej Hajda <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
|
|
Move all public DisplayPort headers into dp/ and update users. No
functional changes.
v3:
* rebased onto latest drm-tip
Signed-off-by: Thomas Zimmermann <[email protected]>
Acked-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This is something that we've wanted for a while now: the ability to
actually look up the respective drm_device for a given drm_dp_aux struct.
This will also allow us to transition over to using the drm_dbg_*() helpers
for debug message printing, as we'll finally have a drm_device to reference
for doing so.
Note that there is one limitation with this - because some DP AUX adapters
exist as platform devices which are initialized independently of their
respective DRM devices, one cannot rely on drm_dp_aux->drm_dev to always be
non-NULL until drm_dp_aux_register() has been called. We make sure to point
this out in the documentation for struct drm_dp_aux.
v3:
* Add WARN_ON_ONCE() to drm_dp_aux_register() if drm_dev isn't filled out
Signed-off-by: Lyude Paul <[email protected]>
Acked-by: Thierry Reding <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Dave Airlie <[email protected]>
|
|
Since this is a bridge, we don't start out with a respective DRM device.
Likewise this means we don't have a connector, which also means that we
should be following drm_dp_aux_register()'s documentation advice and not
call drm_dp_aux_register() until we have a matching connector. Instead,
call drm_dp_aux_init() in tc_probe() and wait until tc_bridge_attach() to
register our AUX channel. We also add tc_bridge_detach() to handle
unregistering the AUX adapter once the bridge has been disconnected.
Signed-off-by: Lyude Paul <[email protected]>
Reviewed-by: Robert Foss <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
With the bridge operations implemented the last step to prepare
this driver for a chained setup is the use of the bridge panel driver.
The bridge panel driver is only used when a port@2 is present in
the DT. So when the display driver requests a connector
support both situations:
- connector created by bridge panel driver
- connector created by this driver
And on top, support that the display driver creates the connector,
which is the preferred setup.
Note: the bridge panel will use the connector type from the panel.
v3:
- Fix wrong logic in connector creation (Laurent)
v2:
- Merge connector and drm_panel_bridge patches
and fix so we do not create two connectors (Laurent)
Signed-off-by: Sam Ravnborg <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Andrzej Hajda <[email protected]>
Cc: Neil Armstrong <[email protected]>
Cc: Jonas Karlman <[email protected]>
Cc: Jernej Skrabec <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Prepare for chained bridge with the addition of
get_edid support.
v2:
- Fixed handling of edid storage (Laurent)
Signed-off-by: Sam Ravnborg <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Cc: Andrzej Hajda <[email protected]>
Cc: Neil Armstrong <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Jonas Karlman <[email protected]>
Cc: Jernej Skrabec <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Prepare the bridge driver for chained operation by adding
support for the detect operation.
v3:
- Fix code to make it readable (Laurent)
v2:
- Do not announce detect operation if there is no hpd pin (Laurent)
Signed-off-by: Sam Ravnborg <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Cc: Andrzej Hajda <[email protected]>
Cc: Neil Armstrong <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Jonas Karlman <[email protected]>
Cc: Jernej Skrabec <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
When validating a mode, bridges may need to do so in the context of a
display, as specified by drm_display_info. An example is the meson
dw-hdmi bridge that needs to consider the YUV 4:2:0 output format to
perform clock calculations.
Bridges that need the display info currently retrieve it from the
drm_connector created by the bridge. This gets in the way of moving
connector creation out of bridge drivers. To make this possible, pass
the drm_display_info to drm_bridge_funcs .mode_valid().
Changes to the bridge drivers have been performed with the following
coccinelle semantic patch and have been compile-tested.
@ rule1 @
identifier funcs;
identifier fn;
@@
struct drm_bridge_funcs funcs = {
...,
.mode_valid = fn
};
@ depends on rule1 @
identifier rule1.fn;
identifier bridge;
identifier mode;
@@
enum drm_mode_status fn(
struct drm_bridge *bridge,
+ const struct drm_display_info *info,
const struct drm_display_mode *mode
)
{
...
}
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Reviewed-by: Boris Brezillon <[email protected]>
Reviewed-by: Guido Günther <[email protected]> # for the nwl-dsi part:
Signed-off-by: Sam Ravnborg <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/20200526011505.31884-11-laurent.pinchart+renesas@ideasonboard.com
|
|
Requested my mripard for some misc patches that need this as a base.
Signed-off-by: Dave Airlie <[email protected]>
|
|
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 components. For instance a
pipeline with a bridge connected to the DDC signals to read EDID data,
and another one connected to the HPD signal to detect connection and
disconnection, will not be possible to support through this model.
- It requires every bridge driver to implement similar connector
handling code, resulting in code duplication.
- It assumes that a bridge will either be wired to a connector or to
another bridge, but doesn't support bridges that can be used in both
positions very well (although there is some ad-hoc support for this in
the analogix_dp bridge driver).
In order to solve these issues, ownership of the connector should be
moved to the display controller driver (where it can be implemented
using helpers provided by the core).
Extend the bridge API to allow disabling connector creation in bridge
drivers as a first step towards the new model. The new flags argument to
the bridge .attach() operation allows instructing the bridge driver to
skip creating a connector. Unconditionally set the new flags argument to
0 for now to keep the existing behaviour, and modify all existing bridge
drivers to return an error when connector creation is not requested as
they don't support this feature yet.
The change is based on the following semantic patch, with manual review
and edits.
@ rule1 @
identifier funcs;
identifier fn;
@@
struct drm_bridge_funcs funcs = {
...,
.attach = fn
};
@ depends on rule1 @
identifier rule1.fn;
identifier bridge;
statement S, S1;
@@
int fn(
struct drm_bridge *bridge
+ , enum drm_bridge_attach_flags flags
)
{
... when != S
+ if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
+ DRM_ERROR("Fix bridge driver to make connector optional!");
+ return -EINVAL;
+ }
+
S1
...
}
@ depends on rule1 @
identifier rule1.fn;
identifier bridge, flags;
expression E1, E2, E3;
@@
int fn(
struct drm_bridge *bridge,
enum drm_bridge_attach_flags flags
) {
<...
drm_bridge_attach(E1, E2, E3
+ , flags
)
...>
}
@@
expression E1, E2, E3;
@@
drm_bridge_attach(E1, E2, E3
+ , 0
)
Signed-off-by: Laurent Pinchart <[email protected]>
Reviewed-by: Boris Brezillon <[email protected]>
Acked-by: Sam Ravnborg <[email protected]>
Reviewed-by: Tomi Valkeinen <[email protected]>
Tested-by: Sebastian Reichel <[email protected]>
Reviewed-by: Sebastian Reichel <[email protected]>
Acked-by: Daniel Vetter <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
We're based on v5.6, need v5.6-rc1 at least. :)
Signed-off-by: Maarten Lankhorst <[email protected]>
|
|
Link training fails with:
Link training timeout waiting for LT_LOOPDONE!
main link enable error: -110
This is caused by too tight timeouts, which were changed recently in
aa92213f388b ("drm/bridge: tc358767: Simplify polling in tc_link_training()").
With a quick glance, the commit does not change the timeouts. However,
the method of delaying/sleeping is different, and as the timeout in the
previous implementation was not explicit, the new version in practice
has much tighter timeout.
The same change was made to other parts in the driver, but the link
training timeout is the only one I have seen causing issues.
Nevertheless, 1 us sleep is not very sane, and the timeouts look pretty
tight, so lets fix all the timeouts.
One exception was the aux busy poll, where the poll sleep was much
longer than necessary (or optimal).
I measured the times on my setup, and now the sleep times are set to
such values that they result in multiple loops, but not too many (say,
5-10 loops). The timeouts were all increased to 100ms, which should be
more than enough for all of these, but in case of bad errors, shouldn't
stop the driver as multi-second timeouts could do.
Signed-off-by: Tomi Valkeinen <[email protected]>
Fixes: aa92213f388b ("drm/bridge: tc358767: Simplify polling in tc_link_training()")
Tested-by: Andrey Smirnov <[email protected]>
Reviewed-by: Neil Armstrong <[email protected]>
Signed-off-by: Neil Armstrong <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
To facilitate moving connector creation to display drivers,
decouple the drm_connector from drm_panel.
This patch adds a connector argument to drm_panel_get_modes().
All users of drm_panel_get_modes() already had the connector
available, so updating users was trivial.
With this patch drm_panel no longer keeps a reference to the drm_connector.
Signed-off-by: Sam Ravnborg <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Acked-by: Jeffrey Hugo <[email protected]>
Cc: Thierry Reding <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Sam Ravnborg <[email protected]>
Cc: Andrzej Hajda <[email protected]>
Cc: Neil Armstrong <[email protected]>
Cc: Jonas Karlman <[email protected]>
Cc: Jernej Skrabec <[email protected]>
Cc: Maarten Lankhorst <[email protected]>
Cc: Maxime Ripard <[email protected]>
Cc: David Airlie <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Inki Dae <[email protected]>
Cc: Joonyoung Shim <[email protected]>
Cc: Seung-Woo Kim <[email protected]>
Cc: Kyungmin Park <[email protected]>
Cc: Kukjin Kim <[email protected]>
Cc: Krzysztof Kozlowski <[email protected]>
Cc: Stefan Agner <[email protected]>
Cc: Alison Wang <[email protected]>
Cc: Philipp Zabel <[email protected]>
Cc: Shawn Guo <[email protected]>
Cc: Sascha Hauer <[email protected]>
Cc: Pengutronix Kernel Team <[email protected]>
Cc: Fabio Estevam <[email protected]>
Cc: NXP Linux Team <[email protected]>
Cc: CK Hu <[email protected]>
Cc: Matthias Brugger <[email protected]>
Cc: Marek Vasut <[email protected]>
Cc: Tomi Valkeinen <[email protected]>
Cc: Kieran Bingham <[email protected]>
Cc: Sandy Huang <[email protected]>
Cc: "Heiko Stübner" <[email protected]>
Cc: Benjamin Gaignard <[email protected]>
Cc: Vincent Abriou <[email protected]>
Cc: Chen-Yu Tsai <[email protected]>
Cc: Jonathan Hunter <[email protected]>
Cc: Torsten Duwe <[email protected]>
Cc: Vasily Khoruzhick <[email protected]>
Cc: Icenowy Zheng <[email protected]>
Cc: Sean Paul <[email protected]>
Cc: Linus Walleij <[email protected]>
Cc: Boris Brezillon <[email protected]>
Cc: Hariprasad Kelam <[email protected]>
Cc: Alexios Zavras <[email protected]>
Cc: Brian Masney <[email protected]>
Cc: Rob Clark <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Allison Randal <[email protected]>
Cc: Shayenne Moura <[email protected]>
Cc: Abhinav Kumar <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The DP specification uses the term "default framing" instead of "non-
enhanced framing".
Reviewed-by: Andrzej Hajda <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
During the discussion of patches that enhance the drm_dp_link helpers it
was concluded that these helpers aren't very useful to begin with. Start
pushing the equivalent code into individual drivers to ultimately remove
them.
v3: make link rate unsigned int to avoid overflow
Signed-off-by: Thierry Reding <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Thierry needs fd70c7755bf0 ("drm/bridge: tc358767: fix max_tu_symbol
value") to be able to merge his dp_link patch series.
Some adjacent changes conflicts, plus some clashes in i915 due to
cherry-picking and git trying to be helpful and leaving both versions
in.
Signed-off-by: Daniel Vetter <[email protected]>
|
|
max_tu_symbol was programmed to TU_SIZE_RECOMMENDED - 1, which is not
what the spec says. The spec says:
roundup ((input active video bandwidth in bytes/output active video
bandwidth in bytes) * tu_size)
It is not quite clear what the above means, but calculating
max_tu_symbol = (input Bps / output Bps) * tu_size seems to work and
fixes the issues seen.
This fixes artifacts in some videomodes (e.g. 1024x768@60 on 2-lanes &
1.62Gbps was pretty bad for me).
Signed-off-by: Tomi Valkeinen <[email protected]>
Tested-by: Jyri Sarha <[email protected]>
Signed-off-by: Andrzej Hajda <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
We are about to add a drm_bridge_state that inherits from
drm_private_state which is defined in drm_atomic.h. Problem is,
drm_atomic.h includes drm_crtc.h which in turn includes drm_bridge.h,
leading to "drm_private_state has incomplete type" error.
Let's force all users of the drm_bridge API to explicitly include
drm_bridge.h.
Signed-off-by: Boris Brezillon <[email protected]>
Reviewed-by: Sam Ravnborg <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Replace open coded version with call to drm_panel_get_modes().
Include change to deal with the possible negative
return values from drm_panel_get_modes()
v2:
- Added more info to changelog (Philipp)
Signed-off-by: Sam Ravnborg <[email protected]>
Reviewed-by: Philipp Zabel <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
Cc: Andrzej Hajda <[email protected]>
Cc: Neil Armstrong <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Jonas Karlman <[email protected]>
Cc: Jernej Skrabec <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
To get the chip into the expected state, even when the hardware reset pin
isn't connected, do a software reset in this case. It isn't as thorough as
the hardware reset, as the I2C communication block can not be reset for
obvious reasons, but it's getting the chip into a defined state.
Signed-off-by: Lucas Stach <[email protected]>
Signed-off-by: Andrzej Hajda <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Transfer size of zero means a request to do an address-only
transfer. Since the HW support this, we probably shouldn't be just
ignoring such requests. While at it allow DP_AUX_I2C_MOT flag to pass
through, since it is supported by the HW as well.
Signed-off-by: Andrey Smirnov <[email protected]>
Reviewed-by: Andrzej Hajda <[email protected]>
Reviewed-by: Tomi Valkeinen <[email protected]>
Cc: Andrzej Hajda <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Tomi Valkeinen <[email protected]>
Cc: Andrey Gusakov <[email protected]>
Cc: Philipp Zabel <[email protected]>
Cc: Cory Tusar <[email protected]>
Cc: Chris Healy <[email protected]>
Cc: Lucas Stach <[email protected]>
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Andrzej Hajda <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
We don't need 8 byte array, DP_LINK_STATUS_SIZE (6) should be
enough. This also gets rid of a magic number as a bonus.
Signed-off-by: Andrey Smirnov <[email protected]>
Reviewed-by: Andrzej Hajda <[email protected]>
Reviewed-by: Tomi Valkeinen <[email protected]>
Cc: Andrzej Hajda <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Tomi Valkeinen <[email protected]>
Cc: Andrey Gusakov <[email protected]>
Cc: Philipp Zabel <[email protected]>
Cc: Cory Tusar <[email protected]>
Cc: Chris Healy <[email protected]>
Cc: Lucas Stach <[email protected]>
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Andrzej Hajda <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
tc_get_display_props() never reads more than a byte via AUX, so
there's no need to reserve 8 for that purpose. No function change
intended.
Signed-off-by: Andrey Smirnov <[email protected]>
Reviewed-by: Andrzej Hajda <[email protected]>
Reviewed-by: Tomi Valkeinen <[email protected]>
Cc: Andrzej Hajda <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Tomi Valkeinen <[email protected]>
Cc: Andrey Gusakov <[email protected]>
Cc: Philipp Zabel <[email protected]>
Cc: Cory Tusar <[email protected]>
Cc: Chris Healy <[email protected]>
Cc: Lucas Stach <[email protected]>
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Andrzej Hajda <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
We never pass anything but 100 as timeout_ms to tc_aux_wait_busy(), so
we may as well hardcode that value and simplify function's signature.
Signed-off-by: Andrey Smirnov <[email protected]>
Reviewed-by: Andrzej Hajda <[email protected]>
Reviewed-by: Tomi Valkeinen <[email protected]>
Cc: Andrzej Hajda <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Tomi Valkeinen <[email protected]>
Cc: Andrey Gusakov <[email protected]>
Cc: Philipp Zabel <[email protected]>
Cc: Cory Tusar <[email protected]>
Cc: Chris Healy <[email protected]>
Cc: Lucas Stach <[email protected]>
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Andrzej Hajda <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
tc_wait_pll_lock() is always called as a follow-up for updating
PLLUPDATE and PLLEN bit of a given PLL control register. To simplify
things, merge the two operation into a single helper function
tc_pllupdate() and convert the rest of the code to use it. No
functional change intended.
Signed-off-by: Andrey Smirnov <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Reviewed-by: Andrzej Hajda <[email protected]>
Reviewed-by: Tomi Valkeinen <[email protected]>
Cc: Andrzej Hajda <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Tomi Valkeinen <[email protected]>
Cc: Andrey Gusakov <[email protected]>
Cc: Philipp Zabel <[email protected]>
Cc: Cory Tusar <[email protected]>
Cc: Chris Healy <[email protected]>
Cc: Lucas Stach <[email protected]>
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Andrzej Hajda <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Move common code converting clock rate to an appropriate constant and
configuring SYS_PLLPARAM register into a separate routine and convert
the rest of the code to use it. No functional change intended.
Signed-off-by: Andrey Smirnov <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Reviewed-by: Andrzej Hajda <[email protected]>
Reviewed-by: Tomi Valkeinen <[email protected]>
Cc: Andrzej Hajda <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Tomi Valkeinen <[email protected]>
Cc: Andrey Gusakov <[email protected]>
Cc: Philipp Zabel <[email protected]>
Cc: Chris Healy <[email protected]>
Cc: Cory Tusar <[email protected]>
Cc: Lucas Stach <[email protected]>
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Andrzej Hajda <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Don't assume that requested data transfer size is the same as amount
of data that was transferred. Change the code to get that information
from DP0_AUXSTATUS instead.
Since the check for AUX_BUSY in tc_aux_get_status() is pointless (it
will always called after tc_aux_wait_busy()) and there's only one user
of it, inline its code into tc_aux_transfer() instead of trying to
accommodate the change above.
Signed-off-by: Andrey Smirnov <[email protected]>
Reviewed-by: Andrzej Hajda <[email protected]>
Reviewed-by: Tomi Valkeinen <[email protected]>
Cc: Andrzej Hajda <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Tomi Valkeinen <[email protected]>
Cc: Andrey Gusakov <[email protected]>
Cc: Philipp Zabel <[email protected]>
Cc: Cory Tusar <[email protected]>
Cc: Chris Healy <[email protected]>
Cc: Lucas Stach <[email protected]>
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Andrzej Hajda <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
According to the datasheet tc358767 can transfer up to 16 bytes via
its AUX channel, so the artificial limit of 8 appears to be too
low. However only up to 15-bytes seem to be actually supported and
trying to use 16-byte transfers results in transfers failing
sporadically (with bogus status in case of I2C transfers), so limit it
to 15.
Signed-off-by: Andrey Smirnov <[email protected]>
Reviewed-by: Andrzej Hajda <[email protected]>
Reviewed-by: Tomi Valkeinen <[email protected]>
Cc: Andrzej Hajda <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Tomi Valkeinen <[email protected]>
Cc: Andrey Gusakov <[email protected]>
Cc: Philipp Zabel <[email protected]>
Cc: Cory Tusar <[email protected]>
Cc: Chris Healy <[email protected]>
Cc: Lucas Stach <[email protected]>
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Andrzej Hajda <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Simplify AUX data write by dropping index arithmetic and shifting and
replacing it with a call to a helper function that does two things:
1. Copies user-provided data into a write buffer
2. Transfers contents of the write buffer to up to 4 32-bit
registers on the chip
Note that separate data endianness fix:
tmp = (tmp << 8) | buf[i];
that was reserved for DP_AUX_I2C_WRITE looks really strange, since it
will place data differently depending on the passed user-data
size. E.g. for a write of 1 byte, data transferred to the chip would
look like:
[byte0] [dummy1] [dummy2] [dummy3]
whereas for a write of 4 bytes we'd get:
[byte3] [byte2] [byte1] [byte0]
Since there's no indication in the datasheet that I2C write buffer
should be treated differently than AUX write buffer and no comment in
the original code explaining why it was done this way, that special
I2C write buffer transformation was dropped in this patch.
Signed-off-by: Andrey Smirnov <[email protected]>
Reviewed-by: Andrzej Hajda <[email protected]>
Reviewed-by: Tomi Valkeinen <[email protected]>
Cc: Andrzej Hajda <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Tomi Valkeinen <[email protected]>
Cc: Andrey Gusakov <[email protected]>
Cc: Philipp Zabel <[email protected]>
Cc: Cory Tusar <[email protected]>
Cc: Chris Healy <[email protected]>
Cc: Lucas Stach <[email protected]>
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Andrzej Hajda <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Simplify AUX data read by removing index arithmetic and shifting with
a helper function that does two things:
1. Fetch data from up to 4 32-bit registers from the chip
2. Copy read data into user provided array.
Signed-off-by: Andrey Smirnov <[email protected]>
Reviewed-by: Andrzej Hajda <[email protected]>
Reviewed-by: Tomi Valkeinen <[email protected]>
Cc: Andrzej Hajda <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Tomi Valkeinen <[email protected]>
Cc: Andrey Gusakov <[email protected]>
Cc: Philipp Zabel <[email protected]>
Cc: Cory Tusar <[email protected]>
Cc: Chris Healy <[email protected]>
Cc: Lucas Stach <[email protected]>
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Andrzej Hajda <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
A very unfortunate aspect of tc_write()/tc_read() macro helpers is
that they capture quite a bit of context around them and thus require
the caller to have magic variables 'ret' and 'tc' as well as label
'err'. That makes a number of code paths rather counter-intuitive and
somewhat clunky, for example tc_stream_clock_calc() ends up being like
this:
int ret;
tc_write(DP0_VIDMNGEN1, 32768);
return 0;
err:
return ret;
which is rather surprising when you read the code for the first
time. Since those helpers arguably aren't really saving that much code
and there's no way of fixing them without making them too verbose to
be worth it change the driver code to not use them at all.
Signed-off-by: Andrey Smirnov <[email protected]>
Reviewed-by: Andrzej Hajda <[email protected]>
Reviewed-by: Tomi Valkeinen <[email protected]>
Cc: Andrzej Hajda <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Tomi Valkeinen <[email protected]>
Cc: Andrey Gusakov <[email protected]>
Cc: Philipp Zabel <[email protected]>
Cc: Cory Tusar <[email protected]>
Cc: Chris Healy <[email protected]>
Cc: Lucas Stach <[email protected]>
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Andrzej Hajda <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Simplify tc_set_video_mode() by replacing explicit shifting using
macros from <linux/bitfield.h>. No functional change intended.
Signed-off-by: Andrey Smirnov <[email protected]>
Reviewed-by: Andrzej Hajda <[email protected]>
Reviewed-by: Tomi Valkeinen <[email protected]>
Cc: Andrzej Hajda <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Tomi Valkeinen <[email protected]>
Cc: Andrey Gusakov <[email protected]>
Cc: Philipp Zabel <[email protected]>
Cc: Cory Tusar <[email protected]>
Cc: Chris Healy <[email protected]>
Cc: Lucas Stach <[email protected]>
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Andrzej Hajda <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Replace explicit polling in tc_link_training() with equivalent call to
tc_poll_timeout() for simplicity. No functional change intended (not
including slightly altered debug output).
Signed-off-by: Andrey Smirnov <[email protected]>
Reviewed-by: Andrzej Hajda <[email protected]>
Reviewed-by: Tomi Valkeinen <[email protected]>
Cc: Andrzej Hajda <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Tomi Valkeinen <[email protected]>
Cc: Andrey Gusakov <[email protected]>
Cc: Philipp Zabel <[email protected]>
Cc: Cory Tusar <[email protected]>
Cc: Chris Healy <[email protected]>
Cc: Lucas Stach <[email protected]>
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Andrzej Hajda <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Replace explicit polling loop with equivalent call to
tc_poll_timeout() for brevity. No functional change intended.
Signed-off-by: Andrey Smirnov <[email protected]>
Reviewed-by: Andrzej Hajda <[email protected]>
Reviewed-by: Tomi Valkeinen <[email protected]>
Cc: Andrzej Hajda <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Tomi Valkeinen <[email protected]>
Cc: Andrey Gusakov <[email protected]>
Cc: Philipp Zabel <[email protected]>
Cc: Cory Tusar <[email protected]>
Cc: Chris Healy <[email protected]>
Cc: Lucas Stach <[email protected]>
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Andrzej Hajda <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Implementation of tc_poll_timeout() is almost a 100% copy-and-paste of
the code for regmap_read_poll_timeout(). Replace copied code with a
call to the original. While at it change tc_poll_timeout to accept
"struct tc_data *" instead of "struct regmap *" for brevity. No
functional change intended.
Signed-off-by: Andrey Smirnov <[email protected]>
Reviewed-by: Andrzej Hajda <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Reviewed-by: Tomi Valkeinen <[email protected]>
Cc: Andrzej Hajda <[email protected]>
Cc: Laurent Pinchart <[email protected]>
Cc: Tomi Valkeinen <[email protected]>
Cc: Andrey Gusakov <[email protected]>
Cc: Philipp Zabel <[email protected]>
Cc: Cory Tusar <[email protected]>
Cc: Chris Healy <[email protected]>
Cc: Lucas Stach <[email protected]>
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Andrzej Hajda <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Maarten needs -rc4 backmerged so he can pull in the fbcon notifier
removal topic branch into drm-misc-next.
Signed-off-by: Daniel Vetter <[email protected]>
|
|
Add support for interrupt and hotplug handling. Both are optional.
Signed-off-by: Tomi Valkeinen <[email protected]>
Reviewed-by: Andrzej Hajda <[email protected]>
Signed-off-by: Andrzej Hajda <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Add GPIO and interrupt related registers for HPD work. Mark INTSTS_G and
GPIOI as volatile.
Signed-off-by: Tomi Valkeinen <[email protected]>
Reviewed-by: Andrzej Hajda <[email protected]>
Signed-off-by: Andrzej Hajda <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
We need to know the link bandwidth to filter out modes we cannot
support, so we need to have read the display props before doing the
filtering.
To ensure we have up to date display props, call tc_get_display_props()
in the beginning of tc_connector_get_modes().
Signed-off-by: Tomi Valkeinen <[email protected]>
Reviewed-by: Andrzej Hajda <[email protected]>
Signed-off-by: Andrzej Hajda <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
In tc_bridge_mode_set callback, we store the pointer to the given
drm_display_mode, and use the mode later. Storing a pointer in such a
way looks very suspicious to me, and I have observed odd issues where
the timings were apparently (at least mostly) zero.
Do a copy of the drm_display_mode instead to ensure we don't refer to
freed/modified data.
Signed-off-by: Tomi Valkeinen <[email protected]>
Reviewed-by: Andrzej Hajda <[email protected]>
Signed-off-by: Andrzej Hajda <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
drm_connector_helper_funcs.best_encoder is only needed when the
connector can have more than one encoder, and that is never the case
here.
So remove tc_connector_best_encoder.
Signed-off-by: Tomi Valkeinen <[email protected]>
Reviewed-by: Andrzej Hajda <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Signed-off-by: Andrzej Hajda <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|