From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751793AbcEKCuu (ORCPT ); Tue, 10 May 2016 22:50:50 -0400 Received: from lucky1.263xmail.com ([211.157.147.134]:41208 "EHLO lucky1.263xmail.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751212AbcEKCus (ORCPT ); Tue, 10 May 2016 22:50:48 -0400 X-263anti-spam: KSV:0; X-MAIL-GRAY: 1 X-MAIL-DELIVERY: 0 X-ABS-CHECKED: 4 X-ADDR-CHECKED: 0 X-KSVirus-check: 0 X-RL-SENDER: shawn.lin@rock-chips.com X-FST-TO: devicetree@vger.kernel.org X-SENDER-IP: 58.22.7.114 X-LOGIN-NAME: shawn.lin@rock-chips.com X-UNIQUE-TAG: X-ATTACHMENT-NUM: 0 X-DNS-TYPE: 0 Subject: Re: [PATCH 2/2] dt-bindings: rockchip-dw-mshc: add rockchip,default-drv-phase To: Doug Anderson References: <1462527648-24443-1-git-send-email-shawn.lin@rock-chips.com> <1462527673-24711-1-git-send-email-shawn.lin@rock-chips.com> <1f2f43c7-2672-e448-eddb-2d613bb8dc48@rock-chips.com> Cc: shawn.lin@rock-chips.com, Jaehoon Chung , Ulf Hansson , Rob Herring , "linux-mmc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Brian Norris , Heiko Stuebner , "open list:ARM/Rockchip SoC..." , "devicetree@vger.kernel.org" From: Shawn Lin Message-ID: Date: Wed, 11 May 2016 10:50:17 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: 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 On 2016/5/10 23:57, Doug Anderson wrote: > (again, but not HTML) > ------8<------------------ > > I have less faith than you in the TRM. The TRM is full of minor > errors and is often wrong about the default state of things. IMHO the > only true way to find out is to boot up some SoCs and check. > Okay, I should not have too much confidence on my TRM maybe :). Again, We SHOULD refer to the Mobile Storage Host section (Variable Delay/Clock Generation) instead of CRU section, otherwise even you will see inconsistent decription of mmc_clock->shift. > As far as whether code touches these values: > ---------8<----------------- >> >> maybe. But I think 180(downside) is the better. NAK my previous comments here. Downside is better for SRD, but won't work for DDR mode. When running in DDR mode, we should use 90 instead. So let me elaborate a bit more here. For DDR mode, one single clk cycle should sending two data bits outside to the devices. We need a hold time for both. If 180 is used, the first bit occurs around the downside area, which won't be sampled by devices on the upside. So on the upside, the devices will see a zero bit if you actually send a one-bit, which makes the devices generate CRC finally. For this above, 180 for all SDR mode is ok, but 90 should be deployed for DDR mode. So simply checking the timing to hardcode it should be fine. > > I'm OK with using 180 always as long as SD cards continue to work OK. > Best would be if someone could actually run a protocol analyzer for > all the different speed modes. > > >>> Also: I still haven't heard whether there is any downside to using 180 >>> degrees for modes that only require 90 degrees. Does it cause >>> problems to just always use 180 degrees? If not, we could possibly >>> use 180 degrees everywhere and just hardcode it? >> >> -- Best Regards Shawn Lin