Hi Sergei,
On Tue, Nov 27, 2018 at 6:45 PM Sergei Shtylyov
<sergei.shtyl...@cogentembedded.com> wrote:
> On 11/23/2018 03:59 PM, Geert Uytterhoeven wrote:
> >> Add the RPCSRC internal clock on R-Car V3H (R8A77980) -- it's controlled
> >> by the RPCCKCR.DIV[4:3] on all the R-Car gen3 SoCs except V3M (R8A77970)
> >> but the encoding of this field is different between SoCs.
> >> --- renesas-drivers.orig/drivers/clk/renesas/r8a77980-cpg-mssr.c
> >> +++ renesas-drivers/drivers/clk/renesas/r8a77980-cpg-mssr.c
> [...]
> >> + const struct clk *parent = clks[core->parent];
> >> +
> >> + if (IS_ERR(parent))
> >> + return ERR_CAST(parent);
> >> +
> >> + return clk_register_divider_table(NULL, core->name,
> >> + __clk_get_name(parent),
> >> 0,
> >> + base + CPG_RPCCKCR, 3,
> >> 2, 0,
> >> + cpg_rpcsrc_div_table,
> >> NULL);
> >
> > Don't you need a spinlock (last parameter, currently NULL)?
> > This needs to be synchronized with controlling the RPCD2 and RPC clocks,
> > as they operate on the same register.
>
> Indeed. How about the RMW accesses to the other register? I'd like to place
> the lock/unlock right in cpg_reg_modify()...
Yes, RMW, too.
> > However, that would deadlock, as enabling e.g. RPC-IF will enable
> > all parent clocks?
>
> Could toy please elaborate?
Sorry, I incorrectly assumed it would hold the lock while calling into the
parent, which would deadlock if using the same lock.
But as it only holds the lock for register access, it's fine.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
