Quoting David Dai (2019-01-11 16:56:14)Point taken, I'll leave it out of the macro for now.
On 1/9/2019 11:28 AM, Stephen Boyd wrote:Is only the vote part of the message in little endian format and the
Quoting David Dai (2018-12-13 18:35:04)Sorry, could you clarify this question? If you're referring to the
+Why?
+#define BCM_TCS_CMD(valid, vote) \
+ (BCM_TCS_CMD_COMMIT_MASK | \
+ ((valid) << BCM_TCS_CMD_VALID_SHIFT) | \
+ ((cpu_to_le32(vote) & \
cpu_to_le32, shouldn't we be explicit about converting endianness even
if it might be redundant for this particular qcom platform?
rest is native CPU endianess? It's very odd to see that jammed in the
middle of a bit packing statement like that. Typically the whole u32
would be in one or the other endianness. Also, sparse right complains
about this macro and it's usage, so something is wrong.
I think one other problem is that rpmh API doesn't really talk about
endianness here and that's busted. So if you want to fix endianness
issues that needs to be fixed first.
--Ok, hopefully the kernel-doc comes out easy to understand.Supposed to be unit, the value is on the order of Khz.@@ -29,6 +54,7 @@But there isn't aux_data. Is this supposed to be unit? And what is unit
* @aggr_state: rpmh clock aggregated state
* @last_sent_aggr_state: rpmh clock last aggr state sent to RPMh
* @valid_state_mask: mask to determine the state of the rpmh clock
+ * @aux_data: data specific to the bcm rpmh resource
going to be? 1000?
OK.Yeah... convention seems to be 2 letters and then a number for most BCM@@ -217,6 +340,7 @@ static unsigned long clk_rpmh_recalc_rate(struct clk_hw *hw,It's really IP0?! What was wrong with IPA?
DEFINE_CLK_RPMH_VRM(sdm845, rf_clk1, rf_clk1_ao, "rfclka1", 1);
DEFINE_CLK_RPMH_VRM(sdm845, rf_clk2, rf_clk2_ao, "rfclka2", 1);
DEFINE_CLK_RPMH_VRM(sdm845, rf_clk3, rf_clk3_ao, "rfclka3", 1);
+DEFINE_CLK_RPMH_BCM(sdm845, ipa, "IP0");
resources.