From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: John Stultz <john.stultz@linaro.org>
Cc: "dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
lkml <linux-kernel@vger.kernel.org>,
Wolfram Sang <wsa+renesas@sang-engineering.com>
Subject: Re: [PATCH 5/5 v3] drm/bridge: adv7511: Reuse __adv7511_power_on/off() when probing EDID
Date: Tue, 17 Jan 2017 00:25:31 +0200 [thread overview]
Message-ID: <1668382.5d9jBvLc1l@avalon> (raw)
In-Reply-To: <CALAqxLVN=-9eUFaYWtu_MxTixfHZt_gRvWO7TDDFeDaDQ-uFZg@mail.gmail.com>
Hi John,
On Monday 16 Jan 2017 12:14:48 John Stultz wrote:
> On Mon, Jan 16, 2017 at 8:03 AM, Laurent Pinchart wrote:
> > On Tuesday 03 Jan 2017 11:41:42 John Stultz wrote:
> >> I've found that by just turning the chip on and off via the
> >> POWER_DOWN register, I end up getting i2c_transfer errors
> >> on HiKey.
> >>
> >> Investigating further, it seems some of the register state
> >> in the regmap cache is somehow getting lost. Using the logic
> >> in __adv7511_power_on/off() which syncs and dirtys the cache
> >> avoids this issue.
> >>
> >> Thus this patch changes the EDID probing logic so that we
> >> re-use the __adv7511_power_on/off() calls.
> >
> > regcache_sync() is quite costly as it will write a bunch of registers.
> > Wouldn't it be more efficient to only write the registers that are needed
> > for EDID access ?
>
> So yes, you've mentioned this concern before, and I did spend some
> time to narrow which lost-register state (0x43
> - ADV7511_REG_EDID_I2C_ADDR) was causing the trouble with i2c
> trasnfer errors I was seeing:
> https://lkml.org/lkml/2016/11/22/677
>
> However, I didn't get much feedback on that, and it seems (to me at
> least) concerning that we are losing the underlying state of a
> register in the cache, so just syncing that one register back to the
> hardware might solve the issue I was seeing, but I worry what other
> registers might also be out of sync.
>
> The comment above the regmap_sync in adv7511_power_on after all states:
> "Most of the registers are reset during power down or when HPD is low."
You're right that most registers will be out of sync.
> So it seems like if we're setting the power down (and setting HPD in
> cases where Archit had a patch to add HPD pulsing to the
> adv7511_get_modes path), it seems reasonable to do the same
> regmap_sync()?
It would be if we had to keep the device powered up, but we're powering it
down right after reading the EDID. I don't think there's a need to reconfigure
it completely, only setting the registers needed to read the EDID should be
enough.
> But, I'm not really picky here, and I'm very open to other approaches
> (including something like the patch in the link above) if you have
> suggestions/preferences. I just want it to work reliably on my
> hardware. :)
>
> And just so I can better understand it, can you explain some about the
> impact of your efficiency concerns?
I'm not too picky either :-) If we can't find a reliable way to read the EDID
by just configuring the registers we need, we could go for a full
reconfiguration. However, restoring the value of all cached registers will
result in lots of I2C writes, which are time-consuming operations. EDID read
would be sped up if we could avoid that.
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2017-01-16 22:25 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-03 19:41 [PATCH 0/5 v3] adv7511 EDID probing improvements John Stultz
2017-01-03 19:41 ` [PATCH 1/5 v3] drm/bridge: adv7511: Use work_struct to defer hotplug handing to out of irq context John Stultz
2017-01-03 19:41 ` [PATCH 2/5 v3] drm/bridge: adv7511: Switch to using drm_kms_helper_hotplug_event() John Stultz
2017-01-16 15:47 ` Laurent Pinchart
2017-01-16 15:56 ` Laurent Pinchart
2017-01-16 19:31 ` John Stultz
2017-01-03 19:41 ` [PATCH 3/5 v3] drm/bridge: adv7511: Enable HPD interrupts to support hotplug and improve monitor detection John Stultz
2017-01-03 19:41 ` [PATCH 4/5 v3] drm/bridge: adv7511: Rework adv7511_power_on/off() so they can be reused internally John Stultz
2017-01-16 15:50 ` Laurent Pinchart
2017-01-03 19:41 ` [PATCH 5/5 v3] drm/bridge: adv7511: Reuse __adv7511_power_on/off() when probing EDID John Stultz
2017-01-16 16:03 ` Laurent Pinchart
2017-01-16 20:14 ` John Stultz
2017-01-16 22:25 ` Laurent Pinchart [this message]
2017-01-16 23:16 ` [RFC][PATCH] drm/bridge: adv7511: Re-write the i2c address as it may have been lost John Stultz
2017-01-16 23:36 ` Laurent Pinchart
2017-01-16 23:39 ` John Stultz
2017-01-11 8:48 ` [PATCH 0/5 v3] adv7511 EDID probing improvements Archit Taneja
2017-01-12 0:06 ` John Stultz
2017-01-12 4:22 ` Archit Taneja
2017-01-16 15:57 ` Laurent Pinchart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1668382.5d9jBvLc1l@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=john.stultz@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=wsa+renesas@sang-engineering.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).