When testing with a panel that's apparently a little more persnickety
about the correct power sequence (specifically Samsung ATNA33XC20), we
found that the ti-sn65dsi86 was doing things just slightly wrong.

Looking closely at the ti-sn65dsi86's datasheet, the power off
sequence is supposed to be:
1. Clear VSTREAM_ENABLE bit
2. Stop DSI stream from GPU. DSI lanes must be placed in LP11 state.
3. Program the ML_TX_MODE to 0x0 (OFF)
4. Program the DP_NUM_LANES register to 0x0
5. Clear the DP_PLL_EN bit.
6. Deassert the EN pin.
7. Remove power from supply pins

Since we were doing the whole sequence in the "disable", I believe
that step #2 (stopping the DSI stream from the GPU) wasn't
happening. We also weren't setting DP_NUM_LANES to 0.

Let's fix this.

NOTE: things are a little asymmetric now. For instance, we turn the
PLL on in "enable" but now we're not turning it off until
"post_disable". It would seem to make sense to move the PLL turning on
to "pre_enable" to match. Unfortunately, I don't believe that's
allowed. It looks as if (in the non-refclk mode which probably nobody
is using) we have to wait until the MIPI clock is there before we can
enable the PLL. In any case, the way it is here won't really
hurt--it'll just leave the PLL on a little longer.

Fixes: a095f15c ("drm/bridge: add support for sn65dsi86 bridge driver")
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Acked-by: NRobert Foss <robert.foss@linaro.org>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210730084534.v2.2.If8a8ec3bf1855cf0dbb62c005a71d6698c99c125@changeid

To prepare for making connector creation option, move connector creation
out of ti_sn_bridge_attach to a separate function.

No functional change intended.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NStephen Boyd <swboyd@chromium.org>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NRobert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210624000304.16281-7-laurent.pinchart+renesas@ideasonboard.com

Reorganize the functions in sections, related to connector operations,
bridge operations, AUX adapter, GPIO controller and probe & remove.

This prepares for proper support of DRM_BRIDGE_ATTACH_NO_CONNECTOR that
will add more functions, to ensure that the code will stay readable.

No functional change intended.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NStephen Boyd <swboyd@chromium.org>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NRobert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210624000304.16281-6-laurent.pinchart+renesas@ideasonboard.com

To simplify interfacing with the panel, wrap it in a panel-bridge and
let the DRM bridge helpers handle chaining of operations.

This also prepares for support of DRM_BRIDGE_ATTACH_NO_CONNECTOR, which
requires all components in the display pipeline to be represented by
bridges.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NJagan Teki <jagan@amarulasolutions.com>
Signed-off-by: NRobert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210624000304.16281-5-laurent.pinchart+renesas@ideasonboard.com

The valid rates are stored in an array of 8 booleans. Replace it with a
bitmask to save space.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NStephen Boyd <swboyd@chromium.org>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NRobert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210624000304.16281-4-laurent.pinchart+renesas@ideasonboard.com

The enable signal may not be controllable by the kernel. Make it
optional.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: NJagan Teki <jagan@amarulasolutions.com>
Reviewed-by: NStephen Boyd <swboyd@chromium.org>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NRobert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210624000304.16281-3-laurent.pinchart+renesas@ideasonboard.com

As I was testing to make sure that the DEFER path worked well with my
patch series, I got tired of seeing this scary message in my logs just
because the panel needed to defer:
  [drm:ti_sn_bridge_probe] *ERROR* could not find any panel node

Let's use dev_err_probe() which nicely quiets this error and also
simplifies the code a tiny bit. We'll also update other places in the
file which can use dev_err_probe().
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210611101711.v10.10.I24bba069e63b1eea84443eef0c8535fd032a6311@changeid

This is really just a revert of commit 58074b08 ("drm/bridge:
ti-sn65dsi86: Read EDID blob over DDC"), resolving conflicts.

The old code failed to read the EDID properly in a very important
case: before the bridge's pre_enable() was called. The way things need
to work:
1. Read the EDID.
2. Based on the EDID, decide on video settings and pixel clock.
3. Enable the bridge w/ the desired settings.

The way things were working:
1. Try to read the EDID but fail; fall back to hardcoded values.
2. Based on hardcoded values, decide on video settings and pixel clock.
3. Enable the bridge w/ the desired settings.
4. Try again to read the EDID, it works now!
5. Realize that the hardcoded settings weren't quite right.
6. Disable / reenable the bridge w/ the right settings.

The reasons for the failures were twofold:
a) Since we never ran the bridge chip's pre-enable then we never set
   the bit to ignore HPD. This meant the bridge chip didn't even _try_
   to go out on the bus and communicate with the panel.
b) Even if we fixed things to ignore HPD, the EDID still wouldn't read
   if the panel wasn't on.

Instead of reverting the code, we could fix it to set the HPD bit and
also power on the panel. However, it also works nicely to just let the
panel code read the EDID. Now that we've split the driver up we can
expose the DDC AUX channel bus to the panel node. The panel can take
charge of reading the EDID.

NOTE: in order for things to work, anyone that needs to read the EDID
will need to instantiate their panel using the new DP AUX bus (AKA by
listing their panel under the "aux-bus" node of the bridge chip in the
device tree).

In the future if we want to use the bridge chip to provide a full
external DP port (which won't have a panel) then we will have to
conditinally add EDID reading back in.
Suggested-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210611101711.v10.9.I9330684c25f65bb318eff57f0616500f83eac3cc@changeid

We want to provide our panel with access to the DP AUX channel. The
way to do this is to let our panel be a child of ours using the fancy
new DP AUX bus support.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NLyude Paul <lyude@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210611101711.v10.8.Ib5fe0638da85800141ce141bb8e441c5f25438d4@changeid

On its own, this change looks a little strange and doesn't do too much
useful. To understand why we're doing this we need to look forward to
future patches where we're going to probe our panel using the new DP
AUX bus. See the patch ("drm/bridge: ti-sn65dsi86: Add support for the
DP AUX bus").

Let's think about the set of steps we'll want to happen when we have
the DP AUX bus:

1. We'll create the DP AUX bus.
2. We'll populate the devices on the DP AUX bus (AKA our panel).
3. For setting up the bridge-related functions of ti-sn65dsi86 we'll
   need to get a reference to the panel.

If we do #1 - #3 in a single probe call things _mostly_ will work, but
it won't be massively robust. Let's explore.

First let's think of the easy case of no -EPROBE_DEFER. In that case
in step #2 when we populate the devices on the DP AUX bus it will
actually try probing the panel right away. Since the panel probe
doesn't defer then in step #3 we'll get a reference to the panel and
we're golden.

Second, let's think of the case when the panel returns
-EPROBE_DEFER. In that case step #2 won't synchronously create the
panel (it'll just add the device to the defer list to do it
later). Step #3 will fail to get the panel and the bridge sub-device
will return -EPROBE_DEFER. We'll depopulate the DP AUX bus. Later
we'll try the whole sequence again. Presumably the panel will
eventually stop returning -EPROBE_DEFER and we'll go back to the first
case where things were golden. So this case is OK too even if it's a
bit ugly that we have to keep creating / deleting the AUX bus over and
over.

So where is the problem? As I said, it's mostly about robustness. I
don't believe that step #2 (creating the sub-devices) is really
guaranteed to be synchronous. This is evidenced by the fact that it's
allowed to "succeed" by just sticking the device on the deferred
list. If anything about the process changes in Linux as a whole and
step #2 just kicks off the probe of the DP AUX endpoints (our panel)
in the background then we'd be in trouble because we might never get
the panel in step #3.

Adding an extra sub-device means we just don't need to worry about
it. We'll create the sub-device for the DP AUX bus and it won't go
away until the whole ti-sn65dsi86 driver goes away. If the bridge
sub-device defers (maybe because it can't find the panel) that won't
depopulate the DP AUX bus and so we don't need to worry about it.

NOTE: there's a little bit of a trick here. Though the AUX channel can
run without the MIPI-to-eDP bits of the code, the MIPI-to-eDP bits
can't run without the AUX channel. We could come up a complicated
signaling scheme (have the MIPI-to-eDP bits return EPROBE_DEFER for a
while or wait on some sort of completion), but it seems simple enough
to just not even bother creating the bridge device until the AUX
channel probes. That's what we'll do.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NLyude Paul <lyude@redhat.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210611101711.v10.7.If89144992cb9d900f8c91a8d1817dbe00f543720@changeid

The ti_sn_aux_transfer() function returns ssize_t (signed long).  It's
supposed to return negative error codes or the number of bytes
transferred.  The "ret" variable is int and the "len" variable is
unsigned int.

The problem is that with a ternary like this, the negative int is first
type promoted to unsigned int to match "len" at this point it is a high
positive value.  Then when it is type promoted to ssize_t (s64) it
remains a high positive value instead of sign extending and becoming a
negative again.

Fix this by removing the ternary.

Fixes: b137406d ("drm/bridge: ti-sn65dsi86: If refclk, DP AUX can happen w/out pre-enable")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NRobert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/YKOGogHasIyvF8nj@mwanda

The ti_sn_gpio_unregister() is not just called from the remove path
but also from the error handling of the init path. That means it can't
have the __exit annotation.

Fixes: bf73537f ("drm/bridge: ti-sn65dsi86: Break GPIO and MIPI-to-eDP bridge into sub-drivers")
Reported-by: Nkernel test robot <lkp@intel.com>
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NRobert Foss <robert.foss@linaro.org>
Signed-off-by: NRobert Foss <robert.foss@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210504073845.1.Ibf4194f4252846edaa0c6a6c7b86588f75ad5529@changeid

Let's reorganize how we init and turn on the reference clock in the
code to allow us to turn it on early (even before pre_enable()) so
that we can read the EDID early. This is handy for eDP because:
- We always assume that a panel is there.
- Once we report that a panel is there we get asked to read the EDID.
- Pre-enable isn't called until we know what pixel clock we want to
  use and we're ready to turn everything on. That's _after_ we get
  asked to read the EDID.

NOTE: the above only works out OK if we "refclk" is provided. Though I
don't have access to any hardware that uses ti-sn65dsi86 and _doesn't_
provide a "refclk", I believe that we'll have trouble reading the EDID
at bootup in that case. Specifically I believe that if there's no
"refclk" we need the MIPI source clock to be active before we can
successfully read the EDID. My evidence here is that, in testing, I
couldn't read the EDID until I turned on the DPPLL in the bridge chip
and that the DPPLL needs the input clock to be active.

Since this is hard to support, let's punt trying to handle this case
if there's no "refclk". In that case we'll enable comms in
pre_enable() like we always did.

I don't believe there are any users of the ti-sn65dsi86 bridge chip
that _don't_ use "refclk". The bridge chip is _very_ inflexible in
that mode. The only time I've seen that mode used was for some really
early prototype hardware that was thrown in the e-waste bin years ago
when we realized how inflexible it was.

Even if someone is using the bridge chip without the "refclk" they're
in no worse shape than they were before the (fairly recent) commit
58074b08 ("drm/bridge: ti-sn65dsi86: Read EDID blob over DDC").
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.13.Ie8cf556114953c6e7634564cc0d3ddbd103cb96c@changeid

No functional changes--this just makes the diffstat of a future change
easier to understand.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.12.I047b8c7c6a3fc60eaca473da7a374f171fb021c2@changeid

Let's make the bridge use autosuspend with a 500ms delay. This is in
preparation for promoting DP AUX transfers to their own sub-driver so
that we're not constantly powering up and down the device as we
transfer all the chunks.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.11.I4c0b4a87e4dc19e5023b4d0a21bbfa6d9c09ebd8@changeid

Let's use the newly minted aux bus to break up the driver into sub
drivers. We're not doing a full breakup here: all the code is still in
the same file and remains largely untouched. The big goal here of
using sub-drivers is to allow part of our code to finish probing even
if some other code needs to defer. This can solve some chicken-and-egg
problems. Specifically:
- In commit 48834e60 ("drm/panel-simple: Support hpd-gpios for
  delaying prepare()") we had to add a bit of a hack to simpel-panel
  to support HPD showing up late. We can get rid of that hack now
  since the GPIO part of our driver can finish probing early.
- We have a desire to expose our DDC bus to simple-panel (and perhaps
  to a backlight driver?). That will end up with the same
  chicken-and-egg problem. A future patch to move this to a sub-driver
  will fix it.
- If/when we support the PWM functionality present in the bridge chip
  for a backlight we'll end up with another chicken-and-egg
  problem. If we allow the PWM to be a sub-driver too then it solves
  this problem.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.9.I3e68fa38c4ccbdbdf145cad2b01e83a1e5eac302@changeid

This is just code motion of the probe routine to move all the things
that are for the "whole chip" (instead of the GPIO parts or the
MIPI-to-eDP parts) together at the start of probe. This is in
preparation for breaking the driver into sub-drivers.

Since we're using devm for all of the "whole chip" stuff this is
actually quite easy now.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.8.Ide8ba40feb2e43bc98a11edbb08d696d62dcd83e@changeid

Let's:
- Set the drvdata as soon as it's allocated. This just sets up a
  pointer so there's no downside here.
- Remove the useless call to i2c_set_clientdata() which is literally
  the same thing as dev_set_drvdata().

No functional changes intended.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.7.If5d4d4e22e97bebcd493b76765c1759527705620@changeid

Tiny cleanup for probe so we don't keep having to specify
"&client->dev" or "pdata->dev". No functional changes intended.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.6.I83925d8ca228bdc5f55b17854c90754efc6a470e@changeid

Let's cleanup the debugfs code to:
- Check for errors.
- Use devm to manage freeing, which also means we don't need to store
  a pointer in our structure.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.5.I5fe072753290c6a77eda736ebd5778e17b7cb0fb@changeid

There's no devm_runtime_enable(), but it's easy to use
devm_add_action_or_reset() and means we don't need to worry about the
disable in our remove() routine or in error paths.

No functional changes intended by this change.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.4.I1e627eb5f316c0cf6595b120e6e262f5bf890300@changeid

Like the previous patch ("drm/bridge: ti-sn65dsi86: Rename the main
driver data structure") this is just a no-op rename in preparation for
splitting the driver up a bit.

Here I've attempted to rename functions / structures making sure that
anything applicable to the whole chip (instead of just the MIPI to eDP
bridge part) included "sn65dsi86" somewhere in the name instead of
just "ti_sn_bridge".
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.3.I4b28c737933a44548662df42ccd37db89ec739c1@changeid

In preparation for splitting this driver into sub-drivers, let's
rename the main data structure so it's clear that it's holding data
for the whole device and not just the MIPI-eDP bridge part.

This is a no-op change.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210423095743.v5.2.Ib03e88304a9ea1c503f1b9567be5cbf8b7c5761c@changeid

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: NLyude Paul <lyude@redhat.com>
Acked-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210423184309.207645-4-lyude@redhat.comReviewed-by: NDave Airlie <airlied@redhat.com>

If we just leave the detect() function as NULL then the upper layers
assume we're always connected. There's no reason for a stub.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NAndrzej Hajda <a.hajda@samsung.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210416153909.v4.6.I826adf4faeb7f39f560b387f6b380e639c6986c8@changeid

We prepared the panel in pre_enable() so we should unprepare it in
post_disable() to match.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NAndrzej Hajda <a.hajda@samsung.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210416153909.v4.5.Ia75c9ffe2a2582393a8532d244da86f18b4c9b21@changeid

Let's make the remove() function strictly the reverse of the probe()
function so it's easier to reason about.

This patch was created by code inspection and should move us closer to
a proper remove.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NAndrzej Hajda <a.hajda@samsung.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210416153909.v4.4.Ifcf1deaa372eba7eeb4f8eb516c5d15b77a657a9@changeid

A random comment inside a function had "/**" in front of it. That
doesn't make sense. Remove.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NAndrzej Hajda <a.hajda@samsung.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210416153909.v4.3.I167766eeaf4c4646a3934c4dd5332decbab6bd68@changeid

The clock framework makes it simple to deal with an optional clock.
You can call clk_get_optional() and if the clock isn't specified it'll
just return NULL without complaint. It's valid to pass NULL to
enable/disable/prepare/unprepare. Let's make use of this to simplify
things a tiny bit.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NRobert Foss <robert.foss@linaro.org>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: NStephen Boyd <swboyd@chromium.org>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NAndrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210416153909.v4.2.Ic9c04f960190faad5290738b2a35d73661862735@changeid

Since we're about to add a back-pointer to drm_dev in drm_dp_aux, let's
move the AUX adapter registration to the first point where we know which
DRM device we'll be working with - when the drm_bridge is attached.
Likewise, we unregister the AUX adapter on bridge detachment by adding a
ti_sn_bridge_detach() callback.
Signed-off-by: NLyude Paul <lyude@redhat.com>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210219215326.2227596-7-lyude@redhat.com

We should be setting the drm_dp_aux_msg::reply field if a NACK or a
SHORT reply happens. Update the error bit handling logic in
ti_sn_aux_transfer() to handle these cases and notify upper layers that
such errors have happened. This helps the retry logic understand that a
timeout has happened, or to shorten the read length if the panel isn't
able to handle the longest read possible.

Note: I don't have any hardware that exhibits these code paths so this
is written based on reading the datasheet for this bridge and inspecting
the code and how this is called.

Changes in v2:
 - Move WRITE_STATUS_UPDATE check from case to assignment

Changes in v2:
 - Handle WRITE_STATUS_UPDATE properly
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Cc: Jonas Karlman <jonas@kwiboo.se>
Cc: Jernej Skrabec <jernej.skrabec@siol.net>
Cc: Sean Paul <seanpaul@chromium.org>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NStephen Boyd <swboyd@chromium.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20201102181144.3469197-5-swboyd@chromium.org

Use the DDC connection to read the EDID from the eDP panel instead of
relying on the panel to tell us the modes.
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
Reviewed-by: NLaurent Pinchart <Laurent.pinchart@ideasonboard.com>
Cc: Jonas Karlman <jonas@kwiboo.se>
Cc: Jernej Skrabec <jernej.skrabec@siol.net>
Cc: Sean Paul <seanpaul@chromium.org>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NStephen Boyd <swboyd@chromium.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20201102181144.3469197-4-swboyd@chromium.org

There's no reason we need to wait here to poll a register over i2c. The
i2c bus is inherently slow and delays are practically part of the
protocol because we have to wait for the device to respond to any
request for a register. Let's rely on the sleeping of the i2c controller
instead of adding any sort of delay here in the bridge driver.
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Cc: Jonas Karlman <jonas@kwiboo.se>
Cc: Jernej Skrabec <jernej.skrabec@siol.net>
Cc: Sean Paul <seanpaul@chromium.org>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NStephen Boyd <swboyd@chromium.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20201102181144.3469197-3-swboyd@chromium.org

These register reads and writes are sometimes directly next to each
other in the register address space. Let's use regmap bulk read/write
APIs to get the data with one transfer instead of multiple i2c
transfers. This helps cut down on the number of transfers in the case of
something like reading an EDID where we read in blocks of 16 bytes at a
time and the last for loop here is sending an i2c transfer for each of
those 16 bytes, one at a time. Ouch!

Changes in v3:
 - Undid changes in v2

Changes in v2:
 - Combined AUX_CMD register write
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Cc: Jonas Karlman <jonas@kwiboo.se>
Cc: Jernej Skrabec <jernej.skrabec@siol.net>
Cc: Sean Paul <seanpaul@chromium.org>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NStephen Boyd <swboyd@chromium.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20201102181144.3469197-2-swboyd@chromium.org

Because clk_disable_unprepare already checked NULL clock parameter,
so the additional checks are unnecessary, just remove it
Signed-off-by: NXu Wang <vulab@iscas.ac.cn>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200930081859.52431-1-vulab@iscas.ac.cn

On some panels hooked up to the ti-sn65dsi86 bridge chip we found that
link training was failing.  Specifically, we'd see:

  ti_sn65dsi86 2-002d: [drm:ti_sn_bridge_enable] *ERROR* Link training failed, link is off (-5)

The panel was hooked up to a logic analyzer and it was found that, as
part of link training, the bridge chip was writing a 0x1 to DPCD
address 00600h and the panel responded NACK.  As can be seen in header
files, the write of 0x1 to DPCD address 0x600h means we were trying to
write the value DP_SET_POWER_D0 to the register DP_SET_POWER.  The
panel vendor says that a NACK in this case is not unexpected and means
"not ready, try again".

In testing, we found that this panel would respond with a NACK in
about 1/25 times.  Adding the retry logic worked fine and the most
number of tries needed was 3.  Just to be safe, we'll add 10 tries
here and we'll add a little blurb to the logs if we ever need more
than 5.
Signed-off-by: NDouglas Anderson <dianders@chromium.org>
Tested-By: NSteev Klimaszewski <steev@kali.org>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20201002135920.1.I2adbc90b2db127763e2444bd5a4e5bf30e1db8e5@changeid

Replace the existing /* fall through */ comments and its variants with
the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary
fall-through markings when it is the case.

[1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-throughSigned-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>

These functions are now empty and no longer
useful so remove the functions and their uses.
Signed-off-by: NJoe Perches <joe@perches.com>
Cc: Bernard Zhao <bernard@vivo.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>,
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Icenowy Zheng <icenowy@aosc.io>,
Cc: Jagan Teki <jagan@amarulasolutions.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Robert Chiras <robert.chiras@nxp.com>
Cc: dri-devel@lists.freedesktop.org,
Cc: linux-kernel@vger.kernel.org
Cc: opensource.kernel@vivo.com
Signed-off-by: Sam Ravnborg <sam@ravnborg.org> # Fixed build and a few warnings
Link: https://patchwork.freedesktop.org/patch/msgid/9e13761020750b1ce2f1fabee23ef6e2a2942882.camel@perches.com

Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
    For each line:
      If doesn't contain `\bxmlns\b`:
        For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
	  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
            If both the HTTP and HTTPS versions
            return 200 OK and serve the same content:
              Replace HTTP with HTTPS.
Signed-off-by: NAlexander A. Klimov <grandmaster@al2klimov.de>
Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200708121604.14292-1-grandmaster@al2klimov.de

ti-sn65dsi86 bridge is enumerated as a runtime device. When
suspend is triggered, PM core adds a refcount on all the
devices and calls device suspend, since usage count is
already incremented, runtime suspend will not be called
and it kept the bridge regulators and gpios ON which resulted
in platform not entering into XO shutdown.

Add changes to force suspend on the runtime device during pm sleep.
Signed-off-by: NHarigovindan P <harigovi@codeaurora.org>
Reviewed-by: NStephen Boyd <swboyd@chromium.org>
Reviewed-by: NDouglas Anderson <dianders@chromium.org>
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200609120455.20458-1-harigovi@codeaurora.org