Hi Rob, On Fri, Jan 20, 2017 at 08:15:21AM -0600, Rob Herring wrote: > > The only thing that might be vendor specific would be the (optional) > > declaration of the mali_gpu_device_data structure. As far as I know, > > there's two things of importance there: > > - the list of the valid OPPs in order to do DVFS, but that could be > > made generic too using the operating-points binding > > > > - And the valid area for the buffers for the fbdev blobs (fb_start, > > fb_size and shared_mem_size). I'm not entirely happy with this one > > so far (which is also why I've not pushed it). We'd need to come > > up with a way to get the base address and size of the CMA region > > backing the framebuffer allocation, but I haven't find any trivial > > way to do so, so for now I just hardcoded it. Worst case scenario, > > we can hardcode values based on the compatible. > > memory-region property? That might do it, however those buffers usually are allocated by the display engine, and not the GPU device. Even if we declare a reserved memory region and use memory-region in the GPU node, chances are that buffers allocated for the display may not be in that region (for example if it's using the default CMA pool). Unless we create a memory region for the default CMA pool? Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Attachment:
signature.asc
Description: PGP signature
