> On 12.02.2016, at 18:34, Martin Sperl <kernel@xxxxxxxxxxxxxxxx> wrote:
>
> The screen is still blinking and UART does not work.
> Maybe the driver is not able to handle the “remapping”
> of registers to a different range and is touching ram
> used by the FW?
>
> The only solution that I found is using fixed clocks
> in the device-tree (which is not what we intended:
> / {
> clk_uart0: clock@3 {
> compatible = "fixed-clock";
> reg = <3>;
> #clock-cells = <0>;
> clock-output-names = "uart0_pclk";
> clock-frequency = <3000000>;
> };
>
> clk_apb_p: clock@4 {
> compatible = "fixed-clock";
> reg = <4>;
> #clock-cells = <0>;
> clock-output-names = "apb_pclk";
> clock-frequency = <126000000>;
> };
> };
> &uart0 {
> clocks = <&clk_uart0 &clk_apb_p>;
> };
>
> (so I have ruled out that the amba-pl011 writes to
> the wrong addresses).
>
> So as far as I can tell it is only clock related
> and when the new clock-framework is used it fails...
So the issue is triggered as soon as the plld_per
pll divider gets disabled/reenabled.
This happens because the clk_hw.core.prepare_count
drops down to 0 and then unprepare is called.
So we need to increase the ref-count for the pll
and pll_dividers to at least 1 so that these never
get disabled - at least for now until we can come
up with a better contract with the firmware.
Obviously this may impact other drivers as well
where a pll is used for the first time - if nothing
else uses it and the clock gets released, then
the clock would trigger a unprepare of the whole
branch of the clock tree.
The question is: how can we solve it in an acceptable
manner?
Do we need a driver that just holds a reference to
those clocks? Or should we just prepare the clock
after registering it in clk-bcm2835.c?
As for why does this not show up when compiled in?
It seems that in that case the amba_pl011 driver
never gets removed and then probed again.
This is possibly related to the optional use of DMA,
with the amba-pl011 driver that retries the install,
which is not supported on the bcm2835 - at least that
is what the datasheet says. And DMA is (probably) not
enabled during the early boot stages, so it does not
fail once when it tries to register DMA.
Thanks,
Martin
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
