Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp9350791ybl; Fri, 17 Jan 2020 10:26:43 -0800 (PST) X-Google-Smtp-Source: APXvYqwv/cRORhZ4mugNBBLNFDz2Clc7buhcu8zajYloqnXSA229qHU6fFp6L+4eTCzOn6kARj5O X-Received: by 2002:a05:6830:2057:: with SMTP id f23mr7238877otp.110.1579285603523; Fri, 17 Jan 2020 10:26:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579285603; cv=none; d=google.com; s=arc-20160816; b=l9kmcvovyD1BnQbW31aXKysPGtarK11ThRe0q6Rt4YyxSZhHlRoyzh0jikCNxY2PQ2 iMGb2XDbjxlsF5wHiThrujMe0571bpYKG2Mu4atQRd5no+0/MwvRYEx9fhhsU7sBKhaQ gtOy7F0uJCulCHIhOKGpdBTqSI2VOB/A/ojapm1P4UE0jkF57kABCfgZzAGE2GDzG33H qy9UawbDCkDrXXMS1LCzWZ/Q1h+GQS5w4QMvkJWeCKjEVROGQXL4AIbmrV5mqu7D4CSQ K5fQz2IUUwTWfbTgO1XubkS0sWalBR4SVb5q2jPzxttV6877ajqSNZC2BwHaDMFLfJg/ G61A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=Ajf3BP5hBZsV+EVeWhN6NMnAll1+MYA0SUMuToB9Bi8=; b=049omsb/Mbd21kbI42eKWMNI7YNbhq2S94QP5lxN9AYugPnEvjMzZLk+ooXC+qzhyf eaSxRW+S1672A/J+J3tZTr6ka8ua49cXYLEZH+82yyzShaBeL2uzQT6lv/WTblghQj1Z 8HJiaLIll2B//qlWxa5cQh3JKFdp/JwZxgG2lrCytg33HYLXhLKHvoBpAcF2cn3REatk 8t5uBkyGDGBfnU0HQahB7cbHaIXZT9lybim4hUIsDpgRVHHnxjoehQ8GTObB2TQ/EsEg WkWHoL+pDCpwOkXRUolee2f3s2D4Ak2UqriwREv1lJTqIw4lsHBZibVEqDmo/wBqtMhL d+Tg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=rGISdMu+; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e26si16486139otj.113.2020.01.17.10.26.32; Fri, 17 Jan 2020 10:26:43 -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; dkim=pass header.i=@kernel.org header.s=default header.b=rGISdMu+; 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=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728842AbgAQSZl (ORCPT + 99 others); Fri, 17 Jan 2020 13:25:41 -0500 Received: from mail.kernel.org ([198.145.29.99]:38294 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726970AbgAQSZk (ORCPT ); Fri, 17 Jan 2020 13:25:40 -0500 Received: from localhost (lfbn-tou-1-1502-76.w90-89.abo.wanadoo.fr [90.89.68.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 04F0E206D5; Fri, 17 Jan 2020 18:25:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1579285539; bh=Ajf3BP5hBZsV+EVeWhN6NMnAll1+MYA0SUMuToB9Bi8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=rGISdMu+rzywI2gZjVcM1WGByjW5TW2wt+NoZo0MifkumfhruGnOL0SOu98nDSXnW vCTYqXaeAAUINnBx/ZLG1eN9wlBGnta3fl2ZvyHMKSqhoxKpzIugxEBDZ4JIuL9TWZ ETmRjk8Oo4A+/dOMlHkUwJzBbOQsq0qkLu6XJqaE= Date: Fri, 17 Jan 2020 19:25:37 +0100 From: Maxime Ripard To: Jernej =?utf-8?Q?=C5=A0krabec?= Cc: Rob Herring , Chen-Yu Tsai , Mark Rutland , "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" , devicetree@vger.kernel.org, "linux-kernel@vger.kernel.org" Subject: Re: [PATCH 1/2] dt-bindings: arm: sunxi: add OrangePi 3 with eMMC Message-ID: <20200117182537.scttsuq26g6v6yno@gilmour.lan> References: <20200115194216.173117-1-jernej.skrabec@siol.net> <4200557.LvFx2qVVIh@jernej-laptop> <20200116122944.sgl2fgxf5mrg6i52@gilmour.lan> <12435330.uLZWGnKmhe@jernej-laptop> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="mplvgv5b6upxjosy" Content-Disposition: inline In-Reply-To: <12435330.uLZWGnKmhe@jernej-laptop> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --mplvgv5b6upxjosy Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Jan 16, 2020 at 05:33:45PM +0100, Jernej =C5=A0krabec wrote: > Dne =C4=8Detrtek, 16. januar 2020 ob 13:29:44 CET je Maxime Ripard napisa= l(a): > > On Thu, Jan 16, 2020 at 12:10:58AM +0100, Jernej =C5=A0krabec wrote: > > > Hi! > > > > > > Dne sreda, 15. januar 2020 ob 22:57:31 CET je Rob Herring napisal(a): > > > > On Wed, Jan 15, 2020 at 1:42 PM Jernej Skrabec > > > > > > wrote: > > > > > OrangePi 3 can optionally have eMMC. Add a compatible for it. > > > > > > > > Is this just a population option or a different board layout? If the > > > > former, I don't think you need a new compatible, just add/enable a > > > > node for the eMMC. > > > > > > I have only board with eMMC but I imagine it's the former. Even so, > > > current > > > approach with Allwinner boards is to have two different board DT file= s, > > > one for each variant. This can be seen from > > > Documentation/devicetree/bindings/arm/ sunxi.yaml which has a lot of > > > compatibles ending with "-emmc". I guess reason for that is to avoid > > > having MMC controller being powered on for no reason. > > The main reason for that is that those populating options can be > > conflicting. For example, last week we discussed an issue about the > > eMMC being on the same pin set than an SPI flash, both options being > > available. > > > > The solution Andre suggested then was to let the eMMC be disabled, and > > have the bootloader probe the emmc, and if found, enable > > it. Otherwise, it means that you have a SPI flash (and enable it). > > > > I guess a similar solution would apply here. > > From what I can tell from schematic, pins are dedicated for eMMC. > > So what solution do you suggest? Put eMMC node in original OrangePi 3 DT = and > set status to disabled? If it's always dedicated to eMMC, but the eMMC is not always there, I guess we could remove the non-removable property from the eMMC mode. IIRC, without it (and without CD GPIO), it will fall-back to polling the card and will be able to detect it if it's there (and not use it if it's not). Maxime --mplvgv5b6upxjosy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCXiH8IQAKCRDj7w1vZxhR xbWvAQDklRiCu9YordwQFOhckNNptssNw4rGbHaZXxEmxqtxQAD/UzPfwuDk4SR/ fyxg+YnibVHtraJeNwUYsL27/pkCOQA= =TwtM -----END PGP SIGNATURE----- --mplvgv5b6upxjosy--