Hi Angus,
[snip]
So I'm not sure if the ipg clock is the right one for the boards that has different clock for ipg and per.
So I only looked at imx6qdl.dtsi where the clocks are different
clocks = <&clks IMX6QDL_CLK_UART_IPG>, <&clks IMX6QDL_CLK_UART_SERIAL>; clock-names = "ipg", "per";
And from that file it looks like the per clock would be the correct one.
Yes, 'per' seems to be the right one.
Should the clock be looked up by id instead of by name and then have a different code path for each imx board type ?
But how to get the right clk id? The id's for all the implementations are different. Or not?
}/* as fallback we try to get the clk rate that way */if (rate == 0)rate = imx_get_uartclk();Would it be better to re-write imx_get_uartclk so that both the getting and setting of clocks was correct ?
I do not understand what you mean with that.
There are other places in the code that imx_get_uartclk gets called. If an index was added to imx_get_uartclk(int index) then you wouldn't need the code above in the mxc_serial_setbrg function. That would also make all of the places where imx_get_uartclk gets called return the correct value.
By index do you mean the clk id?
It might make sense to create a new function imx7_get_uartclk that gets called on newer SOCs so that the imx6 and earlier code doesn't need to get changed.
At what point should this be called instead of the imx_get_uartclk() function?
With DM clocks enabled I don't even think it makes sense to call those older functions.
You mean when DM clocks are available the "new" method should be used and no fallback to the old mechanism?
For older boards it makes sense to fallback to the single clock. On newer boards if it returned an error instead it would have been easier for you to figure out where the serial console failed.
-- Heiko