From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Subject: Re: [RFC PATCH 1/4] memory: tegra124-emc: Add EMC driver Date: Wed, 18 Jun 2014 16:33:39 -0600 Message-ID: <53A213C3.2020207@wwwdotorg.org> References: <1402925713-25426-1-git-send-email-tomeu.vizoso@collabora.com> <1402925713-25426-2-git-send-email-tomeu.vizoso@collabora.com> <539F4D44.3070309@wwwdotorg.org> <53A03186.3040703@collabora.com> <53A069B6.6070902@wwwdotorg.org> <53A1CB23.5090307@collabora.com> <20140618220008.GC26514@mithrandir> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: =?UTF-8?B?U3TDqXBoYW5lIE1hcmNoZXNpbg==?= , Thierry Reding Cc: devicetree@vger.kernel.org, Mike Turquette , Tomeu Vizoso , linux-pm@vger.kernel.org, "Rafael J. Wysocki" , Linux Kernel list , "dri-devel@lists.freedesktop.org" , Kyungmin Park , myungjoo.ham@samsung.com, "linux-tegra@vger.kernel.org" , linux-arm-kernel@lists.infradead.org List-Id: linux-pm@vger.kernel.org T24gMDYvMTgvMjAxNCAwNDoxOSBQTSwgU3TDqXBoYW5lIE1hcmNoZXNpbiB3cm90ZToKPiBPbiBX ZWQsIEp1biAxOCwgMjAxNCBhdCAzOjAwIFBNLCBUaGllcnJ5IFJlZGluZwo+IDx0aGllcnJ5LnJl ZGluZ0BnbWFpbC5jb20+IHdyb3RlOgo+PiBPbiBXZWQsIEp1biAxOCwgMjAxNCBhdCAwNzoyMzo0 N1BNICswMjAwLCBUb21ldSBWaXpvc28gd3JvdGU6Cj4+PiBPbiAwNi8xNy8yMDE0IDA2OjE1IFBN LCBTdGVwaGVuIFdhcnJlbiB3cm90ZToKPj4+PiBPbiAwNi8xNy8yMDE0IDA2OjE2IEFNLCBUb21l dSBWaXpvc28gd3JvdGU6Cj4+Pj4+IE9uIDA2LzE2LzIwMTQgMTA6MDIgUE0sIFN0ZXBoZW4gV2Fy cmVuIHdyb3RlOgo+Pj4+Pj4gT24gMDYvMTYvMjAxNCAwNzozNSBBTSwgVG9tZXUgVml6b3NvIHdy b3RlOgo+Pj4+Pj4+ICsjaWZkZWYgQ09ORklHX1RFR1JBMTI0X0VNQwo+Pj4+Pj4+ICtpbnQgdGVn cmExMjRfZW1jX3Jlc2VydmVfYmFuZHdpZHRoKHVuc2lnbmVkIGludCBjb25zdW1lciwgdW5zaWdu ZWQKPj4+Pj4+PiBsb25nIHJhdGUpOwo+Pj4+Pj4+ICt2b2lkIHRlZ3JhMTI0X2VtY19zZXRfZmxv b3IodW5zaWduZWQgbG9uZyBmcmVxKTsKPj4+Pj4+PiArdm9pZCB0ZWdyYTEyNF9lbWNfc2V0X2Nl aWxpbmcodW5zaWduZWQgbG9uZyBmcmVxKTsKPj4+Pj4+PiArI2Vsc2UKPj4+Pj4+PiAraW50IHRl Z3JhMTI0X2VtY19yZXNlcnZlX2JhbmR3aWR0aCh1bnNpZ25lZCBpbnQgY29uc3VtZXIsIHVuc2ln bmVkCj4+Pj4+Pj4gbG9uZyByYXRlKQo+Pj4+Pj4+ICt7IHJldHVybiAtRU5PREVWOyB9Cj4+Pj4+ Pj4gK3ZvaWQgdGVncmExMjRfZW1jX3NldF9mbG9vcih1bnNpZ25lZCBsb25nIGZyZXEpCj4+Pj4+ Pj4gK3sgcmV0dXJuOyB9Cj4+Pj4+Pj4gK3ZvaWQgdGVncmExMjRfZW1jX3NldF9jZWlsaW5nKHVu c2lnbmVkIGxvbmcgZnJlcSkKPj4+Pj4+PiAreyByZXR1cm47IH0KPj4+Pj4+PiArI2VuZGlmCj4+ Pj4+Pgo+Pj4+Pj4gSSdsbCByZXBlYXQgd2hhdCBJIHNhaWQgb2ZmLWxpc3Qgc28gdGhhdCB3ZSBj YW4gaGF2ZSB0aGUgd2hvbGUKPj4+Pj4+IGNvbnZlcnNhdGlvbiBvbiB0aGUgbGlzdDoKPj4+Pj4+ Cj4+Pj4+PiBUaGF0IGxvb2tzIGxpa2UgYSBjdXN0b20gVGVncmEtc3BlY2lmaWMgQVBJLiBJIHRo aW5rIGl0J2QgYmUgbXVjaCBiZXR0ZXIKPj4+Pj4+IHRvIGludGVncmF0ZSB0aGlzIGludG8gdGhl IGNvbW1vbiBjbG9jayBmcmFtZXdvcmsgYXMgYSBzdGFuZGFyZCBjbG9jawo+Pj4+Pj4gY29uc3Ry YWludHMgQVBJLiBUaGVyZSBhcmUgb3RoZXIgdXNlLWNhc2VzIGZvciBjbG9jayBjb25zdHJhaW50 cyBiZXNpZGVzCj4+Pj4+PiBFTUMgc2NhbGluZyAoZS5nLiBzb21lIGluIGF1ZGlvIG9uIFRlZ3Jh LCBhbmQgSSdtIHN1cmUgbWFueSBvbiBvdGhlcgo+Pj4+Pj4gU29DcyB0b28pLgo+Pj4+Pgo+Pj4+ PiBZZXMsIEkgd3JvdGUgYSBiaXQgaW4gdGhlIGNvdmVyIGxldHRlciBhYm91dCBvdXIgcmVxdWly ZW1lbnRzIGFuZCBob3cKPj4+Pj4gdGhleSBtYXAgdG8gdGhlIENDRi4gQ291bGQgeW91IHBsZWFz ZSBjb21tZW50IG9uIHRoYXQ/Cj4+Pj4KPj4+PiBNeSBjb21tZW50cyByZW1haW4gdGhlIHNhbWUu IEkgYmVsaWV2ZSB0aGlzIGlzIHNvbWV0aGluZyB0aGF0IGJlbG9uZ3MgaW4KPj4+PiB0aGUgY2xv Y2sgZHJpdmVyLCBvciBhdCB0aGUgbGVhc3QsIHNvbWUgQVBJIHRoYXQgdGFrZXMgYSBzdHJ1Y3Qg Y2xvY2sgYXMKPj4+PiBpdHMgcGFyYW1ldGVyLCBzbyB0aGF0IGRyaXZlcnMgY2FuIHVzZSB0aGUg ZXhpc3RpbmcgRFQgY2xvY2sgbG9va3VwCj4+Pj4gbWVjaGFuaXNtLgo+Pj4KPj4+IE9rLCBsZXQg bWUgcHV0IHRoaXMgc3RyYXdtYW4gaGVyZSB0byBzZWUgaWYgSSBoYXZlIGdvdHRlbiBjbG9zZSB0 byB3aGF0IHlvdQo+Pj4gaGF2ZSBpbiBtaW5kOgo+Pj4KPj4+ICogYWRkIHBlci1jbGllbnQgYWNj b3VudGluZyAoUmFiaW4ncyBwYXRjaGVzIHJlZmVyZW5jZWQgYmVmb3JlKQo+Pj4KPj4+ICogYWRk IGNsa19zZXRfZmxvb3IsIHRvIGJlIHVzZWQgYnkgY3B1ZnJlcSwgbG9hZCBzdGF0cywgZXRjLgo+ Pj4KPj4+ICogYWRkIGNsa19zZXRfY2VpbGluZywgdG8gYmUgdXNlZCBieSBiYXR0ZXJ5IGRyaXZl cnMsIHRoZXJtYWwsIGV0Yy4KPj4+Cj4+PiAqIGFuIEVNQyBkcml2ZXIgd291bGQgY29sbGVjdCBi YW5kd2lkdGggYW5kIGxhdGVuY3kgcmVxdWVzdHMgZnJvbSBjb25zdW1lcnMKPj4+IGFuZCBjYWxs IGNsa19zZXRfZmxvb3Igb24gdGhlIEVNQyBjbG9jay4KPj4+Cj4+PiAqIHRoZSBFTUMgZHJpdmVy IHdvdWxkIGFsc28gcmVnaXN0ZXIgZm9yIHJhdGUgY2hhbmdlIG5vdGlmaWNhdGlvbnMgaW4gdGhl Cj4+PiBFTUMgY2xvY2sgYW5kIHdvdWxkIHVwZGF0ZSB0aGUgbGF0ZW5jeSBhbGxvd2FuY2UgcmVn aXN0ZXJzIGF0IHRoYXQgcG9pbnQuCj4+Cj4+IExhdGVuY3kgYWxsb3dhbmNlIHJlZ2lzdGVycyBh cmUgcGFydCBvZiB0aGUgTUMgcmF0aGVyIHRoYW4gdGhlIEVNQy4gU28gSQo+PiB0aGluayB3ZSBo YXZlIHR3byBvcHRpb25zOiBhKSBoYXZlIGEgdW5pZmllZCBkcml2ZXIgZm9yIE1DIGFuZCBFTUMg b3IgYikKPj4gcHJvdmlkZSB0d28gcGFydHMgb2YgdGhlIEFQSSBpbiB0d28gZHJpdmVycy4KPj4K Pj4gT3IgcGVyaGFwcyBjKSwgY3JlYXRlIGEgZ2VuZXJpYyBmcmFtZXdvcmsgdGhhdCBib3RoIE1D IGFuZCBFTUMgY2FuCj4+IHJlZ2lzdGVyIHdpdGggKGJhbmR3aWR0aCBmb3IgRU1DLCBsYXRlbmN5 IGZvciBNQykuCj4gCj4gSXMgdGhlcmUgYW55IG1vdGl2YXRpb24gZm9yIGtlZXBpbmcgTUMgYW5k IEVNQyBzZXBhcmF0ZT8gSW4gbXkgbWluZCwKPiB0aGUgc29sdXRpb24gd2FzIGFsd2F5cyB0byBo YW5kbGUgdGhvc2UgdG9nZXRoZXIuCgpXZWxsLCB0aGV5IGFyZSBkb2N1bWVudGVkIGFzIGJlaW5n IHNlcGFyYXRlIEhXIG1vZHVsZXMgaW4gdGhlIFRSTS4KCkkga25vdyB0aGVyZSdzIGFuIGludGVy bG9jayBpbiBIVyBzbyB0aGF0IHdoZW4gdGhlIEVNQyBjbG9jayBpcyBjaGFuZ2VkLAp0aGUgRU1D IHJlZ2lzdGVycyBjYW4gZmxpcCBhdG9taWNhbGx5IHRvIGEgbmV3IGNvbmZpZ3VyYXRpb24uCgpJ J20gbm90IGF3YXJlIG9mIGFueSBzaW1pbGFyIEhXIGludGVybG9jayBiZXR3ZWVuIE1DIGFuZCBF TUMgcmVnaXN0ZXJzLgpUaGF0IHdvdWxkIGltcGx5IHRoYXQgdmVyeSB0aWdodCBjby1vcmRpbmF0 aW9uIHNob3VsZG4ndCBiZSByZXF1aXJlZC4KCkRvIHRoZSBNQyBsYXRlbmN5IGFsbG93YW5jZSBy ZWdpc3RlcnMgL3JlYWxseS8gbmVlZCB0byBiZSAqdmVyeSB0aWdodGx5KgptYW5hZ2VkIHdoZW5l dmVyIHRoZSBFTUMgY2xvY2sgaXMgY2hhbmdlZCwgb3IgaXMgaXQganVzdCBhIG1hdHRlciBvZiBp dApiZWluZyBhIGdvb2QgaWRlYSB0byB1cGRhdGUgRU1DIGNsb2NrIGFuZCBNQyBsYXRlbmN5IGFs bG93YW5jZSByZWdpc3RlcnMKYXQgcm91Z2hseSB0aGUgc2FtZSB0aW1lPyBFdmVuIGlmIHRoZXJl J3Mgc29tZSBjby1vcmRpbmF0aW9uIHJlcXVpcmVkLAptYXliZSBpdCBjYW4gYmUgaGFuZGxlZCBy YXRoZXIgbGlrZSBjcHVmcmVxIG5vdGlmaWNhdGlvbnM7IHVzZSBjbG9jawpwcmUtcmF0ZSBjaGFu Z2Ugbm90aWZpY2F0aW9ucyB0byBzZXQgTUMgdXAgaW4gYSB3YXkgdGhhdCdsbCB3b3JrIGF0IGJv dGgKb2xkL25ldyBFTUMgY2xvY2tzLCBhbmQgdGhlbiBjbG9jayBwb3N0LXJhdGUgbm90aWZpY2F0 aW9ucyB0byB0aGUgZmluYWwKTUMgY29uZmlndXJhdGlvbj8KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVsIG1haWxpbmcgbGlzdApkcmktZGV2 ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFp bG1hbi9saXN0aW5mby9kcmktZGV2ZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 From: swarren@wwwdotorg.org (Stephen Warren) Date: Wed, 18 Jun 2014 16:33:39 -0600 Subject: [RFC PATCH 1/4] memory: tegra124-emc: Add EMC driver In-Reply-To: References: <1402925713-25426-1-git-send-email-tomeu.vizoso@collabora.com> <1402925713-25426-2-git-send-email-tomeu.vizoso@collabora.com> <539F4D44.3070309@wwwdotorg.org> <53A03186.3040703@collabora.com> <53A069B6.6070902@wwwdotorg.org> <53A1CB23.5090307@collabora.com> <20140618220008.GC26514@mithrandir> Message-ID: <53A213C3.2020207@wwwdotorg.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 06/18/2014 04:19 PM, St?phane Marchesin wrote: > On Wed, Jun 18, 2014 at 3:00 PM, Thierry Reding > wrote: >> On Wed, Jun 18, 2014 at 07:23:47PM +0200, Tomeu Vizoso wrote: >>> On 06/17/2014 06:15 PM, Stephen Warren wrote: >>>> On 06/17/2014 06:16 AM, Tomeu Vizoso wrote: >>>>> On 06/16/2014 10:02 PM, Stephen Warren wrote: >>>>>> On 06/16/2014 07:35 AM, Tomeu Vizoso wrote: >>>>>>> +#ifdef CONFIG_TEGRA124_EMC >>>>>>> +int tegra124_emc_reserve_bandwidth(unsigned int consumer, unsigned >>>>>>> long rate); >>>>>>> +void tegra124_emc_set_floor(unsigned long freq); >>>>>>> +void tegra124_emc_set_ceiling(unsigned long freq); >>>>>>> +#else >>>>>>> +int tegra124_emc_reserve_bandwidth(unsigned int consumer, unsigned >>>>>>> long rate) >>>>>>> +{ return -ENODEV; } >>>>>>> +void tegra124_emc_set_floor(unsigned long freq) >>>>>>> +{ return; } >>>>>>> +void tegra124_emc_set_ceiling(unsigned long freq) >>>>>>> +{ return; } >>>>>>> +#endif >>>>>> >>>>>> I'll repeat what I said off-list so that we can have the whole >>>>>> conversation on the list: >>>>>> >>>>>> That looks like a custom Tegra-specific API. I think it'd be much better >>>>>> to integrate this into the common clock framework as a standard clock >>>>>> constraints API. There are other use-cases for clock constraints besides >>>>>> EMC scaling (e.g. some in audio on Tegra, and I'm sure many on other >>>>>> SoCs too). >>>>> >>>>> Yes, I wrote a bit in the cover letter about our requirements and how >>>>> they map to the CCF. Could you please comment on that? >>>> >>>> My comments remain the same. I believe this is something that belongs in >>>> the clock driver, or at the least, some API that takes a struct clock as >>>> its parameter, so that drivers can use the existing DT clock lookup >>>> mechanism. >>> >>> Ok, let me put this strawman here to see if I have gotten close to what you >>> have in mind: >>> >>> * add per-client accounting (Rabin's patches referenced before) >>> >>> * add clk_set_floor, to be used by cpufreq, load stats, etc. >>> >>> * add clk_set_ceiling, to be used by battery drivers, thermal, etc. >>> >>> * an EMC driver would collect bandwidth and latency requests from consumers >>> and call clk_set_floor on the EMC clock. >>> >>> * the EMC driver would also register for rate change notifications in the >>> EMC clock and would update the latency allowance registers at that point. >> >> Latency allowance registers are part of the MC rather than the EMC. So I >> think we have two options: a) have a unified driver for MC and EMC or b) >> provide two parts of the API in two drivers. >> >> Or perhaps c), create a generic framework that both MC and EMC can >> register with (bandwidth for EMC, latency for MC). > > Is there any motivation for keeping MC and EMC separate? In my mind, > the solution was always to handle those together. Well, they are documented as being separate HW modules in the TRM. I know there's an interlock in HW so that when the EMC clock is changed, the EMC registers can flip atomically to a new configuration. I'm not aware of any similar HW interlock between MC and EMC registers. That would imply that very tight co-ordination shouldn't be required. Do the MC latency allowance registers /really/ need to be *very tightly* managed whenever the EMC clock is changed, or is it just a matter of it being a good idea to update EMC clock and MC latency allowance registers at roughly the same time? Even if there's some co-ordination required, maybe it can be handled rather like cpufreq notifications; use clock pre-rate change notifications to set MC up in a way that'll work at both old/new EMC clocks, and then clock post-rate notifications to the final MC configuration? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755338AbaFRWdq (ORCPT ); Wed, 18 Jun 2014 18:33:46 -0400 Received: from avon.wwwdotorg.org ([70.85.31.133]:55700 "EHLO avon.wwwdotorg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751106AbaFRWdo (ORCPT ); Wed, 18 Jun 2014 18:33:44 -0400 Message-ID: <53A213C3.2020207@wwwdotorg.org> Date: Wed, 18 Jun 2014 16:33:39 -0600 From: Stephen Warren User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: =?UTF-8?B?U3TDqXBoYW5lIE1hcmNoZXNpbg==?= , Thierry Reding CC: Tomeu Vizoso , devicetree@vger.kernel.org, Mike Turquette , linux-pm@vger.kernel.org, "Rafael J. Wysocki" , Linux Kernel list , "dri-devel@lists.freedesktop.org" , Kyungmin Park , myungjoo.ham@samsung.com, "linux-tegra@vger.kernel.org" , linux-arm-kernel@lists.infradead.org Subject: Re: [RFC PATCH 1/4] memory: tegra124-emc: Add EMC driver References: <1402925713-25426-1-git-send-email-tomeu.vizoso@collabora.com> <1402925713-25426-2-git-send-email-tomeu.vizoso@collabora.com> <539F4D44.3070309@wwwdotorg.org> <53A03186.3040703@collabora.com> <53A069B6.6070902@wwwdotorg.org> <53A1CB23.5090307@collabora.com> <20140618220008.GC26514@mithrandir> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/18/2014 04:19 PM, Stéphane Marchesin wrote: > On Wed, Jun 18, 2014 at 3:00 PM, Thierry Reding > wrote: >> On Wed, Jun 18, 2014 at 07:23:47PM +0200, Tomeu Vizoso wrote: >>> On 06/17/2014 06:15 PM, Stephen Warren wrote: >>>> On 06/17/2014 06:16 AM, Tomeu Vizoso wrote: >>>>> On 06/16/2014 10:02 PM, Stephen Warren wrote: >>>>>> On 06/16/2014 07:35 AM, Tomeu Vizoso wrote: >>>>>>> +#ifdef CONFIG_TEGRA124_EMC >>>>>>> +int tegra124_emc_reserve_bandwidth(unsigned int consumer, unsigned >>>>>>> long rate); >>>>>>> +void tegra124_emc_set_floor(unsigned long freq); >>>>>>> +void tegra124_emc_set_ceiling(unsigned long freq); >>>>>>> +#else >>>>>>> +int tegra124_emc_reserve_bandwidth(unsigned int consumer, unsigned >>>>>>> long rate) >>>>>>> +{ return -ENODEV; } >>>>>>> +void tegra124_emc_set_floor(unsigned long freq) >>>>>>> +{ return; } >>>>>>> +void tegra124_emc_set_ceiling(unsigned long freq) >>>>>>> +{ return; } >>>>>>> +#endif >>>>>> >>>>>> I'll repeat what I said off-list so that we can have the whole >>>>>> conversation on the list: >>>>>> >>>>>> That looks like a custom Tegra-specific API. I think it'd be much better >>>>>> to integrate this into the common clock framework as a standard clock >>>>>> constraints API. There are other use-cases for clock constraints besides >>>>>> EMC scaling (e.g. some in audio on Tegra, and I'm sure many on other >>>>>> SoCs too). >>>>> >>>>> Yes, I wrote a bit in the cover letter about our requirements and how >>>>> they map to the CCF. Could you please comment on that? >>>> >>>> My comments remain the same. I believe this is something that belongs in >>>> the clock driver, or at the least, some API that takes a struct clock as >>>> its parameter, so that drivers can use the existing DT clock lookup >>>> mechanism. >>> >>> Ok, let me put this strawman here to see if I have gotten close to what you >>> have in mind: >>> >>> * add per-client accounting (Rabin's patches referenced before) >>> >>> * add clk_set_floor, to be used by cpufreq, load stats, etc. >>> >>> * add clk_set_ceiling, to be used by battery drivers, thermal, etc. >>> >>> * an EMC driver would collect bandwidth and latency requests from consumers >>> and call clk_set_floor on the EMC clock. >>> >>> * the EMC driver would also register for rate change notifications in the >>> EMC clock and would update the latency allowance registers at that point. >> >> Latency allowance registers are part of the MC rather than the EMC. So I >> think we have two options: a) have a unified driver for MC and EMC or b) >> provide two parts of the API in two drivers. >> >> Or perhaps c), create a generic framework that both MC and EMC can >> register with (bandwidth for EMC, latency for MC). > > Is there any motivation for keeping MC and EMC separate? In my mind, > the solution was always to handle those together. Well, they are documented as being separate HW modules in the TRM. I know there's an interlock in HW so that when the EMC clock is changed, the EMC registers can flip atomically to a new configuration. I'm not aware of any similar HW interlock between MC and EMC registers. That would imply that very tight co-ordination shouldn't be required. Do the MC latency allowance registers /really/ need to be *very tightly* managed whenever the EMC clock is changed, or is it just a matter of it being a good idea to update EMC clock and MC latency allowance registers at roughly the same time? Even if there's some co-ordination required, maybe it can be handled rather like cpufreq notifications; use clock pre-rate change notifications to set MC up in a way that'll work at both old/new EMC clocks, and then clock post-rate notifications to the final MC configuration?