From mboxrd@z Thu Jan 1 00:00:00 1970 From: Geert Uytterhoeven Date: Fri, 26 Sep 2014 06:25:26 +0000 Subject: Re: [PATCH/RFC v2 02/12] PM / Domains: Add DT bindings for PM QoS device latencies Message-Id: List-Id: References: <1410893339-6361-1-git-send-email-geert+renesas@glider.be> <1410893339-6361-3-git-send-email-geert+renesas@glider.be> <7heguzbd4z.fsf@deeprootsystems.com> In-Reply-To: <7heguzbd4z.fsf@deeprootsystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-arm-kernel@lists.infradead.org Hi Kevin, On Thu, Sep 25, 2014 at 11:31 PM, Kevin Hilman wrote: > Geert Uytterhoeven writes: >> PM QoS device start/stop and save/restore state latencies are more or >> less properties of the hardware. >> In legacy code, they're specified from platform code. >> On DT platforms, their values should come from DT. >> >> Signed-off-by: Geert Uytterhoeven >> --- >> Should these properties be called "linux,*-latency"? > > Hmm, the start/stop latencies are clearly properties of the hardware, > but the save/restore latencies seem to be a function of the driver. > e.g., some drivers may keep a shadow copy of their registers in memory > so the save time is minimized. > > I don't have too strong of an opinion on this, but probably the drivers > should just add their own values to the start/stop latencies to add the > linux specific overhead. Thanks. I agree with you on this, so I'll remove the save/restore latencies. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754043AbaIZGZf (ORCPT ); Fri, 26 Sep 2014 02:25:35 -0400 Received: from mail-lb0-f174.google.com ([209.85.217.174]:56086 "EHLO mail-lb0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753446AbaIZGZ2 (ORCPT ); Fri, 26 Sep 2014 02:25:28 -0400 MIME-Version: 1.0 In-Reply-To: <7heguzbd4z.fsf@deeprootsystems.com> References: <1410893339-6361-1-git-send-email-geert+renesas@glider.be> <1410893339-6361-3-git-send-email-geert+renesas@glider.be> <7heguzbd4z.fsf@deeprootsystems.com> Date: Fri, 26 Sep 2014 08:25:26 +0200 X-Google-Sender-Auth: h9-_l4L0qd7k1YrU6R70d7IjHLs Message-ID: Subject: Re: [PATCH/RFC v2 02/12] PM / Domains: Add DT bindings for PM QoS device latencies From: Geert Uytterhoeven To: Kevin Hilman Cc: Geert Uytterhoeven , "Rafael J. Wysocki" , Len Brown , Pavel Machek , Simon Horman , Magnus Damm , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Ulf Hansson , Tomasz Figa , Philipp Zabel , Grygorii Strashko , Linux PM list , "devicetree@vger.kernel.org" , Linux-sh list , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Kevin, On Thu, Sep 25, 2014 at 11:31 PM, Kevin Hilman wrote: > Geert Uytterhoeven writes: >> PM QoS device start/stop and save/restore state latencies are more or >> less properties of the hardware. >> In legacy code, they're specified from platform code. >> On DT platforms, their values should come from DT. >> >> Signed-off-by: Geert Uytterhoeven >> --- >> Should these properties be called "linux,*-latency"? > > Hmm, the start/stop latencies are clearly properties of the hardware, > but the save/restore latencies seem to be a function of the driver. > e.g., some drivers may keep a shadow copy of their registers in memory > so the save time is minimized. > > I don't have too strong of an opinion on this, but probably the drivers > should just add their own values to the start/stop latencies to add the > linux specific overhead. Thanks. I agree with you on this, so I'll remove the save/restore latencies. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From mboxrd@z Thu Jan 1 00:00:00 1970 From: Geert Uytterhoeven Subject: Re: [PATCH/RFC v2 02/12] PM / Domains: Add DT bindings for PM QoS device latencies Date: Fri, 26 Sep 2014 08:25:26 +0200 Message-ID: References: <1410893339-6361-1-git-send-email-geert+renesas@glider.be> <1410893339-6361-3-git-send-email-geert+renesas@glider.be> <7heguzbd4z.fsf@deeprootsystems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Return-path: In-Reply-To: <7heguzbd4z.fsf@deeprootsystems.com> Sender: linux-sh-owner@vger.kernel.org To: Kevin Hilman Cc: Geert Uytterhoeven , "Rafael J. Wysocki" , Len Brown , Pavel Machek , Simon Horman , Magnus Damm , Rob Herring , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , Ulf Hansson , Tomasz Figa , Philipp Zabel , Grygorii Strashko , Linux PM list , "devicetree@vger.kernel.org" , Linux-sh list , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" List-Id: devicetree@vger.kernel.org Hi Kevin, On Thu, Sep 25, 2014 at 11:31 PM, Kevin Hilman wrote: > Geert Uytterhoeven writes: >> PM QoS device start/stop and save/restore state latencies are more or >> less properties of the hardware. >> In legacy code, they're specified from platform code. >> On DT platforms, their values should come from DT. >> >> Signed-off-by: Geert Uytterhoeven >> --- >> Should these properties be called "linux,*-latency"? > > Hmm, the start/stop latencies are clearly properties of the hardware, > but the save/restore latencies seem to be a function of the driver. > e.g., some drivers may keep a shadow copy of their registers in memory > so the save time is minimized. > > I don't have too strong of an opinion on this, but probably the drivers > should just add their own values to the start/stop latencies to add the > linux specific overhead. Thanks. I agree with you on this, so I'll remove the save/restore latencies. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From mboxrd@z Thu Jan 1 00:00:00 1970 From: geert@linux-m68k.org (Geert Uytterhoeven) Date: Fri, 26 Sep 2014 08:25:26 +0200 Subject: [PATCH/RFC v2 02/12] PM / Domains: Add DT bindings for PM QoS device latencies In-Reply-To: <7heguzbd4z.fsf@deeprootsystems.com> References: <1410893339-6361-1-git-send-email-geert+renesas@glider.be> <1410893339-6361-3-git-send-email-geert+renesas@glider.be> <7heguzbd4z.fsf@deeprootsystems.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Kevin, On Thu, Sep 25, 2014 at 11:31 PM, Kevin Hilman wrote: > Geert Uytterhoeven writes: >> PM QoS device start/stop and save/restore state latencies are more or >> less properties of the hardware. >> In legacy code, they're specified from platform code. >> On DT platforms, their values should come from DT. >> >> Signed-off-by: Geert Uytterhoeven >> --- >> Should these properties be called "linux,*-latency"? > > Hmm, the start/stop latencies are clearly properties of the hardware, > but the save/restore latencies seem to be a function of the driver. > e.g., some drivers may keep a shadow copy of their registers in memory > so the save time is minimized. > > I don't have too strong of an opinion on this, but probably the drivers > should just add their own values to the start/stop latencies to add the > linux specific overhead. Thanks. I agree with you on this, so I'll remove the save/restore latencies. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds