From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Boyd Subject: Re: [PATCH 6/6] drm/msm: add OCMEM driver Date: Thu, 1 Oct 2015 11:00:31 -0700 Message-ID: <20151001180031.GF19319@codeaurora.org> References: <1443556138-21085-1-git-send-email-robdclark@gmail.com> <1443556138-21085-7-git-send-email-robdclark@gmail.com> <560B9469.7030103@linaro.org> <560CED74.4070700@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from smtp.codeaurora.org ([198.145.29.96]:34739 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752844AbbJASAd (ORCPT ); Thu, 1 Oct 2015 14:00:33 -0400 Content-Disposition: inline In-Reply-To: <560CED74.4070700@linaro.org> Sender: linux-arm-msm-owner@vger.kernel.org List-Id: linux-arm-msm@vger.kernel.org To: Stanimir Varbanov Cc: Rob Clark , "dri-devel@lists.freedesktop.org" , linux-arm-msm , Bjorn Andersson 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 wrote: > >> On Wed, Sep 30, 2015 at 3:51 AM, Stanimir Varbanov > >> 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