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

Stephen Boyd sboyd at codeaurora.org
Thu Oct 1 11:00:31 PDT 2015


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.

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


More information about the dri-devel mailing list