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 > 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... 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. 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.. BR, -R > >> I'm working on vidc driver upstream version so it will be nice to test >> ocmem driver from it, too. >> >>> split this out and make the allocation less hard coded. But I'll punt >>> on that until I better understand the non-gpu uses-cases (and whether >>> the allocation *really* needs to be as complicated as it is in the >>> downstream driver). >>> >>> Signed-off-by: Rob Clark <robdclark@xxxxxxxxx> >>> --- >>> drivers/gpu/drm/msm/Makefile | 3 +- >>> drivers/gpu/drm/msm/adreno/a3xx_gpu.c | 19 +- >>> drivers/gpu/drm/msm/adreno/a4xx_gpu.c | 19 +- >>> drivers/gpu/drm/msm/msm_drv.c | 2 + >>> drivers/gpu/drm/msm/msm_gpu.h | 3 + >>> drivers/gpu/drm/msm/ocmem/ocmem.c | 399 ++++++++++++++++++++++++++++++++++ >>> drivers/gpu/drm/msm/ocmem/ocmem.h | 46 ++++ >>> 7 files changed, 463 insertions(+), 28 deletions(-) >>> create mode 100644 drivers/gpu/drm/msm/ocmem/ocmem.c >>> create mode 100644 drivers/gpu/drm/msm/ocmem/ocmem.h >>> >> >> <snip> >> >> -- >> 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
