Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753157AbcKRJSt (ORCPT ); Fri, 18 Nov 2016 04:18:49 -0500 Received: from mail-qt0-f173.google.com ([209.85.216.173]:34797 "EHLO mail-qt0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752168AbcKRJSp (ORCPT ); Fri, 18 Nov 2016 04:18:45 -0500 MIME-Version: 1.0 In-Reply-To: References: <20161117093438.17988-1-wens@csie.org> From: Linus Walleij Date: Fri, 18 Nov 2016 10:18:43 +0100 Message-ID: Subject: Re: [PATCH] ARM: dts: sunxi: Explicitly enable pull-ups for MMC pins To: klaus.goger@theobroma-systems.com, Ulf Hansson , "linux-mmc@vger.kernel.org" Cc: Chen-Yu Tsai , Maxime Ripard , "devicetree@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , linux-sunxi Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3077 Lines: 77 [Notice this reply has little to do with the patch in question: I think it should be applied. I just want to involve some MMC/SD people here] On Thu, Nov 17, 2016 at 9:57 PM, wrote: > On 2016-11-17 10:34, Chen-Yu Tsai wrote: >> >> Given that MMC starts in open-drain mode and the pull-ups are required, >> it's best to enable it for all the pin settings. > > It's even more complicated than that with MMC. It starts in open-drain mode > for > CMD during initialization but changes to push-pull afterwards. The card has > internal pull-ups to prevent bus floating during setup and will disable them > after switching to 4bit mode (or 8bit for eMMC when available). > But even after switching to push-pull drivers there are states the bus would > float and pull ups have to ensure a high level on the bus. > > See JESD84-A441 chapter 7.15 ff as reference. > > The difference between the P-bit and Z-bit is that a P-bit is actively > driven > to HIGH by the card respectively host output driver, while Z-bit is driven > to > (respectively kept) HIGH by the pull-up resistors Rcmd respectively Rdat. > > Enabling the pull ups on the CPU would be the right choice considering that > most boards will not have external pull-ups. Even if they would have one, > adding the internal in parallel would work in almost all cases and the > increase in power consumption would be negligible. I guess you are referring to software-controlled pull up on the pad ring of the SoC. Nominally that should be handled by pin control like in this patch. It is not clear from context to me which of the lines need to be handled like this? Just the data lines? DAT0 would be the critical line to pull up in that case, since the others will not be used until bus switch anyways right? But what about CMD? I assume CLK should always be push-pull? Also: if the pins have an explicit Open Drain setting, should that be used? I guess so? Overall I think this construction is pretty common. We essentially have two classes of connections: - Those connecting the eMMC or even MMC/SD card directly to the SoC. No pull-ups on the board. Here it makes sense to have: 1. A pin control default state with open drain and pull-ups enabled for those lines and it then needs 2. A second "4/8bit mode" that will switch these pins to push-pull mode and turn off the pull-ups. If the OD+pull-up state is the default we should probably standardize a default name for the state when we kick in 4/8bit mode from the IOS operation. - Those connection the MMC/SD on an external slot through a levelshifter/EMI filter. In that case I guess it is pretty much dependent on the levelshifter or EMI thing how the lines out of the SoC should be configured, and usually it is static so you do not need to worry about it after boot configuration of pins. (Mostly no bias, push-pull I think.) I highly suspect a whole bunch of SoC drivers are not getting this business right today. Not even in out-of-tree vendor kernels. Yours, Linus Walleij