From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932070AbcCBJ2M (ORCPT ); Wed, 2 Mar 2016 04:28:12 -0500 Received: from mail-sn1nam02on0053.outbound.protection.outlook.com ([104.47.36.53]:27088 "EHLO NAM02-SN1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753629AbcCBJ2H (ORCPT ); Wed, 2 Mar 2016 04:28:07 -0500 X-Greylist: delayed 4925 seconds by postgrey-1.27 at vger.kernel.org; Wed, 02 Mar 2016 04:28:07 EST Authentication-Results: spf=pass (sender IP is 149.199.60.100) smtp.mailfrom=xilinx.com; arndb.de; dkim=none (message not signed) header.d=none;arndb.de; dmarc=bestguesspass action=none header.from=xilinx.com; Subject: Re: [RFC PATCH] drivers: ata: Read Rx water mark value from device-tree To: Arnd Bergmann , Michal Simek References: <1455974302-7082-1-git-send-email-anuragku@xilinx.com> <3802E9A6666DF54886E2B9CBF743BA9825E025F6@XAP-PVEXMBX01.xlnx.xilinx.com> <56D69EDD.40400@xilinx.com> <3012728.7zDNPtQ7kR@wuerfel> CC: Anurag Kumar Vulisha , Rob Herring , =?UTF-8?Q?S=c3=b6ren_Brinkmann?= , "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" From: Michal Simek Message-ID: <56D6B217.2000701@xilinx.com> Date: Wed, 2 Mar 2016 10:27:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <3012728.7zDNPtQ7kR@wuerfel> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-RCIS-Action: ALLOW X-TM-AS-Product-Ver: IMSS-7.1.0.1224-8.0.0.1202-22166.006 X-TM-AS-User-Approved-Sender: Yes;Yes X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:149.199.60.100;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10009020)(6009001)(2980300002)(438002)(189002)(164054003)(51914003)(76104003)(24454002)(199003)(2950100001)(76176999)(54356999)(92566002)(87266999)(50986999)(4001350100001)(87936001)(1220700001)(1096002)(86362001)(586003)(80316001)(64126003)(83506001)(23746002)(106466001)(107886002)(5001770100001)(11100500001)(189998001)(93886004)(6806005)(65806001)(65956001)(77096005)(63266004)(4001450100002)(230700001)(47776003)(5001960100004)(33656002)(4001430100002)(2906002)(50466002)(5008740100001)(81156009)(36756003)(107986001);DIR:OUT;SFP:1101;SCL:1;SRVR:SN1NAM02HT001;H:xsj-pvapsmtpgw02;FPR:;SPF:Pass;MLV:sfv;MX:1;A:1;LANG:en; X-MS-Office365-Filtering-Correlation-Id: 35bbba27-24f4-44c9-99d4-08d3427cf569 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(8251501002);SRVR:SN1NAM02HT001; X-Microsoft-Antispam-PRVS: <1bac4aac17de4c6986b2a4cd1923ee60@SN1NAM02HT001.eop-nam02.prod.protection.outlook.com> X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(13018025)(5005006)(8121501046)(13015025)(13024025)(13017025)(13023025)(10201501046)(3002001);SRVR:SN1NAM02HT001;BCL:0;PCL:0;RULEID:;SRVR:SN1NAM02HT001; X-Forefront-PRVS: 086943A159 X-OriginatorOrg: xilinx.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Mar 2016 09:28:04.5869 (UTC) X-MS-Exchange-CrossTenant-Id: 657af505-d5df-48d0-8300-c31994686c5c X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=657af505-d5df-48d0-8300-c31994686c5c;Ip=[149.199.60.100];Helo=[xsj-pvapsmtpgw02] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM02HT001 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2.3.2016 10:11, Arnd Bergmann wrote: > On Wednesday 02 March 2016 09:05:49 Michal Simek wrote: >> On 2.3.2016 06:53, Anurag Kumar Vulisha wrote: >>>>>>> >>>>>>> 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. >> >> that 0x40 is value choose based on testing that it is not causing any >> visible problem and this is used as default value in the driver >> (PTC_RX_WM_VAL - ahci_ceva.c) >> >> Values which you can setup are in range 0x0 - 0x7f (7bits). It means >> hardware fifo size is probably 0x80. >> >> And this dt/module parameter is IMHO just sw setting setup by user. >> It means I am not quite sure that this is DT parameter because it is >> just SW setting. >> I expect this range will be valid for all silicon revisions. >> If happen that any silicon revision can't setup certain level because of >> HW bug we can handle it via DT parameter or specific compatible string. >> But setting up watermark SW level via DT doesn't look correct to me. >> >> Please let me know what you think. > > Ok, thanks for the background. I think we should just leave it to be > set by the driver then. Please make sure that each SoC specific .dtsi > file has a unique "compatible" string for the device though, so that > the driver can later override it based on the specific variant if > that ends up being necessary for performance or bug-avoidance. No problem with default value in driver. Something has to be setup. Reset value based on reg spec I was checking is 0x20. Based on our testing we saw some issues that's why 0x40 was setup as default value. There is a need to be able to configure this value for example for testing different values that's why I think module parameter should be the right way to go. If this should be DT parameters there should be different ceva IP which allows different fifo size and different watermark level to be setup by user. What do you think? Does it sound reasonable. Thanks, Michal