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: >>> Hi Rob, >>> >>> Thanks for your work. >>> >>> On 09/29/2015 10:48 PM, Rob Clark wrote: >>>> For now, since the GPU is the only upstream consumer, just stuff this >>>> into drm/msm. Eventually if we have other consumers, we'll have to >>> >>> As the video encoder/decoder driver (vidc) for apq8084 && msm8974 also >>> use the ocmem for scratch buffers, it might be better to relocate the >>> ocmem driver in drivers/soc/qcom from the beginning? >> >> I wasn't really sure how soon vidc would support 8084/8974 (I assume >> first target is 8916 which fortunately doesn't have ocmem), or if it My expectations are that the same driver will work on apq8084, as well. >> 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. > > btw, I should add that I don't mind adding it in drivers/soc/qcom (or > somewhere else?) to start with if others prefer, I just didn't want to > give the wrong impression that it is ready yet for multiple clients. I see. Then to avoid confusions you could remove all clients and keep only graphics from ocmem_client enum. > > All I know is the gpu uses it statically and is pretty much useless > without ocmem, so for lack of understanding of the other use cases I > just tried to add simply what the gpu needs.. Got it now, thanks. -- regards, Stan -- 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
