linux-kernel - Re: [RFC][PATCH 5/5 v2] drm/bridge: adv7511: Reuse __adv7511_power

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 30 Nov 2016 10:12:20 +0530
From:   Archit Taneja <architt@...eaurora.org>
To:     John Stultz <john.stultz@...aro.org>,
        lkml <linux-kernel@...r.kernel.org>
Cc:     David Airlie <airlied@...ux.ie>,
        Wolfram Sang <wsa+renesas@...g-engineering.com>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        dri-devel@...ts.freedesktop.org
Subject: Re: [RFC][PATCH 5/5 v2] drm/bridge: adv7511: Reuse
 __adv7511_power_on/off() when probing EDID



On 11/29/2016 10:34 AM, 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.
>
> Cc: David Airlie <airlied@...ux.ie>
> Cc: Archit Taneja <architt@...eaurora.org>
> Cc: Wolfram Sang <wsa+renesas@...g-engineering.com>
> Cc: Lars-Peter Clausen <lars@...afoo.de>
> Cc: Laurent Pinchart <laurent.pinchart@...asonboard.com>
> Cc: dri-devel@...ts.freedesktop.org
> Signed-off-by: John Stultz <john.stultz@...aro.org>
> ---
> v2: Split into two patches to make the change more clear.
>     Also provided more rational as to why the change is
>     important.
>
>  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 17 +++--------------
>  1 file changed, 3 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> index 1948968..487b33d 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> @@ -559,24 +559,13 @@ static int adv7511_get_modes(struct adv7511 *adv7511,
>  	unsigned int count;
>
>  	/* Reading the EDID only works if the device is powered */
> -	if (!adv7511->powered) {
> -		regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER,
> -				   ADV7511_POWER_POWER_DOWN, 0);
> -		if (adv7511->i2c_main->irq) {
> -			regmap_write(adv7511->regmap, ADV7511_REG_INT_ENABLE(0),
> -				     ADV7511_INT0_EDID_READY);
> -			regmap_write(adv7511->regmap, ADV7511_REG_INT_ENABLE(1),
> -				     ADV7511_INT1_DDC_ERROR);
> -		}
> -		adv7511->current_edid_segment = -1;
> -	}
> +	if (!adv7511->powered)
> +		__adv7511_power_on(adv7511);

In terms of changes in terms of register configurations, replacing with
__adv7511_power_on() here would add a register write to ADV7511_REG_POWER2
as discussed before.

Also, after the patch that enables HPD, we'd also be adding the ADV7511_INT0_HPD
bit in ADV7511_REG_INT_ENABLE(0).

I am not entirely sure about what effect adding POWER2 would have. If we don't
see any negative effects because of it, I think we should be fine.

The extra HPD bit in INT_ENABLE(0) shouldn't be a problem, though. In fact, it
prevents the HPD mask from being cleared after we get_modes is called, which may
have resulted in us missing out on HPD interrupts.

Thanks,
Archit

>
>  	edid = drm_do_get_edid(connector, adv7511_get_edid_block, adv7511);
>
>  	if (!adv7511->powered)
> -		regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER,
> -				   ADV7511_POWER_POWER_DOWN,
> -				   ADV7511_POWER_POWER_DOWN);
> +		__adv7511_power_off(adv7511);
>
>  	kfree(adv7511->edid);
>  	adv7511->edid = edid;
>

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project