#define<tab>

It wold be safer to check if both clocks exist in the dtb before trying to enable them.

This might leave one or both clocks enabled which may not be desirable.

It feels like we need a high level API to optionally set the frequency & enable the clock, it's a common operation. Even better if it can handle multiple clocks & cleanup correctly on failure of one.

Missing uart_snps

This is not needed

Could you integrate the change from D5718 with it ?
The disabled nodes aren't needed.

#include "sun7i-a20-hdmi.dtsi"

/ {

soc@01c00000 {
        hdmi@01c16000 {
                status = "okay";
        };

        hdmiaudio {
                status = "okay";
        };
};

};

&mmc0_pins_a {

allwinner,pull = <SUN4I_PINCTRL_PULL_UP>;

};

#include "sun7i-a20-hdmi.dtsi"

/ {

soc@01c00000 {
        hdmi@01c16000 {
                status = "okay";
        };

        hdmiaudio {
                status = "okay";
        };
};

};

#include "sun7i-a20-hdmi.dtsi"

/ {

soc@01c00000 {
        hdmi@01c16000 {
                status = "okay";
        };

        hdmiaudio {
                status = "okay";
        };
};

};

Do we know if the HDMI code works on sun4i-a10?

Should get sorted out when D5749 is merged.

This should get cleaned up when D5749 gets merged.

Settings frequency in consumer driver is not frequent operation, mainly if is fixed. Imho, it's always better to setup base frequency plan for whole SoC at one place (in this case probably in driver for "/clocks" node). Typical consumers of clk_set_freq() are MMC, HDMI or UART - where frequency must be changed at runtime by user or connected device request.

You're right I forgot, just tested it and it doesn't work.

Not supported on sun4i-a10 yet.