All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stanimir Varbanov <stanimir.varbanov@linaro.org>
To: Rob Clark <robdclark@gmail.com>,
	Stanimir Varbanov <stanimir.varbanov@linaro.org>
Cc: "dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	Bjorn Andersson <bjorn.andersson@sonymobile.com>,
	Stephen Boyd <sboyd@codeaurora.org>
Subject: Re: [PATCH 6/6] drm/msm: add OCMEM driver
Date: Thu, 01 Oct 2015 11:23:16 +0300	[thread overview]
Message-ID: <560CED74.4070700@linaro.org> (raw)
In-Reply-To: <CAF6AEGt1H5-V1JyDG3BkY6WzGyNNFTg3pKgyWPafPBQW9ygrNw@mail.gmail.com>

On 09/30/2015 02:45 PM, Rob Clark wrote:
> On Wed, Sep 30, 2015 at 7:31 AM, Rob Clark <robdclark@gmail.com> wrote:
>> On Wed, Sep 30, 2015 at 3:51 AM, Stanimir Varbanov
>> <stanimir.varbanov@linaro.org> 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

  reply	other threads:[~2015-10-01  8:23 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-29 19:48 [PATCH 0/6] Add OCMEM support (v2) Rob Clark
2015-09-29 19:48 ` [PATCH 1/6] qcom-scm: fix endianess issue in __qcom_scm_is_call_available Rob Clark
2015-09-29 21:00   ` Stephen Boyd
2015-09-29 19:48 ` [PATCH 2/6] qcom-scm: fix header compile errors Rob Clark
2015-09-29 21:02   ` Stephen Boyd
2015-09-29 19:48 ` [PATCH 3/6] qcom-scm: add missing prototype for qcom_scm_is_available() Rob Clark
2015-09-29 19:48 ` [PATCH 4/6] qcom-scm: add ocmem support Rob Clark
2015-09-29 21:38   ` Stephen Boyd
2015-09-29 21:53     ` Rob Clark
2015-09-29 22:33       ` Stephen Boyd
2015-10-01 20:13         ` Rob Clark
2015-10-01 21:52           ` Stephen Boyd
2015-09-29 19:48 ` [PATCH 5/6] drm/msm: update generated headers Rob Clark
2015-09-29 19:48 ` [PATCH 6/6] drm/msm: add OCMEM driver Rob Clark
2015-09-30  7:51   ` Stanimir Varbanov
2015-09-30 11:31     ` Rob Clark
2015-09-30 11:45       ` Rob Clark
2015-10-01  8:23         ` Stanimir Varbanov [this message]
2015-10-01 18:00           ` Stephen Boyd
2015-10-01 19:25             ` Rob Clark
2015-10-02  0:26               ` Rob Clark
2015-10-02  0:59                 ` Stephen Boyd
2015-10-02  1:37                   ` Rob Clark

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=560CED74.4070700@linaro.org \
    --to=stanimir.varbanov@linaro.org \
    --cc=bjorn.andersson@sonymobile.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=robdclark@gmail.com \
    --cc=sboyd@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.