[PATCH] drm/bridge: analogix: Don't return -EINVAL when panel not support PSR in PSR functions

[Zain Wang]

在 2016/12/6 1:28, Sean Paul 写道:
> On Sun, Dec 4, 2016 at 10:13 PM, Archit Taneja <architt at codeaurora.org> wrote:
>>
>> On 12/02/2016 09:33 PM, Sean Paul wrote:
>>> On Thu, Dec 1, 2016 at 10:54 PM, Archit Taneja <architt at 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 at 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?
>>
> Yeah, one could make a case for dev_info (disclaimer: I have a high
> tolerance for noisy logs), but a warning does seem excessive.
>
> Sean
OK, I will remove the dev_warn since there is a dev_dbg for the same case.
>
>> 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
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>
>
>