public inbox for linux-rockchip@lists.infradead.org
 help / color / mirror / Atom feed
From: Archit Taneja <architt@codeaurora.org>
To: Sean Paul <seanpaul@chromium.org>
Cc: "zain wang" <wzz@rock-chips.com>,
	"Daniel Vetter" <daniel.vetter@ffwll.ch>,
	"Inki Dae" <inki.dae@samsung.com>,
	"David Airlie" <airlied@linux.ie>,
	"Tomeu Vizoso" <tomeu.vizoso@collabora.com>,
	"Mika Kahola" <mika.kahola@intel.com>,
	"Stéphane Marchesin" <marcheu@chromium.org>,
	"Tomasz Figa" <tfiga@chromium.org>,
	"Doug Anderson" <dianders@chromium.org>,
	"Thierry Reding" <treding@nvidia.com>,
	"Krzysztof Kozlowski" <k.kozlowski@samsung.com>,
	"Heiko Stuebner" <heiko@sntech.de>,
	"Jingoo Han" <jingoohan1@gmail.com>,
	"Javier Martinez Canillas" <javier@osg.samsung.com>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
	linux-rockchip@lists.infradead.org
Subject: Re: [PATCH] drm/bridge: analogix: Don't return -EINVAL when panel not support PSR in PSR functions
Date: Mon, 5 Dec 2016 08:43:38 +0530	[thread overview]
Message-ID: <85f3e098-9566-751e-f201-dddda973f77a@codeaurora.org> (raw)
In-Reply-To: <CAOw6vbJTRLu6mTWXWNBmhhgxmkK-szgnUY_bZ+es5PKnjetiXw@mail.gmail.com>



On 12/02/2016 09:33 PM, Sean Paul wrote:
> On Thu, Dec 1, 2016 at 10:54 PM, Archit Taneja <architt@codeaurora.org> wrote:
>> Hi,
>>
>> On 12/02/2016 08:02 AM, zain wang wrote:
>>>
>>> We will ignored PSR setting if panel not support it. So, in this case, we
>>> should
>>> return from analogix_dp_enable/disable_psr() without any error code.
>>> Let's retrun 0 instead of -EINVAL when panel not support PSR in
>>> analogix_dp_enable/disable_psr().
>>>
>>> Signed-off-by: zain wang <wzz@rock-chips.com>
>>> ---
>>>  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 6 ++++--
>>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>>> b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>>> index 6e0447f..0cb3695 100644
>>> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>>> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
>>> @@ -112,7 +112,7 @@ int analogix_dp_enable_psr(struct device *dev)
>>>         struct edp_vsc_psr psr_vsc;
>>>
>>>         if (!dp->psr_support)
>>> -               return -EINVAL;
>>> +               return 0;
>>
>>
>> Looking at the rockchip analogix dp code, in analogix_dp_psr_set, the worker
>> that calls
>> analogix_dp_enable/disable_psr isn't even if psr isn't enabled. So, the
>> bridge funcs
>> shouldn't be called in the first place. I think the error handling is fine
>> to have
>> here.
>>
>
> Hi Archit,
>
> This was my first impression, too, and the complexity of the various
> psr abstraction layers don't help :)
>
> However, this code path will be hit if the source supports psr, but
> the sink doesn't. The rockchip_drm_psr code doesn't know if the sink
> supports psr, so it will end up calling this.

Okay, thanks for the explanation. The dev_warn() below still seems
unnecessary, right?

Archit

>
> Sean
>
>
>>>
>>>         /* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */
>>>         memset(&psr_vsc, 0, sizeof(psr_vsc));
>>> @@ -135,7 +135,7 @@ int analogix_dp_disable_psr(struct device *dev)
>>>         struct edp_vsc_psr psr_vsc;
>>>
>>>         if (!dp->psr_support)
>>> -               return -EINVAL;
>>> +               return 0;
>>>
>>>         /* Prepare VSC packet as per EDP 1.4 spec, Table 6.9 */
>>>         memset(&psr_vsc, 0, sizeof(psr_vsc));
>>> @@ -878,6 +878,8 @@ static void analogix_dp_commit(struct
>>> analogix_dp_device *dp)
>>>         dp->psr_support = analogix_dp_detect_sink_psr(dp);
>>>         if (dp->psr_support)
>>>                 analogix_dp_enable_sink_psr(dp);
>>> +       else
>>> +               dev_warn(dp->dev, "Sink not support PSR\n");
>>
>>
>> This doesn't seem beneficial either. There seems to be a debug
>> print already in analogix_dp_detect_sink_psr which reports PSR
>> related info.
>>
>> Archit
>>
>>>  }
>>>
>>>  /*
>>>
>>
>> --
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
>> a Linux Foundation Collaborative Project

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

  reply	other threads:[~2016-12-05  3:13 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-02  2:32 [PATCH] drm/bridge: analogix: Don't return -EINVAL when panel not support PSR in PSR functions zain wang
2016-12-02  3:54 ` Archit Taneja
2016-12-02 16:03   ` Sean Paul
2016-12-05  3:13     ` Archit Taneja [this message]
2016-12-05 17:28       ` Sean Paul
     [not found]         ` <CAOw6vbLv_q8XPj4_A7Yx1HaVVkdUTeq9=EHAjtJd7bOge2C21Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-12-07  0:45           ` Zain Wang

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=85f3e098-9566-751e-f201-dddda973f77a@codeaurora.org \
    --to=architt@codeaurora.org \
    --cc=airlied@linux.ie \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dianders@chromium.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=heiko@sntech.de \
    --cc=inki.dae@samsung.com \
    --cc=javier@osg.samsung.com \
    --cc=jingoohan1@gmail.com \
    --cc=k.kozlowski@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=marcheu@chromium.org \
    --cc=mika.kahola@intel.com \
    --cc=seanpaul@chromium.org \
    --cc=tfiga@chromium.org \
    --cc=tomeu.vizoso@collabora.com \
    --cc=treding@nvidia.com \
    --cc=wzz@rock-chips.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