On 2/1/23 20:52, Matthias Brugger wrote:
Hi all,
On 11/01/2023 06:37, Macpaul Lin wrote:
On 1/9/23 23:13, AngeloGioacchino Del Regno wrote:
Il 05/01/23 10:28, Macpaul Lin ha scritto:
Introduce the split MT8195 laptop and iot USB configurations.
The hardware specifications for LAPTOP devices is different from IOT
devices. The major differences include some hardware constrains for
dual-role switch for USB controllers in different configurations,
especially for power management and other control flows as well.
Here are some hardware specifiction differences listed:
1. LAPTOP (Cherry Tomato boards) don't support USB gadget (device
mode).
2. IOT devices must support multiple gadget devices and host mode.
3. Dual-role switch is not fully supported. Only USB PORT0 support
dual-role switch.
4. Power management is designed in primary and secondary dominator.
For a dual-role port, the device controller is the primary
controller
for power management; while the host controller is the secondary.
LAPTOP devices should remove device nodes for avoiding abnormal
behavior.
This modifcation is to add USB configurations "mt8195-laptop-usb.dtsi"
for LAPTOP devices, and add "mt8195-iot-usb.dtsi" for IOT devices.
To remove common USB configurations for mt8195.dtsi and switch includes
dtsi these new files for the boards will come in next patch.
Signed-off-by: Macpaul Lin <macpaul.lin@xxxxxxxxxxxx>
I'm mostly sure that there's no reason to split the two configurations.
I agree in that Tomato doesn't support gadget mode on the Type-A port
and I
honestly don't currently know (and I'll test that later!) if it would
be possible
to act as gadget on any of the two Type-C ports.
Of course I agree on the fact that a laptop acting as a gadget may
not be useful,
but that's not something that I want to judge, as someone may find a
usecase.
In any case, even if Tomato does *not* support gadget mode on *any*
port at all,
I wonder why we wouldn't be able to probe MTU3 (and correctly
describe the SoC)
on Chromebooks but only on MT8195-based IoT boards...
...and in case there's any real issue, we can always force host mode
(with a
generic devicetree property!) on the MTU3 on Tomato.
We are sorry it cannot be achieved by even setting "force host mode"
to usb device node. At least, it cannot be done on MT8195.
The basic reason is the power requirements for USB host on a LAPTOP
are different from those on an IoT device.
The main cause is low power management. The hardware of each device
port is different on MT8195. Even the bit fields definition in
registers were different.
Some details such as sequence need to be coordinated with the SPM
firmware. When a device hardware is involved in runtime PM, function
like remote wakeup and other suspend/resume behavior will be abnormal
for a LAPTOP device. If we split the dtsi for different devices,
people can choose different configuration in SPM firmware in coreboot
or in TF-A to meet the requirement. Hence we'd better not to get more
messy code in Linux driver.
I'm not sure I understand everything here. If the XHCI device is a child
of the mtu3 node then we have problems with some SPM firmware that is
not coordinated with the runtime PM functions of the kernel?
The behavior of runtime PM function, especially the behavior of USB
remote wake up will be different if mtu3 node is involved, for MT8195.
Fixing that in the device tree sounds wrong here. I think the real fix
would be, to fix the SPM firmware, so that it can deal with that.
Or is there more to it? If so what? In that case can we try to ignore
the runtime PM in the MTU3 kernel driver?
I'm not an USB expert but to me it looks very strange that we can have
the XHCI devices nodes as 'standalone' or as children of mtu3. We should
try to describe the HW as it is in DT.
After a discussion with MTU3 maintainer Chunfeng, we think there might
be a way to give it a try to refactor the mtu3 driver.
That is to create an extra USB platform device to handle mtu3 and
xhci-mtk as the children at the same level. Both mtu3 platform device
xhci-mtk platform device will become the children of a common USB
platform device. However, we are not sure if this could work and solved the
dependencies. It requires some development time and MediaTek need
to allocate some developer's resource to verify this approach.
Regards,
Matthias
Finally, if we're able to add MTU3 to Tomato boards, this means that
we won't be
seeing these two DTSI files and that USB nodes are still going to all
lie in the
main `mt8195.dtsi` file, without all this duplication that I'm seeing
here.
What do you think?
Regards,
Angelo
Thanks for the suggestion, we hope the next platform in the future
could avoid this issue and reduce some duplicate dts.
Macpaul Lin
Thanks
Macpaul Lin
