Re: [PATCH v2 1/2] mmc: dw_mmc: Handle late vmmc regulators with EPROBE_DEFER
Hi Doug,
On Fri, Jun 07 2013, Doug Anderson wrote:
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index bc3a1bc..ab5642d 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -1895,7 +1895,7 @@ static int dw_mci_init_slot(struct dw_mci *host,
> unsigned int id)
> struct mmc_host *mmc;
> struct dw_mci_slot *slot;
> const struct dw_mci_drv_data *drv_data = host->drv_data;
> - int ctrl_id, ret;
> + int ctrl_id;
> u8 bus_width;
>
> mmc = mmc_alloc_host(sizeof(struct dw_mci_slot), host->dev);
> @@ -1985,19 +1985,6 @@ static int dw_mci_init_slot(struct dw_mci *host,
> unsigned int id)
> #endif /* CONFIG_MMC_DW_IDMAC */
> }
>
> - host->vmmc = devm_regulator_get(mmc_dev(mmc), "vmmc");
> - if (IS_ERR(host->vmmc)) {
> - pr_info("%s: no vmmc regulator found\n", mmc_hostname(mmc));
> - host->vmmc = NULL;
> - } else {
> - ret = regulator_enable(host->vmmc);
> - if (ret) {
> - dev_err(host->dev,
> - "failed to enable regulator: %d\n", ret);
> - goto err_setup_bus;
> - }
> - }
> -
> if (dw_mci_get_cd(mmc))
> set_bit(DW_MMC_CARD_PRESENT, &slot->flags);
> else
> @@ -2023,10 +2010,6 @@ static int dw_mci_init_slot(struct dw_mci *host,
> unsigned int id)
> queue_work(host->card_workqueue, &host->card_work);
>
> return 0;
> -
> -err_setup_bus:
> - mmc_free_host(mmc);
> - return -EINVAL;
> }
>
> static void dw_mci_cleanup_slot(struct dw_mci_slot *slot, unsigned int id)
This hunk breaks the build for me, because err_setup_bus and ret are
used in the error path of the call to mmc_add_host() in this function.
I'll push a version that leaves those in. Let me know if you think
something strange is happening that made this work okay for you, like
a mismerge.
- Chris.
--
Chris Ball <http://printf.net/>
One Laptop Per Child
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 2/2] mmc: dw_mmc: Add the ability to set the ciu clock frequency
Hi Doug, On Fri, Jun 07 2013, Doug Anderson wrote: > As of now we rely on code outside of the driver to set the ciu clock > frequency. There's no reason to do that. Add support for setting up > the clock in the driver during probe. > > Signed-off-by: Doug Anderson > Acked-by: Jaehoon Chung > --- > Changes in v2: > - Added example as per Jaehoon. Thanks, pushed to mmc-next for 3.11. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 1/2] mmc: dw_mmc: Handle late vmmc regulators with EPROBE_DEFER
Hi Doug, On Fri, Jun 07 2013, Doug Anderson wrote: > It is possible to specify a regulator that should be turned on when > dw_mmc is probed. At the moment dw_mmc will fail to use the regulator > properly if the regulator probes after dw_mmc. Fix this problem by > honoring EPROBE_DEFER. > > At the same time move the regulator code out of the slot init code. > We only specify one regulator for the whole device and other parts of > the code (like suspend/resume) assume that the regulator has only been > enabled once. > > Signed-off-by: Doug Anderson > --- > Changes in v2: > - Avoid hackery to detect regulators that will never show up. > - Move regulator out of slot init--it doesn't belong there. Thanks, pushed to mmc-next for 3.11. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] mmc: sh_mobile_sdhi: fix error return code in sh_mobile_sdhi_probe()
Hi Wei,
On Tue, May 28 2013, Wei Yongjun wrote:
> From: Wei Yongjun
>
> Fix to return a negative error code instead of 0 when we cannot get
> IRQ source by platform_get_irq(), as done elsewhere in this function.
>
> Signed-off-by: Wei Yongjun
> ---
> drivers/mmc/host/sh_mobile_sdhi.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sh_mobile_sdhi.c
> b/drivers/mmc/host/sh_mobile_sdhi.c
> index cc4c872..a4316b3 100644
> --- a/drivers/mmc/host/sh_mobile_sdhi.c
> +++ b/drivers/mmc/host/sh_mobile_sdhi.c
> @@ -273,8 +273,10 @@ static int sh_mobile_sdhi_probe(struct platform_device
> *pdev)
> }
>
> /* There must be at least one IRQ source */
> - if (!i)
> + if (!i) {
> + ret = irq;
> goto eirq;
> + }
> }
>
> dev_info(&pdev->dev, "%s base at 0x%08lx clock rate %u MHz\n",
Thanks, pushed to mmc-next for 3.11.
- Chris.
--
Chris Ball <http://printf.net/>
One Laptop Per Child
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RESEND PATCH V3 0/8] mmc_of_parse() adaptations, switch mvsdio to mmc_of_parse()
Hi Simon, Simon Baatz writes: > RESEND V3: > - Dropped patches 9 and 10, they are part of linux-next already > NB: patch 7 as well, but I did not want to change the numbering I've pushed all patches except 7 to mmc-next for 3.11 now, and I made Stephen Warren's nit change to patch 6. Thanks! - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v9 1/9] ARM: davinci: move private EDMA API to arm/common
Hi, On Fri, Jun 07 2013, Sekhar Nori wrote: > + Chris since the patch has some davinci_mmc.c changes. > > Chris, Mark, > > On 3/6/2013 9:45 PM, Matt Porter wrote: >> Move mach-davinci/dma.c to common/edma.c so it can be used >> by OMAP (specifically AM33xx) as well. >> >> Signed-off-by: Matt Porter >> Acked-by: Sekhar Nori > > Can you please ack changes in mmc and sound respectively? I would like > to take the patch for v3.11. For davinci_mmc.c: Acked-by: Chris Ball Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V4 2/3] ARM: mmc: bcm281xx SDHCI driver
Hi Christian,
On Wed, May 29 2013, Christian Daudt wrote:
> + /* if device is eMMC, emulate card insert right here */
> + if (kona_dev->non_removable) {
> + ret = sdhci_bcm_kona_sd_card_emulate(host, 1);
> + if (ret) {
> + dev_err(dev,
> + "unable to emulate card insertion\n");
> + goto err_remove_host;
> + }
> + } else if (gpio_is_valid(kona_dev->cd_gpio)) {
> + ret = devm_gpio_request(dev, kona_dev->cd_gpio, "sdio cd");
> + if (ret < 0) {
> + dev_err(mmc_dev(host->mmc),
> + "Unable to request GPIO pin %d\n",
> + kona_dev->cd_gpio);
> + goto err_remove_host;
> + }
> +
> + gpio_direction_input(kona_dev->cd_gpio);
> +
> + /* Set debounce for SD Card detect to maximum value (128ms)
> + *
> + * NOTE-1: If gpio_set_debounce() returns error we still
> + * continue with the default debounce value set. Another reason
> + * for doing this is that on rhea-ray boards the SD Detect GPIO
> + * is on GPIO Expander and gpio_set_debounce() will return error
> + * and if we return error from here, then probe() would fail and
> + * SD detection would always fail.
> + *
> + * NOTE-2: We also give a msleep() of the "debounce" time here
> + * so that we give enough time for the debounce to stabilize
> + * before we read the gpio value in gpio_get_value_cansleep().
> + */
> + ret = gpio_set_debounce(kona_dev->cd_gpio,
> + (SD_DETECT_GPIO_DEBOUNCE_128MS * 1000));
> + if (ret < 0) {
> + dev_err(mmc_dev(host->mmc),
> + "%s: gpio set debounce failed."
> + "default debounce value assumed\n", __func__);
> + }
> +
> + /* Sleep for 128ms to allow debounce to stabilize */
> + msleep(SD_DETECT_GPIO_DEBOUNCE_128MS);
> + /* request irq for cd_gpio after the gpio debounce is
> + * stabilized, otherwise, some bogus gpio interrupts might be
> + * triggered.
> + */
> + irq = gpio_to_irq(kona_dev->cd_gpio);
> + ret = devm_request_threaded_irq(dev,
> + irq,
> + NULL,
> + sdhci_bcm_kona_pltfm_cd_interrupt,
> + IRQF_TRIGGER_FALLING|
> + IRQF_TRIGGER_RISING |
> + IRQF_ONESHOT |
> + IRQF_NO_SUSPEND, "sdio cd", host);
> + if (ret) {
> + dev_err(mmc_dev(host->mmc),
> + "Failed irq %d request for gpio=%d ret=%d\n",
> + gpio_to_irq(kona_dev->cd_gpio),
> + kona_dev->cd_gpio, ret);
> + goto err_remove_host;
> + }
> + if (gpio_is_valid(kona_dev->wp_gpio)) {
> + ret = devm_gpio_request(dev,
> + kona_dev->wp_gpio, "sdio wp");
> + if (ret < 0) {
> + dev_err(&pdev->dev,
> + "Unable to request WP pin %d\n",
> + kona_dev->wp_gpio);
> + kona_dev->wp_gpio = -1;
> + } else {
> + gpio_direction_input(kona_dev->wp_gpio);
> + }
> + }
Could you investigate replacing this section of code with a call to
mmc_of_parse(), please? It should be able to replace your parsing
and handling of bus-width, cd-gpios, wp-gpios, and non-removable
(other than the initialization quirks specific to your hardware).
I'd like to avoid every driver having its own DT parsing.
Thanks,
- Chris.
--
Chris Ball <http://printf.net/>
One Laptop Per Child
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH -next] mmc: dw_mmc: fix error return code in dw_mci_probe()
Hi, On Tue, Apr 23 2013, Seungwon Jeon wrote: > On Friday, April 19, 2013 , Wei Yongjun wrote: >> From: Wei Yongjun >> >> Fix to return -ENOMEM in alloc workqueue error case instead >> of 0, as done elsewhere in this function. >> >> Signed-off-by: Wei Yongjun > > Acked-by: Seungwon Jeon Thanks, pushed to mmc-next for 3.11. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH -next] mmc: mxs-mmc: fix error return code in mxs_mmc_probe()
Hi, On Fri, Apr 19 2013, Marek Vasut wrote: > Dear Wei Yongjun, > >> From: Wei Yongjun >> >> Fix to return -ENODEV in the request dma error case instead >> of 0, as done elsewhere in this function. >> >> Signed-off-by: Wei Yongjun > > Seems ok to me. > > Reviewed-by: Marek Vasut Thanks, pushed to mmc-next for 3.11. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 0/5] mmc: mxcmmc: add mpc512x support
Hi, On Mon, Apr 08 2013, Anatolij Gustschin wrote: > The SDHC controller on mpc512x is compatible with i.MX31 SDHC > controller, the existing MMC host driver can be used on > mpc512x with some modifications, the patch series extends > the existing driver. It is based on the following v3 mxcmmc DT > support patch: > >https://patchwork.kernel.org/patch/2368631 > > Changes in v3 series are mentioned in each patch > > Anatolij Gustschin (5): > mmc: mxcmmc: fix race conditions for host->req and host->data access > mmc: mxcmmc: add mpc512x SDHC support > mmc: mxcmmc: use slot-gpio API for write-protect detection > mmc: mxcmmc: constify mxcmci_devtype > mmc: mxcmmc: enable DMA support on mpc512x > > arch/powerpc/boot/dts/mpc5121.dtsi |2 + > drivers/mmc/host/Kconfig | 10 +- > drivers/mmc/host/mxcmmc.c | 209 > ++-- > 3 files changed, 159 insertions(+), 62 deletions(-) Thanks, all pushed to mmc-next for 3.10. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3] mmc: mxcmmc: DT support
Hi, On Fri, Apr 12 2013, Arnd Bergmann wrote: > On Sunday 31 March 2013, Anatolij Gustschin wrote: >> >> From: Markus Pargmann >> >> Adding devicetree support for imx21-mmc and imx31-mmc. Based on generic >> gpio helper functions by Guennadi and generic DMA devicetree bindings. >> >> Signed-off-by: Markus Pargmann >> Signed-off-by:: Anatolij Gustschin > > Acked-by: Arnd Bergmann Thanks! Pushed to mmc-next for 3.10. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3] mmc: mxcmmc: DT support
Hi, On Sun, Mar 31 2013, Anatolij Gustschin wrote: > From: Markus Pargmann > > Adding devicetree support for imx21-mmc and imx31-mmc. Based on generic > gpio helper functions by Guennadi and generic DMA devicetree bindings. > > Signed-off-by: Markus Pargmann > Signed-off-by:: Anatolij Gustschin Sascha, Arnd, perhaps one of you could review this? There's another patchset waiting on it. Thanks! - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v7 0/5] Add DT support for davinci_mmc driver
Hi, On Tue, Apr 02 2013, Sekhar Nori wrote: > I would like to take this series through DaVinci tree to manage the > dependencies with mach-davinci. I need your ack on the driver part and > the DT binding. Can you please provide your ack? Acked-by: Chris Ball Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH -next] mmc: wmt-sdmmc: remove unused variable in wmt_complete_data_request()
Hi,
On Tue, Mar 12 2013, Tony Prisk wrote:
> On Mon, 2013-03-11 at 22:36 +0800, Wei Yongjun wrote:
>> From: Wei Yongjun
>>
>> The variable 'mmc' is initialized but never used
>> otherwise, so remove the unused variable.
>>
>> Signed-off-by: Wei Yongjun
>> ---
>> drivers/mmc/host/wmt-sdmmc.c | 2 --
>> 1 file changed, 2 deletions(-)
>>
>> diff --git a/drivers/mmc/host/wmt-sdmmc.c b/drivers/mmc/host/wmt-sdmmc.c
>> index 154f0e8..41d5802 100644
>> --- a/drivers/mmc/host/wmt-sdmmc.c
>> +++ b/drivers/mmc/host/wmt-sdmmc.c
>> @@ -348,13 +348,11 @@ static void wmt_complete_data_request(struct
>> wmt_mci_priv *priv)
>>
>> static irqreturn_t wmt_mci_dma_isr(int irq_num, void *data)
>> {
>> -struct mmc_host *mmc;
>> struct wmt_mci_priv *priv;
>>
>> int status;
>>
>> priv = (struct wmt_mci_priv *)data;
>> -mmc = priv->mmc;
>>
>> status = readl(priv->sdmmc_base + SDDMA_CCR) & 0x0F;
>>
>>
>
> Acked-by: Tony Prisk
Thanks, pushed to mmc-next for 3.10.
- Chris.
--
Chris Ball <http://printf.net/>
One Laptop Per Child
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 00/13] mmc: core and driver DT and related development
Hi, On Tue, Feb 19 2013, Guennadi Liakhovetski wrote: >> Thanks! Pushed to mmc-next, will think about merging for 3.9. > > Thanks! Please, push all of them (taking into account v5 of #03/13), but > hold back on #13, it'll need some more work. Okay, I've dropped #13 from mmc-next. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 00/13] mmc: core and driver DT and related development
Hi Guennadi, On Fri, Feb 15 2013, Guennadi Liakhovetski wrote: > This is v4 of a patch-series, extending mmc subsystem device-tree usage > and adding more advanced DT capabilities to sh_mmcif and sh_mobile_sdhi / > tmio_mmc drivers. Changes since v3 are described in respective patches. > Thanks to all who commented on v3. > > Guennadi Liakhovetski (13): > mmc: sdhi, tmio: only check flags in tmio-mmc driver proper > mmc: detailed definition of CD and WP MMC line polarities in DT > mmc: provide a standard MMC device-tree binding parser centrally > mmc: (cosmetic) remove "extern" from function declarations > mmc: sh-mmcif: use mmc_of_parse() to parse standard MMC DT bindings > mmc: tmio-mmc: define device-tree bindings > mmc: tmio-mmc: parse device-tree bindings > mmc: sh_mobile_sdhi: remove unused .pdata field > mmc: sh_mobile_sdhi: use managed resource allocations > mmc: tmio: remove unused and deprecated symbols > mmc: tmio: add support for the VccQ regulator > mmc: add DT bindings for more MMC capability flags > mmc: tmio: add barriers to IO operations Thanks! Pushed to mmc-next, will think about merging for 3.9. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/3] omap_hsmmc DT DMA Client support
Hi Matt, On Fri, Feb 01 2013, Matt Porter wrote: > This series adds DT DMA Engine Client support to the omap_hsmmc. > It leverages the generic DMA OF helpers in -next and the > dma_request_slave_channel_compat() wrapper introduced in the > AM33XX DMA Engine series to support DMA in omap_hsmmc on platforms > booting via DT. These platforms include omap2/3/4/5 and am33xx. > > These patches were split out from the v5 version of the AM33XX DMA > series and split from the EDMA-specific omap_hsmmc changes. Thanks, pushed to mmc-next for 3.9. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] mmc: add BCM2835 driver
Hi Stephen, On Thu, Jan 03 2013, Stephen Warren wrote: > Add a very simple driver for the BCM2835 SoC, which is used in the > Raspberry Pi board. > > Signed-off-by: Stephen Warren Looks good, thanks -- pushed to mmc-next for 3.9. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/2] mmc: add no-1-8-v device tree flag
Hi, On Sun, Nov 25 2012, Daniel Drake wrote: > The OLPC XO-1.75 laptop includes a SDHCI controller which is 1.8v > capable, and it truthfully reports so in its capabilities. This > alternate voltage is used for driving new "UHS-I" SD cards at their > full speed. > > However, what the controller doesn't know is that the motherboard > physically doesn't have a 1.8v supply available, so attempting to > switch to the 1.8v level will result in a situation that cannot be > recovered from without physically replugging the SD card. > > Add a device tree flag that can be used on systems like these, > and hook it up to the equivalent SDHCI quirk. > > Signed-off-by: Daniel Drake Thanks, pushed to mmc-next for 3.8. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/2] sdhci: add quirk for lack of 1.8v support
Hi, On Sun, Nov 25 2012, Daniel Drake wrote: > The OLPC XO-1.75 laptop includes a SDHCI controller which is 1.8v > capable, and it truthfully reports so in its capabilities. This > alternate voltage is used for driving new "UHS-I" SD cards at their > full speed. > > However, what the controller doesn't know is that the motherboard > physically doesn't have a 1.8v supply available. > > Add a quirk so that systems such as this one can override disable > 1.8v support, adding support for UHS-I cards (by running them at > 3.3v). > > This avoids a problem where the system would first try to run the > card at 1.8v, fail, and then not be able to fully reset the card > to retry at the normal 3.3v voltage. > > This is more appropriate than using the MISSING_CAPS quirk, which > is intended for cases where the SDHCI controller is actually lying > about its capabilities, and would force us to somehow override both > caps words from another source. > > Signed-off-by: Daniel Drake Thanks, pushed to mmc-next for 3.8. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2 2/2] mmc: sdhci-spear: Add clk_{un}prepare() support
Hi,
On Fri, Sep 28 2012, Viresh Kumar wrote:
> clk_{un}prepare is mandatory for platforms using common clock framework. Since
> this driver is used by SPEAr platform, which supports common clock framework,
> add clk_{un}prepare() support for it.
>
> Signed-off-by: Viresh Kumar
> ---
> drivers/mmc/host/sdhci-spear.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-spear.c b/drivers/mmc/host/sdhci-spear.c
> index ecad282..6be89c0 100644
> --- a/drivers/mmc/host/sdhci-spear.c
> +++ b/drivers/mmc/host/sdhci-spear.c
> @@ -140,7 +140,7 @@ static int __devinit sdhci_probe(struct platform_device
> *pdev)
> goto err;
> }
>
> - ret = clk_enable(sdhci->clk);
> + ret = clk_prepare_enable(sdhci->clk);
> if (ret) {
> dev_dbg(&pdev->dev, "Error enabling clock\n");
> goto put_clk;
> @@ -260,7 +260,7 @@ set_drvdata:
> free_host:
> sdhci_free_host(host);
> disable_clk:
> - clk_disable(sdhci->clk);
> + clk_disable_unprepare(sdhci->clk);
> put_clk:
> clk_put(sdhci->clk);
> err:
> @@ -282,7 +282,7 @@ static int __devexit sdhci_remove(struct platform_device
> *pdev)
>
> sdhci_remove_host(host, dead);
> sdhci_free_host(host);
> - clk_disable(sdhci->clk);
> + clk_disable_unprepare(sdhci->clk);
> clk_put(sdhci->clk);
>
> return 0;
> @@ -297,7 +297,7 @@ static int sdhci_suspend(struct device *dev)
>
> ret = sdhci_suspend_host(host);
> if (!ret)
> - clk_disable(sdhci->clk);
> + clk_disable_unprepare(sdhci->clk);
>
> return ret;
> }
> @@ -308,7 +308,7 @@ static int sdhci_resume(struct device *dev)
> struct spear_sdhci *sdhci = dev_get_platdata(dev);
> int ret;
>
> - ret = clk_enable(sdhci->clk);
> + ret = clk_prepare_enable(sdhci->clk);
> if (ret) {
> dev_dbg(dev, "Resume: Error enabling clock\n");
> return ret;
Thanks, pushed to mmc-next for 3.7.
- Chris.
--
Chris Ball <http://printf.net/>
One Laptop Per Child
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2 1/2] mmc: sdhci-spear: add device tree bindings
Hi, On Fri, Sep 28 2012, Viresh Kumar wrote: > This adds simple DT bindings for SDHCI SPEAr controller. It uses cd-gpios from > common mmc bindings. > > This also fixes spear300-evb.dts with correct name for card detect binding. > > Signed-off-by: Viresh Kumar > --- > V1->V2: > - Use cd-gpios instead of int-gpio as binding for card detect gpio. > - Fix spear300-evb.dts binding name for cd-gpios > - Removed power-gpio from DT bindings and code, must be handled via regulators > > .../devicetree/bindings/mmc/sdhci-spear.txt| 18 +++ > arch/arm/boot/dts/spear300-evb.dts | 3 +- > arch/arm/boot/dts/spear320-evb.dts | 2 - > drivers/mmc/host/sdhci-spear.c | 57 > +- > 4 files changed, 74 insertions(+), 6 deletions(-) > create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-spear.txt Thanks, pushed to mmc-next for 3.7. It might be possible to remove sdhci-spear.c in the future -- all it's doing at the moment is the card_power_gpio handling (which should be a regulator) and cd-gpio handling (which can be done by core/slot-gpio.c). So perhaps sdhci-pltfm can handle SPEAr hosts directly, once we move the platdata users away from card_power_gpio. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH Resend 1/2] mmc: sdhci-spear: add device tree bindings
Hi,
On Fri, Sep 28 2012, viresh kumar wrote:
>> You should use a fixed regulator instead of this power-gpio hack.
>> It's easy to hook up a fixed regulator to a gpio:
>>
>> vmmc1: fixedregulator@0 {
>> compatible = "regulator-fixed";
>> regulator-name = "fixed-supply";
>> regulator-min-microvolt = <180>;
>> regulator-max-microvolt = <180>;
>> gpio = <&gpio1 16 0>;
>> startup-delay-us = <7>;
>> vin-supply = <&parent_reg>;
>> };
>>
>> and then you can encode the regulator inside your SD host:
>>
>> sdhci@fc00 {
>> compatible = "st,spear300-sdhci";
>> reg = <0xfc00 0x1000>;
>> cd-gpios = <&gpio0 6 0>;
>> vmmc-supply = <&vmmc1>;
>> };
>>
>> and the MMC core will take care of making sure that it's powered up
>> only when needed. What do you think?
>
> We haven't used regulator framework till now for SPEAr and i am not much
> knowledgeable in that.
>
> Because i am not adding this power hack now and it had been there
> since ever, i would request you to take this patchset as is..
>
> @Shiraz: Can you please explore this a bit and provide a separate
> patch for it in future?
I think now is a good time to get the DT bindings right instead of
propagating previous hacks into the DT, and this should be a pretty
simple change -- it's not even a code change, since the code for
automatically handling a vmmc-supply exists already. Once we start
accepting power-gpios properties we can't easily get rid of them later.
If you don't have time to work on this, I guess I could accept the patch
without the power-gpios handling included (since it'll still work with
a DT that provides a vmmc-supply), but I don't want to take the patch
as-is and legitimize the power-gpios binding. Does that make sense?
Thanks,
- Chris.
--
Chris Ball <http://printf.net/>
One Laptop Per Child
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH Resend 1/2] mmc: sdhci-spear: add device tree bindings
Hi Viresh,
On Fri, Sep 28 2012, Viresh Kumar wrote:
> This adds simple DT bindings for SDHCI SPEAr controller. It uses cd-gpios from
> common mmc bindings.
>
> This also fixes spear300-evb.dts with correct name for card detect binding.
>
> Signed-off-by: Viresh Kumar
> ---
> V1->resend:
> - Use cd-gpios instead of int-gpio as binding for card detect gpio.
> - Fix spear300-evb.dts binding name for cd-gpios
>
> .../devicetree/bindings/mmc/sdhci-spear.txt| 28 +
> arch/arm/boot/dts/spear300-evb.dts | 2 +-
> drivers/mmc/host/sdhci-spear.c | 71
> +-
> 3 files changed, 98 insertions(+), 3 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-spear.txt
>
> diff --git a/Documentation/devicetree/bindings/mmc/sdhci-spear.txt
> b/Documentation/devicetree/bindings/mmc/sdhci-spear.txt
> new file mode 100644
> index 000..cd34a05
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/sdhci-spear.txt
> @@ -0,0 +1,28 @@
> +* SPEAr SDHCI Controller
> +
> +Required properties:
> +- compatible : "st,spear300-sdhci"
> +- reg : Address range of the sdhci
> +- interrupt-parent: Should be the phandle for the interrupt controller
> + that services interrupts for this device
> +- interrupt: Should contain the sdhci interrupt number
You don't have to mention reg/interrupts, because they're already
covered in mmc.txt.
> +Optional Properties:
> +- cd-gpios: card detect gpio, with zero flags.
> +- power-gpio: specifies the power gpio pin with flags: active low:1, active
> + high:0
> +- power_always_enb: power should be on before inserting the card and so
> can't be
> + switched off. Only valid when power gpio is supported.
power-gpio should be "power-gpios" (even though there's only one), and
power_always_enb should use hyphens instead of underscores, but I have
a more fundamental request:
You should use a fixed regulator instead of this power-gpio hack.
It's easy to hook up a fixed regulator to a gpio:
vmmc1: fixedregulator@0 {
compatible = "regulator-fixed";
regulator-name = "fixed-supply";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
gpio = <&gpio1 16 0>;
startup-delay-us = <7>;
vin-supply = <&parent_reg>;
};
and then you can encode the regulator inside your SD host:
sdhci@fc00 {
compatible = "st,spear300-sdhci";
reg = <0xfc00 0x1000>;
cd-gpios = <&gpio0 6 0>;
vmmc-supply = <&vmmc1>;
};
and the MMC core will take care of making sure that it's powered up
only when needed. What do you think?
Thanks,
- Chris.
--
Chris Ball <http://printf.net/>
One Laptop Per Child
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v6 8/9] mmc: dw_mmc: add support for implementation specific callbacks
Hi, On Thu, Sep 20 2012, Thomas Abraham wrote: >> In non-Exynos platform, host->drv_data has NULL. > > Yes, sorry, I missed that. > > Chris, should I fix this and send the updated patch or shall I send a > separate fix patch. A separate fix patch would be good, please. (I'd normally take an updated patch but Stephen Rothwell's asked for people to hold off rebasing now that -rc7 is out, which is reasonable.) Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v6 0/9] mmc: dw_mmc: add support for device tree based instantiation
Hi Thomas, On Wed, Sep 19 2012, Thomas Abraham wrote: >> Hi Jaehoon, Seungwon, >> >> All the changes you have suggested for this patch series has been >> completed. If you could ack this series, it would be great. >> >> Thanks, >> Thomas. > > Hi Chris, > > I have addressed all the comments received for the v5 of the dw-mmc > device tree support patch series. Will Newton has acked this patch > series. Can this series be merged for v3.7 ? Yes, looks good; pushed to mmc-next for 3.7. Jaehoon and Seungwon, if you reply soon with your ACK then I'll add it to this patchset. Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v5] mmc: sdhci-s3c: Add device tree support
Hi,
On Mon, Sep 17 2012, Thomas Abraham wrote:
> On 23 August 2012 22:40, Thomas Abraham wrote:
>> Add device tree based discovery support for Samsung's sdhci controller
>>
>> Cc: Ben Dooks
>> Cc: Kukjin Kim
>> Cc: Chris Ball
>> Signed-off-by: Thomas Abraham
>> ---
>> Changes since v4:
>> Adapted to new mmc core card detection bindings as specfied in the patch:
>> [PATCH] mmc: dt: Add card-detection properties to core binding
>> and extends it "samsung,cd-pinmux-gpio" property as suggested by
>> Mitch Bradley
>>
>> Changes since v3:
>>
>> The patch series that adds device tree support for Samsung sdhci controller
>> had six patches in total, of which, the first five patches have been
>> accepted.
>> The sixth patch in the series was dropped since it was using custom Samsung
>> properties for descrbing the bus-width and card-detect gpio, but had
>> otherwise
>> addressed all the comments.
>>
>> This patch reworks the sixth patch in v3 of the sdhci device tree support
>> patch series. The only change in this patch from the v3 version is the use of
>> generic mmc bindings for descrbing the bus-width and card-detect gpio.
>>
>> .../devicetree/bindings/mmc/samsung-sdhci.txt | 53 +++
>> drivers/mmc/host/sdhci-s3c.c | 162
>> +++-
>> 2 files changed, 209 insertions(+), 6 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
>
> Hi Chris,
>
> This patch adds device tree support for sdhci-s3c driver. All the
> comments for this patch has been addressed. Can this be queued for
> v3.7?
Yes, sounds good. Jaehoon, perhaps you could give your Reviewed-by
for me to add to the patch? I've pushed this to mmc-next for 3.7
now, after adding Jaehoon's else-if suggestion that wasn't acted on:
diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index 3d91c7a..0c77b10 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -461,22 +461,18 @@ static int __devinit sdhci_s3c_parse_dt(struct device
*dev,
if (gpio_is_valid(gpio)) {
pdata->cd_type = S3C_SDHCI_CD_GPIO;
goto found_cd;
- } else {
- if (gpio != -ENOENT) {
- dev_err(dev, "invalid card detect gpio specified\n");
- return -EINVAL;
- }
+ } else if (gpio != -ENOENT) {
+ dev_err(dev, "invalid card detect gpio specified\n");
+ return -EINVAL;
}
gpio = of_get_named_gpio(node, "samsung,cd-pinmux-gpio", 0);
if (gpio_is_valid(gpio)) {
pdata->cd_type = S3C_SDHCI_CD_INTERNAL;
goto found_cd;
- } else {
- if (gpio != -ENOENT) {
- dev_err(dev, "invalid card detect gpio specified\n");
- return -EINVAL;
- }
+ } else if (gpio != -ENOENT) {
+ dev_err(dev, "invalid card detect gpio specified\n");
+ return -EINVAL;
}
dev_info(dev, "assuming no card detect line available\n");
Thanks,
- Chris.
--
Chris Ball <http://printf.net/>
One Laptop Per Child
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] mmc: dt: Add card-detection properties to core binding.
Signed-off-by: Chris Ball --- Documentation/devicetree/bindings/mmc/mmc.txt | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt index 8a6811f..8e2e0ba 100644 --- a/Documentation/devicetree/bindings/mmc/mmc.txt +++ b/Documentation/devicetree/bindings/mmc/mmc.txt @@ -9,12 +9,17 @@ Interpreted by the OF core: Required properties: - bus-width: Number of data lines, can be <1>, <4>, or <8> +Card detection: +If no property below is supplied, standard SDHCI card detect is used. +Only one of the properties in this section should be supplied: + - broken-cd: There is no card detection available; polling must be used. + - cd-gpios: Specify GPIOs for card detection, see gpio binding + - non-removable: non-removable slot (like eMMC); assume always present. + Optional properties: -- cd-gpios: Specify GPIOs for card detection, see gpio binding - wp-gpios: Specify GPIOs for write protection, see gpio binding - cd-inverted: when present, polarity on the cd gpio line is inverted - wp-inverted: when present, polarity on the wp gpio line is inverted -- non-removable: non-removable slot (like eMMC) - max-frequency: maximum operating clock frequency Example: -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] mmc: dt: Add 'broken-cd' DT binding
Hi Stephen, On Wed, Aug 22 2012, Stephen Warren wrote: > On 08/22/2012 04:17 AM, Chris Ball wrote: >> Hi, >> >> On Wed, Aug 22 2012, Shawn Guo wrote: >>> The following is what I have on my mind. >>> >>> broken-cd cd-gpiosimplication >>> --- >>> no no SDHCI CD >>> no yes GPIO CD >>> yes no NO CD / Broken CD >>> yes yes Invalid >>> >>> yes: property presents >>> no: property does not present >> >> This matches Mitch's last suggestion exactly -- I think we're all agreed >> on these properties now. The only remaining question is how to handle >> the pinctrl for CD in Thomas's case. > > Sorry if this has already been mentioned, but I assume the standard > non-removable property overrides any of those, or is invalid in > combination with any of those? Yes, absolutely. I'll make sure to explain that in the new version of the document. (I think the reason it hasn't been mentioned much in this thread is that it's already part of the core bindings.) Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] mmc: dt: Add 'broken-cd' DT binding
Hi Thomas, On Wed, Aug 22 2012, Thomas Abraham wrote: >> none -> currently "samsung,sdhci-cd-internal" >> broken-cd -> currently "samsung,sdhci-cd-none" >> cd-gpios -> currently "samsung,sdhci-cd-gpios" >> non-removable -> currently "samsung,sdhci-cd-permanent" >> cd-gpios + samsung,sdhci-cd-external -> currently "samsung,sdhci-cd-external" >> >> How does that sound? > > Not quite there yet. It is not possible to leave out cd-gpios for > "samsung,sdhci-cd-internal" since the current Samsung pinmux > configuration piggybacks on gpio dt binding. Can we use the following > instead. > > none -> currently "samsung,sdhci-cd-none" > broken-cd-> currently "samsung,sdhci-cd-none" > cd-gpios -> currently "samsung,sdhci-cd-gpios" > non-removable -> currently "samsung,sdhci-cd-permanent" > cd-gpios + samsung,sdhci-cd-internal -> currently "samsung,sdhci-cd-internal" I see. Okay; unless anyone has better ideas, it sounds like you should go ahead and do that -- with something like this in your binding docs: "This binding differs from the core MMC binding by requiring a cd-gpios property to be present to use internal card-detection. If no cd-gpios are present (and "non-removable" is missing) the driver will poll for card-detection as if a "broken-cd" property was provided." I'll send out the new core bindings doc shortly. Finishing off another thread -- the "samsung-sdhci.txt" name is okay. Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] mmc: dt: Add 'broken-cd' DT binding
Hi Shawn, On Wed, Aug 22 2012, Shawn Guo wrote: > mmc: sdhci: Always pass clock request value zero to set_clock host op > > To allow the set_clock host op to disable the SDCLK source when not > needed, always call the host op when the requested clock speed is > zero. Do this even if host->clock already equals zero, because > the SDHCI driver may set that value (without calling the host op) > to force an update at the next (non-zero-speed) call. > > Signed-off-by: Todd Poynor > Acked-by: Adrian Hunter > Signed-off-by: Chris Ball > > Reverting the commit will get "controller" mode back to work. Weird; I wonder how that's related to card detection. I'm afraid it's ultimately a driver bug -- esdhc should be able to handle having set_clock called with a value of 0. It seems to have a case in esdhc_set_clock() for 0, so I'm surprised it's not working. What's the symptom of the failure? Can you debug some more? Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] mmc: dt: Add 'broken-cd' DT binding
Hi Thomas, On Wed, Aug 22 2012, Thomas Abraham wrote: >> This matches Mitch's last suggestion exactly -- I think we're all agreed >> on these properties now. The only remaining question is how to handle >> the pinctrl for CD in Thomas's case. > > Hi Chris, > > For sdhci-s3c driver, the 'broken-cd' and 'cd-gpios' bindings are > sufficient. But, are drivers free to use implementation specific > behavior when using these bindings. Or do we strictly adhere to the > table which Shawn has listed. For sdhci-s3c driver, I would like to > deviate from the "implication" column listed above. I'd rather you use the implications described above for the names described above; there's not much point in defining named behaviors across the subsystem if they're actually different in each driver. But I think you can still use driver-internal properties that change the interpretation of those names in a documented way. If the meaning of cd-gpios is modified when coupled with your "samsung,sdhci-cd-external", that's okay with me. That should cover all the cases you need until you migrate to using pinctrl, right? So, you could immediately support: none -> currently "samsung,sdhci-cd-internal" broken-cd -> currently "samsung,sdhci-cd-none" cd-gpios -> currently "samsung,sdhci-cd-gpios" non-removable -> currently "samsung,sdhci-cd-permanent" cd-gpios + samsung,sdhci-cd-external -> currently "samsung,sdhci-cd-external" How does that sound? Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] mmc: dt: Add 'broken-cd' DT binding
Hi, On Wed, Aug 22 2012, Shawn Guo wrote: > The following is what I have on my mind. > > broken-cd cd-gpiosimplication > --- > nono SDHCI CD > noyes GPIO CD > yes no NO CD / Broken CD > yes yes Invalid > > yes: property presents > no: property does not present This matches Mitch's last suggestion exactly -- I think we're all agreed on these properties now. The only remaining question is how to handle the pinctrl for CD in Thomas's case. Thanks! - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] mmc: dt: Add 'broken-cd' DT binding
Hi, On Tue, Aug 21 2012, Rob Herring wrote: >> cd-gpios and cd-external can be present on the same node. if broken-cd >> is present, it must be the only one of these nodes used. > > I don't see the point of cd-external. Either you just use the CD > interrupt defined within the SDHCI or you have a gpio line independent > of the SDHCI and use cd-gpios. You've described two of the possible cases, but not the third. In the third case, you have a gpio line that is not independent of the SDHCI, because it is the SDHCI's CD pin brought out to be directly accessible via a GPIO. The difference is in the handling of the interrupt -- if you don't have "cd-external" then you're just using the SDHCI's interrupt, but if you have an independent line then you're going to need to register your own IRQ handler on it, and "cd-external" signifies that. Thomas wrote this explanation earlier in the thread: > "samsung,sdhci-cd-gpio" means that the cd-gpio line is not connected > to the card-detect pad of the sdhci controller. Instead, it identifies > cd-gpio as a gpio pin, connected to the card-detect pin of the "card > slot" and it can used as a source of external interrupt. The driver > can register card insert/remove handler for this interrupt and get > notified about the changes in card state. > > "sdhci-cd-internal" means that the "cd-gpio" line is used to connect > the card-detect pin of the card slot and the card-detect pad of the > sdhci controller. The controller is then aware of any changes in card > state and the controller generates appropriate interrupts to notify > changes in card-state. Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] mmc: dt: Add 'broken-cd' DT binding
Hi, adding Shawn and Wolfram,
On Tue, Aug 21 2012, Arnd Bergmann wrote:
> On Tuesday 21 August 2012, Chris Ball wrote:
>> How about this?
>>
>> broken-cd: No CD available, use polling.
>>
>> cd-gpios: The CD pin on the host is working and brought out to a GPIO.
>>
>> external-cd-gpios: The CD pin on the host is broken, but there's an
>>independent external GPIO available.
>>
>>
>> (Each host should only have one of these properties.)
>
> The fsl-imx-esdhc.txt binding already has all three cases, but
> describes them differently:
>
> fsl,cd-internal: when present, the CD pin on the host is working
> cd-gpios: when present, contains the gpio line that CD is connected to
> If both are absent, it has to use polling.
Aside: the bindings do not match the code. The bindings document says
to use "fsl,cd-internal", and imx51-babbage.dts does so -- but the code
doesn't check for "fsl,cd-internal", it checks for "fsl,cd-controller":
if (of_get_property(np, "fsl,cd-controller", NULL))
boarddata->cd_type = ESDHC_CD_CONTROLLER;
The same confusion is present for fsl,wp-{controller,internal}.
Ignoring that, these bindings are similar, but not the same -- imx-esdhc
only allows one of the cd_type cases to be true, so you either have
cd-internal or you have cd-gpios:
if (of_get_property(np, "fsl,cd-controller", NULL))
boarddata->cd_type = ESDHC_CD_CONTROLLER;
boarddata->cd_gpio = of_get_named_gpio(np, "cd-gpios", 0);
if (gpio_is_valid(boarddata->cd_gpio))
boarddata->cd_type = ESDHC_CD_GPIO;
This differs from Thomas's binding -- he wants a way to say "the cd-gpio
mentioned in cd-gpios is [internal/external] to the card's CD pin".
Rob Herring said:
> This makes the most sense to me. However, I prefer broken-cd over
> cd-internal. The binding should add properties for exceptions, not SDHCI
> spec compliant implementations.
Agreed, I was going to say the same thing. Putting it all together, it
sounds like we want:
no extra properties: the CD pin on the host just works.
broken-cd:the CD pin on the host is broken; use polling.
cd-gpios: the GPIO listed is the CD pin on the host being
brought out directly to a GPIO.
cd-external: when used with cd-gpios, specifies that the GPIO
in cd-gpios is external to the CD pin on the host.
cd-gpios and cd-external can be present on the same node. if broken-cd
is present, it must be the only one of these nodes used.
Shawn, I guess I'll leave it up to you on whether/when you'd like to
move away from the "fsl," properties to the new common ones?
If this looks okay to everyone, I'll send a patch soon.
Thanks!
- Chris.
--
Chris Ball <http://printf.net/>
One Laptop Per Child
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] mmc: dt: Add 'broken-cd' DT binding
Hi, On Tue, Aug 21 2012, Thomas Abraham wrote: > I am trying to have a way to represent a gpio line as card detect line > that is not connected to the card-detect pad of the mmc controller but > instead used as a gpio interrupt line or polled gpio line. > > 'broken-cd' would imply that the card-detect pad of the mmc controller > is not connected to the card-detect pin at the slot. The 'cd-gpios' > property in that case would let the driver code to use the 'cd-gpios' > line as the external gpio interrupt or poll it. How about this? broken-cd: No CD available, use polling. cd-gpios: The CD pin on the host is working and brought out to a GPIO. external-cd-gpios: The CD pin on the host is broken, but there's an independent external GPIO available. (Each host should only have one of these properties.) Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] mmc: dt: Add 'broken-cd' DT binding
Hi, On Tue, Aug 21 2012, Arnd Bergmann wrote: > On Tuesday 21 August 2012, Thomas Abraham wrote: >> diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt >> b/Documentation/devicetree/bindings/mmc/mmc.txt >> index 8a6811f..1aa527a 100644 >> --- a/Documentation/devicetree/bindings/mmc/mmc.txt >> +++ b/Documentation/devicetree/bindings/mmc/mmc.txt >> @@ -16,6 +16,8 @@ Optional properties: >> - wp-inverted: when present, polarity on the wp gpio line is inverted >> - non-removable: non-removable slot (like eMMC) >> - max-frequency: maximum operating clock frequency >> +- broken-cd: when present, indicates that the cd-gpios line is not >> + connected to the card-detect pad of the MMC host controller. > > What is the difference between listing the cd line as broken and > listing no cd line at all? I think the documentation's incorrect here -- "broken-cd" should be used without a cd-gpios node, and tells the driver that there is no working WP and we'll need to poll the host (SDHCI_QUIRK_BROKEN_CARD_DETECTION): diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c index 25733ef..23ebdbb 100644 --- a/drivers/mmc/host/sdhci-pxav3.c +++ b/drivers/mmc/host/sdhci-pxav3.c @@ -198,6 +198,9 @@ static struct sdhci_pxa_platdata *pxav3_get_mmc_pdata(struct device *dev) if (clk_delay_cycles > 0) pdata->clk_delay_cycles = clk_delay_cycles; + if (of_find_property(np, "broken-cd", NULL)) + pdata->quirks |= SDHCI_QUIRK_BROKEN_CARD_DETECTION; + return pdata; } #else So, I'd say: "- broken-cd: when present, indicates that there is no card-detect line available on the host; polling should be used instead." Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] mmc: sdhci-s3c: Add device tree support
Hi Thomas, On Thu, Aug 16 2012, Thomas Abraham wrote: > +Optional Board Specific Properties: > +- One of the following properties for card detect type. > + - samsung,sdhci-cd-internal: Card detect line from the card slot is > +connected to the card detect pad of the sdhci controller. A gpio is > +used for this connection (with possible pin function settings). > + - samsung,sdhci-cd-gpio: A gpio line (with possible pin function settings) > +is used a card detect line. This gpio line is not connected to card > detect > +pad of the sdhci controller. > + - samsung,sdhci-cd-none: There is no card detect line. Polling is used to > +detect the presence of the card. (DEFAULT, if no card detect property > +is specified). > + - samsung,sdhci-cd-permanent: There is no card detect line. The card is > +permanently connected to the sdhci controller. sdhci-s3c isn't the only driver that's going to have options for different cd configurations -- maybe now is the right time to move these options into the core bindings? At OLPC we've just started using: * "broken-cd" to mean "samsung,sdhci-cd-none", * the presence of a "cd-gpios" property to imply "samsung,sdhci-cd-gpio". * "non-removable" to mean "samsung,sdhci-cd-permanent" (this is already specified in mmc.txt) Would these work for you? We don't have a distinction between sdhci-cd-internal and sdhci-cd-gpio, and I'm having trouble working out why one is necessary. Why does the driver need to know where the gpio came from, aside from knowing which gpio it is and whether it needs to be inverted (with cd-inverted)? Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] mmc: sdhci-s3c: Add device tree support
Hi,
On Thu, Aug 16 2012, Thomas Abraham wrote:
> Add device tree based discovery support for Samsung's sdhci controller
>
> Cc: Ben Dooks
> Cc: Kukjin Kim
> Cc: Chris Ball
> Signed-off-by: Thomas Abraham
> ---
> Changes since v3:
>
> The patch series that adds device tree support for Samsung sdhci controller
> had six patches in total, of which, the first five patches have been accepted.
> The sixth patch in the series was dropped since it was using custom Samsung
> properties for descrbing the bus-width and card-detect gpio, but had otherwise
> addressed all the comments.
>
> This patch reworks the sixth patch in v3 of the sdhci device tree support
> patch series. The only change in this patch from the v3 version is the use of
> generic mmc bindings for descrbing the bus-width and card-detect gpio.
>
> .../devicetree/bindings/mmc/samsung-sdhci.txt | 51 +++
> drivers/mmc/host/sdhci-s3c.c | 146
> +++-
> 2 files changed, 191 insertions(+), 6 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
>
> diff --git a/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
> b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
> new file mode 100644
> index 000..398540b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
> @@ -0,0 +1,51 @@
> +* Samsung's SDHCI Controller device tree bindings
> +
> +Samsung's SDHCI controller is used as a connectivity interface with external
> +MMC, SD and eMMC storage mediums. This file documents differences between the
> +core mmc properties described by mmc.txt and the properties used by the
> +Samsung implmentation of the SDHCI controller.
> +
> +Required SoC Specific Properties:
> +- compatible: should be one of the following
> + - "samsung,s3c6410-sdhci": For controllers compatible with s3c6410 sdhci
> +controller.
> + - "samsung,exynos4210-sdhci": For controllers compatible with Exynos4 sdhci
> +controller.
> +
> +Required Board Specific Properties:
> +- gpios: Should specify the gpios used for clock, command and data lines. The
> + gpio specifier format depends on the gpio controller.
> +
> +Optional Board Specific Properties:
> +- One of the following properties for card detect type.
> + - samsung,sdhci-cd-internal: Card detect line from the card slot is
> +connected to the card detect pad of the sdhci controller. A gpio is
> +used for this connection (with possible pin function settings).
> + - samsung,sdhci-cd-gpio: A gpio line (with possible pin function settings)
> +is used a card detect line. This gpio line is not connected to card
> detect
> +pad of the sdhci controller.
> + - samsung,sdhci-cd-none: There is no card detect line. Polling is used to
> +detect the presence of the card. (DEFAULT, if no card detect property
> +is specified).
> + - samsung,sdhci-cd-permanent: There is no card detect line. The card is
> +permanently connected to the sdhci controller.
> +
> +Example:
> + sdhci@1253 {
> + compatible = "samsung,exynos4210-sdhci";
> + reg = <0x1253 0x100>;
> + interrupts = <<0 75 0>;
> + bus-width = <4>;
> + samsung,sdhci-cd-internal;
> + cd-gpios = <&gpk2 2 2 3 3>;
> + gpios = <&gpk2 0 2 0 3>, /* clock line */
> + <&gpk2 1 2 0 3>, /* command line */
> + <&gpk2 3 2 3 3>, /* data line 0 */
> + <&gpk2 4 2 3 3>, /* data line 1 */
> + <&gpk2 5 2 3 3>, /* data line 2 */
> + <&gpk2 6 2 3 3>; /* data line 3 */
> + };
> +
> + Note: This example shows both SoC specific and board specific properties
> + in a single device node. The properties can be actually be seperated
> + into SoC specific node and board specific node.
Looks good, except the text file doesn't mention anywhere that it describes
the bindings used by sdhci-s3c.c -- that could be useful information to
someone reading the binding and trying to discover which driver uses it.
Maybe we can call the text file "sdhci-s3c.txt"? Or "samsung,sdhci-s3c.txt"
if you prefer.
Thanks,
- Chris.
--
Chris Ball <http://printf.net/>
One Laptop Per Child
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] mmc: sdhci-s3c: Add device tree support
Hi Thomas, On Thu, Aug 16 2012, Thomas Abraham wrote: > Add device tree based discovery support for Samsung's sdhci controller > > Cc: Ben Dooks > Cc: Kukjin Kim > Cc: Chris Ball > Signed-off-by: Thomas Abraham > --- > drivers/mmc/host/sdhci-s3c.c | 146 > -- > 1 files changed, 140 insertions(+), 6 deletions(-) I know your initial version was submitted before we adopted a set of standard MMC DT bindings, but now that those bindings exist this code should be using them -- there should be a new file: Documentation/devicetree/bindings/mmc/sdhci-s3c.txt describing differences between the mmc.txt bindings and this driver's. Also, you didn't include a patch changelog, so I can't tell whether this contains changes against your v3 of this patch; please do that. Thanks! - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 1/1] ARM: dove: DT support for sdhci-dove
Hi Sebastian, On Tue, Jul 31 2012, Sebastian Hesselbarth wrote: > This patch adds device tree support and binding documentiation for > sdhci-dove. > > v2: extended documentation and removed second interrupt as it is marked > 'reserved' in dove datasheet. > > Signed-off-by: Sebastian Hesselbarth > Cc: Grant Likely > Cc: Rob Herring > Cc: Rob Landley > Cc: Chris Ball > Cc: Anton Vorontsov > Cc: Manuel Lauss > Cc: David Brown > Cc: Andrew Lunn > Cc: devicetree-discuss@lists.ozlabs.org > Cc: linux-...@vger.kernel.org > Cc: linux-ker...@vger.kernel.org > Cc: linux-...@vger.kernel.org > > --- Looks good, pushed to mmc-next for 3.7. In future, please use the area just below the "---" to describe your patch changelog v1->v2; that way it won't go into the commit message in git. Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: linux-next: manual merge of the arm-soc tree with the i2c-embedded tree
Hi, On Mon, Jul 16 2012, Linus Walleij wrote: >> Uhm, I seem to have missed that bindings are deemed more "flexible" as >> long as they are coupled to in-kernel dts files? Is that discussed >> somewhere? I do wonder about it... > > Well patches like this are sent out but not commented on from > the perspective of binding stability. So of course, they get merged. > > Have a look at this commit: > > commit 7f217794ffa72f208a250b79ab0b7ea3de19677f > Author: Arnd Bergmann > Date: Sun May 13 00:14:24 2012 -0400 > > mmc: dt: Consolidate DT bindings > > This is deleting custom properties from DTS files without > adding any code to fallback-support them on old device trees. I agree with your point, but just as an FYI: this patch did involve a conversation about binding stability, and left some attributes (e.g. ti,non-removable) purposefully alone (and different to the new generic MMC bindings) to preserve backwards compatibility: http://article.gmane.org/gmane.linux.kernel.samsung-soc/10409 Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 5/6] mmc: dw_mmc: add device tree support
Hi, On Thu, Jul 12 2012, Thomas Abraham wrote: > diff --git a/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt > b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt > new file mode 100644 > index 000..3acd6c9 > --- /dev/null > +++ b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt > @@ -0,0 +1,108 @@ > +* Synopsis Designware Mobile Storage Host Controller > + > +The Synopsis designware mobile storage host controller is used to interface > +a SoC with storage medium such as eMMC or SD/MMC cards. > + > +Required Properties: > + > +* compatible: should be one of the following > + - snps,dw-mshc: for controllers compliant with synopsis dw-mshc. > + > +* reg: physical base address of the dw-mshc controller and size of its memory > + region. > + > +* interrupts: interrupt specifier for the controller. The format and value of > + the interrupt specifier depends on the interrupt parent for the controller. Please instead add: This file documents differences between the core properties described by mmc.txt and the properties used by the dw_mmc driver. mmc.txt already describes compatible, reg, interrupts, bus-width, cd-gpios, and wp-gpios, so you don't need to describe those again. > + cnt = sizeof(of_quriks) / sizeof(struct dw_mci_of_quirks); > + for (idx = 0; idx < cnt; idx++) > + if (of_get_property(np, of_quriks[idx].quirk, NULL)) > + pdata->quirks |= of_quriks[idx].id; of_quirks, not of_quriks. Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 02/02] clk: clk-of: Use alloc_bootmem() instead of kzalloc()
When of_clk_add_provider() is used at boot time (during .init_early on
ARM, in the motivating case for this patch), kzalloc() cannot be used
because slab isn't up yet.
Signed-off-by: Chris Ball
---
drivers/clk/clk-of.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clk-of.c b/drivers/clk/clk-of.c
index 8b43416..adbb56b 100644
--- a/drivers/clk/clk-of.c
+++ b/drivers/clk/clk-of.c
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_OF
@@ -67,7 +68,7 @@ int of_clk_add_provider(struct device_node *np,
{
struct of_clk_provider *cp;
- cp = kzalloc(sizeof(struct of_clk_provider), GFP_KERNEL);
+ cp = alloc_bootmem(sizeof(struct of_clk_provider));
if (!cp)
return -ENOMEM;
--
Chris Ball <http://printf.net/>
One Laptop Per Child
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 01/02] clk: Refactor of_clk_* into a new clk-of.c
This removes the dependency on CONFIG_COMMON_CLK, which is unnecessary
for the of_clk_* functions -- these functions are passed a struct clk,
which can either be a COMMON_CLK struct or an arch-specific one.
Signed-off-by: Chris Ball
---
drivers/clk/Makefile |2 +
drivers/clk/clk-of.c | 167 ++
drivers/clk/clk.c| 139 ---
include/linux/clk-provider.h | 14
include/linux/clk.h | 17 -
5 files changed, 184 insertions(+), 155 deletions(-)
create mode 100644 drivers/clk/clk-of.c
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 553b30b..9584801 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -2,6 +2,8 @@
obj-$(CONFIG_CLKDEV_LOOKUP)+= clkdev.o
obj-$(CONFIG_COMMON_CLK) += clk.o clk-fixed-rate.o clk-gate.o \
clk-mux.o clk-divider.o clk-fixed-factor.o
+obj-$(CONFIG_OF) += clk-of.o
+
# SoCs specific
obj-$(CONFIG_ARCH_MXS) += mxs/
obj-$(CONFIG_PLAT_SPEAR) += spear/
diff --git a/drivers/clk/clk-of.c b/drivers/clk/clk-of.c
new file mode 100644
index 000..8b43416
--- /dev/null
+++ b/drivers/clk/clk-of.c
@@ -0,0 +1,167 @@
+/*
+ * Copyright 2011-2012 Calxeda, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#ifdef CONFIG_OF
+
+struct of_device_id;
+
+typedef void (*of_clk_init_cb_t)(struct device_node *);
+/**
+ * struct of_clk_provider - Clock provider registration structure
+ * @link: Entry in global list of clock providers
+ * @node: Pointer to device tree node of clock provider
+ * @get: Get clock callback. Returns NULL or a struct clk for the
+ * given clock specifier
+ * @data: context pointer to be passed into @get callback
+ */
+struct of_clk_provider {
+ struct list_head link;
+
+ struct device_node *node;
+ struct clk *(*get)(struct of_phandle_args *clkspec, void *data);
+ void *data;
+};
+
+static LIST_HEAD(of_clk_providers);
+static DEFINE_MUTEX(of_clk_lock);
+
+struct clk *of_clk_src_simple_get(struct of_phandle_args *clkspec,
+void *data)
+{
+ return data;
+}
+EXPORT_SYMBOL_GPL(of_clk_src_simple_get);
+
+/**
+ * of_clk_add_provider() - Register a clock provider for a node
+ * @np: Device node pointer associated with clock provider
+ * @clk_src_get: callback for decoding clock
+ * @data: context pointer for @clk_src_get callback.
+ */
+int of_clk_add_provider(struct device_node *np,
+ struct clk *(*clk_src_get)(struct of_phandle_args
*clkspec,
+ void *data),
+ void *data)
+{
+ struct of_clk_provider *cp;
+
+ cp = kzalloc(sizeof(struct of_clk_provider), GFP_KERNEL);
+ if (!cp)
+ return -ENOMEM;
+
+ cp->node = of_node_get(np);
+ cp->data = data;
+ cp->get = clk_src_get;
+
+ mutex_lock(&of_clk_lock);
+ list_add(&cp->link, &of_clk_providers);
+ mutex_unlock(&of_clk_lock);
+ pr_debug("Added clock from %s\n", np->full_name);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_clk_add_provider);
+
+/**
+ * of_clk_del_provider() - Remove a previously registered clock provider
+ * @np: Device node pointer associated with clock provider
+ */
+void of_clk_del_provider(struct device_node *np)
+{
+ struct of_clk_provider *cp;
+
+ mutex_lock(&of_clk_lock);
+ list_for_each_entry(cp, &of_clk_providers, link) {
+ if (cp->node == np) {
+ list_del(&cp->link);
+ of_node_put(cp->node);
+ kfree(cp);
+ break;
+ }
+ }
+ mutex_unlock(&of_clk_lock);
+}
+EXPORT_SYMBOL_GPL(of_clk_del_provider);
+
+struct clk *of_clk_get_from_provider(struct of_phandle_args *clkspec)
+{
+ struct of_clk_provider *provider;
+ struct clk *clk = NULL;
+
+ /* Check if we have such a provider in our array */
+ mutex_lock(&of_clk_lock);
+ list_for_each_entry(provider, &of_clk_providers, link) {
+ if (provider->node == clkspec->np)
+ clk = provider
Re: [PATCH v3 0/4] DT clock bindings
Hi Rob, On Tue, Jun 12 2012, Rob Herring wrote: > This series defines clock bindings for Device-Tree and adds kernel > support using the common clock infrastructure. The last patch enables > DT clock support for the Calxeda Highbank platform. > > I'm posting this again to solicit further review. There has been some > discussion[1], but no definite path forward. This series is not changed > from the last post other than rebasing to v3.5-rc2. This is a very useful patchset, thanks! Mitch Bradley and I have been hooking up the mach-mmp ARM subarchitecture to it and we needed to make a few changes, mainly because mach-mmp doesn't use COMMON_CLK. The changes are: 1) Remove the COMMON_CLK dependency that the of_clk_* functions have by moving them into a new file, drivers/clk/clk-of.c. The OF functions in drivers/clk/clk.c aren't dependent on anything else in clk.c (since you pass them a struct clk) so they can be moved out easily. The of_clk_* entries in clk-provider.h move to clk.h. 2) Use alloc_bootmem() instead of kzalloc() in of_clk_add_provider(), because we need to set up clocks during .init_early on ARM (which happens pre-slab) so that they are available for platform init. I'll send our patches in a reply to this mail. Are you okay with these changes, and would you like to include them in your patchset? Thanks very much, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] mmc: sdhci-pxa: Add device tree support
Tested on an OLPC XO-1.75. (MMP2, sdhci-pxav3, CONFIG_MACH_MMP2_DT=y)
Signed-off-by: Chris Ball
---
Changes since v1:
* Add CONFIG_OF guard around of_match_table, per Zhangfei.
* Fix function prototypes under !CONFIG_OF, per Zhangfei.
* Change "clk-delay-cycles" to "mrvl,clk-delay-cycles", per Haojian.
.../devicetree/bindings/mmc/sdhci-pxa.txt | 21
drivers/mmc/host/sdhci-pxav2.c | 54
drivers/mmc/host/sdhci-pxav3.c | 52 +++
3 files changed, 127 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
new file mode 100644
index 000..1eb227f
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
@@ -0,0 +1,21 @@
+* Marvell sdhci-pxa v2/v3 controller
+
+This file documents differences between the core properties in mmc.txt
+and the properties used by the sdhci-pxav2 and sdhci-pxav3 drivers.
+
+Required properties:
+- compatible: Should be "mrvl,pxav2-mmc" or "mrvl,pxav3-mmc".
+
+Optional properties:
+- mrvl,clk-delay-cycles: Specify a number of cycles to delay for tuning.
+
+Example:
+
+sdhci@d4280800 {
+ compatible = "mrvl,pxav3-mmc";
+ reg = <0xd4280800 0x800>;
+ interrupts = <27>;
+ bus-width = <8>;
+ mrvl,clk-delay-cycles = <31>;
+ non-removable;
+};
diff --git a/drivers/mmc/host/sdhci-pxav2.c b/drivers/mmc/host/sdhci-pxav2.c
index dbb75bf..b6ee885 100644
--- a/drivers/mmc/host/sdhci-pxav2.c
+++ b/drivers/mmc/host/sdhci-pxav2.c
@@ -28,6 +28,9 @@
#include
#include
#include
+#include
+#include
+
#include "sdhci.h"
#include "sdhci-pltfm.h"
@@ -121,6 +124,48 @@ static struct sdhci_ops pxav2_sdhci_ops = {
.platform_8bit_width = pxav2_mmc_set_width,
};
+#ifdef CONFIG_OF
+static const struct of_device_id sdhci_pxav2_of_match[] = {
+ {
+ .compatible = "mrvl,pxav2-mmc",
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, sdhci_pxav2_of_match);
+
+static struct sdhci_pxa_platdata *pxav2_get_mmc_pdata(struct device *dev)
+{
+ struct sdhci_pxa_platdata *pdata;
+ struct device_node *np = dev->of_node;
+ u32 bus_width;
+ u32 clk_delay_cycles;
+
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return NULL;
+
+ if (of_find_property(np, "non-removable", NULL))
+ pdata->flags |= PXA_FLAG_CARD_PERMANENT;
+
+ of_property_read_u32(np, "bus-width", &bus_width);
+ if (bus_width == 8)
+ pdata->flags |= PXA_FLAG_SD_8_BIT_CAPABLE_SLOT;
+
+ of_property_read_u32(np, "mrvl,clk-delay-cycles", &clk_delay_cycles);
+ if (clk_delay_cycles > 0) {
+ pdata->clk_delay_sel = 1;
+ pdata->clk_delay_cycles = clk_delay_cycles;
+ }
+
+ return pdata;
+}
+#else
+static inline struct sdhci_pxa_platdata *pxav2_get_mmc_pdata(struct device
*dev)
+{
+ return NULL;
+}
+#endif
+
static int __devinit sdhci_pxav2_probe(struct platform_device *pdev)
{
struct sdhci_pltfm_host *pltfm_host;
@@ -128,6 +173,8 @@ static int __devinit sdhci_pxav2_probe(struct
platform_device *pdev)
struct device *dev = &pdev->dev;
struct sdhci_host *host = NULL;
struct sdhci_pxa *pxa = NULL;
+ const struct of_device_id *match;
+
int ret;
struct clk *clk;
@@ -156,6 +203,10 @@ static int __devinit sdhci_pxav2_probe(struct
platform_device *pdev)
| SDHCI_QUIRK_BROKEN_TIMEOUT_VAL
| SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN;
+ match = of_match_device(of_match_ptr(sdhci_pxav2_of_match), &pdev->dev);
+ if (match) {
+ pdata = pxav2_get_mmc_pdata(dev);
+ }
if (pdata) {
if (pdata->flags & PXA_FLAG_CARD_PERMANENT) {
/* on-chip device */
@@ -218,6 +269,9 @@ static struct platform_driver sdhci_pxav2_driver = {
.driver = {
.name = "sdhci-pxav2",
.owner = THIS_MODULE,
+#ifdef CONFIG_OF
+ .of_match_table = sdhci_pxav2_of_match,
+#endif
.pm = SDHCI_PLTFM_PMOPS,
},
.probe = sdhci_pxav2_probe,
diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index f296956..cb8be1d 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -28,6 +28,9 @@
#include
#include
#include
+#include
+#include
+
#include "sdhci.h"
#include "sdhci-pltfm.h"
@@ -164,6 +167,46 @@ static struct sdhci_ops pxav3_sdhci_ops
Re: [PATCH] mmc: sdhci-pxa: Add device tree support
Hi Haojian, On Wed, Jun 13 2012, haojian.zhu...@gmail.com wrote: > Compatible node could be "mrvl,pxav3-mmc" or "mrvl,sdhci-pxav3". It's > depend on your choice. I prefer to use vendor name in compatible > property. > And we could avoid naming conflict. Okay, I'll just stick with mrvl,pxav3-mmc. > + if (of_find_property(np, "non-removable", NULL)) > + pdata->flags |= PXA_FLAG_CARD_PERMANENT; > + > + of_property_read_u32(np, "bus-width", &bus_width); > + if (bus_width == 8) > + pdata->flags |= PXA_FLAG_SD_8_BIT_CAPABLE_SLOT; > + > + of_property_read_u32(np, "clk-delay-cycles", &clk_delay_cycles); > + if (clk_delay_cycles > 0) > + pdata->clk_delay_cycles = clk_delay_cycles; > + > > These properties should be "mrvl,non-removable", "mrvl,bus-width", > "mrvl,clk-delay-cycles". Since it's mentioned in > Documentations/devicetree/booting-without-of.txt. "It is recommended > that if you add any "custom" property whose name may clash with > standard defined ones, you prefix them with your vendor name and > a comma." Not quite -- the "non-removable" and "bus-width" properties are part of the MMC core DT bindings as defined in: Documentation/devicetree/bindings/mmc/mmc.txt They are not custom Marvell properties. So, these two need to stay as they are (one day we'll interpret them in the sdhci driver instead of in sdhci-pxa) but I've changed clk_delay_cycles to mrvl,clk_delay_cycles in v2 of the patch, which I'm about to send out. I also applied all of Zhangfei's changes. Thanks for the review! - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] mmc: sdhci-pxa: Add device tree support
Hi Zhangfei,
On Tue, Jun 12 2012, zhangfei gao wrote:
> On Wed, Jun 13, 2012 at 3:05 AM, Chris Ball wrote:
>> Tested on an OLPC XO-1.75. Â (MMP2, sdhci-pxav3, CONFIG_MACH_MMP2_DT=y)
>>
>> Signed-off-by: Chris Ball
>> ---
>>  .../devicetree/bindings/mmc/sdhci-pxa.txt      |  21
>>  drivers/mmc/host/sdhci-pxav2.c           |  52
>>
>>  drivers/mmc/host/sdhci-pxav3.c           |  50
>> +++
>> Â 3 files changed, 123 insertions(+)
>> Â create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
>
> Thanks Chris for the great help, compile error if CONFIG_OF not defined.
Thanks for catching this!
How do you feel about having the compatible node say "sdhci-pxav3"
instead of "mrvl,pxav3-mmc"? I used the mrvl prefix because it fits
in with the rest of your existing DT, but it seems like it would be
better to name the driver directly. The DTs here live inside the
source tree, so we're not depending on anyone else's terminology.
If you're okay with sdhci-pxav{2,3} in compatible, I'll include that
in v2 of the patch with the rest of your fixes.
- Chris.
--
Chris Ball <http://printf.net/>
One Laptop Per Child
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] mmc: sdhci-pxa: Add device tree support
Tested on an OLPC XO-1.75. (MMP2, sdhci-pxav3, CONFIG_MACH_MMP2_DT=y)
Signed-off-by: Chris Ball
---
.../devicetree/bindings/mmc/sdhci-pxa.txt | 21
drivers/mmc/host/sdhci-pxav2.c | 52
drivers/mmc/host/sdhci-pxav3.c | 50 +++
3 files changed, 123 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
new file mode 100644
index 000..5896c24
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
@@ -0,0 +1,21 @@
+* Marvell sdhci-pxa v2/v3 controller
+
+This file documents differences between the core properties in mmc.txt
+and the properties used by the sdhci-pxav2 and sdhci-pxav3 drivers.
+
+Required properties:
+- compatible: Should be "mrvl,pxav2-mmc" or "mrvl,pxav3-mmc".
+
+Optional properties:
+- clk-delay-cycles: Specify a number of cycles to delay for tuning.
+
+Example:
+
+sdhci@d4280800 {
+ compatible = "mrvl,pxav3-mmc";
+ reg = <0xd4280800 0x800>;
+ interrupts = <27>;
+ bus-width = <8>;
+ clk-delay-cycles = <31>;
+ non-removable;
+};
diff --git a/drivers/mmc/host/sdhci-pxav2.c b/drivers/mmc/host/sdhci-pxav2.c
index dbb75bf..b4b1c1d 100644
--- a/drivers/mmc/host/sdhci-pxav2.c
+++ b/drivers/mmc/host/sdhci-pxav2.c
@@ -28,6 +28,9 @@
#include
#include
#include
+#include
+#include
+
#include "sdhci.h"
#include "sdhci-pltfm.h"
@@ -121,6 +124,48 @@ static struct sdhci_ops pxav2_sdhci_ops = {
.platform_8bit_width = pxav2_mmc_set_width,
};
+#ifdef CONFIG_OF
+static const struct of_device_id sdhci_pxav2_of_match[] = {
+ {
+ .compatible = "mrvl,pxav2-mmc",
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, sdhci_pxav2_of_match);
+
+static struct sdhci_pxa_platdata *pxav2_get_mmc_pdata(struct device *dev)
+{
+ struct sdhci_pxa_platdata *pdata;
+ struct device_node *np = dev->of_node;
+ u32 bus_width;
+ u32 clk_delay_cycles;
+
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return NULL;
+
+ if (of_find_property(np, "non-removable", NULL))
+ pdata->flags |= PXA_FLAG_CARD_PERMANENT;
+
+ of_property_read_u32(np, "bus-width", &bus_width);
+ if (bus_width == 8)
+ pdata->flags |= PXA_FLAG_SD_8_BIT_CAPABLE_SLOT;
+
+ of_property_read_u32(np, "clk-delay-cycles", &clk_delay_cycles);
+ if (clk_delay_cycles > 0) {
+ pdata->clk_delay_sel = 1;
+ pdata->clk_delay_cycles = clk_delay_cycles;
+ }
+
+ return pdata;
+}
+#else
+static inline struct sdhci_pxa_platdata pxav2_get_mmc_pdata(struct device *dev)
+{
+ return NULL;
+}
+#endif
+
static int __devinit sdhci_pxav2_probe(struct platform_device *pdev)
{
struct sdhci_pltfm_host *pltfm_host;
@@ -128,6 +173,8 @@ static int __devinit sdhci_pxav2_probe(struct
platform_device *pdev)
struct device *dev = &pdev->dev;
struct sdhci_host *host = NULL;
struct sdhci_pxa *pxa = NULL;
+ const struct of_device_id *match;
+
int ret;
struct clk *clk;
@@ -156,6 +203,10 @@ static int __devinit sdhci_pxav2_probe(struct
platform_device *pdev)
| SDHCI_QUIRK_BROKEN_TIMEOUT_VAL
| SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN;
+ match = of_match_device(of_match_ptr(sdhci_pxav2_of_match), &pdev->dev);
+ if (match) {
+ pdata = pxav2_get_mmc_pdata(dev);
+ }
if (pdata) {
if (pdata->flags & PXA_FLAG_CARD_PERMANENT) {
/* on-chip device */
@@ -218,6 +269,7 @@ static struct platform_driver sdhci_pxav2_driver = {
.driver = {
.name = "sdhci-pxav2",
.owner = THIS_MODULE,
+ .of_match_table = sdhci_pxav2_of_match,
.pm = SDHCI_PLTFM_PMOPS,
},
.probe = sdhci_pxav2_probe,
diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index f296956..1835c94 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -28,6 +28,9 @@
#include
#include
#include
+#include
+#include
+
#include "sdhci.h"
#include "sdhci-pltfm.h"
@@ -164,6 +167,46 @@ static struct sdhci_ops pxav3_sdhci_ops = {
.platform_send_init_74_clocks = pxav3_gen_init_74_clocks,
};
+#ifdef CONFIG_OF
+static const struct of_device_id sdhci_pxav3_of_match[] = {
+ {
+ .compatible = "mrvl,pxav3-mmc",
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, sdhci_pxav3_of_match);
+
Re: [PATCH v2 8/9] ARM: dts: refresh dts file for arch mmp
reg property of the top-level interrupt-controller, which "claims" 0x1000 bytes of address space starting at 0xd42082000. The solution is to put the intcmux nodes underneath the interrupt-controller node. The interrupt-controller node now has #address-cells and #size-cells properties so it can have children, but it does not have a ranges property, so the address space is not passed through. The child (intcmux) reg addresses can then be interpreted independently, without conflict. e) The AXI bus address space is actually larger than the existing MMP2 device tree implies. According to the MMP2 datasheet, the range from 0xD400_ to 0xD401_ is AXI (PDMA controller). AXI space also extends up to address 0xF800_, and there are some devices up above 0xF000_ - USB SPH, ULPI, ISP, EPD, and VMeta config. So (in the hierarchical version), the AXI ranges property encompasses the full range from 0xD400_ up to 0xF800_. f) The APB bus address space does not start at 0xD400_, but rather at 0xD401_. g) For the reasons mentioned in point (c), the top-level gpio node cannot have both a ranges property (to pass through the address space) and also a reg property claiming that address space. The solution is to remove its ranges property, adjusting its children's (gcb nodes) addresses to be offsets within a private (not pass-through) address space. h) The "model" property in mmp2-brownstone.dts said "Aspenite". I changed it to "Brownstone". -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/9] ARM: mmp: support DT in irq
0.126224] initlevel:6=device, 150 registered initcalls [0.128223] VFS: Disk quotas dquot_6.5.2 [0.128351] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) [0.129006] msgmni has been set to 1004 [0.129679] io scheduler noop registered [0.129704] io scheduler deadline registered [0.129735] io scheduler cfq registered (default) [0.147410] Console: switching to colour frame buffer device 100x40 [0.165729] pxa2xx-uart.2: ttyS2 at MMIO 0xd4018000 (irq = 24) is a UART3 [0.604763] console [ttyS2] enabled [0.613511] brd: module loaded [0.613712] OLPC XO-1.75 Embedded Controller driver probed [0.622654] input: Power Button as /devices/platform/olpc-ec-1.75.0/input/input0 [0.647411] input: OLPC OLS notify as /devices/platform/olpc-ols.0/input/input1 [0.660453] OLPC Outdoor Light Sensor driver probed [0.670807] OLPC XO-1.75 lid and ebook switches [0.680812] input: OLPC lid switch as /devices/virtual/input/input2 [0.692890] input: OLPC ebook switch as /devices/virtual/input/input3 [0.705720] usbcore: registered new interface driver ipheth [0.717368] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [0.729787] pxau2o-ehci pxau2o-ehci.0: pxa9xx ehci [0.740594] pxau2o-ehci pxau2o-ehci.0: new USB bus registered, assigned bus number 1 [0.756209] pxau2o-ehci pxau2o-ehci.0: irq 44, io mem 0xd4208000 [0.787420] pxau2o-ehci pxau2o-ehci.0: USB 2.0 started, EHCI 1.00 [0.799530] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [0.812178] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [0.825201] usb usb1: Product: pxa9xx ehci [0.834973] usb usb1: Manufacturer: Linux 3.4.0-44790-g83931a4-dirty ehci_hcd [0.847854] usb usb1: SerialNumber: pxau2o-ehci.0 [0.858798] hub 1-0:1.0: USB hub found [0.868222] hub 1-0:1.0: 1 port detected [0.80] Initializing USB Mass Storage driver... [0.888467] usbcore: registered new interface driver usb-storage [0.900160] USB Mass Storage support registered. [0.910406] usbcore: registered new interface driver libusual [0.921801] usbcore: registered new interface driver mdc800 [0.932865] mdc800: v0.7.5 (30/10/2000):USB Driver for Mustek MDC800 Digital Camera [0.946314] usbcore: registered new interface driver usbserial [0.957782] usbcore: registered new interface driver usbserial_generic [0.969927] USB Serial support registered for generic [0.980620] usbserial: USB Serial Driver core [0.990928] OLPC SP keyboard/touchpad driver probed [1.052001] Spurious irq 17, i 8, max_icu_nr is 8, in MMP INTC [1.111662] Spurious irq 17, i 8, max_icu_nr is 8, in MMP INTC [1.162916] Spurious irq 17, i 8, max_icu_nr is 8, in MMP INTC [repeat forever] -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/9] ARM: mmp: support DT in irq
Hi, On Wed, May 30 2012, Haojian Zhuang wrote: >> Did you test non-DT boot with these changes? >> > I tested non-DT boot on my brownstone board on TTC dkb board. Thanks. Do you know how/where cascade_irq gets set on that board? > It seems that you meet issue in icu_mux_irq_demux(). Could you give me > the detail which interrupt is running while you meet the error? It was IRQ 17 (TWSI). > By the way, do you have the boot log? I'll send it tomorrow when I get back to work. Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/9] ARM: mmp: support DT in irq
Hi Haojian,
On Fri, Apr 27 2012, Haojian Zhuang wrote:
> Append new interrupt driver that could support both pxa168 and mmp2
> silicon. And this driver supports device tree.
>
> Since CONFIG_SPARSE_IRQ is enabled in arch-mmp, irq driver should
> handle reserved NR_IRQS_LEGACY in irq domain.
>
> Signed-off-by: Haojian Zhuang
This patch (now in mainline) breaks boot on XO-1.75 (MMP2, non-DT).
I hit the error path below:
> + for (i = 1; i < max_icu_nr; i++) {
> + if (irq == icu_data[i].cascade_irq) {
> + domain = icu_data[i].domain;
> + data = (struct icu_chip_data *)domain->host_data;
> + break;
> + }
> + }
> + if (i >= max_icu_nr) {
> + pr_err("Spurious irq %d in MMP INTC\n", irq);
> + return;
> + }
This error path is hit because i=8 and max_icu_nr=8, which is because
we never matched (irq == icu_data[i].cascade_irq) in the for loop above.
This test is outside of a DT path, but cascade_irq appears to only ever
be set *inside* a DT path:
> + icu_data[i].cascade_irq = irq_of_parse_and_map(node, 0);
> + if (!icu_data[i].cascade_irq) {
> + ret = -EINVAL;
> + goto err;
> + }
Did you test non-DT boot with these changes?
Thanks,
- Chris.
--
Chris Ball <http://printf.net/>
One Laptop Per Child
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 1/3] mmc: atmel-mci: add device tree support
Hi, On Thu, May 24 2012, Jean-Christophe PLAGNIOL-VILLARD wrote: >> + >> +pdata->slot[slot_id].detect_is_active_high = >> +of_property_read_bool(cnp, "cd-inverted"); > > I really this this is redondant with gpio binding > > Chris?? Hm, I think go ahead and add it for now -- I agree it's redundant, but we should go through and remove the redundancy from all drivers (and the binding document, which is in 3.5-rc1 now) at once later. Since it's in the bindings doc, best to implement it until that changes. Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] mmc: dt: Consolidate DT bindings
Hi Arnd, On Sun, May 13 2012, Arnd Bergmann wrote: > I've verified that there are no conflicts with anything we have in > arm-soc right now, so I think it should just go through your > tree. Ah, I based the patch on latest linux-next. That's why there aren't conflicts against arm-soc, but there are conflicts (in the omap and tegra dts changes) between the patch and Linus master/mmc-next: Applying: mmc: dt: Consolidate DT bindings error: patch failed: arch/arm/boot/dts/omap3-beagle.dts:57 error: patch failed: arch/arm/boot/dts/omap4-panda.dts:55 error: patch failed: arch/arm/boot/dts/omap4-sdp.dts:94 error: patch failed: arch/arm/boot/dts/tegra-cardhu.dts:141 error: patch failed: arch/arm/boot/dts/tegra-harmony.dts:335 error: patch failed: arch/arm/boot/dts/tegra-ventana.dts:338 Patch failed at 0001 mmc: dt: Consolidate DT bindings So I think merging via arm-soc is the only way to get it to Linus without conflicts. (Alternatively I can take it in mmc-next and Linus can handle the conflicts.) Thanks! - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2] mmc: dt: Consolidate DT bindings
Hi Arnd, On Fri, Mar 30 2012, Stephen Warren wrote: >> No progress so far. I would suggest we apply the patch below to unify >> the bindings we have. I tried to minimize the impact by picking the most >> common version for each property, but if we know about devices that would >> get broken by this, we may have to be more careful. >> >> Signed-off-by: Arnd Bergmann Here's a version of your MMC DT bindings patch that responds to Stephen Warren's review comments, refreshed against latest linux-next -- I'd like to get this merged for v3.5. Since it touches many .dts files, should it go via arm-soc? Thanks. From: Arnd Bergmann Subject: [PATCH] mmc: dt: Consolidate DT bindings This patch unifies the current DT MMC bindings documentation and code, adds generic MMC DT bindings documentation, and updates .dts files for consistency. Signed-off-by: Arnd Bergmann [cjb: typo fixes, addition of max-frequency property] Signed-off-by: Chris Ball --- Changes since Arnd's v1: * Typo fix from Stephen Warren: s/interrupt/interrupts/ * Typo fix: s/non-removable/ti,non-removable/. This one's being preserved for backwards compatibility. * Add max-frequency property. .../devicetree/bindings/mmc/fsl-esdhc.txt |6 +++-- .../devicetree/bindings/mmc/fsl-imx-esdhc.txt |2 +- .../devicetree/bindings/mmc/mmc-spi-slot.txt |3 ++- Documentation/devicetree/bindings/mmc/mmc.txt | 27 .../devicetree/bindings/mmc/nvidia-sdhci.txt |4 +-- .../devicetree/bindings/mmc/ti-omap-hsmmc.txt |4 +-- arch/arm/boot/dts/imx53-smd.dts|4 +-- arch/arm/boot/dts/imx6q-arm2.dts |2 +- arch/arm/boot/dts/omap3-beagle.dts |2 +- arch/arm/boot/dts/omap4-panda.dts |4 +-- arch/arm/boot/dts/omap4-sdp.dts|6 ++--- arch/arm/boot/dts/tegra-cardhu.dts |2 ++ arch/arm/boot/dts/tegra-harmony.dts|2 ++ arch/arm/boot/dts/tegra-paz00.dts |2 ++ arch/arm/boot/dts/tegra-seaboard.dts |2 ++ arch/arm/boot/dts/tegra-ventana.dts|2 ++ arch/powerpc/boot/dts/mpc8569mds.dts |1 + drivers/mmc/host/omap_hsmmc.c |2 +- drivers/mmc/host/sdhci-esdhc-imx.c |2 +- drivers/mmc/host/sdhci-pltfm.c |8 -- 20 files changed, 66 insertions(+), 21 deletions(-) create mode 100644 Documentation/devicetree/bindings/mmc/mmc.txt diff --git a/Documentation/devicetree/bindings/mmc/fsl-esdhc.txt b/Documentation/devicetree/bindings/mmc/fsl-esdhc.txt index 64bcb8b..0d93b4b 100644 --- a/Documentation/devicetree/bindings/mmc/fsl-esdhc.txt +++ b/Documentation/devicetree/bindings/mmc/fsl-esdhc.txt @@ -11,9 +11,11 @@ Required properties: - interrupt-parent : interrupt source phandle. - clock-frequency : specifies eSDHC base clock frequency. - sdhci,wp-inverted : (optional) specifies that eSDHC controller -reports inverted write-protect state; +reports inverted write-protect state; New devices should use +the generic "wp-inverted" property. - sdhci,1-bit-only : (optional) specifies that a controller can -only handle 1-bit data transfers. +only handle 1-bit data transfers. New devices should use the +generic "bus-width = <1>" property. - sdhci,auto-cmd12: (optional) specifies that a controller can only handle auto CMD12. diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt index ab22fe6..c7e404b 100644 --- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt +++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt @@ -9,7 +9,7 @@ Required properties: - interrupts : Should contain eSDHC interrupt Optional properties: -- fsl,card-wired : Indicate the card is wired to host permanently +- non-removable : Indicate the card is wired to host permanently - fsl,cd-internal : Indicate to use controller internal card detection - fsl,wp-internal : Indicate to use controller internal write protection - cd-gpios : Specify GPIOs for card detection diff --git a/Documentation/devicetree/bindings/mmc/mmc-spi-slot.txt b/Documentation/devicetree/bindings/mmc/mmc-spi-slot.txt index 89a0084..d64aea5 100644 --- a/Documentation/devicetree/bindings/mmc/mmc-spi-slot.txt +++ b/Documentation/devicetree/bindings/mmc/mmc-spi-slot.txt @@ -10,7 +10,8 @@ Required properties: Optional properties: - gpios : may specify GPIOs in this order: Card-Detect GPIO, - Write-Protect GPIO. + Write-Protect GPIO. Note that this does not follow the + binding from mmc.txt, for historic reasons. - interrupts : the interrupt of a card detect interrupt. - interrupt-parent : the phandle for the interrupt controller that services in
Re: [PATCH 1/3] mmc/sdhci-spear: No need to check 'pdev == NULL' in probe
Hi Viresh, On Tue, May 01 2012, Viresh Kumar wrote: > On 4/10/2012 3:06 PM, Viresh KUMAR wrote: >> On 3/27/2012 8:40 AM, Viresh KUMAR wrote: >>> > pdev is guaranteed to be valid in probe. And so check is not required to >>> > check >>> > if it is non-NULL. Remove it. >>> > >>> > Signed-off-by: Viresh Kumar >> Hi Chris, >> >> Can you atleast apply first two patches of this set. Will rework patch 3/3 >> after >> DT support is finalized by arnd. > > Chris, > > Can you please apply these? Sorry for the delay -- I've pushed patches 1 and 2 to mmc-next for 3.5 now. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] mmc: omap_hsmmc: Get rid of of_have_populated_dt() usage
Hi,
On Wed, Apr 11 2012, Rajendra Nayak wrote:
> of_have_populated_dt() is not expected to be used in drivers but
> instead only in early platform init code.
> Drivers on the other hand should rely on dev->of_node or of_match_device().
> Besides usage of of_have_populated_dt() also throws up build error as below
> which was reported by Balaji TK, when omap_hsmmc is built as a module.
>
> ERROR: "allnodes" [drivers/mmc/host/omap_hsmmc.ko] undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
>
> So get rid of all of_have_populated_dt() usage in omap_hsmmc driver and
> instead use dev->of_node to make the same dicisions as earlier.
>
> Signed-off-by: Rajendra Nayak
> Reported-by: Benoit Cousson
> Cc: Balaji TK
> Cc: Rob Herring
> Cc: Sebastian Andrzej Siewior
> ---
> drivers/mmc/host/omap_hsmmc.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index ecc9521..4254b6f 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -252,7 +252,7 @@ static int omap_hsmmc_set_power(struct device *dev, int
> slot, int power_on,
>* the pbias cell programming support is still missing when
>* booting with Device tree
>*/
> - if (of_have_populated_dt() && !vdd)
> + if (dev->of_node && !vdd)
> return 0;
>
> if (mmc_slot(host).before_set_reg)
> @@ -1564,7 +1564,7 @@ static void omap_hsmmc_set_ios(struct mmc_host *mmc,
> struct mmc_ios *ios)
>* can't be allowed when booting with device
>* tree.
>*/
> - (!of_have_populated_dt())) {
> + !host->dev->of_node) {
> /*
> * The mmc_select_voltage fn of the core does
>* not seem to set the power_mode to
Thanks, pushed to mmc-next for 3.4.
- Chris.
--
Chris Ball <http://printf.net/>
One Laptop Per Child
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 6/6] mmc: sdhci-s3c: Add device tree support
Hi Arnd, (Diff truncated to show relevant hunks.) On Fri, Mar 30 2012, Arnd Bergmann wrote: > diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt > b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt > index dbd4368..90b86e5 100644 > --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt > +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt > @@ -15,10 +15,10 @@ Optional properties: > ti,dual-volt: boolean, supports dual voltage cards > -supply: phandle to the regulator device tree node > "supply-name" examples are "vmmc", "vmmc_aux" etc > -ti,bus-width: Number of data lines, default assumed is 1 if the property is > missing. > +bus-width: Number of data lines, default assumed is 1 if the property is > missing. > cd-gpios: GPIOs for card detection > wp-gpios: GPIOs for write protection > -ti,non-removable: non-removable slot (like eMMC) > +non-removable: non-removable slot (like eMMC) > ti,needs-special-reset: Requires a special softreset sequence > > Example: > @@ -27,7 +27,7 @@ Example: > reg = <0x4809c000 0x400>; > ti,hwmods = "mmc1"; > ti,dual-volt; > - ti,bus-width = <4>; > + bus-width = <4>; > vmmc-supply = <&vmmc>; /* phandle to regulator node */ > ti,non-removable; > }; > diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c > index 47adb16..ae48fc7 100644 > --- a/drivers/mmc/host/omap_hsmmc.c > +++ b/drivers/mmc/host/omap_hsmmc.c > @@ -1766,7 +1766,7 @@ static struct omap_mmc_platform_data > *of_get_hsmmc_pdata(struct device *dev) > pdata->slots[0].nonremovable = true; > pdata->slots[0].no_regulator_off_init = true; > } > - of_property_read_u32(np, "ti,bus-width", &bus_width); > + of_property_read_u32(np, "bus-width", &bus_width); > if (bus_width == 4) > pdata->slots[0].caps |= MMC_CAP_4_BIT_DATA; > else if (bus_width == 8) Here you change "ti,non-removable" to "non-removable" in the properties section of ti-omap-hsmmc.txt without changing it in the example section of that document, or in the code or shipped .dts files. (Presumably you decided to preserve it for backwards compatibility, so the bindings documentation shouldn't be changed.) Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC] dt: export of_have_populated_dt
Hi,
On Tue, Apr 10 2012, Cousson, Benoit wrote:
> Hi Balaji,
>
> On 4/10/2012 5:11 PM, Balaji T K wrote:
>> If of_have_populated_dt is called from module, build fails with "allnodes"
>> undefined error, so remove inline and export of_have_populated_dt.
>
> Is this function really called from the MMC driver?
~/git/linux % git grep of_have_populated_dt drivers/
drivers/gpio/gpio-samsung.c:if (!of_have_populated_dt())
drivers/mmc/host/omap_hsmmc.c: if (of_have_populated_dt() && !vdd)
drivers/mmc/host/omap_hsmmc.c: (!of_have_populated_dt())) {
- Chris.
--
Chris Ball <http://printf.net/>
One Laptop Per Child
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 6/6] mmc: sdhci-s3c: Add device tree support
Hi Arnd, On Fri, Mar 30 2012, Arnd Bergmann wrote: > On Friday 30 March 2012, Viresh Kumar wrote: >> On 3/27/2012 9:49 PM, Arnd Bergmann wrote: >> > These bindings came up in a discussion IRC today. I think it's rather bad >> > that >> > we can't agree on a common way to name the properties for mmc. We have >> > bindings being proposed or already included from Anton, Stephen, Shawn, >> > Rajendra, Viresh, Lee and Thomas. Almost all of them define GPIO pins >> > for card detect and write protect, as well properties to define the bus >> > width and high-speed modes, but we seem to have almost as many different >> > definitions of these as we have drivers. >> > >> > Can we please come up with a common binding for these? >> >> Is there any progress on this? Sorry i wasn't following all mails. >> How should i progress for sdhci-spear? > > No progress so far. I would suggest we apply the patch below to unify > the bindings we have. I tried to minimize the impact by picking the most > common version for each property, but if we know about devices that would > get broken by this, we may have to be more careful. > > Signed-off-by: Arnd Bergmann Thanks very much for doing this -- I'll be happy to take the patch in mmc-next once you get time to post a v2 covering Stephen Warren's review comments (and adding "max-frequency" to the document, I guess). - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 5/7] ARM: mmp: append OF support on pxa168
Hi, On Sun, Apr 08 2012, Haojian Zhuang wrote: > There's a typo error in comments. MMP_DT is only for PXA168 & PXA910. > We need to append MMP2_DT for ARMv7 in arch-mmp directory. Since we > are not intended to build ARMv5 and ARMv7 together. Okay. In that case, you should make sure that MMP_DT cannot be selected when CPU_MMP2 is selected, by encoding that dependency in the Kconfig. Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 5/7] ARM: mmp: append OF support on pxa168
Hi,
On Mon, Mar 05 2012, Haojian Zhuang wrote:
> +static int __init mmp_intc_add_irq_domain(struct device_node *np,
> +struct device_node *parent)
> +{
> + irq_domain_add_simple(np, 0);
> + return 0;
> +}
> +
> +static int __init mmp_gpio_add_irq_domain(struct device_node *np,
> +struct device_node *parent)
> +{
> + irq_domain_add_simple(np, IRQ_GPIO_START);
> + return 0;
> +}
This patch was merged for 3.4-rc1, but it fails to compile because Grant
removed irq_domain_add_simple() in 3.4-rc1.
- Chris.
--
Chris Ball <http://printf.net/>
One Laptop Per Child
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 5/7] ARM: mmp: append OF support on pxa168
Hi, On Mon, Mar 05 2012, Haojian Zhuang wrote: > Enable PXA168 and aspenite support. > > Signed-off-by: Haojian Zhuang > --- > arch/arm/mach-mmp/Kconfig | 10 ++ > arch/arm/mach-mmp/Makefile |1 + > arch/arm/mach-mmp/mmp-dt.c | 75 > > 3 files changed, 86 insertions(+), 0 deletions(-) > create mode 100644 arch/arm/mach-mmp/mmp-dt.c > > diff --git a/arch/arm/mach-mmp/Kconfig b/arch/arm/mach-mmp/Kconfig > index 323d4c9..5a90b9a 100644 > --- a/arch/arm/mach-mmp/Kconfig > +++ b/arch/arm/mach-mmp/Kconfig > @@ -2,6 +2,16 @@ if ARCH_MMP > > menu "Marvell PXA168/910/MMP2 Implmentations" > > +config MACH_MMP_DT > + bool "Support MMP2 platforms from device tree" > + select CPU_PXA168 > + select CPU_PXA910 > + select USE_OF > + help > + Include support for Marvell MMP2 based platforms using > + the device tree. Needn't select any other machine while > + MACH_MMP_DT is enabled. > + This patch breaks the build with MACH_MMP_DT=y in 3.4-rc2 for me: MACH_MMP_DT selects CPU_PXA168 which selects CPU_32v5, which results in: armv7-unknown-linux-gnueabi-gcc -Wp,-MD,arch/arm/mm/.dma-mapping.o.d -nostdinc -isystem /opt/crosstool/gcc-4.6.0/lib/gcc/armv7-unknown-linux-gnueabi/4.6.0/include -I/home/cjb/git/olpc-kernel/arch/arm/include -Iarch/arm/include/generated -Iinclude -I/home/cjb/git/olpc-kernel/include -include /home/cjb/git/olpc-kernel/include/linux/kconfig.h -I/home/cjb/git/olpc-kernel/arch/arm/mm -Iarch/arm/mm -D__KERNEL__ -mlittle-endian -I/home/cjb/git/olpc-kernel/arch/arm/mach-mmp/include -I/home/cjb/git/olpc-kernel/arch/arm/plat-pxa/include -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -Os -marm -fno-dwarf2-cfi-asm -mabi=aapcs-linux -mno-thumb-interwork -funwind-tables -D__LINUX_ARM_ARCH__=5 -march=armv5te -msoft-float -Uarm -Wframe-larger-than=1024 -fno-stack-protector -Wno-unused-but-set-variable -fomit-frame-pointer -g -Wdeclaration-after-statement -Wno-pointer -sign -fno-strict-overflow -fconserve-stack-D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(dma_mapping)" -D"KBUILD_MODNAME=KBUILD_STR(dma_mapping)" -c -o arch/arm/mm/dma-mapping.o /home/cjb/git/olpc-kernel/arch/arm/mm/dma-mapping.c /home/cjb/git/olpc-kernel/arch/arm/kernel/entry-armv.S: Assembler messages: /home/cjb/git/olpc-kernel/arch/arm/kernel/entry-armv.S:207: Error: selected processor does not support ARM mode `clrex' CPU_32v5=y adds: arch/arm/Makefile:arch-$(CONFIG_CPU_32v5) :=-D__LINUX_ARM_ARCH__=5 $(call cc-option,-march=armv5te,-march=armv4t) - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 0/6] mmc: sdhci-s3c: Rework platform data and add device tree support
Hi Kukjin, On Wed, Mar 28 2012, Kukjin Kim wrote: >>> As a result I'm dropping this tree -- and all of the patches that I >>> have on top of it -- from mmc-next so that I can get a pull request >>> out. This means that I'm dropping: >> > Hmm, I think, if you're ok, you can send a second pull request to > Linus for it and actually, it is in linux-next for a long time via mmc > and samsung tree. > > Note, please don't rebase it because its resolution for conflicts is > in linux-next and I think Linus will use it when happens > conflicts...Or I can provide new tree on top of latest mainline. But > I'm not sure about latter. I can't send the tree as it is to Linus now, because Arnd has asked us to hold off on these device tree bindings and work with the unified bindings he's proposing instead. (Rebasing to drop that patch will introduce new conflicts.) I'm going to send Mark Brown's two patches to Linus now, even though it will cause a conflict in -next. The rest (other than the device tree bindings) are mergable after -rc1, because they're fixes, so we'll eventually get everything except DT in to 3.4. I think you should just drop this patchset from your tree in linux-next entirely now. Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 0/6] mmc: sdhci-s3c: Rework platform data and add device tree support
Hi Kukjin, On Tue, Feb 21 2012, Chris Ball wrote: > On Tue, Feb 21 2012, Kukjin Kim wrote: >> I created topic branch for this we talked. You can pull that following: >> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git >> v3.4-for-cjb >> >> If any problems, please kindly let me know. > > Pushed to mmc-next, thanks. (I'm expecting that you'll do the merge > to Linus.) I was expecting you to merge these patches, but they aren't in the arm-soc tree and haven't been sent to Linus, and we're in the last few days of the merge window. As a result I'm dropping this tree -- and all of the patches that I have on top of it -- from mmc-next so that I can get a pull request out. This means that I'm dropping: mmc: sdhci-s3c: Add device tree support mmc: sdhci-s3c: Keep a copy of platform data and use it mmc: sdhci-s3c: derive transfer width host capability from max_width in ARM: SAMSUNG: remove all uses of clk_type member in sdhci platform data ARM: EXYNOS: use 'exynos4-sdhci' as device name for sdhci controllers mmc: sdhci-s3c: Remove usage of clk_type member in platform data .. which I was expecting you to merge, and also: mmc: sdhci-s3c: fix broken compilation for non-Exynos SoCs mmc: sdhci-s3c: Enable runtime power management mmc: sdhci-s3c: Use CONFIG_PM_SLEEP to ifdef system suspend mmc: sdhci-s3c: use devm_ functions .. which were merged on top of the above patches. We'll have to try again with 3.5 for the new features, and post-rc1 for the fixes. Please let me know what happened with this merge. Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 0/4] omap hsmmc device tree support
Hi, On Mon, Mar 12 2012, Rajendra Nayak wrote: > The series adds device tree support for OMAP hsmmc > driver. > > Changes in V2: > -1- Minor fixes based on comments from Grant. > -2- Added a seperate compatible for omap3. > -3- Added a new binding "ti,needs-special-reset" > to handle some mmc modules which need special > softreset sequence. > -4- Updated board dts files with "status = disable;" > for unused mmc modules. > > Rob, > I retained your ack on patch 1 despite the additional > binding that I added to handle the special softreset > sequence. Let me know if you have any issues with it. > > Chris. > Patch 1 and Patch 2 apply cleanly on mmc-next and can > be taken in from the mmc tree after relevent acks from > DT folks. > Patch 3 and Patch 4 which update dts files, I plan to > push via linux-omap/Tony's tree. Thanks, I've pushed patches 1 and 2 to mmc-next for 3.4, with Balaji's Tested-by. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 0/6] mmc: sdhci-s3c: Rework platform data and add device tree support
Hi, On Wed, Feb 22 2012, Mark Brown wrote: > On Tue, Feb 21, 2012 at 08:17:41AM -0500, Chris Ball wrote: > >> Pushed to mmc-next, thanks. (I'm expecting that you'll do the merge >> to Linus.) > > I've been sending patches adding runtime PM support to this driver for a > while with no response - are there any issues with those? I don't have s3c hardware, so I've been waiting for a Tested-by or ACK from someone who does -- Kukjin, any objection if I take this into mmc-next with a plan to merge it, to provoke some testing? Is it possible for you to test/review the patch? Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 0/6] mmc: sdhci-s3c: Rework platform data and add device tree support
Hi, On Tue, Feb 21 2012, Kukjin Kim wrote: > I created topic branch for this we talked. You can pull that following: > git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git > v3.4-for-cjb > > If any problems, please kindly let me know. Pushed to mmc-next, thanks. (I'm expecting that you'll do the merge to Linus.) - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 0/6] mmc: sdhci-s3c: Rework platform data and add device tree support
Hi, On Thu, Feb 16 2012, Kukjin Kim wrote: > I mean if I or you create topic branch for this whole series, can be > merged into both tree for avoiding conflicts with further working. Of > course, the topic branch don't have to rebase after merging into each > tree. > > If you're ok on this and my opinion, let me create the topic branch. Okay, sure. Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 0/6] mmc: sdhci-s3c: Rework platform data and add device tree support
Hi, On Thu, Feb 09 2012, Kukjin Kim wrote: > Looks ok to me and I'd like to pick this series in samsung tree with Chris' > ack. > > Chris, is it ok? If you need to merge this in your tree, please let me know. > I will provide topic branch for it. > > If any problems, please let me know. I don't have a very strong opinion, but I think it's probably better to go via the mmc tree since the patch is so large and hence the chance of conflict before merging is high. Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH REPOST 1/2] arm/dt: Tegra: Update SDHCI nodes to match bindings
Hi, On Tue, Sep 20 2011, Stephen Warren wrote: > Arnd Bergmann wrote at Tuesday, September 20, 2011 11:43 AM: >> On Tuesday 20 September 2011, Stephen Warren wrote: >> > The bindings were recently updated to have separate properties for each >> > type of GPIO. Update the Device Tree source to match that. >> > >> > Signed-off-by: Stephen Warren >> > Acked-by: Olof Johansson >> > --- >> > I'd previously sent these to Grant assuming they'd go in his dt/next >> > branch, >> > but perhaps these should go in through Arnd's arm-soc next/dt branch? >> > >> >> Which tree has the update that changed the bindings? I think it should >> go into the same one. >> >> If it's already upstream, I can take it into the fixes branch. > > Chris applied them to the mmc-next tree: > > git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git > > which appears to be temporarily at: > > git://dev.laptop.org/users/cjb/mmc Sending these via Arnd's next/dt sounds good to me. I know we'd usually take changes that require an atomic update through the same tree, but Stephen said in https://lkml.org/lkml/2011/8/30/352 : I don't think there's actually any need for that; initializing Tegra's SDHCI from device-tree has never worked in mainline to date; it relies on patch 1 being there. And if patch 2 was there without patch 3, the worst that will happen is some port runs in 4-bit mode instead of 8-bit, which evidently works fine since I didn't even notice 8-bit support was missing... Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/3] arm/dt: Tegra: Update SDHCI nodes to match bindings
Hi, On Tue, Aug 30 2011, Stephen Warren wrote: > I don't think there's actually any need for that; initializing Tegra's > SDHCI from device-tree has never worked in mainline to date; it relies > on patch 1 being there. And if patch 2 was there without patch 3, > the worst that will happen is some port runs in 4-bit mode instead of > 8-bit, which evidently works fine since I didn't even notice 8-bit > support was missing... Ah, okay. I've merged patch 2 to mmc-next for 3.2, then, and will keep an eye on what happens with the arch patches. Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/3] arm/dt: Tegra: Update SDHCI nodes to match bindings
Hi Stephen, On Tue, Aug 30 2011, Stephen Warren wrote: > Signed-off-by: Stephen Warren > Acked-by: Olof Johansson > --- > This is a repost of http://www.spinics.net/lists/linux-tegra/msg02117.html > I'm including it here since it's not in linux-next yet, and patch 3 depends > on it. I assume I should wait for patches 1+3 to appear in -next via another tree before I merge patch 2 -- let me know if that's incorrect. Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/2] sdhci/tegra: Add Device Tree probing support
Hi Stephen, On Tue, Aug 23 2011, Stephen Warren wrote: > From: Grant Likely > > Add hooks to read gpio configuration out of the device tree node. > > [grant.likely: Rewrite of original patch from John Bonesio] > Signed-off-by: Grant Likely > [swarren: Fixed tegra_sdhci_get_ro() to retrieve pdata correctly] > [swarren: Reworked to avoid #ifdef CONFIG_OF] > [swarren: Reworked binding based on fsl-imx-esdhc.txt] > [swarren: Documented binding] > Signed-off-by: Stephen Warren > --- > Theoretically, these two patches should be merged in order in one place, > since the 2nd logically depends on the first. However, it's really just > a documentation dependency, so I think it's fine to merge them into the > MMC and DT trees separately and let them meet in linux-next. > > .../devicetree/bindings/mmc/nvidia-sdhci.txt | 25 ++ > drivers/mmc/host/sdhci-tegra.c | 51 +++ > 2 files changed, 65 insertions(+), 11 deletions(-) > create mode 100644 Documentation/devicetree/bindings/mmc/nvidia-sdhci.txt Okay, I've pushed this patch [1/2] to mmc-next for 3.2. Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 0/4] Add device tree probe for sdhci-esdhc-imx
Hi Shawn, Sascha, On Sat, Jul 09 2011, Shawn Guo wrote: >> > Shawn Guo (4): >> > mmc: sdhci-esdhc-imx: do not reference platform data after probe >> > mmc: sdhci-esdhc-imx: get rid of the uses of cpu_is_mx() >> > mmc: sdhci-pltfm: dt device does not pass parent to sdhci_alloc_host >> > mmc: sdhci-esdhc-imx: add device tree probe support >> >> These don't apply against mmc-next -- what is your tree based on? >> > It's based on linux-next with following patch applied. > > [PATCH v4 4/4] mmc: sdhci-esdhc-imx: extend card_detect and > write_protect support for mx5 > http://permalink.gmane.org/gmane.linux.kernel.mmc/8748 > > You applied the 3 of 4 patches in that series, and expect Sascha to > send this one through his tree after you send those 3. I see. In that case, either Sascha can send this new series with my: Acked-by: Chris Ball or I'll send it as a second pull request after Sascha sends [4/4]. Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 0/4] Add device tree probe for sdhci-esdhc-imx
Hi Shawn, On Wed, Jul 06 2011, Shawn Guo wrote: > The first patch copies platform data into driver private data, and > do not reference platform data after probe. The second one removes > the uses of cpu_is_mx(). The third one makes a dt related fix on > sdhci-pltfm.c, and the last one adds actual device tree probe for > sdhci-esdhc-imx driver. > > Changes since v2: > * Add patch #1 > * Do not use Linux details of cd-type and wp-type for binding > > Changes since v1: > * Address review comments given by Grant > > Shawn Guo (4): > mmc: sdhci-esdhc-imx: do not reference platform data after probe > mmc: sdhci-esdhc-imx: get rid of the uses of cpu_is_mx() > mmc: sdhci-pltfm: dt device does not pass parent to sdhci_alloc_host > mmc: sdhci-esdhc-imx: add device tree probe support These don't apply against mmc-next -- what is your tree based on? Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 0/4] Consolidate sdhci pltfm & OF drivers and get them self registered
Hi Grant, On Fri, May 27 2011, Grant Likely wrote: > Any chance we can get this series into $NEXT_KERNEL? I think I'd rather not in this case, hope that's okay. It hasn't seen testing in linux-next yet, there's a reasonable chance of it breaking sdhci-pltfm users in subtle ways -- we haven't had much testing from the individual -pltfm driver maintainers yet -- and the mmc merge was (relatively) huge already this cycle. I'll certainly push it to linux-next as soon as -rc1 is released, though. Sound okay? Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/5] consolidate sdhci pltfm & OF drivers and get them self registered
Hi Wolfram, On Fri, Mar 25 2011, Shawn Guo wrote: > Here are what the patch set does. > > * Remove .probe and .remove hooks from sdhci-pltfm.c and make it be > a pure common helper function providers. > * Add .probe and .remove hooks for sdhci pltfm drivers sdhci-cns3xxx, > sdhci-dove, sdhci-tegra, and sdhci-esdhc-imx to make them self > registered with calling helper functions created above. > * Migrate the use of sdhci_of_host and sdhci_of_data to > sdhci_pltfm_host and sdhci_pltfm_data, so that OF version host and > data structure works can be saved, and pltfm version works for both > cases. > * Add OF common helper stuff into sdhci-pltfm.c, and make OF version > sdhci drivers sdhci-of-esdhc and sdhci-of-hlwd become self > registered as well, so that sdhci-of-core.c and sdhci-of.h can be > removed. > * Consolidate the OF and pltfm esdhc drivers into one with sharing > the same pair of .probe and .remove hooks. As a result, > sdhci-esdhc-imx.c and sdhci-of-esdhc.c go away, while > sdhci-esdhc.c comes in and works for both MPCxxx and i.MX. > * Eliminate include/linux/mmc/sdhci-pltfm.h with moving stuff into > drivers/mmc/host/sdhci-pltfm.h. If you get time, would appreciate getting an ACK from you on the patch changes (including Grant's review). Thanks very much! - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: drivers/mmc/host/sdhci-of-core.c on sparc64
Hi,
On Thu, Jan 13, 2011 at 03:41:40PM -0800, Andrew Morton wrote:
> > > drivers/mmc/host/sdhci-of-core.c:24:25: asm/machdep.h: No such file or
> > > directory
> > > drivers/mmc/host/sdhci-of-core.c: In function `sdhci_of_wp_inverted':
> > > drivers/mmc/host/sdhci-of-core.c:115: error: implicit declaration of
> > > function `machine_is'
> > >
> > > That code's been there for a while. Did someone change Kconfig?
> >
> > Can you attach a .config? is arch-specific, so I'd
> > suggest that you're building on an unsupported arch.
> >
>
> sparc64 allmodconfig.
You're right, Andrew -- Rob (CC'd) changed the MMC Kconfig to build this
driver on Sparc. Mainline commit 236cdc7bc71 ("of: make drivers depend
on CONFIG_OF instead of CONFIG_PPC_OF").
Rob also posted a patch to devicetree-discuss@, on top of the one above
("mmc: sdhci-of: fix build on non-powerpc platforms"), to fix up the
Sparc build by ifdef'ing for PPC inside the driver. Grant merged the
first patch but not the second, hence sparc64 allmodconfig is broken
now. The reason Grant didn't merge the second patch may be that Wolfram
objected to #ifdef proliferation inside the driver.
Options, as I see it:
* revert the commit such that MMC_SDHCI_OF once again depends on PPC_OF
* take the second patch as-is
* come up with a less-#ifdeffy second patch
Wolfram, would appreciate your input on what we should do here. Thanks,
--
Chris Ball <http://printf.net/>
One Laptop Per Child
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
