From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S938661AbcKXJt2 (ORCPT <rfc822;w@1wt.eu>);
        Thu, 24 Nov 2016 04:49:28 -0500
Received: from mail-io0-f176.google.com ([209.85.223.176]:34234 "EHLO
        mail-io0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S936468AbcKXJtZ (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Thu, 24 Nov 2016 04:49:25 -0500
MIME-Version: 1.0
In-Reply-To: <8737ihmctr.fsf@free-electrons.com>
References: <cover.86006f271b60cf7c0b4c5a51762a9dacca4c4718.1477911954.git-series.gregory.clement@free-electrons.com>
 <4031579.CBE32NHUoW@wuerfel> <877f7tmduw.fsf@free-electrons.com>
 <28082657.RK5ubAe11Q@wuerfel> <8737ihmctr.fsf@free-electrons.com>
From: Marcin Wojtas <mw@semihalf.com>
Date: Thu, 24 Nov 2016 10:49:23 +0100
Message-ID: <CAPv3WKddPHgpRU2_tVoDF=5Z-nqfFPxjgJ-+z9o-1tR2=fFvAA@mail.gmail.com>
Subject: Re: [PATCH 5/10] dt: bindings: Add bindings for Marvell Xenon SD Host Controller
To: Gregory CLEMENT <gregory.clement@free-electrons.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        Jimmy Xu <zmxu@marvell.com>, Andrew Lunn <andrew@lunn.ch>,
        Ulf Hansson <ulf.hansson@linaro.org>,
        Romain Perier <romain.perier@free-electrons.com>,
        Liuliu Zhao <zhaoliul@marvell.com>, Peng Zhu <zhupeng@marvell.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Nadav Haklai <nadavh@marvell.com>, Ziji Hu <huziji@marvell.com>,
        Victor Gu <xigu@marvell.com>, Doug Jones <dougj@marvell.com>,
        Jisheng Zhang <jszhang@marvell.com>,
        Yehuda Yitschak <yehuday@marvell.com>, Xueping Liu <xpliu@marvell.com>,
        Hilbert Zhang <zzhang@marvell.com>, Shiwu Zhang <zhangshw@marvell.com>,
        Yu Cao <yucao@marvell.com>,
        Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
        "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
        Jason Cooper <jason@lakedaemon.net>, Hanna Hawa <hannah@marvell.com>,
        Kostya Porotchkin <kostap@marvell.com>, Ryan Gao <ygao@marvell.com>,
        "Wei(SOCP) Liu" <liuw@marvell.com>,
        Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
        Keji Zhang <keji@marvell.com>, "Jack(SH) Zhu" <jmzhu@marvell.com>,
        "linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
        Adrian Hunter <adrian.hunter@intel.com>,
        Wilson Ding <dingwei@marvell.com>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Gregory,

2016-11-24 10:44 GMT+01:00 Gregory CLEMENT <gregory.clement@free-electrons.com>:
> Hi Arnd,
>
>  On jeu., nov. 24 2016, Arnd Bergmann <arnd@arndb.de> wrote:
>
>> On Thursday, November 24, 2016 10:22:31 AM CET Gregory CLEMENT wrote:
>>>
>>> I don't have an option for mmc in general, but using child node do not
>>> fit at all the xenon controller.
>>>
>>> For this controller each slot has its own set of register, so there is
>>> no common ressource to share so no advantage to use it. Using child node
>>> in our case will just make the code more complex for no benefit.
>>
>> If every slot has its own registers, what is it that makes up the
>> 'controller'? It sounds to me that you just have to adjust the terminology
>> and talk about multiple controllers then, with one slot per controller.
>>
>
> I agree and actually there were some words about in at the begining of
> the binding:
>
> "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."
>
> All the confusion came from the fact that we still need to identify a
> slot ID. For an obscure reason the hardware can't guess the slot ID from
> the address register."
>

How about to avoid confusion, by simply renaming this number to
port-id/xenon-id or anything else but slot? I guess this may allow to
avoid some misunderstandings.

Best regards,
Marcin