On 2/16/25 15:57, Ivaylo Ivanov wrote:

On 2/16/25 15:19, Krzysztof Kozlowski wrote:

quoted

On 16/02/2025 10:51, Ivaylo Ivanov wrote:

quoted

quoted

quoted

quoted

 You need to
integrate the changes, not create duplicated driver.

I can do that, but it would be come a bit cluttered, won't it? Depends on
if we want to follow the current oem-provided initialization sequence, or
try and fully reuse what we have in there.

I think it duplicates a lot, so it won't be clutter. We have many
drivers having common code and per-variant ops.

So the approach to take here is to make a common driver?

For example: one common module and two modules per each soc, because I
assume some per-soc stuff might be needed. But maybe even these two
modules are not necessary and everything could be in one driver.

...

So, Exynos2200 has a much simpler eusb initialization sequence than what
is present in mainline for QCOMs. I still don't really think the drivers
should be merged, as we aren't really duplicating code per-say.

I've already started working on merging them, and my current idea is to
not redefine the registers once again for 2200, but rather make an enum
that defines if the SoC is a QCOM or EXYNOS, and select the register
offsets dynamically

Never mind. That's a bad idea - after more digging way too much bits differ
not just the register layout. I'll implement the init/exit sequence in the
qcom driver separately. Sadly I can't reuse much code.

Best regards,
Ivaylo

 - similarly as how I did with USIv1. If a register
offset is not present, it'd just not do the write. My guess is that this
will make it work with the qualcomm init sequence as well, so it'd result
in even less redundant code (apart from the eUSB tuning, which can be
omitted for now).

quoted

quoted

What about the current modelling scheme, as-in taking the phandle to
the usbcon phy and handling it?

What about it? 

As I said in the commit description, I'm passing the USBCON phy as a
phandle to the eusb2 node and enabling/disabling it when needed. I'm
not 100% sure it would be adequate to include that in a common snps EUSB
driver, as it seems to more of a quirk with the exynoses. But then how
can I model it so that it's correctly described according to how the
hardware works (as-in usbcon "muxing" between child phys, in this case
eUSB and snps USBDP combophy)

Regarding repeaters, I still don't have the TI repeater implemented.

Best regards,
Ivaylo

quoted

Did you look at the bindings of qcom snps eusb2? Are you
saying you do not have here repeater? If so, then this phy phandle might
not be correct.



Best regards,
Krzysztof