Quoting A.s. Dong (2018-10-17 08:45:05)

quoted

-----Original Message-----
From: Stephen Boyd [mailto:sboyd at kernel.org]
Sent: Wednesday, October 17, 2018 11:17 PM
Quoting A.s. Dong (2018-10-17 01:56:35)

quoted

quoted

From: Stephen Boyd [mailto:sboyd at 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.

quoted

quoted

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.

quoted

quoted

quoted

quoted

+       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,

quoted

+                                           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.

quoted

quoted

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.