From: Viktor Barna <[email protected]>
(Part of the split. Please, take a look at the cover letter for more
details).
Signed-off-by: Viktor Barna <[email protected]>
---
drivers/net/wireless/celeno/cl8k/rates.h | 154 +++++++++++++++++++++++
1 file changed, 154 insertions(+)
create mode 100644 drivers/net/wireless/celeno/cl8k/rates.h
diff --git a/drivers/net/wireless/celeno/cl8k/rates.h b/drivers/net/wireless/celeno/cl8k/rates.h
new file mode 100644
index 000000000000..223924f21dc2
--- /dev/null
+++ b/drivers/net/wireless/celeno/cl8k/rates.h
@@ -0,0 +1,154 @@
+/* SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause */
+/* Copyright(c) 2019-2022, Celeno Communications Ltd. */
+
+#ifndef CL_RATE_CTRL_H
+#define CL_RATE_CTRL_H
+
+#include <linux/types.h>
+
+#include "ipc_shared.h"
+#include "wrs.h"
+
+#define RATE_CTRL_OFFSET_OFDM 4
+#define RATE_CNTRL_HE_SPATIAL_CONF_DEF 0xF
+
+/* Op_mode field in mm_update_rate_dl_req structure */
+enum cl_op_mode {
+ RATE_OP_MODE_FIXED,
+ RATE_OP_MODE_DEFAULT_HE,
+ RATE_OP_MODE_DEFAULT_OFDM,
+ RATE_OP_MODE_DEFAULT_CCK,
+ RATE_OP_MODE_STA_SU,
+ RATE_OP_MODE_STA_MU,
+ RATE_OP_MODE_MCAST,
+ RATE_OP_MODE_BCAST
+};
+
+/* Value to be set in tx_host_info */
+enum cl_rate_ctrl_entry {
+ RATE_CTRL_ENTRY_NA = 0,
+
+ RATE_CTRL_ENTRY_STA,
+ RATE_CTRL_ENTRY_FIXED_RATE,
+ RATE_CTRL_ENTRY_MIN_HE,
+ RATE_CTRL_ENTRY_MIN_OFDM,
+ RATE_CTRL_ENTRY_MIN_CCK,
+ RATE_CTRL_ENTRY_MCAST,
+ RATE_CTRL_ENTRY_BCAST,
+
+ /* Entry size in firmware is represented by 3 bits */
+ RATE_CTRL_ENTRY_MAX = 8
+};
+
+/*
+ * sw_ctrl includes eights bits (16 - 23) to be used by software.
+ * Bit 16 is used by driver to indicate tx_bf.
+ * Bit 17 is used by driver to indicate fallback.
+ * Bit 18 - 23 are still free.
+ */
+struct cl_rate_ctrl_info_fields {
+ u32 mcs_index : 7; /* [6:0] */
+ u32 bw : 2; /* [8:7] */
+ u32 gi : 2; /* [10:9] */
+ u32 pre_type_or_stbc : 1; /* [11] */
+ u32 format_mod : 4; /* [15:12] */
+ u32 tx_bf : 1; /* [16] */
+ u32 fallback : 1; /* [17] */
+ u32 sw_ctrl : 6; /* [23:18] */
+ u32 tx_chains : 8; /* [31:24] */
+};
+
+union cl_rate_ctrl_info {
+ struct cl_rate_ctrl_info_fields field;
+ u32 word;
+};
+
+struct cl_rate_ctrl_info_he_fields {
+ u32 spatial_conf : 4; /* [3:0] */
+ u32 starting_sts : 3; /* [6:4] */
+ u32 ru_index : 6; /* [12:7] */
+ u32 ru_type : 3; /* [15:13] */
+ u32 ru_band : 1; /* [16] */
+ u32 mu_usr_pos : 2; /* [18:17] */
+ u32 dcm_data : 1; /* [19] */
+ u32 num_usrs_mu_dl : 4; /* [23:20] */
+ u32 ru_alloc : 8; /* [31:24] */
+};
+
+union cl_rate_ctrl_info_he {
+ struct cl_rate_ctrl_info_he_fields field;
+ u32 word;
+};
+
+#define DATA_RATE_INVERSE_Q 15
+
+struct cl_inverse_data_rate {
+ u16 he[CHNL_BW_MAX][WRS_SS_MAX][WRS_MCS_MAX_HE][WRS_GI_MAX_HE];
+ u16 ht_vht[CHNL_BW_MAX][WRS_SS_MAX][WRS_MCS_MAX_VHT][WRS_GI_MAX_VHT];
+ u16 ofdm[WRS_MCS_MAX_OFDM];
+ u16 cck[WRS_MCS_MAX_CCK];
+};
+
+extern struct cl_inverse_data_rate inverse_data_rate;
+
+extern const u16 data_rate_he_x10[CHNL_BW_MAX][WRS_SS_MAX][WRS_MCS_MAX_HE][WRS_GI_MAX_HE];
+extern const u16 data_rate_ht_vht_x10[CHNL_BW_MAX][WRS_SS_MAX][WRS_MCS_MAX_VHT][WRS_GI_MAX_VHT];
+extern const u16 data_rate_ofdm_x10[];
+extern const u16 data_rate_cck_x10[];
+
+struct cl_hw;
+struct cl_sta;
+struct cl_sw_txhdr;
+
+u32 cl_rate_ctrl_generate(struct cl_hw *cl_hw, struct cl_sta *cl_sta,
+ u8 mode, u8 bw, u8 nss, u8 mcs, u8 gi,
+ bool fallback_en, bool mu_valid);
+void cl_rate_ctrl_convert(union cl_rate_ctrl_info *rate_ctrl_info);
+void cl_rate_ctrl_parse(union cl_rate_ctrl_info *rate_ctrl_info, u8 *nss, u8 *mcs);
+
+void cl_rate_ctrl_set_default(struct cl_hw *cl_hw);
+
+void cl_rate_ctrl_set_default_per_he_minrate(struct cl_hw *cl_hw, u8 bw,
+ u8 nss, u8 mcs, u8 gi);
+bool cl_rate_ctrl_set_mcast(struct cl_hw *cl_hw, u8 mode, u8 mcs);
+void cl_rate_ctrl_update_desc_single(struct cl_hw *cl_hw, struct tx_host_info *info,
+ struct cl_sw_txhdr *sw_txhdr);
+void cl_rate_ctrl_update_desc_agg(struct cl_hw *cl_hw, struct tx_host_info *info);
+void cl_data_rates_inverse_build(void);
+u16 cl_data_rates_get(u8 mode, u8 bw, u8 nss, u8 mcs, u8 gi);
+u16 cl_data_rates_get_x10(u8 mode, u8 bw, u8 nss, u8 mcs, u8 gi);
+
+#ifdef CONFIG_CL8K_DYN_BCAST_RATE
+
+struct cl_dyn_bcast_rate {
+ u8 sta_min_mcs;
+ u8 bcast_mcs;
+ u8 wrs_mode;
+ u8 ltf;
+};
+
+void cl_dyn_bcast_rate_init(struct cl_hw *cl_hw);
+void cl_dyn_bcast_rate_set(struct cl_hw *cl_hw, u8 bcast_mcs);
+void cl_dyn_bcast_rate_recovery(struct cl_hw *cl_hw);
+void cl_dyn_bcast_rate_change(struct cl_hw *cl_hw, struct cl_sta *cl_sta_change,
+ u8 old_mcs, u8 new_mcs);
+void cl_dyn_bcast_rate_update_upon_assoc(struct cl_hw *cl_hw, u8 mcs, u8 num_sta);
+void cl_dyn_bcast_rate_update_upon_disassoc(struct cl_hw *cl_hw, u8 mcs, u8 num_sta);
+void cl_dyn_bcast_update(struct cl_hw *cl_hw);
+#endif /* CONFIG_CL8K_DYN_BCAST_RATE */
+#ifdef CONFIG_CL8K_DYN_MCAST_RATE
+
+struct cl_dyn_mcast_rate {
+ u8 wrs_mode_default;
+ u8 wrs_mode_curr;
+};
+
+void cl_dyn_mcast_rate_init(struct cl_hw *cl_hw);
+void cl_dyn_mcast_rate_set(struct cl_hw *cl_hw);
+void cl_dyn_mcast_rate_recovery(struct cl_hw *cl_hw);
+void cl_dyn_mcast_rate_update_upon_assoc(struct cl_hw *cl_hw, u8 wrs_mode, u8 num_sta);
+void cl_dyn_mcast_rate_update_upon_disassoc(struct cl_hw *cl_hw, u8 wrs_mode, u8 num_sta);
+void cl_dyn_mcast_update(struct cl_hw *cl_hw);
+#endif /* CONFIG_CL8K_DYN_MCAST_RATE */
+
+#endif /* CL_RATE_CTRL_H */
--
2.36.1
On Tue, 2022-05-24 at 14:34 +0300, [email protected] wrote:
>
> +/*
> + * sw_ctrl includes eights bits (16 - 23) to be used by software.
that makes it sound like these are firmware things and should be endian
safe?
johannes
On Thu, 26 May 2022 21:54:36 +0200, [email protected] wrote:
> that makes it sound like these are firmware things and should be endian
> safe?
Yes, it should, thanks! PS: can you, please, clarify whether it is ok to reply
with “ACK” for all comments, those does not imply anything special in response?
Just to show, that we saw the comment and will take it into account. Or …is it
enough to mention that in RFCv3 changelist? We are grateful for the review!
Best regards,
Viktor Barna
On Tue, 2022-07-12 at 02:17 +0300, Viktor Barna wrote:
> On Thu, 26 May 2022 21:54:36 +0200, [email protected] wrote:
> > that makes it sound like these are firmware things and should be endian
> > safe?
>
> Yes, it should, thanks! PS: can you, please, clarify whether it is ok to reply
> with “ACK” for all comments, those does not imply anything special in response?
> Just to show, that we saw the comment and will take it into account. Or …is it
> enough to mention that in RFCv3 changelist? We are grateful for the review!
>
From my POV, it's sufficient to list in the version changelog "addressed
comments from <person>" or so, not like in gerrit where you have to mark
as "ack"/"done" for each comment :-)
Of course if there's something where you disagree or want to solve it in
another way, it's probably easier to continue the discussion with that
comment instead.
johannes