From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grant Likely Subject: Re: [PATCH 19/19] Documentation: ACPI for ARM64 Date: Wed, 20 Aug 2014 11:42:27 -0500 Message-ID: <20140820164227.E0F4BC41204@trevor.secretlab.ca> References: <1406206825-15590-1-git-send-email-hanjun.guo@linaro.org> <1406206825-15590-20-git-send-email-hanjun.guo@linaro.org> Return-path: Received: from mail-qa0-f50.google.com ([209.85.216.50]:47782 "EHLO mail-qa0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751506AbaHTQmi (ORCPT ); Wed, 20 Aug 2014 12:42:38 -0400 Received: by mail-qa0-f50.google.com with SMTP id s7so7308760qap.9 for ; Wed, 20 Aug 2014 09:42:37 -0700 (PDT) In-Reply-To: <1406206825-15590-20-git-send-email-hanjun.guo@linaro.org> Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: Catalin Marinas , "Rafael J. Wysocki" , Mark Rutland Cc: Graeme Gregory , Arnd Bergmann , Sudeep Holla , Will Deacon , Jason Cooper , Marc Zyngier , Bjorn Helgaas , Daniel Lezcano , Mark Brown , Robert Richter , Lv Zheng , Robert Moore , Lorenzo Pieralisi , Liviu Dudau , Randy Dunlap , Charles.Garcia-Tobin@arm.com, linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linaro-acpi-private@linaro.org, Hanjun Guo On Thu, 24 Jul 2014 21:00:25 +0800, Hanjun Guo wrote: > +Clocks > +------ > + > +Like clocks that are part of the power resources there is no standard way > +to represent a clock tree in ACPI 5.1 in a similar manner to how it is > +described in DT. > + > +Devices affected by this include things like UARTs, SoC driven LCD displays, > +etc. > + > +The firmware for example UEFI should initialise these clocks to fixed working > +values before the kernel is executed. If a driver requires to know rates of > +clocks set by firmware then they can be passed to kernel using _DSD. > + > +example :- > + > +Device (CLK0) { > + ... > + > + Name (_DSD, Package() { > + ToUUID("XXXXX"), > + Package() { > + Package(2) {"#clock-cells", 0}, > + Package(2) {"clock-frequency", "10000"} > + } > + }) > + > + ... > +} > + > +Device (USR1) { > + ... > + > + Name (_DSD, Package() { > + ToUUID("XXXXX"), > + Package() { > + Package(2) {"clocks", Package() {1, ^CLK0}}}, > + } > + }) > + > + ... > +} Really? This looks wrong. The above example goes right back to conceptually putting the clock tree into ACPI. I would expect the ACPI way to expose current clock rate to an individual device driver is to expose a clock rate method that internally knows how to return the currently set rate. g. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752448AbaHTQmm (ORCPT ); Wed, 20 Aug 2014 12:42:42 -0400 Received: from mail-qa0-f42.google.com ([209.85.216.42]:55651 "EHLO mail-qa0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751506AbaHTQml (ORCPT ); Wed, 20 Aug 2014 12:42:41 -0400 From: Grant Likely Subject: Re: [PATCH 19/19] Documentation: ACPI for ARM64 To: Hanjun Guo , Catalin Marinas , "Rafael J. Wysocki" , Mark Rutland Cc: Graeme Gregory , Arnd Bergmann , Sudeep Holla , Will Deacon , Jason Cooper , Marc Zyngier , Bjorn Helgaas , Daniel Lezcano , Mark Brown , Robert Richter , Lv Zheng , Robert Moore , Lorenzo Pieralisi , Liviu Dudau , Randy Dunlap , Charles.Garcia-Tobin@arm.com, linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linaro-acpi-private@linaro.org, Hanjun Guo In-Reply-To: <1406206825-15590-20-git-send-email-hanjun.guo@linaro.org> References: <1406206825-15590-1-git-send-email-hanjun.guo@linaro.org> <1406206825-15590-20-git-send-email-hanjun.guo@linaro.org> Date: Wed, 20 Aug 2014 11:42:27 -0500 Message-Id: <20140820164227.E0F4BC41204@trevor.secretlab.ca> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 24 Jul 2014 21:00:25 +0800, Hanjun Guo wrote: > +Clocks > +------ > + > +Like clocks that are part of the power resources there is no standard way > +to represent a clock tree in ACPI 5.1 in a similar manner to how it is > +described in DT. > + > +Devices affected by this include things like UARTs, SoC driven LCD displays, > +etc. > + > +The firmware for example UEFI should initialise these clocks to fixed working > +values before the kernel is executed. If a driver requires to know rates of > +clocks set by firmware then they can be passed to kernel using _DSD. > + > +example :- > + > +Device (CLK0) { > + ... > + > + Name (_DSD, Package() { > + ToUUID("XXXXX"), > + Package() { > + Package(2) {"#clock-cells", 0}, > + Package(2) {"clock-frequency", "10000"} > + } > + }) > + > + ... > +} > + > +Device (USR1) { > + ... > + > + Name (_DSD, Package() { > + ToUUID("XXXXX"), > + Package() { > + Package(2) {"clocks", Package() {1, ^CLK0}}}, > + } > + }) > + > + ... > +} Really? This looks wrong. The above example goes right back to conceptually putting the clock tree into ACPI. I would expect the ACPI way to expose current clock rate to an individual device driver is to expose a clock rate method that internally knows how to return the currently set rate. g. From mboxrd@z Thu Jan 1 00:00:00 1970 From: grant.likely@linaro.org (Grant Likely) Date: Wed, 20 Aug 2014 11:42:27 -0500 Subject: [PATCH 19/19] Documentation: ACPI for ARM64 In-Reply-To: <1406206825-15590-20-git-send-email-hanjun.guo@linaro.org> References: <1406206825-15590-1-git-send-email-hanjun.guo@linaro.org> <1406206825-15590-20-git-send-email-hanjun.guo@linaro.org> Message-ID: <20140820164227.E0F4BC41204@trevor.secretlab.ca> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, 24 Jul 2014 21:00:25 +0800, Hanjun Guo wrote: > +Clocks > +------ > + > +Like clocks that are part of the power resources there is no standard way > +to represent a clock tree in ACPI 5.1 in a similar manner to how it is > +described in DT. > + > +Devices affected by this include things like UARTs, SoC driven LCD displays, > +etc. > + > +The firmware for example UEFI should initialise these clocks to fixed working > +values before the kernel is executed. If a driver requires to know rates of > +clocks set by firmware then they can be passed to kernel using _DSD. > + > +example :- > + > +Device (CLK0) { > + ... > + > + Name (_DSD, Package() { > + ToUUID("XXXXX"), > + Package() { > + Package(2) {"#clock-cells", 0}, > + Package(2) {"clock-frequency", "10000"} > + } > + }) > + > + ... > +} > + > +Device (USR1) { > + ... > + > + Name (_DSD, Package() { > + ToUUID("XXXXX"), > + Package() { > + Package(2) {"clocks", Package() {1, ^CLK0}}}, > + } > + }) > + > + ... > +} Really? This looks wrong. The above example goes right back to conceptually putting the clock tree into ACPI. I would expect the ACPI way to expose current clock rate to an individual device driver is to expose a clock rate method that internally knows how to return the currently set rate. g.