On Mon, Feb 22, 2021 at 8:06 AM Rob Clark <robdclark@xxxxxxxxx> wrote: > > On Mon, Feb 22, 2021 at 7:45 AM Akhil P Oommen <akhilpo@xxxxxxxxxxxxxx> wrote: > > > > On 2/19/2021 9:30 PM, Rob Clark wrote: > > > On Fri, Feb 19, 2021 at 2:44 AM Akhil P Oommen <akhilpo@xxxxxxxxxxxxxx> wrote: > > >> > > >> On 2/18/2021 9:41 PM, Rob Clark wrote: > > >>> On Thu, Feb 18, 2021 at 4:28 AM Akhil P Oommen <akhilpo@xxxxxxxxxxxxxx> wrote: > > >>>> > > >>>> On 2/18/2021 2:05 AM, Jonathan Marek wrote: > > >>>>> On 2/17/21 3:18 PM, Rob Clark wrote: > > >>>>>> On Wed, Feb 17, 2021 at 11:08 AM Jordan Crouse > > >>>>>> <jcrouse@xxxxxxxxxxxxxx> wrote: > > >>>>>>> > > >>>>>>> On Wed, Feb 17, 2021 at 07:14:16PM +0530, Akhil P Oommen wrote: > > >>>>>>>> On 2/17/2021 8:36 AM, Rob Clark wrote: > > >>>>>>>>> On Tue, Feb 16, 2021 at 12:10 PM Jonathan Marek <jonathan@xxxxxxxx> > > >>>>>>>>> wrote: > > >>>>>>>>>> > > >>>>>>>>>> Ignore nvmem_cell_get() EOPNOTSUPP error in the same way as a > > >>>>>>>>>> ENOENT error, > > >>>>>>>>>> to fix the case where the kernel was compiled without CONFIG_NVMEM. > > >>>>>>>>>> > > >>>>>>>>>> Fixes: fe7952c629da ("drm/msm: Add speed-bin support to a618 gpu") > > >>>>>>>>>> Signed-off-by: Jonathan Marek <jonathan@xxxxxxxx> > > >>>>>>>>>> --- > > >>>>>>>>>> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 6 +++--- > > >>>>>>>>>> 1 file changed, 3 insertions(+), 3 deletions(-) > > >>>>>>>>>> > > >>>>>>>>>> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c > > >>>>>>>>>> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c > > >>>>>>>>>> index ba8e9d3cf0fe..7fe5d97606aa 100644 > > >>>>>>>>>> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c > > >>>>>>>>>> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c > > >>>>>>>>>> @@ -1356,10 +1356,10 @@ static int a6xx_set_supported_hw(struct > > >>>>>>>>>> device *dev, struct a6xx_gpu *a6xx_gpu, > > >>>>>>>>>> > > >>>>>>>>>> cell = nvmem_cell_get(dev, "speed_bin"); > > >>>>>>>>>> /* > > >>>>>>>>>> - * -ENOENT means that the platform doesn't support > > >>>>>>>>>> speedbin which is > > >>>>>>>>>> - * fine > > >>>>>>>>>> + * -ENOENT means no speed bin in device tree, > > >>>>>>>>>> + * -EOPNOTSUPP means kernel was built without CONFIG_NVMEM > > >>>>>>>>> > > >>>>>>>>> very minor nit, it would be nice to at least preserve the gist of the > > >>>>>>>>> "which is fine" (ie. some variation of "this is an optional thing and > > >>>>>>>>> things won't catch fire without it" ;-)) > > >>>>>>>>> > > >>>>>>>>> (which is, I believe, is true, hopefully Akhil could confirm.. if not > > >>>>>>>>> we should have a harder dependency on CONFIG_NVMEM..) > > >>>>>>>> IIRC, if the gpu opp table in the DT uses the 'opp-supported-hw' > > >>>>>>>> property, > > >>>>>>>> we will see some error during boot up if we don't call > > >>>>>>>> dev_pm_opp_set_supported_hw(). So calling "nvmem_cell_get(dev, > > >>>>>>>> "speed_bin")" > > >>>>>>>> is a way to test this. > > >>>>>>>> > > >>>>>>>> If there is no other harm, we can put a hard dependency on > > >>>>>>>> CONFIG_NVMEM. > > >>>>>>> > > >>>>>>> I'm not sure if we want to go this far given the squishiness about > > >>>>>>> module > > >>>>>>> dependencies. As far as I know we are the only driver that uses this > > >>>>>>> seriously > > >>>>>>> on QCOM SoCs and this is only needed for certain targets. I don't > > >>>>>>> know if we > > >>>>>>> want to force every target to build NVMEM and QFPROM on our behalf. > > >>>>>>> But maybe > > >>>>>>> I'm just saying that because Kconfig dependencies tend to break my > > >>>>>>> brain (and > > >>>>>>> then Arnd has to send a patch to fix it). > > >>>>>>> > > >>>>>> > > >>>>>> Hmm, good point.. looks like CONFIG_NVMEM itself doesn't have any > > >>>>>> other dependencies, so I suppose it wouldn't be the end of the world > > >>>>>> to select that.. but I guess we don't want to require QFPROM > > >>>>>> > > >>>>>> I guess at the end of the day, what is the failure mode if you have a > > >>>>>> speed-bin device, but your kernel config misses QFPROM (and possibly > > >>>>>> NVMEM)? If the result is just not having the highest clk rate(s) > > >>>> > > >>>> Atleast on sc7180's gpu, using an unsupported FMAX breaks gmu. It won't > > >>>> be very obvious what went wrong when this happens! > > >>> > > >>> Ugg, ok.. > > >>> > > >>> I suppose we could select NVMEM, but not QFPROM, and then the case > > >>> where QFPROM is not enabled on platforms that have the speed-bin field > > >>> in DT will fail gracefully and all other platforms would continue on > > >>> happily? > > >>> > > >>> BR, > > >>> -R > > >> > > >> Sounds good to me. > > >> > > > > > > You probably should do a quick test with NVMEM enabled but QFPROM > > > disabled to confirm my theory, but I *think* that should work > > > > > > BR, > > > -R > > > > > > > I tried it on an sc7180 device. The suggested combo (CONFIG_NVMEM + no > > CONFIG_QCOM_QFPROM) makes the gpu probe fail with error "failed to read > > speed-bin. Some OPPs may not be supported by hardware". This is good > > enough clue for the developer that he should fix the broken speedbin > > detection. > > > > Ok, great.. then sounds like selecting NVMEM is a good approach > btw, did anyone ever send a patch to select NVMEM? I'm not seeing one but I could be overlooking something BR, -R _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel