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. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
