On 11/03/2024 18:23, Volodymyr Babchuk wrote:
Hi Caleb,
Caleb Connolly <caleb.conno...@linaro.org> writes:
On 06/03/2024 21:24, Volodymyr Babchuk wrote:
Hi Caleb,
Caleb Connolly <caleb.conno...@linaro.org> writes:
[...]
+};
+
+&tlmm {
+ /* U-Boot pinctrl driver does not understand multiple tiles */
+ reg = <0x0 0x03000000 0x0 0x1000000>;
+ /delete-property/ reg-names;
This won't be needed if we can make the tiles offset in the pinctrl
driver compatible:
#define WEST 0x00000000
#define EAST 0x00400000
#define NORTH 0x00800000
#define SOUTH 0x00C00000
Hmm, I assume that in this case pinctrl driver should map all the four
tiles independently? Are there guarantees in U-Boot that four separate
memory regions will be mapped into virtual memory with the same relative
positions? Linux clearly don't make such guarantees.
U-Boot doesn't use virtual addresses on arm platforms, it only goes as
far as reading the address from DT, nothing else, so this is totally
fine and is how the other SoCs do it.
For me it looks like we are depending on implementation details
knowledge. I.e MMU API does not provide such guarantees, but drivers
know how ARM MMU code is working internally and drivers depend on
exactly this behavior. But if you are saying that it is totally fine,
I'll rework the patch. No big deal. Actually, I already tried this and
it is working fine.
+
+ /* U-Boot ethernet driver wants to drive reset as GPIO */
+ /delete-node/ phy-reset-pins;
I suppose this is not needed as phy-reset-pins also configures the pin
as GPIO only.
Well, yes. This also puzzles me up, but for some reason it stops working
if I leave this node intact. Looks like I need to look at this deeper
before posting the next version.
Possibly the pinconf defined in the phy-reset-pins node causes U-Boot to
misbehave, can you check if this patch fixes it (there is a bug in the
line "return msm_gpio_direction_input(dev, gpio);", it should become
just "msm_gpio_direction_input(dev, gpio);").
I had the exact same issue with the gpio-regulator driver and this was
the solution I ended up going with.
https://urldefense.com/v3/__https://lore.kernel.org/u-boot/20240131-b4-qcom-livetree-v1-7-4071c0787...@linaro.org/__;!!GF_29dbcQIUBPA!xFhZe7DKgRbr63sirEJLuH-B0AnGs7jvx8tdJPKLTgFuZ3I3_zpVml7l23G-_vJO_JiUR-wUO4GMPJFcE-8p50H3pf7nbxit$
[lore[.]kernel[.]org]
It is exactly this. With your patch I don't need to /delete-node/
anymore. I'll add a comment in the cover message that this series are
depended on your patch.
Please can you split the power domain and clock patches into a separate
series? As I'd like to depend on them for the next revision of my
series, and we'd otherwise have a cyclical dependency.
Of course.
As I understood, you are interested in "clk: qcom: clear div mask before
assigning a new divider" and "clk: qcom: add support for power domains
uclass", correct?
Yes. I tried the power domain stuff out on SMD845 today and ran into
quite a few issues. Specifically as a lot of the devices reference the
rpmhpd power domain which we don't support (and don't *need* to support)
in U-Boot. I'm not sure what the best way forward will be for this.
Maybe a "nop" power domain driver?
Do you have the same issues on sm8150?
--
// Caleb (they/them)
