On Wed, Sep 06, 2023 at 02:14:14PM +0200, Konrad Dybcio wrote: > > The general idea is that we could use tags for this. So, instead of... > > > > path = icc_get(dev, MASTER_MDP_DISP, SLAVE_EBI1_DISP); > > > > it would be... > > > > path = icc_get(dev, MASTER_MDP, SLAVE_EBI1); > > icc_set_tag(path, QCOM_ICC_TAG_VOTER_DISP); > > > > I have an early prototype with basic testing already. I can hopefully > > clean it up and post for review in the next couple of weeks. > I was initially not very happy with this approach (overloading tags > with additional information), but it grew on me over time. > > My only concern is that if we reserve say bits 16-31 for path tags > (remember, dt-bindings are ABI), we may eventually run out of them. The voter tags wouldn't require bitmasks like the bucket tags do. We'd just need an integer for each voter shifted into the proper position in the tag value. Thus, reserving N bits for the voters would give us 2**N voters, which should be plenty. For example: #define QCOM_ICC_VOTERS_START 16 #define QCOM_ICC_VOTERS_END 23 #define QCOM_ICC_TAG_VOTER_HLOS (0 << QCOM_ICC_VOTERS_START) #define QCOM_ICC_TAG_VOTER_DISP (1 << QCOM_ICC_VOTERS_START) #define QCOM_ICC_TAG_VOTER_CAM_IFE_0 (2 << QCOM_ICC_VOTERS_START) #define QCOM_ICC_TAG_VOTER_CAM_IFE_1 (3 << QCOM_ICC_VOTERS_START) #define QCOM_ICC_TAG_VOTER_CAM_IFE_2 (4 << QCOM_ICC_VOTERS_START) The applicable voters should likely be defined in the target-specific headers, rather than the common qcom,icc.h. The bit range used for them could be common, but each target may only support a small subset of the total set of possible voters across all targets. Clients requiring multiple voters for the same logical path should be rare. On the off-chance they require that, they could just request the same path multiple times with different voter tags applied and call icc_set_bw() for each of them separately. I'm back from travel and vacation and plan to pick this up again soon.
