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

[Rob Clark]

On Thu, Oct 1, 2015 at 2:00 PM, Stephen Boyd <sboyd at codeaurora.org> wrote:
> On 10/01, Stanimir Varbanov wrote:
>> On 09/30/2015 02:45 PM, Rob Clark wrote:
>> > 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:
>> >>> On 09/29/2015 10:48 PM, Rob Clark wrote:
>> >> 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...
>>
>> OK, I will try to sort out ocmem use cases for vidc driver.
>>
>
> The simplest thing to do is to split the memory between GPU and
> vidc statically. The other use cases with preemption and eviction
> and DMA add a lot of complexity that we can explore at a later
> time if need be.

true, as long as one of the clients is the static gpu client, I guess
we could reasonably easily support up to two clients reasonably
easily...

BR,
-R

> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project