RE: [PATCH V4 03/11] clk: imx: scu: add scu clock divider

[Stephen Boyd <sboyd@kernel.org>]

Quoting A.s. Dong (2018-10-17 08:45:05)
> > -----Original Message-----
> > From: Stephen Boyd [mailto:sboyd@kernel.org]
> > Sent: Wednesday, October 17, 2018 11:17 PM
> > Quoting A.s. Dong (2018-10-17 01:56:35)
> > > > From: Stephen Boyd [mailto:sboyd@kernel.org]
> > > > Sent: Wednesday, October 17, 2018 5:26 AM Quoting A.s. Dong
> > > > (2018-10-14 01:07:49)
> > >
> > > How about do something like below?
> > > struct req_get_clock_rate {
> > >         u16 resource;
> > >         u8 clk;
> > > } __packed;
> > >
> > > struct resp_get_clock_rate {
> > >         u32 rate;
> > > } __packed;
> > 
> > This doesn't need __packed because it's a single u32.
> > 
> 
> It's a safe writing, but yes, can be removed.
> 
> > >
> > > struct imx_sc_msg_get_clock_rate {
> > >         struct imx_sc_rpc_msg hdr;
> > >         union {
> > >                 struct req_get_clock_rate req;
> > >                 struct resp_get_clock_rate resp;
> > >         } data;
> > > } __packed;
> > >
> > 
> > Yes something like this would be best. And now I wonder if
> > imx_scu_call_rpc() is doing endianness swapping? Or does it copy data into
> > these response structures? I'm saying that the u32/16/8 may need to be
> > __le32/16/8 and then have the proper accessors.
> > 
> 
> No endianness swapping. It's fixed little endian.
> SCU protocol isn't aware of these structures. The structures are defined
> according to SCU protocol definition to make sure each field position and size
> are correct. Then SCU IPC driver just send and receive them sequentially.
> Client driver uses the structures to retrieve the responding filed values.
> 
> We do this like drivers/firmware/ti_sci.h
> Do you think we still need specify __le32/16/8 for this case?

Probably, because the CPU in linux could be big endian or little endian.
It doesn't hurt to do it right to begin with and then you get the
support for free if it's ever used later on.

> 
> > >
> > > > > +       hdr->size = 3;
> > > > > +
> > > > > +       msg.rate = rate;
> > > > > +       msg.resource = div->rsrc_id;
> > > > > +       msg.clk = div->clk_type;
> > > > > +
> > > > > +       ret = imx_scu_call_rpc(ccm_ipc_handle, &msg, true);
> > > > > +       if (ret)
> > > > > +               pr_err("%s: failed to set clock rate %ld : ret %d\n",
> > > > > +                       clk_hw_get_name(hw), rate, ret);
> > > > > +
> > > > > +       return 0;
> > > > > +}
> > > > > +
> > > > > +static const struct clk_ops clk_divider_scu_ops = {
> > > > > +       .recalc_rate = clk_divider_scu_recalc_rate,
> > > > > +       .round_rate = clk_divider_scu_round_rate,
> > > > > +       .set_rate = clk_divider_scu_set_rate, };
> > > > > +
> > > > > +struct clk_hw *imx_clk_register_divider_scu(const char *name,
> > > > > +                                           const char
> > > > *parent_name,
> > > > > +                                           u32 rsrc_id,
> > > > > +                                           u8 clk_type) {
> > > > > +       struct clk_divider_scu *div;
> > > > > +       struct clk_init_data init;
> > > > > +       struct clk_hw *hw;
> > > > > +       int ret;
> > > > > +
> > > > > +       div = kzalloc(sizeof(*div), GFP_KERNEL);
> > > > > +       if (!div)
> > > > > +               return ERR_PTR(-ENOMEM);
> > > > > +
> > > > > +       div->rsrc_id = rsrc_id;
> > > > > +       div->clk_type = clk_type;
> > > > > +
> > > > > +       init.name = name;
> > > > > +       init.ops = &clk_divider_scu_ops;
> > > > > +       init.flags = CLK_GET_RATE_NOCACHE;
> > > >
> > > > Why nocache? Please have a good reason and add a comment indicating
> > why.
> > > >
> > >
> > > Because on MX8, the clocks are tightly couple with power domain that
> > > once the power domain is off, the clock status will be lost.
> > > Making it NOCACHE helps user to retrieve the real clock status from HW
> > > Instead of using the possible invalid cached rate.
> > >
> > > Is that reasonable enough to specify it?
> > 
> > Yes, you can add a comment like that. Or the clk rate can be restored when the
> > power domain is enabled again?
> 
> No restore when power domain is enabled again. That needs driver to do special
> handling. 
> 
> Can we add the comment in commit message as there're still many other places
> using this?
> 

Sure. Please also add the comment into the code so we don't have to dig
it out of commit text.