Message-ID: <546a5723-a974-ed0a-93e3-b46c919b0f7e@fivetechno.de>
Date:   Mon, 20 Jan 2020 15:34:02 +0100
From:   Markus Reichl <m.reichl@...etechno.de>
To:     Guenter Roeck <linux@...ck-us.net>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Heiko Stuebner <heiko@...ech.de>,
        Linux USB Mailing List <linux-usb@...r.kernel.org>,
        Linux Kernel <linux-kernel@...r.kernel.org>,
        linux-rockchip@...ts.infradead.org
Subject: Re: [Bug ?] usb :typec :tcpm :fusb302

Hi Guenter,

Am 20.01.20 um 15:21 schrieb Guenter Roeck:
> On 1/20/20 3:58 AM, Heikki Krogerus wrote:
>> Hi Markus,
>>
>> On Thu, Jan 09, 2020 at 05:29:07PM +0100, Markus Reichl wrote:
>>> Hi,
>>>
>>> I'm working with a ROC-RK3399-PC arm64 board from firefly, circuit sheet [1].
>>> The board is powered from an USB-C type connector via an FUSB302 PD controller.
>>> With measured 15W+ power consumption it should use higher voltage PD modes than
>>> the standard 5V USB-C mode.
>>>
>>> When I add the related connector node in DTS [2] the FUSB302 initializes
>>> the right PD mode (e.g. 15V/3A).
>>>
>>> But during initialisation the PD is switched off shortly and the board has a blackout.
>>> When I inject a backup supply voltage behind the FUSB302 (e.g. at SYS_12V line) during boot
>>> I can remove the backup after succesfull setting up the PD and the board will run fine.
>>>
>>> Is it possible to change the behaviour of the fusb302 driver to not power down the PD supply
>>> during init?
>>
>> I guess it's also possible that the problem is with tcpm.c instead of
>> fusb302.c. tcpm.c provides the USB PD state matchines. Guenter! Can
>> you take a look at this?
>>
> 
> There was always a problem with handoff from the bootloader. tcpm_init() calls
> tcpm_reset_port() which turns vbus and vconn off, which I imagine can
> trigger the situation.
> 
> Unfortunately I was never able to solve the puzzle. The Type-C protocol does
> not support any kind of "hand-off" from one component in the system to another.
> If the state machine doesn't start from a clean state, there is pretty
> much no guarantee that it ever synchronizes.
> 
> Maybe someone can find a better solution, but when I wrote the code I just
> could not get it to work reliably without resetting everything during
> registration.
> 
> Note that v4.4 did not include the upstream tcpm code, suggesting the
> code in the vendor kernel was possibly using a different or backported
> state machine. Impossible to say what was done there without access
> to the code.

The vendor code for fusb302 is here:
https://github.com/FireflyTeam/kernel/tree/rk3399/firefly/drivers/mfd

Gruß,
-- 
Markus Reichl
> 
> Guenter
> 
>> Both tcpm.c and fusb302.c create debugfs entries that have a more
>> detailed log about things that are happening. Can you check what you
>> have in those (when you boot with the mains cable plugged it)?
>>
>>          % mount debugfs -t debugfs /sys/kernel/debug
>>          % cat /sys/kernel/debug/tcpm*
>>          % cat /sys/kernel/debug/fusb302/*
>>
>> Which kernel are you running by the way?
>>
>>> In vendor kernel (4.4) this is done somehow but the sources are too different for me to find
>>> out how.
>>>
>>> Gruß,
>>> -- 
>>> Markus Reichl
>>>
>>> [1]
>>> http://download.t-firefly.com/product/RK3399/Docs/Hardware/%E5%8E%9F%E7%90%86%E5%9B%BE%E5%92%8C%E8%B4%B4%E7%89%87%E5%9B%BE/ROC-RK3399-PC/ROC-3399-PC-V10-A-20180804_%E5%8E%9F%E7%90%86%E5%9B%BE.pdf
>>>
>>> [2]
>>> https://lkml.org/lkml/2019/12/10/517
>>
> 

Powered by blists - more mailing lists