In D36138#821412, @ganbold wrote:

Ok, I hope the updated patch would work.

@sos can you test and let me know?

thanks,

In D36138#821033, @ganbold wrote:

Ok, as @sos said, I updated the patch accordingly

In D36138#821033, @ganbold wrote:

Ok, as @sos said, I updated the patch accordingly

In D36138#820717, @ganbold wrote:

In D36138#820614, @sos wrote:

In D36138#820415, @ganbold wrote:

Ah, right, updated the diff.

But you still missed a few of those bit -1's :)

Do I still miss -1's ? I'm probably blind, where do I miss them?

In D36138#820415, @ganbold wrote:

Ah, right, updated the diff.

In D36138#820415, @ganbold wrote:

Ah, right, updated the diff.

Fix rk809 support, no other changes

More style updates from Ganbold, misc cosmetic changes.
Support for the 3'rd USB2 port on the DWC3 controller.
Tested not to break rk3399 support (rockpro64)

Style changes as pr ganbold, added USB2 support

The "drive-strength" support is bogus for the rk3568, in fact I'm in doubt if it works at all for any of the chipsets :)
At any rate this is all getting way to messy for my liking, I'll properly add support another way here,,,

Having looked more into the PMIC's on the Q64 it is somewhat of a mess, they should be located in /sys/dev/iicbus/pmic as they are not either arm64 or rockchip specific, however down there it is even more of a mess as some are I the pic dir some are not, there are even some that are in both :). I'll look into getting the rk8xx pmic's supported by one driver at at least in "myBSD" put them in the right place together with support for the CPU one which is already partly there..
What happened to getting things put in the right places ? much of the arm/arm64 support is a royal mess as is, I stumbled over this when I did Marvell support for the espressobin as well...
The copyright is easily fixed, just at oversight as that file emerged from at empty templete here and I forgot it...

No you most certainly can not return EINVAL when it is zero :) it will panic the kernel: panic: clknode_refresh_cache failed for 'sclk_audpwm_frac
But returning 0 and a frequency of zero will make it "do the right thing" later when the clock comes available.
Have you tried it on your board ?

It could, but it gets ugly, and the driver/file name should then be something like rk8xx instead. However the 816/817 has lots more functionality so it might make sense in the long run to keep it separate.

The following clocks:
clk_i2s0_8ch_tx_frac: rk_clk_fract_recalc denominator is zero!
clk_i2s0_8ch_rx_frac: rk_clk_fract_recalc denominator is zero!
clk_i2s1_8ch_tx_frac: rk_clk_fract_recalc denominator is zero!
clk_i2s1_8ch_rx_frac: rk_clk_fract_recalc denominator is zero!
clk_i2s2_2ch_frac: rk_clk_fract_recalc denominator is zero!
clk_i2s3_2ch_tx_frac: rk_clk_fract_recalc denominator is zero!
clk_i2s3_2ch_rx_frac: rk_clk_fract_recalc denominator is zero!
mclk_spdif_8ch_frac: rk_clk_fract_recalc denominator is zero!
sclk_audpwm_frac: rk_clk_fract_recalc denominator is zero!
clk_uart1_frac: rk_clk_fract_recalc denominator is zero!
clk_uart2_frac: rk_clk_fract_recalc denominator is zero!
clk_uart3_frac: rk_clk_fract_recalc denominator is zero!
clk_uart4_frac: rk_clk_fract_recalc denominator is zero!
clk_uart5_frac: rk_clk_fract_recalc denominator is zero!
clk_uart6_frac: rk_clk_fract_recalc denominator is zero!
clk_uart7_frac: rk_clk_fract_recalc denominator is zero!
clk_uart8_frac: rk_clk_fract_recalc denominator is zero!
clk_uart9_frac: rk_clk_fract_recalc denominator is zero!
sclk_uart0_frac: rk_clk_fract_recalc denominator is zero!