From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stanimir Varbanov Subject: Re: [PATCH 6/6] drm/msm: add OCMEM driver Date: Thu, 01 Oct 2015 11:23:16 +0300 Message-ID: <560CED74.4070700@linaro.org> References: <1443556138-21085-1-git-send-email-robdclark@gmail.com> <1443556138-21085-7-git-send-email-robdclark@gmail.com> <560B9469.7030103@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Return-path: Received: from mail-wi0-f180.google.com ([209.85.212.180]:37163 "EHLO mail-wi0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756273AbbJAIXW (ORCPT ); Thu, 1 Oct 2015 04:23:22 -0400 Received: by wicfx3 with SMTP id fx3so16887627wic.0 for ; Thu, 01 Oct 2015 01:23:21 -0700 (PDT) In-Reply-To: Sender: linux-arm-msm-owner@vger.kernel.org List-Id: linux-arm-msm@vger.kernel.org To: Rob Clark , Stanimir Varbanov Cc: "dri-devel@lists.freedesktop.org" , linux-arm-msm , Bjorn Andersson , Stephen Boyd 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: >>> 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