From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754683AbcGTTtR (ORCPT ); Wed, 20 Jul 2016 15:49:17 -0400 Received: from mail-pa0-f43.google.com ([209.85.220.43]:36489 "EHLO mail-pa0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751917AbcGTTtQ (ORCPT ); Wed, 20 Jul 2016 15:49:16 -0400 Date: Wed, 20 Jul 2016 12:49:12 -0700 From: Andrey Pronin To: Rob Herring Cc: Jarkko Sakkinen , Peter Huewe , Marcel Selhorst , Jason Gunthorpe , tpmdd-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org, Christophe Ricard , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala , devicetree@vger.kernel.org Subject: Re: [PATCH v2 1/2] tpm: devicetree: document properties for cr50 Message-ID: <20160720194912.GA61154@apronin> References: <1468549218-19215-1-git-send-email-apronin@chromium.org> <5274cc806888a709c639e701dad894543885b2c9.1468985673.git.apronin@chromium.org> <20160720190303.GA5620@rob-hp-laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160720190303.GA5620@rob-hp-laptop> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 20, 2016 at 02:03:03PM -0500, Rob Herring wrote: > On Tue, Jul 19, 2016 at 08:41:24PM -0700, Andrey Pronin wrote: Hi Rob, > As I mentioned, there may be common properties. It doesn't seem you > looked, so I did: > > - spi-rx-delay-us - (optional) Microsecond delay after a read transfer. > - spi-tx-delay-us - (optional) Microsecond delay after a write transfer. > > Seems to me setting one or both of these should work for you. > Yes, good catch, my fault I didn't see those. But they are not exactly what I mean and need. I don't need delay after each read or write transfer. What is needed is a guaranteed time between transfers. So, if the next transaction doesn't come withing the next X ms (or us), we don't waste time on inserting a delays after this transaction at all. Following the description and always inserting a delay must work well for short microseconds-long delays. For longer milliseconds-long delays a different strategy of checking the time when the previous transaction was and only delaying if it was not too long ago is better. Thus, I won't be able to re-use these properties anyways based on their current description in bindings/spi/spi-bus.txt. > > +- sleep-delay-ms: Time after the last SPI activity, after which the chip > > + may go to sleep. > > +- wake-start-delay-ms: Time after initiating wake up before the chip is > > + ready to accept commands over SPI. > > I also asked why these 2 can't be hard-coded in the driver? > Sorry, I just updated this patch description in v2 to indicate why they are not hard-coded, but didn't answer explicitly. As the firmware changes, a different revision of it can have a different time before it sleeps in its configuration, or the time it takes it to startup may be different. Thus, there's a way to set it here w/o changing the driver. Andrey From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrey Pronin Subject: Re: [PATCH v2 1/2] tpm: devicetree: document properties for cr50 Date: Wed, 20 Jul 2016 12:49:12 -0700 Message-ID: <20160720194912.GA61154@apronin> References: <1468549218-19215-1-git-send-email-apronin@chromium.org> <5274cc806888a709c639e701dad894543885b2c9.1468985673.git.apronin@chromium.org> <20160720190303.GA5620@rob-hp-laptop> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20160720190303.GA5620@rob-hp-laptop> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tpmdd-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Rob Herring Cc: Mark Rutland , devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Christophe Ricard , Pawel Moll , Ian Campbell , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, tpmdd-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, Kumar Gala List-Id: devicetree@vger.kernel.org On Wed, Jul 20, 2016 at 02:03:03PM -0500, Rob Herring wrote: > On Tue, Jul 19, 2016 at 08:41:24PM -0700, Andrey Pronin wrote: Hi Rob, > As I mentioned, there may be common properties. It doesn't seem you > looked, so I did: > > - spi-rx-delay-us - (optional) Microsecond delay after a read transfer. > - spi-tx-delay-us - (optional) Microsecond delay after a write transfer. > > Seems to me setting one or both of these should work for you. > Yes, good catch, my fault I didn't see those. But they are not exactly what I mean and need. I don't need delay after each read or write transfer. What is needed is a guaranteed time between transfers. So, if the next transaction doesn't come withing the next X ms (or us), we don't waste time on inserting a delays after this transaction at all. Following the description and always inserting a delay must work well for short microseconds-long delays. For longer milliseconds-long delays a different strategy of checking the time when the previous transaction was and only delaying if it was not too long ago is better. Thus, I won't be able to re-use these properties anyways based on their current description in bindings/spi/spi-bus.txt. > > +- sleep-delay-ms: Time after the last SPI activity, after which the chip > > + may go to sleep. > > +- wake-start-delay-ms: Time after initiating wake up before the chip is > > + ready to accept commands over SPI. > > I also asked why these 2 can't be hard-coded in the driver? > Sorry, I just updated this patch description in v2 to indicate why they are not hard-coded, but didn't answer explicitly. As the firmware changes, a different revision of it can have a different time before it sleeps in its configuration, or the time it takes it to startup may be different. Thus, there's a way to set it here w/o changing the driver. Andrey ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev