[PATCH 6/6] drm/msm: add OCMEM driver

[Rob Clark]

On Wed, Sep 30, 2015 at 7:31 AM, Rob Clark <robdclark at gmail.com> wrote:
> On Wed, Sep 30, 2015 at 3:51 AM, Stanimir Varbanov
> <stanimir.varbanov at linaro.org> wrote:
>> Hi Rob,
>>
>> Thanks for your work.
>>
>> On 09/29/2015 10:48 PM, Rob Clark wrote:
>>> For now, since the GPU is the only upstream consumer, just stuff this
>>> into drm/msm.  Eventually if we have other consumers, we'll have to
>>
>> As the video encoder/decoder driver (vidc) for apq8084 && msm8974 also
>> use the ocmem for scratch buffers, it might be better to relocate the
>> ocmem driver in drivers/soc/qcom from the beginning?
>
> I wasn't really sure how soon vidc would support 8084/8974 (I assume
> first target is 8916 which fortunately doesn't have ocmem), or if it
> was mandatory or just power optimization..  but yes, the plan was to
> move it somewhere else (not sure quite where, drivers/doc/qcom?)
> sometime..  Preferably when someone who understands all the other
> ocmem use-cases better could figure out what we really need to add to
> the driver.
>
> In downstream driver there is a lot of complexity that appears to be
> in order to allow two clients to each allocate a portion of a macro
> within a region (ie. aggregate_macro_state(), apply_macro_vote(),
> etc), and I wanted to figure out if that is even a valid use-case
> before trying to make ocmem something that could actually support
> multiple clients.
>
> There is also some complexity about ensuring that if clients aren't
> split up on region boundaries, that you don't have one client in
> region asking for wide-mode and other for narrow-mode..
> (switch_region_mode()) but maybe we could handle that by just
> allocating wide from bottom and narrow from top.  Also seems to be
> some craziness for allowing one client to pre-empt/evict another.. a
> dm engine, etc, etc..
>
> All I know is gpu just statically allocates one big region aligned
> chunk of ocmem, so I ignored the rest of the crazy (maybe or maybe not
> hypothetical) use-cases for now...

btw, I should add that I don't mind adding it in drivers/soc/qcom (or
somewhere else?) to start with if others prefer, I just didn't want to
give the wrong impression that it is ready yet for multiple clients.

All I know is the gpu uses it statically and is pretty much useless
without ocmem, so for lack of understanding of the other use cases I
just tried to add simply what the gpu needs..

BR,
-R

>
>> I'm working on vidc driver upstream version so it will be nice to test
>> ocmem driver from it, too.
>>
>>> split this out and make the allocation less hard coded.  But I'll punt
>>> on that until I better understand the non-gpu uses-cases (and whether
>>> the allocation *really* needs to be as complicated as it is in the
>>> downstream driver).
>>>
>>> Signed-off-by: Rob Clark <robdclark at gmail.com>
>>> ---
>>>  drivers/gpu/drm/msm/Makefile          |   3 +-
>>>  drivers/gpu/drm/msm/adreno/a3xx_gpu.c |  19 +-
>>>  drivers/gpu/drm/msm/adreno/a4xx_gpu.c |  19 +-
>>>  drivers/gpu/drm/msm/msm_drv.c         |   2 +
>>>  drivers/gpu/drm/msm/msm_gpu.h         |   3 +
>>>  drivers/gpu/drm/msm/ocmem/ocmem.c     | 399 ++++++++++++++++++++++++++++++++++
>>>  drivers/gpu/drm/msm/ocmem/ocmem.h     |  46 ++++
>>>  7 files changed, 463 insertions(+), 28 deletions(-)
>>>  create mode 100644 drivers/gpu/drm/msm/ocmem/ocmem.c
>>>  create mode 100644 drivers/gpu/drm/msm/ocmem/ocmem.h
>>>
>>
>> <snip>
>>
>> --
>> regards,
>> Stan