From: Chanwoo Choi <cw00.choi@samsung.com>
To: Hans de Goede <hdegoede@redhat.com>,
MyungJoo Ham <myungjoo.ham@samsung.com>,
Chen-Yu Tsai <wens@csie.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] extcon: axp288: Only reschedule charger-detection at boot when a SDP is detected
Date: Tue, 16 Jan 2018 08:43:33 +0900 [thread overview]
Message-ID: <5A5D3CA5.7040801@samsung.com> (raw)
In-Reply-To: <4176b3af-01f8-9a5e-f6c8-4c446468918f@redhat.com>
On 2018년 01월 15일 20:32, Hans de Goede wrote:
> HI,
>
> On 15-01-18 10:08, Chanwoo Choi wrote:
>> On 2018년 01월 15일 17:36, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 15-01-18 06:22, Chanwoo Choi wrote:
>>>> On 2018년 01월 15일 00:10, Hans de Goede wrote:
>>>>> The only misdetection which can happen at boot due to data-lines mux issues
>>>>> is detecting a non SDP as SDP, so we only need to retry if we detect a SDP
>>>>> on our first detection.
>>>>>
>>>>> Note Vbus misdetection is not a problem, as soon as the drivers controlling
>>>>> the Vbus path set it correctly we will get an interrupt which reschedules
>>>>> the charger-detection.
>>>>>
>>>>> Also update the comment about the re-detection to reflect this.
>>>>>
>>>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>>>>> ---
>>>>> drivers/extcon/extcon-axp288.c | 14 +++++++-------
>>>>> 1 file changed, 7 insertions(+), 7 deletions(-)
>>>>>
>>>>> diff --git a/drivers/extcon/extcon-axp288.c b/drivers/extcon/extcon-axp288.c
>>>>> index 63b99d5becd7..17e6808af0d1 100644
>>>>> --- a/drivers/extcon/extcon-axp288.c
>>>>> +++ b/drivers/extcon/extcon-axp288.c
>>>>> @@ -161,16 +161,16 @@ static void axp288_chrg_detect_complete(struct axp288_extcon_info *info,
>>>>> /*
>>>>> * We depend on other drivers to do things like mux the data lines,
>>>>> * enable/disable vbus based on the id-pin, etc. Sometimes the BIOS has
>>>>> - * not set these things up correctly resulting in the initial charger
>>>>> - * cable type detection giving a wrong result and we end up not charging
>>>>> - * or charging at only 0.5A.
>>>>> + * not set these things up correctly resulting in a wrong result for the
>>>>> + * initial charger type detection and we end up charging at only 0.5A.
>>>>> *
>>>>> - * So we schedule a second cable type detection after 2 seconds to
>>>>> - * give the other drivers time to load and do their thing.
>>>>> + * If our first detect detects an SDP charger-type, we try again after
>>>>> + * 2 seconds to give the other drivers time to load and do their thing.
>>>>> */
>>>>> if (!info->first_detect_done) {
>>>>> - queue_delayed_work(system_wq, &info->det_work,
>>>>> - msecs_to_jiffies(2000));
>>>>> + if (info->previous_cable == EXTCON_CHG_USB_SDP)
>>>>> + queue_delayed_work(system_wq, &info->det_work,
>>>>> + msecs_to_jiffies(2000));
>>>>> info->first_detect_done = true;
>>>>> }
>>>>>
>>>>
>>>> I understand why you add the second delayed_work because of dependency
>>>> of other consumer driver. But, this patch is not proper method. It looks
>>>> like the workaround.
>>>>
>>>> We need to consider the fundamental solution such as using OF graph
>>>> or sending the pending notification when consumer driver is probed.
>>>
>>> I agree that having some sort of proper probe ordering here would be
>>> better. But on these ACPI systems that is going to be quite tricky todo,
>>> since we've no control over the firmware there.
>>>
>>> Note that you've already merged the workaround, this patch merely changes
>>> the workaround to avoid it in cases where it is not necessary, so I would
>>> really like to see this get merged.
>>
>> I merged your patch because I knew this issue related to dependency.
>>
>> But, I don't want to merge this patch until developing the fundamental
>> method. All extcon provider driver have the same issue. I'll try to
>> resolve this issue thro extcon framework.
>
> I really don't see how holding this very simple patch hostage is going to
> help (or deter) finding a better solution for this.
>
> In the mean time my original patch seems to cause mis-detection of CDP ports
> as SDP ports which this fixes.
I disagree this patch for only one specific connector. Instead of adding second
delayed_work for detection, you better to extend the time from 2 sec to 4 sec
on first time detection.
--
Best Regards,
Chanwoo Choi
Samsung Electronics
next prev parent reply other threads:[~2018-01-15 23:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20180114151033epcas4p4f32a575853ca8d34d2eb362ba7d8b197@epcas4p4.samsung.com>
2018-01-14 15:10 ` [PATCH 1/2] extcon: axp288: Constify the axp288_pwr_up_down_info array Hans de Goede
2018-01-14 15:10 ` [PATCH 2/2] extcon: axp288: Only reschedule charger-detection at boot when a SDP is detected Hans de Goede
2018-01-15 5:22 ` Chanwoo Choi
2018-01-15 8:36 ` Hans de Goede
2018-01-15 9:08 ` Chanwoo Choi
2018-01-15 11:32 ` Hans de Goede
2018-01-15 23:43 ` Chanwoo Choi [this message]
2018-01-16 9:33 ` Hans de Goede
2018-01-17 1:04 ` Chanwoo Choi
2018-01-25 17:06 ` Hans de Goede
2018-01-15 5:35 ` [PATCH 1/2] extcon: axp288: Constify the axp288_pwr_up_down_info array Chanwoo Choi
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=5A5D3CA5.7040801@samsung.com \
--to=cw00.choi@samsung.com \
--cc=hdegoede@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=myungjoo.ham@samsung.com \
--cc=wens@csie.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