Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964839AbcKXKFj (ORCPT ); Thu, 24 Nov 2016 05:05:39 -0500 Received: from mout.kundenserver.de ([212.227.17.24]:54645 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S936459AbcKXKFh (ORCPT ); Thu, 24 Nov 2016 05:05:37 -0500 From: Arnd Bergmann To: linux-arm-kernel@lists.infradead.org Cc: Thomas Petazzoni , Gregory CLEMENT , Jimmy Xu , Andrew Lunn , Ulf Hansson , Romain Perier , Liuliu Zhao , Peng Zhu , Adrian Hunter , Nadav Haklai , Ziji Hu , Victor Gu , Doug Jones , Jisheng Zhang , Yehuda Yitschak , "Wei(SOCP) Liu" , Xueping Liu , Hilbert Zhang , Shiwu Zhang , Yu Cao , Sebastian Hesselbarth , "devicetree@vger.kernel.org" , Jason Cooper , Keji Zhang , Kostya Porotchkin , Ryan Gao , Marcin Wojtas , Hanna Hawa , "Jack(SH) Zhu" , "linux-mmc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Wilson Ding Subject: Re: [PATCH 5/10] dt: bindings: Add bindings for Marvell Xenon SD Host Controller Date: Thu, 24 Nov 2016 11:04:36 +0100 Message-ID: <8756050.yoKoJPCyHz@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-34-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <20161124104858.3604c11d@free-electrons.com> References: <8737ihmctr.fsf@free-electrons.com> <20161124104858.3604c11d@free-electrons.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:JPmiUzzbBvxr37W6aSZbG+0mrRO5pPcG+wxe/n87lcdiNAGtlZ9 RD4xCQ8cZ5LGFOT/asrTuYLG7WwCGEmfuyRqTq+otrdyC6i39/Go8IVwshYV7xfJyqFyitP ivvb+3XL+JznzpDNcNdSMvZ8/GJJMxnJiZQwZPrZYnVPZJXixz/O+HwmO0X5QqXlprS+AVK ksjypp6KVpdjX1z5PEHuw== X-UI-Out-Filterresults: notjunk:1;V01:K0:LHeI6BhLmIc=:PZorqQO3VCih4sZjmT/GJ7 PcVxjXCoGQf8/GMfDQa2EVyWrNpOJn5YXiirccqeZhGOYpLmPndhKqxZ3v5gWu/H4FivtVuGJ F3goS/TZr0kxIQK/Zd94SEacLfNwIeUIicwHhYlu7Mea4qOy9nKpO/NsCrZKns2iLWR1KmmK+ sRp7HIlnJydX0L17CVemgtDkLbTgeDX93WFx12xvkwU9zVqyDzQkP6Lb8nLrXmbKBc92hMw7i 2QfTPKXY/XVo479iMaNpq0XXPu+WS1vWRA1D/evpQDkXLL2hqTGQhssYWQaSv3xOFdhsTyTH+ 0BrgPHt+KJI3iH6Y1uuIfzHwVxVHdHd7pQJUxtQUt3LbLxegDJ3RZ0eCCpb9BGfhux05FoVxP nrKVZOel+pi5Q2Qdqz5/PXN6ng4SL00c5yjiGCDEJUnZOcKbkfrcXaO9IbxNqTIsz74M5mz2/ FlpkAJWW0X+I+y5i92yGayaHViozMRfLYqcEJJns+FysiWJH9ePRspIwUsiu5UvxInYM2ke+Z Y8lFWMR3Uppto6AfhMIwWaJE47Uw9ja44r4mDIcrrQR8wIOECAJaO5U5sC/uH1cfXOgRXsXPb WsOiL4dO8jmeR6J5RHQHX1c7tus0Hyoo3xEsHjo7blvYNVu+Ep89Jp0uU/pvUjvalkILDGK55 r81nzwg6yn+MRGYQJCI6ssSBH7nb3sbvF9S7fTHngHJ+2B/xPgYzH6GXAoGOO1jvp2MfFE5VS yPGKJakFur375EME Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1060 Lines: 29 On Thursday, November 24, 2016 10:48:58 AM CET Thomas Petazzoni wrote: > Hello, > > On Thu, 24 Nov 2016 10:44:48 +0100, Gregory CLEMENT wrote: > > > "A single Xenon IP can support multiple slots. > > Each slot acts as an independent SDHC. It owns independent resources, such > > as register sets clock and PHY. > > Each slot should have an independent device tree node." > > I think this wording is still very confusing, and continues to cause > confusion. > > We should just state that each Xenon controller supports a single slot, > and that's it. > > The text still says "a single Xenon IP can support multiple slots", > which continues to cause confusion. Agreed. Ideally we'd find out why exactly the slot number must be used for accessing some of the registers to have a better explanation to put in there, aside from stating that only one slot is supported but the number must be set. Could it be that this is some form of pinmuxing, i.e. that each controller could in theory be used for any of the slots but you have to pick one of them? Arnd