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@gmail.com wrote:
On Wed, Sep 30, 2015 at 3:51 AM, Stanimir Varbanov stanimir.varbanov@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.