| Message ID | 20231129065748.19871-4-quic_sibis@quicinc.com (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
| Series | firmware: arm_scmi: Miscellaneous fixes and opp count increase | expand |
On Wed, Nov 29, 2023 at 12:27:48PM +0530, Sibi Sankar wrote: > The number of opps on certain variants of the X1E80100 SoC are greater > than current maximum, so increase the MAX_OPP count to the next log level > to accommodate that. > Hi, > Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> > --- > drivers/firmware/arm_scmi/perf.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/firmware/arm_scmi/perf.c b/drivers/firmware/arm_scmi/perf.c > index 3344ce3a2026..edf34a3c4d6a 100644 > --- a/drivers/firmware/arm_scmi/perf.c > +++ b/drivers/firmware/arm_scmi/perf.c > @@ -24,7 +24,7 @@ > #include "protocols.h" > #include "notify.h" > > -#define MAX_OPPS 16 > +#define MAX_OPPS 24 > There is an hashtable, opps_by_freq, sized by an ilog2().... ....so, can we stick to a power-of-2 like 32 instead ? (and be more future proof too...) Other than this, LGTM Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Thanks, Cristian
On 11/30/23 18:30, Cristian Marussi wrote: > On Wed, Nov 29, 2023 at 12:27:48PM +0530, Sibi Sankar wrote: >> The number of opps on certain variants of the X1E80100 SoC are greater >> than current maximum, so increase the MAX_OPP count to the next log level >> to accommodate that. >> > > Hi, Hey Cristian, Thanks for taking time to review the series. > > >> Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> >> --- >> drivers/firmware/arm_scmi/perf.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/firmware/arm_scmi/perf.c b/drivers/firmware/arm_scmi/perf.c >> index 3344ce3a2026..edf34a3c4d6a 100644 >> --- a/drivers/firmware/arm_scmi/perf.c >> +++ b/drivers/firmware/arm_scmi/perf.c >> @@ -24,7 +24,7 @@ >> #include "protocols.h" >> #include "notify.h" >> >> -#define MAX_OPPS 16 >> +#define MAX_OPPS 24 >> > > There is an hashtable, opps_by_freq, sized by an ilog2().... > > ....so, can we stick to a power-of-2 like 32 instead ? > (and be more future proof too...) Thanks, will get this changed in the next re-spin. > > Other than this, LGTM > > Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> > > Thanks, > Cristian
diff --git a/drivers/firmware/arm_scmi/perf.c b/drivers/firmware/arm_scmi/perf.c index 3344ce3a2026..edf34a3c4d6a 100644 --- a/drivers/firmware/arm_scmi/perf.c +++ b/drivers/firmware/arm_scmi/perf.c @@ -24,7 +24,7 @@ #include "protocols.h" #include "notify.h" -#define MAX_OPPS 16 +#define MAX_OPPS 24 enum scmi_performance_protocol_cmd { PERF_DOMAIN_ATTRIBUTES = 0x3,
The number of opps on certain variants of the X1E80100 SoC are greater than current maximum, so increase the MAX_OPP count to the next log level to accommodate that. Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com> --- drivers/firmware/arm_scmi/perf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)