From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751644AbcBWKVq (ORCPT ); Tue, 23 Feb 2016 05:21:46 -0500 Received: from mout.kundenserver.de ([212.227.17.13]:58903 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751190AbcBWKVl (ORCPT ); Tue, 23 Feb 2016 05:21:41 -0500 From: Arnd Bergmann To: Anurag Kumar Vulisha Cc: "robh+dt@kernel.org" , "pawel.moll@arm.com" , "mark.rutland@arm.com" , "ijc+devicetree@hellion.org.uk" , "galak@codeaurora.org" , "tj@kernel.org" , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-ide@vger.kernel.org" , Anirudha Sarangi , Srikanth Vemula , Punnaiah Choudary Kalluri Subject: Re: [RFC PATCH] drivers: ata: Read Rx water mark value from device-tree Date: Tue, 23 Feb 2016 11:20:30 +0100 Message-ID: <8540232.vQE3WQTD95@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <3802E9A6666DF54886E2B9CBF743BA9825E01009@XAP-PVEXMBX01.xlnx.xilinx.com> References: <1455974302-7082-1-git-send-email-anuragku@xilinx.com> <18251200.Xfr10N5eWq@wuerfel> <3802E9A6666DF54886E2B9CBF743BA9825E01009@XAP-PVEXMBX01.xlnx.xilinx.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:o1HSHObAf2ynYub376KDTOkoPQzIqo7jdevwXSc+dCJhrrTTtao PulUgLfuV/ldqXNQJr/MF4d9V8gYdEmdIcETOGidwymDFg8BYHbu2pV4veAMzYKgnpH/SJB KRKaUyInHylegKBgnIjXIpcmloLpyFN43ffTH7L0/TPsEJtBvFE49x/nAhP9QhdDqGcVGIS pA2tugn12li7SOQooh/pw== X-UI-Out-Filterresults: notjunk:1;V01:K0:5FHW4UmWWU0=:cTGukW5UEXgA0KLo6vg6N8 N2XLBkqerOrf7BAaJmNKArpjZsKewkOYzdN/qbTjRXIXokr/XR8IdhLsiIXCDJf0/UBj8ZNkY F0GK6SWskbYoHaUaWKD2Afwd+IAz7CEe3F54dVOEBm1/fVFrN+dmJX/9IpDaoahygPJIuq57Q XWdgIpzSBW0q0X/bJy1eDRZ9202yFCmRAfsNEwWqX/Fh6suGZldHC4uwLZxn2z9KyylXuateu BF1+WvIQ9To7lnDsl7fIxa1WM9GbDJeMRrG6J68vJ6Xx9a20D8uH4DMVx2Z3dmOiZnnY0nhuK rpXlRzO7nrQOlY4MZ6WfwR8Syx6lVkNY9t1OkWZjMvOfXvtY8JisioqfYjeHhcA2fk+6NRTR2 2ybScQec1PpvazK0XnZGauFy7lMDqzAVxvi/ZFe20uqCVaXV8wxWwGetK8qUvMGHbum51pgbH UegBnH9zVmq4XF+q9gopSdbc7FykqMf7wcnptS3qBZkKJrsxOdzqfVJzuOtIrVrkVLuzfaIT8 IEqVAYLCDRUkhEJfKXYndFZTv5ievulTgr9sLELAmvXngLbiTlolGeq8hnDzkY5MlZQgadHyC voEmw2w84jg+Eg4J3x9JIGbvX9xmq7ukRtaRcaYb61kp2lja0Ihl12dLQP2sOcyMSYKyDHEly /o7LkctDTwPYTYa/dslE3s4kDavd3TG50MOKFUybozRQUPWs0ZLE+CBMAWMMBD1a+0O5eJP/o mfBgQG5Se9vDkkFi Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 23 February 2016 05:58:32 Anurag Kumar Vulisha wrote: > > > > I don't know what is appropriate because I have no idea what Rxwatermark is > > good for. Can you try describing why we can't just set it to the correct value > > for everyone automatically? > > > > This RX watermark level sets the minimum number of free locations within the RX FIFO .When the rx fifo level crosses the programmed watermark level ,sata controller will transmit HOLDS to the device asking it to wait. This happens when dma > reads the rx fifo data slower than the device is sending the data. Note that it can take some time for the HOLDs to get to > the other end and in the time there must be enough room in the FIFO to absorb all data that could arrive from the device. > Currently we are using 0x40 for this value, which works fine with all hardware designs we are currently having. But hoping > that this value may vary for future silicon versions, I wanted to make this as a configurable value. So for this reason I thought > of moving it either to device-tree or making it as a module_param() property. > Ok, so if this depends on the silicon version, your initial approach would be better than the module_param. I would probably make this dependent on the compatible string instead, and have a table in the device driver that uses a specific value for each variant of the device, but either way should be fine. Having a separate property is most appropriate if for each hardware revision there is exactly one ideal value, while a table in the driver makes more sense if this takes a bit of tuning and the driver might choose to optimize it differently based on other constraints, such as its own interrupt handler implementation. Arnd