All of lore.kernel.org
 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: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-15 12:37 [PATCH] [RFT] drm: adv7511/33: fix adv7511_cec_init() failure handling Arnd Bergmann
2017-11-15 12:37 ` Arnd Bergmann
2017-11-15 12:58 ` Hans Verkuil
2017-11-15 12:58   ` Hans Verkuil
2017-11-16 16:42   ` Naresh Kamboju
2017-11-16 21:50 ` John Stultz
2017-11-16 21:50   ` John Stultz
2017-11-16 22:20   ` John Stultz
2017-11-16 22:20     ` John Stultz
2017-11-16 22:23     ` John Stultz
2017-11-16 22:23       ` John Stultz
2017-11-16 22:59     ` [RFC][PATCH] drm: adv7511/33: Fix " John Stultz
2017-11-16 22:59       ` John Stultz
2017-11-26 12:56       ` Archit Taneja [this message]
2017-11-28 21:32         ` John Stultz
2017-11-28 21:32           ` John Stultz
2017-11-29  5:05           ` Archit Taneja
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-17  8:43       ` Hans Verkuil
2017-11-20 15:05       ` 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:13         ` John Stultz
2017-11-20 20:57     ` [PATCHv2] " Hans Verkuil
2017-11-20 20:57       ` Hans Verkuil
2017-11-20 23:12       ` John Stultz
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:18           ` Hans Verkuil
2017-11-21  8:17     ` [PATCHv3] " Hans Verkuil
2017-11-21  8:17       ` Hans Verkuil
2017-11-21  8:22       ` Laurent Pinchart
2017-11-23  0:22       ` John Stultz
2017-11-23  0:22         ` John Stultz
2017-11-30  7:02         ` Archit Taneja
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.