On 06/09/2019 11:55, Mark Brown wrote: [...] >>> However you're probably better off hiding all this stuff with the >>> generic OPP code rather than open coding it - this already has much >>> better handling for this, it supports voltage ranges rather than single >>> voltages and optional regulators already. I'm not 100% clear why this >>> is open coded TBH but I might be missing something, if there's some >>> restriction preventing the generic code being used it seems like those >>> sohuld be fixed. > >> To be honest I've no idea how to use the generic OPP code to do this. I >> suspect the original open coding was cargo-culted from another driver: >> the comments in the function look like they were lifted from >> drivers/devfreq/rk3399_dmc.c. Any help tidying this up would be appreciated. > > Yes, there's a lot of cargo culting of bad regulator API usage in > the DRM subsystem for some reason, I keep having to do these > periodic sweeps and there's always stuff in there. I think a lot > of it comes from BSP code that just gets dropped in without > review and then cut'n'pasted but I've not figured out why DRM is > so badly affected. I've been working on tidying up the devfreq usage in Panfrost. From what I can see your patch is correct and I just needed to work out how to fix my DT. Steve _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
