From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rajendra Nayak Subject: Re: [Freedreno] [PATCH 2/2] arm64: dts: sdm845: Support GPU/GMU Date: Fri, 9 Mar 2018 15:49:00 +0530 Message-ID: <4fd61bd2-757b-ef30-a07f-ed74af031ff5@codeaurora.org> References: <20180302215638.6145-1-jcrouse@codeaurora.org> <20180302215638.6145-3-jcrouse@codeaurora.org> <20180305044221.GC23018@vireshk-i7> <20180305152818.GC15200@jcrouse-lnx.qualcomm.com> <20180306042656.GJ23018@vireshk-i7> <20180306153757.GD15200@jcrouse-lnx.qualcomm.com> <20180307050624.GR23018@vireshk-i7> <20180308201438.GA10589@jcrouse-lnx.qualcomm.com> <20180309034332.GO6842@vireshk-i7> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20180309034332.GO6842@vireshk-i7> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Viresh Kumar , freedreno@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-arm-msm@vger.kernel.org, vireshk@kernel.org, nm@ti.com, sboyd@codeaurora.org, linux-pm@vger.kernel.org, devicetree@vger.kernel.org, dianders@chromium.org, linux-arm-kernel@lists.infradead.org, sboyd@kernel.org List-Id: linux-arm-msm@vger.kernel.org SGV5IEpvcmRhbi9WaXJlc2gsCgpPbiAwMy8wOS8yMDE4IDA5OjEzIEFNLCBWaXJlc2ggS3VtYXIg d3JvdGU6Cj4gT24gMDgtMDMtMTgsIDEzOjE0LCBKb3JkYW4gQ3JvdXNlIHdyb3RlOgo+PiBJdCBz ZWVtcyB0byBtZSB0aGF0IHBlcmZvcm1hbmNlX3N0YXRlIGhhcyBhIGRpcmVjdCByZWxhdGlvbnNo aXAgd2l0aCBnZW5wZAo+PiB3aGljaCBpcyBnb29kIGZvciBDUFUgdm90ZXMgYnV0IGluIHRoaXMg Y2FzZSwgd2UncmUganVzdCBwYXNzaW5nIGFsb25nIHJhdyBkYXRhCj4+IHRvIGFuIGluZGVwZW5k ZW50IG1pY3JvY29udHJvbGxlci4gVGhlICdxY29tLGFyYy1sZXZlbCcgaXMgdXNlZCB0byBjb25z dHJ1Y3QKPj4gdGhlIGFjdHVhbCB2YWx1ZXMgdGhhdCB0aGUgR01VIHdpbGwgcHJvZ3JhbSBpbnRv IHRoZSBSUE1oLiBTaW5jZSB0aGVzZSBhcmUKPiAKPiBUaGUgImdlbnBkIiBoZXJlIGlzIGNyZWF0 ZWQgc3BlY2lhbGx5IGZvciB0aGlzIFJQTS4gVGhlIHBlcmZvcm1hbmNlLXN0YXRlIHRoaW5nCj4g aXMgZGVzaWduZWQgdG8gc29sdmUgdGhpcyB2ZXJ5IHNwZWNpZmljIHByb2JsZW0gb2YgcXVhbGNv bW0gU29DcyBhbmQgdGhlcmUgaXMgbm8KPiB3YXkgd2UgYXJlIGdvaW5nIHRvIGFkZCBhbm90aGVy IHByb3BlcnR5IGZvciB0aGlzIG5vdy4KPiAKPj4gaW5mb3JtYXRpb25hbCAoZnJvbSB0aGUgQ1BV IHBlcnNwZWN0aXZlKSByYXRoZXIgdGhhbiBmdW5jdGlvbmFsIEkgZmVlbCBsaWtlCj4+IHRoYXQg dXNpbmcgcGVyZm9ybWFuY2Vfc3RhdGUgZm9yIHRoaXMgd291bGQgYmUgYXMgaGFja3kgYXMgdXNp bmcgb3BwLW1pY3Jvdm9sdAo+PiBvciBzb21ldGhpbmcgZWxzZS4KPiAKPiBUaGVyZSBpcyBzb21l IFdJUCBzdHVmZiBoZXJlIFJhamVuZHJhIGlzIHRlc3RpbmcgY3VycmVudGx5LgoKV2hhdCBJIGFt IGRvaW5nIGlzIGEgcG93ZXJkb21haW4gZHJpdmVyIHRvIGNvbW11bmljYXRlIG1hZ2ljIHZhbHVl cyBmcm9tCkNQVSB0byBycG1oLCBsb29rcyBsaWtlIHdlIG5lZWQgYW5vdGhlciBvbmUgdG8gY29t bXVuaWNhdGUgZnJvbSBDUFUgdG8KR01VIG5vdyA6KQoKQSBmZXcgdGhpbmdzLAoqIHNvbWVvbmUg d2lsbCBuZWVkIHRvIG1hcCB0aGVzZSBsYXJnZXIgbWFnaWMgdmFsdWVzIGludG8gc29tZXRoaW5n IHRoYXQKcnBtaCB3b3VsZCB1bmRlcnN0YW5kIChiZXR3ZWVuIDAgdG8gMTUgb24gdGhlIHNkbTg0 NSksIHRoYXRzIGRvbmUgYnkKcmVhZGluZyB0aGUgY29tbWFuZCBkYiBsZXZlbCBtYXBzLiBJcyB0 aGlzIGRvbmUgYnkgR01VPwoKKiBhcmUgdGhlc2UgY29tbXVuaWNhdGVkIGp1c3Qgb25jZSBmb3Ig ZXZlcnkgT1BQIGF0IGluaXQvYm9vdCwgb3IgZm9yCmV2ZXJ5IE9QUCBzd2l0Y2g/CgoqIHdoYXRz IHRoZSBjb21tdW5pY2F0aW9uIG1lY2hhbmlzbSB3ZSB1c2UgYmV0d2VlbiBDUFUgYW5kIEdNVT8g CgpyZWdhcmRzClJhamVuZHJhCgo+IAo+IHNzaDovL2dpdEBnaXQubGluYXJvLm9yZy9wZW9wbGUv dmlyZXNoLmt1bWFyL215bGludXguZ2l0IG9wcC9nZW5wZC9xY29tCj4gCj4gUGxlYXNlIGhhdmUg YSB0YWxrIHdpdGggUmFqZW5kcmEgd2hvIGNhbiBoZWxwIHlvdSB1bmRlcnN0YW5kIG9uIGhvdyB0 aGlzIGNhbiBiZQo+IHVzZWQgZm9yIEdQVXMuCj4gCgotLSAKUXVhbGNvbW0gSW5ub3ZhdGlvbiBD ZW50ZXIsIEluYy4gaXMgYSBtZW1iZXIgb2YgQ29kZSBBdXJvcmEgRm9ydW0sCmhvc3RlZCBieSBU aGUgTGludXggRm91bmRhdGlvbgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwpkcmktZGV2ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZlbEBsaXN0cy5mcmVlZGVz a3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9k cmktZGV2ZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 From: rnayak@codeaurora.org (Rajendra Nayak) Date: Fri, 9 Mar 2018 15:49:00 +0530 Subject: [Freedreno] [PATCH 2/2] arm64: dts: sdm845: Support GPU/GMU In-Reply-To: <20180309034332.GO6842@vireshk-i7> References: <20180302215638.6145-1-jcrouse@codeaurora.org> <20180302215638.6145-3-jcrouse@codeaurora.org> <20180305044221.GC23018@vireshk-i7> <20180305152818.GC15200@jcrouse-lnx.qualcomm.com> <20180306042656.GJ23018@vireshk-i7> <20180306153757.GD15200@jcrouse-lnx.qualcomm.com> <20180307050624.GR23018@vireshk-i7> <20180308201438.GA10589@jcrouse-lnx.qualcomm.com> <20180309034332.GO6842@vireshk-i7> Message-ID: <4fd61bd2-757b-ef30-a07f-ed74af031ff5@codeaurora.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hey Jordan/Viresh, On 03/09/2018 09:13 AM, Viresh Kumar wrote: > On 08-03-18, 13:14, Jordan Crouse wrote: >> It seems to me that performance_state has a direct relationship with genpd >> which is good for CPU votes but in this case, we're just passing along raw data >> to an independent microcontroller. The 'qcom,arc-level' is used to construct >> the actual values that the GMU will program into the RPMh. Since these are > > The "genpd" here is created specially for this RPM. The performance-state thing > is designed to solve this very specific problem of qualcomm SoCs and there is no > way we are going to add another property for this now. > >> informational (from the CPU perspective) rather than functional I feel like >> that using performance_state for this would be as hacky as using opp-microvolt >> or something else. > > There is some WIP stuff here Rajendra is testing currently. What I am doing is a powerdomain driver to communicate magic values from CPU to rpmh, looks like we need another one to communicate from CPU to GMU now :) A few things, * someone will need to map these larger magic values into something that rpmh would understand (between 0 to 15 on the sdm845), thats done by reading the command db level maps. Is this done by GMU? * are these communicated just once for every OPP at init/boot, or for every OPP switch? * whats the communication mechanism we use between CPU and GMU? regards Rajendra > > ssh://git at git.linaro.org/people/viresh.kumar/mylinux.git opp/genpd/qcom > > Please have a talk with Rajendra who can help you understand on how this can be > used for GPUs. > -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation