From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752407AbdAXIWH (ORCPT <rfc822;w@1wt.eu>);
        Tue, 24 Jan 2017 03:22:07 -0500
Received: from mail-wm0-f67.google.com ([74.125.82.67]:36066 "EHLO
        mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751951AbdAXIUs (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 24 Jan 2017 03:20:48 -0500
Date: Tue, 24 Jan 2017 09:20:39 +0100
From: Ingo Molnar <mingo@kernel.org>
To: Lu Baolu <baolu.lu@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Mathias Nyman <mathias.nyman@linux.intel.com>,
        Ingo Molnar <mingo@redhat.com>, tglx@linutronix.de,
        peterz@infradead.org, linux-usb@vger.kernel.org, x86@kernel.org,
        linux-kernel@vger.kernel.org, Jiri Slaby <jslaby@suse.cz>
Subject: Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability
Message-ID: <20170124082039.GB8667@gmail.com>
References: <1479189731-2728-1-git-send-email-baolu.lu@linux.intel.com>
 <1479189731-2728-2-git-send-email-baolu.lu@linux.intel.com>
 <20170119093743.GC22865@gmail.com>
 <58817A25.6080305@linux.intel.com>
 <20170122090423.GA15061@gmail.com>
 <5886DBB7.4070501@linux.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5886DBB7.4070501@linux.intel.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


* Lu Baolu <baolu.lu@linux.intel.com> wrote:

> Hi Ingo,
> 
> On 01/22/2017 05:04 PM, Ingo Molnar wrote:
> > * Lu Baolu <baolu.lu@linux.intel.com> wrote:
> >
> >>>> +static void xdbc_runtime_delay(unsigned long count)
> >>>> +{
> >>>> +	udelay(count);
> >>>> +}
> >>>> +static void (*xdbc_delay)(unsigned long) = xdbc_early_delay;
> >>> Is this udelay() complication really necessary? udelay() should work fine even in 
> >>> early code. It might not be precisely calibrated, but should be good enough.
> >> I tried udelay() in the early code. It's not precise enough for the
> >> hardware handshaking.
> > Possibly because on x86 early udelay() did not work at all - i.e. there's no delay 
> > whatsoever.
> 
> Yes.
> 
> >
> > Could you try it on top of this commit in tip:timers/core:
> >
> >   4c45c5167c95 x86/timer: Make delay() work during early bootup
> >
> > ?
> 
> I tried tip:timers/core. It's not precise enough for my context either.
> 
> __const_udelay().
> 
> 157 inline void __const_udelay(unsigned long xloops)
> 158 {
> 159         unsigned long lpj = this_cpu_read(cpu_info.loops_per_jiffy) ? : loops_per_jiffy;
> 160         int d0;
> 161
> 162         xloops *= 4;
> 163         asm("mull %%edx"
> 164                 :"=d" (xloops), "=&a" (d0)
> 165                 :"1" (xloops), "0" (lpj * (HZ / 4)));
> 166
> 167         __delay(++xloops);
> 168 }
> 
> 
> In my early  code, loops_per_jiffy is not initialized yet. Hence "lpj" for the asm line
> is 4096 (default value).
> 
> The  cpu_info.loops_per_jiffy actually reads 8832000 after initialization. They are
> about 2000 times different.
> 
> I did a hacky test in kernel to check the difference between these two different
> "lpj" values. (The hacky patch is attached.) Below is the output for 100ms delay.
> 
> [    2.494751] udelay_test uninitialized ---->start
> [    2.494820] udelay_test uninitialized ---->end
> [    2.494828] udelay_test initialized ---->start
> [    2.595234] udelay_test initialized ---->end
> 
> For 100ms delay, udelay() with uninitialized loops_per_jiffy only gives a delay of
> only 69us.

Ok, then could we add some simple calibration to make udelay work much better - or 
perhaps move the udelay calibration up earlier?

Hiding essentially an early udelay() implementation in an early-printk driver is 
ugly and counterproductive.

Thanks,

	Ingo