On Mon, Jul 13, 2020 at 06:24:26PM +0300, Georgi Djakov wrote: > On 7/1/20 07:25, Jonathan Marek wrote: > > The a6xx GMU can vote for ddr and cnoc bandwidth, but it needs to be able > > to query the interconnect driver for bcm addresses and commands. > > It's not very clear to me how the GMU firmware would be dealing with this? Does > anyone have an idea whether the GMU makes any bandwidth decisions? Or is it just > a static configuration and it just enables/disables a TCS? The GMU can perform a direct vote to the hardware. For now it is a static configuration with pre-determined bandwidths generated from the OPP table. > I think that we can query the address from the cmd-db, but we have to know the > bcm names and the path. All the BCM/TCS information looks to be very low-level > and implementation specific, so exposing it through an API is not very good, > but hard-coding all this information is not good either. Exactly my concern. The BCM information in particular is going to end up being extremely target specific. Jordan > Thanks, > Georgi > > > > > I'm not sure what is the best way to go about implementing this, this is > > what I came up with. > > > > I included a quick example of how this can be used by the a6xx driver to > > fill out the GMU bw_table (two ddr bandwidth levels in this example, note > > this would be using the frequency table in dts and not hardcoded values). > > > > Signed-off-by: Jonathan Marek <jonathan@xxxxxxxx> > > --- > > drivers/gpu/drm/msm/adreno/a6xx_hfi.c | 20 ++++------- > > drivers/interconnect/qcom/icc-rpmh.c | 50 +++++++++++++++++++++++++++ > > include/soc/qcom/icc.h | 11 ++++++ > > 3 files changed, 68 insertions(+), 13 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
