Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp429612imu; Fri, 16 Nov 2018 04:55:08 -0800 (PST) X-Google-Smtp-Source: AJdET5dvT1EJ1TdrhhKe5vASIEKgNRxuIMSIO6Kqc9y5Ei5OmBc9wqfGoto+mjcWvoVubGyTZIZx X-Received: by 2002:a17:902:4c08:: with SMTP id a8-v6mr10669264ple.211.1542372908920; Fri, 16 Nov 2018 04:55:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542372908; cv=none; d=google.com; s=arc-20160816; b=niQjJdURjc7GKZzBsyqc4f0lOpi21Zc3OH4Y5B2R7WqDjpI0Ybh2/c5AejrKJLBUZQ aWGfWdCTwkfo43/UXzvM1LG5E6FEsxf3nyXx4GPVkHZdrndMOHkU8rzJhMv8QHVUbjrH v3Md3nRQ/CaHFxT9Wa0R8ynkFyxCm9q5Z41qzQpHJmXpaAHOxTTAko0zm13mIVC8pRtF IJBesJjPiNCW1gYwx5dGGAeQ9KBzywfuFEqr1I/lYUebaaiLrHTVN7wSqTS6fsVzaihD LcAgQlwR+ciBybzWzpTeQSHwr3s2MGmuO5pF2JYQFjSr9dVvXn6gKmrl7do4tzvy/0To XtYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:organization:from:references:cc:to:subject; bh=Kgct/q0Xa+2+nvj7fMOaVtDX23YYtKcIW6LF/VXvQOg=; b=I5G4ZOztda1/G2+nt/efwn8kp8yKZm/pRN5Bk4Gv1XvEHMWsm/bSHMdoX6jXwVbUwS hXzKslpyCH4R8wc3OPvVHW3DtgQAonTzKjaemm4Dc7TSqcSrrpSG+CkRJLlGOMvwCw0e L8rMZnrmdUWCGkys/+k2mAuSy9If1RQnFrBHIXXJv9XXhJRenoUwhtDoRyFICBg2FiNt 4vV6AznAVtnOsoG+wGquaOWbBJ6b+VEdM0IYVE5djAmb1bhfkLI6zv4xSTZbug8/TOq5 4FjNEvj82JBubMXa603PA1V3UJZcFo0DD/CtuVVAfextSs6BmN4AHt+icJ1TJTeyb224 NatA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=codethink.co.uk Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v184-v6si34186728pfv.249.2018.11.16.04.54.53; Fri, 16 Nov 2018 04:55:08 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=codethink.co.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389739AbeKPXGS (ORCPT + 99 others); Fri, 16 Nov 2018 18:06:18 -0500 Received: from imap1.codethink.co.uk ([176.9.8.82]:50426 "EHLO imap1.codethink.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389692AbeKPXGR (ORCPT ); Fri, 16 Nov 2018 18:06:17 -0500 Received: from [78.40.148.180] (helo=[0.0.0.0]) by imap1.codethink.co.uk with esmtpsa (Exim 4.84_2 #1 (Debian)) id 1gNddG-0006uA-G4; Fri, 16 Nov 2018 12:53:58 +0000 Subject: Re: [PATCH] USB: host: ehci: allow tine of highspeed nak-count To: Alan Stern , Ben Dooks Cc: gregkh@linuxfoundation.org, linux-usb@vger.kernel.org, linux-kernel@lists.codethink.co.uk, linux-kernel@vger.kernel.org References: From: Ben Dooks Organization: Codethink Limited. Message-ID: <39eb9e8b-2b5d-ea75-3232-be77c3743dbc@codethink.co.uk> Date: Fri, 16 Nov 2018 12:53:57 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 14/11/18 18:47, Alan Stern wrote: > On Wed, 14 Nov 2018, Ben Dooks wrote: > >> From: Ben Dooks >> >> At least some systems benefit with less scheduling if the NAK count >> value is set higher than the default 4. For instance a Tegra3 with >> an SMSC9512 showed less interrupt load when this was changed to 14. > > Interesting. Why do you think this is? In theory, increasing the NAK > count RL value should cause a higher memory bus load and perhaps a > slight rise in the interrupt load (transfers will complete a little > more quickly because the controller tries harder to poll the endpoints > and see if they are ready). I thought the NAK counter was decremented until the transfer is given up on. I'm going to have to go back and get some actual figures from a running system as this was originally done over a year ago with the SMSC9512 (IIRC) network driver. >> To allow the changing of this value, add a sysfs node to each of >> the controllers to allow run-time changing. >> >> Signed-off-by: Ben Dooks > > The patch looks okay to me. I'll look at getting some tracing from the SMSC driver to see what is going on. -- Ben Dooks http://www.codethink.co.uk/ Senior Engineer Codethink - Providing Genius https://www.codethink.co.uk/privacy.html