From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752953AbbBYQ0H (ORCPT ); Wed, 25 Feb 2015 11:26:07 -0500 Received: from mail-wg0-f52.google.com ([74.125.82.52]:43967 "EHLO mail-wg0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752401AbbBYQ0F (ORCPT ); Wed, 25 Feb 2015 11:26:05 -0500 Message-ID: <54EDF79B.80805@cit-ec.uni-bielefeld.de> Date: Wed, 25 Feb 2015 17:26:03 +0100 From: Robert Abel Reply-To: rabel@cit-ec.uni-bielefeld.de User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Tony Lindgren , Roger Quadros CC: linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org, linux@arm.linux.org.uk Subject: Re: [PATCH 5/8 v2] ARM OMAP2+ GPMC: change get_gpmc_timing_reg output for DTS References: <1424808331-17592-1-git-send-email-rabel@cit-ec.uni-bielefeld.de> <1424808331-17592-2-git-send-email-rabel@cit-ec.uni-bielefeld.de> <1424808331-17592-3-git-send-email-rabel@cit-ec.uni-bielefeld.de> <1424808331-17592-4-git-send-email-rabel@cit-ec.uni-bielefeld.de> <1424808331-17592-5-git-send-email-rabel@cit-ec.uni-bielefeld.de> <54EDCD29.3010404@ti.com> <20150225152324.GN11056@atomide.com> In-Reply-To: <20150225152324.GN11056@atomide.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Tony, On 25 Feb 2015 16:23, Tony Lindgren wrote: > * Roger Quadros [150225 05:28]: >> On 24/02/15 22:05, Robert ABEL wrote: >>> DTS output was formatted to require additional work when copy-pasting into DTS. >>> Nano-second timings were removed, because they were not a confidence interval nor >>> an indication what timing values would result in the same #ticks >> If they were not is it possible to dump min,max timings that will result in >> the same ticks? > Yeah my plan was o display the nanosecond range resulting in the > same tick value. That makes it a bit easier to compare the timings > to the data sheet. So maybe show both tick and ns range? Ah, so my hunch was right. I reimplemented that correctly now. Basically, your code just went [ticks-1, ticks+1] in ns. But times are always ceiling(ns / gpmc_[f]clk), i.e. (ticks - 1, ticks] in ns. Some other patches change as well because of this change, so a v3 is in order =]. Regards, Robert