mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Archit Taneja <architt@codeaurora.org>
To: John Stultz <john.stultz@linaro.org>, Arnd Bergmann <arnd@arndb.de>
Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	David Airlie <airlied@linux.ie>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Bhumika Goyal <bhumirks@gmail.com>,
	Inki Dae <inki.dae@samsung.com>,
	dri-devel@lists.freedesktop.org,
	lkml <linux-kernel@vger.kernel.org>,
	Xinliang Liu <xinliang.liu@linaro.org>,
	Dan Carpenter <dan.carpenter@oracle.com>,
	Sean Paul <seanpaul@chromium.org>,
	Hans Verkuil <hans.verkuil@cisco.com>
Subject: Re: [RFC][PATCH] drm: adv7511/33: Fix adv7511_cec_init() failure handling
Date: Sun, 26 Nov 2017 18:26:06 +0530	[thread overview]
Message-ID: <6faf6790-c5a3-8ca7-eb51-115842a66ceb@codeaurora.org> (raw)
In-Reply-To: <1510873179-20786-1-git-send-email-john.stultz@linaro.org>

Hi,

On 11/17/2017 04:29 AM, John Stultz wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> 
> An otherwise correct cleanup patch from Dan Carpenter turned a broken
> failure handling from a feature patch by Hans Verkuil into a kernel
> Oops, so bisection points to commit 7af35b0addbc ("drm/kirin: Checking
> for IS_ERR() instead of NULL") rather than 3b1b975003e4 ("drm:
> adv7511/33: add HDMI CEC support").
> 
> I've managed to piece together several partial problems, though
> I'm still struggling with the bigger picture:
> 
> adv7511_probe() registers a drm_bridge structure that was allocated
> with devm_kzalloc(). It calls adv7511_cec_init(), which fails for an
> unknown reason, which in turn triggers the registered structure to be
> removed.
> 
> Elsewhere, kirin_drm_platform_probe() gets called, which calls
> of_graph_get_remote_node(), and that returns NULL. Before Dan's
> patch we would go on with a NULL pointer here and register that,
> now kirin_drm_platform_probe() fails with -ENODEV.
> 
> In a third driver, dsi_parse_dt() calls drm_of_find_panel_or_bridge(),
> which after not finding a panel goes on to call of_drm_find_bridge(),
> and that crashes due to the earlier list corruption.
> 
> This addresses the first issue by making sure that adv7511_probe()
> does not completely fail when the adv7511_cec_init() function fails,
> and instead we just disable the CEC feature. This avoids having the
> driver entirely fail to load if just the CEC initialization fails.
> 
> Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
> Cc: Xinliang Liu <xinliang.liu@linaro.org>
> Cc: Dan Carpenter <dan.carpenter@oracle.com>
> Cc: Sean Paul <seanpaul@chromium.org>
> Cc: Hans Verkuil <hans.verkuil@cisco.com>
> Cc: Archit Taneja <architt@codeaurora.org>
> Link: https://bugs.linaro.org/show_bug.cgi?id=3345
> Link: https://lkft.validation.linaro.org/scheduler/job/48017#L3551
> Fixes: 7af35b0addbc ("drm/kirin: Checking for IS_ERR() instead of NULL")
> Fixes: 3b1b975003e4 ("drm: adv7511/33: add HDMI CEC support")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> [jstultz: Reworked so when adv7511_cec_init() fails, we disable the feature instead
> of disabling the entire driver, which causes graphics to not funciton]
> Signed-off-by: John Stultz <john.stultz@linaro.org>
> ---
> Just wanted to send out my rework of Arnd's patch here.
> Feedback would be welcome.
> 
> thanks
> -john
> 
>   drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 8 ++++----
>   1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> index 0e14f15..939c3b9 100644
> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
> @@ -1203,12 +1203,12 @@ static int adv7511_probe(struct i2c_client *i2c, const struct i2c_device_id *id)
>   
>   #ifdef CONFIG_DRM_I2C_ADV7511_CEC
>   	ret = adv7511_cec_init(dev, adv7511, offset);
> -	if (ret)
> -		goto err_unregister_cec;
>   #else
> -	regmap_write(adv7511->regmap, ADV7511_REG_CEC_CTRL + offset,
> -		     ADV7511_CEC_CTRL_POWER_DOWN);
> +	ret = 1;
>   #endif
> +	if (ret)
> +		regmap_write(adv7511->regmap, ADV7511_REG_CEC_CTRL + offset,
> +			     ADV7511_CEC_CTRL_POWER_DOWN);

This would force CEC to be powered off even if adv7511_cec_init() returned 0, right?
We wouldn't want that if we want to use CEC on a platform that supports it.

Do we know why the call to adv7511_cec_init() is failing on the Hikey board? If it's
because there isn't a "cec" clock specified in DT, it's not really a fatal error, it
just means that the platform hasn't been set up to support CEC. In that case, we
should just power down the CEC block. So, if adv7511_cec_init() would return a
-ENOENT, which we could use as a hint to power down CEC. So, maybe something like this?:

#ifdef CONFIG_DRM_I2C_ADV7511_CEC
         ret = adv7511_cec_init(dev, adv7511, offset);
         if (ret && ret != -ENOENT)	
		goto err_unregister_cec;
#endif
	if (ret)
             regmap_write(adv7511->regmap, ADV7511_REG_CEC_CTRL + offset,
                         ADV7511_CEC_CTRL_POWER_DOWN);

Apart from this, we should also move adv7511_cec_init() up in the probe so that
it's called before the drm_bridge is registered.

Thanks,
Archit

>   
>   	return 0;
>   
> 

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

  reply	other threads:[~2017-11-26 12:56 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-15 12:37 [PATCH] [RFT] drm: adv7511/33: fix " Arnd Bergmann
2017-11-15 12:58 ` Hans Verkuil
2017-11-16 16:42   ` Naresh Kamboju
2017-11-16 21:50 ` John Stultz
2017-11-16 22:20   ` John Stultz
2017-11-16 22:23     ` John Stultz
2017-11-16 22:59     ` [RFC][PATCH] drm: adv7511/33: Fix " John Stultz
2017-11-26 12:56       ` Archit Taneja [this message]
2017-11-28 21:32         ` John Stultz
2017-11-29  5:05           ` Archit Taneja
2017-11-29  8:15             ` Arnd Bergmann
2017-11-17  8:43     ` [RFC] [PATCH] " Hans Verkuil
2017-11-20 15:05       ` Hans Verkuil
2017-11-20 15:06         ` Hans Verkuil
2017-11-20 20:13       ` John Stultz
2017-11-20 20:57     ` [PATCHv2] " Hans Verkuil
2017-11-20 23:12       ` John Stultz
2017-11-21  6:48       ` Laurent Pinchart
2017-11-21  8:18         ` Hans Verkuil
2017-11-21  8:17     ` [PATCHv3] " Hans Verkuil
2017-11-21  8:22       ` Laurent Pinchart
2017-11-23  0:22       ` John Stultz
2017-11-30  7:02         ` Archit Taneja

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=6faf6790-c5a3-8ca7-eb51-115842a66ceb@codeaurora.org \
    --to=architt@codeaurora.org \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=airlied@linux.ie \
    --cc=arnd@arndb.de \
    --cc=bhumirks@gmail.com \
    --cc=dan.carpenter@oracle.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hans.verkuil@cisco.com \
    --cc=inki.dae@samsung.com \
    --cc=john.stultz@linaro.org \
    --cc=lars@metafoo.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=seanpaul@chromium.org \
    --cc=xinliang.liu@linaro.org \
    /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

Powered by JetHome