On Thu, Oct 1, 2015 at 2:00 PM, Stephen Boyd <sboyd@xxxxxxxxxxxxxx> 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@xxxxxxxxx> wrote: >> >> On Wed, Sep 30, 2015 at 3:51 AM, Stanimir Varbanov >> >> <stanimir.varbanov@xxxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
