From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751890AbdASVjD (ORCPT ); Thu, 19 Jan 2017 16:39:03 -0500 Received: from mail-wm0-f46.google.com ([74.125.82.46]:36395 "EHLO mail-wm0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751478AbdASVjB (ORCPT ); Thu, 19 Jan 2017 16:39:01 -0500 MIME-Version: 1.0 In-Reply-To: <20170119145041.GA11757@hardcore> References: <20161219121552.18316-1-jglauber@cavium.com> <20170119145041.GA11757@hardcore> From: Ulf Hansson Date: Thu, 19 Jan 2017 22:38:05 +0100 Message-ID: Subject: Re: [PATCH v10 0/8] Cavium MMC driver To: Jan Glauber Cc: "linux-mmc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , David Daney , "Steven J . Hill" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [...] > I've added a fixed regulator to DT: > > vcc_3v3: regulator-vcc_3v3 { > compatible = "regulator-fixed"; > regulator-name = "VCC_3V3"; > regulator-min-microvolt = <3300000>; > regulator-max-microvolt = <3300000>; > > gpio = <&gpio_6_0 8 0>; > /* enable-gpio = <&gpio_6_0 8 0>; */ > enable-active-high; > }; > > This seems to enable the gpio. Is this sufficient or do I need the > gpio-regulator? Looks good to me. [...] >> > In porting the driver to arm64 I run into some issues. >> > >> > 1. mmc_parse_of is not capable of supporting multiple slots behind one >> > controller. On arm64 the host controller is presented as one PCI device. >> > There are no devices per slot as with the platform variant, so I >> > needed to create dummy devices to make mmc_parse_of work. >> > IMHO it would be cleaner if mmc_parse_of could be extended to cover >> > the multiple slots case. >> >> Yes. I agree that this make sense! >> Seems like we could try to make use of the struct device_node instead >> of the struct device. >> >> I will try to come up with an idea, I keep you posted. >> >> > >> > 2. Without setting MMC_CAP_1_8V_DDR DDR mode is not usable for eMMC. >> > I would prefer to introduce a new cap flag, MMC_CAP_3_3V_DDR, >> > if possible. Currently I need to add "mmc-ddr-1_8v" to DTS, >> > which seems odd for a 3.3v only host controller. >> >> This keep coming back. Both DT bindings and changing to the mmc core >> has been posted. >> >> Allow me to help out and re-post a new series. You can build on top of >> them - I will keep you on cc. > > Any news here? Can you give me a pointer? For 1), I need some more time. Feel free to try it out your self. For 2), I am working on it. Likely in the beginning of next week I will post something. [...] Kind regards Uffe