* [PATCH] mmc: dw_mmc: fix dw_mci_get_cd
From: Seungwon Jeon @ 2014-01-15 14:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D6938A.9050806@linaro.org>
On Wed, January 15, 2014, Zhangfei wrote:
> On 01/15/2014 08:26 PM, Seungwon Jeon wrote:
>
> >>>> @@ -1033,7 +1033,8 @@ static int dw_mci_get_cd(struct mmc_host *mmc)
> >>>> int present;
> >>>> struct dw_mci_slot *slot = mmc_priv(mmc);
> >>>> struct dw_mci_board *brd = slot->host->pdata;
> >>>> - int gpio_cd = !mmc_gpio_get_cd(mmc);
> >>>> + struct dw_mci *host = slot->host;
> >>>> + int gpio_cd = mmc_gpio_get_cd(mmc);
> >>>>
> >>>> /* Use platform get_cd function, else try onboard card detect */
> >>>> if (brd->quirks & DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
> >>>> @@ -1041,11 +1042,12 @@ static int dw_mci_get_cd(struct mmc_host *mmc)
> >>>> else if (brd->get_cd)
> >>>> present = !brd->get_cd(slot->id);
> >>>> else if (!IS_ERR_VALUE(gpio_cd))
> >>>> - present = !!gpio_cd;
> >>>> + present = !gpio_cd;
> >>> !!gpio_cd or gpio_cd is correct, isn't it?
> >>>
> >>
> >> No, mmc_gpio_get_cd(mmc) has to revert.
> > I'm missing something?
> > If card is detected, mmc_gpio_get_cd() returns non-zero, right?
> > I guess gpio_cd should be kept.
> >
>
> Hmm, looks you are right.
> Though not see clearly mmc_gpio_get_cd declaratoin, other drivers
> directly set get_cd as mmc_gpio_get_cd.
> .get_cd = mmc_gpio_get_cd
>
> However, in our board cd =0 when card is deteced while cd=1 when card is
> removed.
> In order to mmc_gpio_get_cd return 1, MMC_CAP2_CD_ACTIVE_HIGH has to be
> set, as well as new property "caps2-mmc-cd-active-low".
Ok, you could do more.
mmc_gpio_get_cd() is expected to return non-zero if card is detection.
>
> --- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
> +++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
> @@ -73,6 +73,8 @@ Optional properties:
> +* caps2-mmc-cd-active-low: cd pin is low when card active
> +
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> + if (of_find_property(np, "caps2-mmc-cd-active-low", NULL))
> + pdata->caps2 |= MMC_CAP2_CD_ACTIVE_HIGH;
> +
>
> But it looks strange "cd-active-low" describing "CD_ACTIVE_HIGH" flag.
> When card active, cd = 0, and ACTIVE_HIGH is required to make
> mmc_gpio_get_cd return 1.
I think your board seems not to use pull-up on GPIO line for card detection.
So, MMC_CAP2_CD_ACTIVE_HIGH would be needed.
Thanks,
Seungwon Jeon
> int mmc_gpio_get_cd(struct mmc_host *host)
> {
> return !gpio_get_value_cansleep(ctx->cd_gpio) ^
> !!(host->caps2 & MMC_CAP2_CD_ACTIVE_HIGH);
> }
>
> Thanks
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* device-tree: at91: irq and gpios: problem while requesting a gpio used as an interrupt source.
From: Jean-Jacques Hiblot @ 2014-01-15 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140115135617.GF9558@ns203013.ovh.net>
2014/1/15 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>:
> On 14:44 Wed 15 Jan , Jean-Jacques Hiblot wrote:
>> 2014/1/15 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>:
>> > On 14:04 Wed 15 Jan , Jean-Jacques Hiblot wrote:
>> >> 2014/1/15 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>:
>> >> > On 12:05 Mon 13 Jan , Jean-Jacques Hiblot wrote:
>> >> >> Hi Boris,
>> >> >>
>> >> >> 2014/1/13 boris brezillon <b.brezillon@overkiz.com>:
>> >> >> > On 13/01/2014 11:29, Jean-Jacques Hiblot wrote:
>> >> >> >>
>> >> >> >> Hello Nicolas, Jean-Christophe,
>> >> >> >>
>> >> >> >> As I was trying to enable the touchscreen on the at91sam9261ek with
>> >> >> >> device-tree support, I ran into an issue. The touchscreen driver needs
>> >> >> >> to know the state of the pendown gpio and also needs it as an
>> >> >> >> interrupt source.
>> >> >> >>
>> >> >> >> The problem is that when a gpio is used as an interrupt, it's
>> >> >> >> requested by the pinctrl driver during the xlate stage, marking it
>> >> >> >> unavaliable for the other driver.
>> >> >> >> It looks like the at91 pinctrl driver is the only one to use
>> >> >> >> gpio_request() in the xlate stage. Maybe we should remove this:
>> >> >> >
>> >> >> >
>> >> >> > You should only request it as a GPIO and then use gpio_to_irq to get the
>> >> >> > related IRQ.
>> >> >> > Because what is done here, is to solve the case where only the irq
>> >> >> > is request, and in this specific case we need to request the pin as a
>> >> >> > GPIO.
>> >> >> >
>> >> >>
>> >> >> That's what I did first, and was about to submit the patch for the
>> >> >> touchscreen driver.
>> >> >> However it doesn't feel right. Being able to get the state of a gpio
>> >> >> that is also an interrupt seems very useful to me, not only for a
>> >> >> touchscreen controller.
>> >> >>
>> >> >> I understand why it's being done here. It's a matter of being sure
>> >> >> that the GPIO is an input and that it'll not be configured otherwise
>> >> >> latter.
>> >> >> But:
>> >> >> 1) I'm wondering why the atmel pinctrl is the only one to do that.
>> >> >
>> >> > because this the only to start to do it right
>> >> > I had a very long discussion woth LinusW and Grant the Gpio need to stop to
>> >> > use gpio_to_irq & co for irq.
>> >> How can you get the value of the gpio that is also an interrupt source then ?
>> >> Can you give a short example?
>> >
>> > you just have to check the irq source
>> >
>> > failing or raising
>> >
>> > but on 9261 impossible the gpio does not have such detail
>> >
>> > but anyway this is the invert you need to get the information from the IRQ no the way
>> > arround
>>
>> Should I modify the touchscreen driver to use irq_to_gpio() in this
>> case then ? or is this also not proper ?
>>
> no as said by arnd irq_to_gpio does not exsit
>
> that's why I said the irq need to provide you the information as it's a
> raising or failing irq
Even when this kind of information is available it's not enough to
know for sure the state of the gpio. Think of short pulses such as the
glitches you have when you press a button.
>
> Best Regards,
> J.
^ permalink raw reply
* [PATCH v1 3/5] pinctrl: st: Add software edge trigger interrupt support.
From: srinivas kandagatla @ 2014-01-15 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbFGOm2xm5H+of_NuJ6DVmBDcEODZbDxVU8nGC-RU64Tw@mail.gmail.com>
Thankyou for reviewing the patch.
On 15/01/14 14:27, Linus Walleij wrote:
> On Tue, Jan 14, 2014 at 3:52 PM, <srinivas.kandagatla@st.com> wrote:
>
>> From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
>>
>> ST pin controller does not have hardware support for detecting edge
>> triggered interrupts, It only has level triggering support.
>> This patch attempts to fake up edge triggers from hw level trigger
>> support in software. With this facility now the gpios can be easily used
>> for keypads, otherwise it would be difficult for drivers like keypads to
>> work with level trigger interrupts.
>>
>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@st.com>
>
> Clever! Mostly I like the patch as it is but:
>
>> for_each_set_bit(n, &port_active, BITS_PER_LONG) {
>> + /* check if we are detecting fake edges ... */
>> + pin_edge_cfg = ST_IRQ_EDGE_CONF(bank_edge_mask, n);
>> +
>> + if (pin_edge_cfg) {
>> + /* edge detection. */
>> + val = st_gpio_get(&bank->gpio_chip, n);
>> + if (val)
>> + writel(BIT(n), bank->base + REG_PIO_SET_PCOMP);
>> + else
>> + writel(BIT(n), bank->base + REG_PIO_CLR_PCOMP);
>> +
>> + if (pin_edge_cfg != ST_IRQ_EDGE_BOTH &&
>> + !((pin_edge_cfg & ST_IRQ_EDGE_FALLING) ^ val))
>> + continue;
>> + }
>> +
>
> Please insert comments here to explain what you are actually doing
> because I sure as hell do not understand this code without comments
> describing the trick used.
I agree, I will document this logic in next version.
Thanks,
srini
>
> Yours,
> Linus Walleij
>
>
^ permalink raw reply
* [RFC PATCH 1/1] of/irq: create interrupts-extended-2 property
From: Grant Likely @ 2014-01-15 14:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140115121750.GE25824@e106331-lin.cambridge.arm.com>
On Wed, Jan 15, 2014 at 12:17 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Wed, Jan 15, 2014 at 11:47:25AM +0000, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> The new interrupts-extended property, which reuses the phandle+arguments
>> pattern used by GPIOs and other core bindings, still have some issue.
>>
>> If an SoC have already specifiy interrupt and a board want to add specific
>> interrupt such as GPIO (which can be optionnal) be need to re-define
>> interrupts-extended. So allow to have an optionnale interrupts-extended-2
>> property.
>>
>
> NAK.
>
> This is a hack that works around a dts organisation issue. This is _not_
> a binding or parsing issue.
>
> Properties can be overridden - just describe all of the interrupts in
> the final dts file.
Agreed. The current binding handles the case of multiple interrupts just fine.
g.
^ permalink raw reply
* [PATCH] ARM: sunxi: Add driver for sunxi usb phy
From: Kishon Vijay Abraham I @ 2014-01-15 15:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389740305-6993-1-git-send-email-hdegoede@redhat.com>
On Wednesday 15 January 2014 04:28 AM, Hans de Goede wrote:
> The Allwinner A1x / A2x SoCs have 2 or 3 usb phys which are all accessed
> through a single set of registers. Besides this there are also some other
> phy related bits which need poking, which are per phy, but shared between the
> ohci and ehci controllers, so these are also controlled from this new phy
> driver.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> .../devicetree/bindings/phy/sun4i-usb-phy.txt | 26 ++
> drivers/phy/Kconfig | 11 +
> drivers/phy/Makefile | 1 +
> drivers/phy/phy-sun4i-usb.c | 318 +++++++++++++++++++++
> 4 files changed, 356 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> create mode 100644 drivers/phy/phy-sun4i-usb.c
>
> diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> new file mode 100644
> index 0000000..6c54b3b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> @@ -0,0 +1,26 @@
> +Allwinner sun4i USB PHY
> +-----------------------
> +
> +Required properties:
> +- compatible : should be one of "allwinner,sun4i-a10-usb-phy",
> + "allwinner,sun5i-a13-usb-phy" or "allwinner,sun7i-a20-usb-phy"
> +- reg : 2 or 3 register offset + length pairs, 1 phy base reg pair +
> + 1 pair for the pmu-irq register of each hcd
> +- #phy-cells : from the generic phy bindings, must be 1
> +
> +Optional properties:
> +- clocks : phandle + clock specifier for the phy clock
> +- clock-names : "usb_phy"
> +- resets : a list of phandle + reset specifier pairs
> +- reset-names : "usb0_reset", "usb1_reset", and / or "usb2_reset"
> +
> +Example:
> + usbphy: phy at 0x01c13400 {
> + #phy-cells = <1>;
> + compatible = "allwinner,sun4i-a10-usb-phy";
> + reg = <0x01c13400 0x10 0x01c14800 0x4 0x01c1c800 0x4>;
> + clocks = <&usb_clk 8>;
> + clock-names = "usb_phy";
> + resets = <&usb_clk 1>, <&usb_clk 2>;
> + reset-names = "usb1_reset", "usb2_reset";
> + };
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 330ef2d..dcce4cf 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -51,4 +51,15 @@ config PHY_EXYNOS_DP_VIDEO
> help
> Support for Display Port PHY found on Samsung EXYNOS SoCs.
>
> +config PHY_SUN4I_USB
> + tristate "Allwinner sunxi SoC USB PHY driver"
> + depends on ARCH_SUNXI
> + select GENERIC_PHY
> + help
> + Enable this to support the transceiver that is part of Allwinner
> + sunxi SoCs.
> +
> + This driver controls the entire USB PHY block, both the USB OTG
> + parts, as well as the 2 regular USB 2 host PHYs.
> +
> endmenu
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index d0caae9..e9e82f0 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -7,3 +7,4 @@ obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-video.o
> obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO) += phy-exynos-mipi-video.o
> obj-$(CONFIG_OMAP_USB2) += phy-omap-usb2.o
> obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o
> +obj-$(CONFIG_PHY_SUN4I_USB) += phy-sun4i-usb.o
> diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
> new file mode 100644
> index 0000000..a15ecc1
> --- /dev/null
> +++ b/drivers/phy/phy-sun4i-usb.c
> @@ -0,0 +1,318 @@
> +/*
> + * Allwinner sun4i USB phy driver
> + *
> + * Copyright (C) 2014 Hans de Goede <hdegoede@redhat.com>
> + *
> + * Based on code from
> + * Allwinner Technology Co., Ltd. <www.allwinnertech.com>
> + *
> + * Modelled after: Samsung S5P/EXYNOS SoC series MIPI CSIS/DSIM DPHY driver
> + * Copyright (C) 2013 Samsung Electronics Co., Ltd.
> + * Author: Sylwester Nawrocki <s.nawrocki@samsung.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that 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.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/phy/phy.h>
> +#include <linux/platform_device.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/reset.h>
> +
> +#define REG_ISCR 0x00
> +#define REG_PHYCTL 0x04
> +#define REG_PHYBIST 0x08
> +#define REG_PHYTUNE 0x0c
> +
> +#define SUNXI_AHB_ICHR8_EN BIT(10)
> +#define SUNXI_AHB_INCR4_BURST_EN BIT(9)
> +#define SUNXI_AHB_INCRX_ALIGN_EN BIT(8)
> +#define SUNXI_ULPI_BYPASS_EN BIT(0)
> +
> +#define MAX_PHYS 3
> +
> +struct sun4i_usb_phy_data {
> + struct clk *clk;
> + void __iomem *base;
> + struct mutex mutex;
> + int num_phys;
> + u32 disc_thresh;
> + struct sun4i_usb_phy {
> + struct phy *phy;
> + void __iomem *pmu_irq;
'pmu_irq' is misleading. Can you think of a better name?
Btw Kamil uses syscon interface to set pmu bits. Is it applicable here also?
> + struct regulator *vbus;
> + struct reset_control *reset;
> + int index;
> + } phys[MAX_PHYS];
> +};
> +
> +#define to_sun4i_usb_phy_data(phy) \
> + container_of((phy), struct sun4i_usb_phy_data, phys[(phy)->index])
> +
> +static void sun4i_usb_phy_write(struct sun4i_usb_phy *phy, u32 addr, u32 data,
> + int len)
> +{
> + struct sun4i_usb_phy_data *phy_data = to_sun4i_usb_phy_data(phy);
> + u32 temp, usbc_bit = BIT(phy->index * 2);
> + int i;
> +
> + mutex_lock(&phy_data->mutex);
> +
> + for (i = 0; i < len; i++) {
> + temp = readl(phy_data->base + REG_PHYCTL);
> +
> + /* clear the address portion */
> + temp &= ~(0xff << 8);
> +
> + /* set the address */
> + temp |= ((addr + i) << 8);
> + writel(temp, phy_data->base + REG_PHYCTL);
> +
> + /* set the data bit and clear usbc bit*/
> + temp = readb(phy_data->base + REG_PHYCTL);
> + if (data & 0x1)
> + temp |= BIT(7);
> + else
> + temp &= ~BIT(7);
> + temp &= ~usbc_bit;
> + writeb(temp, phy_data->base + REG_PHYCTL);
> +
> + /* pulse usbc_bit */
> + temp = readb(phy_data->base + REG_PHYCTL);
> + temp |= usbc_bit;
> + writeb(temp, phy_data->base + REG_PHYCTL);
> +
> + temp = readb(phy_data->base + REG_PHYCTL);
> + temp &= ~usbc_bit;
> + writeb(temp, phy_data->base + REG_PHYCTL);
> +
> + data >>= 1;
> + }
> + mutex_unlock(&phy_data->mutex);
> +}
> +
> +static void sun4i_usb_phy_passby(struct sun4i_usb_phy *phy, int enable)
> +{
> + u32 bits, reg_value;
> +
> + if (!phy->pmu_irq)
> + return;
> +
> + bits = SUNXI_AHB_ICHR8_EN | SUNXI_AHB_INCR4_BURST_EN |
> + SUNXI_AHB_INCRX_ALIGN_EN | SUNXI_ULPI_BYPASS_EN;
> +
> + reg_value = readl(phy->pmu_irq);
> +
> + if (enable)
> + reg_value |= bits;
> + else
> + reg_value &= ~bits;
> +
> + writel(reg_value, phy->pmu_irq);
> +}
> +
> +static int sun4i_usb_phy_init(struct phy *_phy)
> +{
> + struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
> + struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
> + int ret;
> +
> + ret = clk_prepare_enable(data->clk);
> + if (ret)
> + return ret;
> +
> + ret = reset_control_deassert(phy->reset);
> + if (ret) {
> + clk_disable_unprepare(data->clk);
> + return ret;
> + }
> +
> + /* Adjust PHY's magnitude and rate */
> + sun4i_usb_phy_write(phy, 0x20, 0x14, 5);
No magic values. Use macros instead.
> +
> + /* Disconnect threshold adjustment */
> + sun4i_usb_phy_write(phy, 0x2a, data->disc_thresh, 2);
> +
> + sun4i_usb_phy_passby(phy, 1);
> +
> + return 0;
> +}
> +
> +static int sun4i_usb_phy_exit(struct phy *_phy)
> +{
> + struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
> + struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
> +
> + sun4i_usb_phy_passby(phy, 0);
> + reset_control_assert(phy->reset);
> + clk_disable_unprepare(data->clk);
Actually PHY API's can be called in interrupt context, in that case
clk_disable_unprepare can't be used.
> +
> + return 0;
> +}
> +
> +static int sun4i_usb_phy_power_on(struct phy *_phy)
> +{
> + struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
> + int ret;
> +
> + if (phy->vbus) {
> + ret = regulator_enable(phy->vbus);
> + if (ret)
> + return ret;
> +
> + }
> +
> + return 0;
> +}
This can simply be
int ret = 0;
if (phy->vbus)
ret = regulator_enable(phy->vbus);
return ret;
> +
> +static int sun4i_usb_phy_power_off(struct phy *_phy)
> +{
> + struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
> +
> + if (phy->vbus)
> + regulator_disable(phy->vbus);
> +
> + return 0;
> +}
> +
> +static struct phy_ops sun4i_usb_phy_ops = {
> + .init = sun4i_usb_phy_init,
> + .exit = sun4i_usb_phy_exit,
> + .power_on = sun4i_usb_phy_power_on,
> + .power_off = sun4i_usb_phy_power_off,
> + .owner = THIS_MODULE,
> +};
> +
> +static struct phy *sun4i_usb_phy_xlate(struct device *dev,
> + struct of_phandle_args *args)
> +{
> + struct sun4i_usb_phy_data *data = dev_get_drvdata(dev);
> +
> + if (WARN_ON(args->args[0] == 0 || args->args[0] >= data->num_phys))
> + return ERR_PTR(-ENODEV);
> +
> + return data->phys[args->args[0]].phy;
> +}
> +
> +static int sun4i_usb_phy_probe(struct platform_device *pdev)
> +{
> + struct sun4i_usb_phy_data *data;
> + struct device *dev = &pdev->dev;
> + struct device_node *np = dev->of_node;
> + void __iomem *pmu_irq = NULL;
> + struct phy_provider *phy_provider;
> + struct reset_control *reset;
> + struct regulator *vbus;
> + struct phy *phy;
> + char name[16];
> + int i;
> +
> + data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> +
> + mutex_init(&data->mutex);
> + if (of_device_is_compatible(np, "allwinner,sun4i-a10-usb-phy")) {
> + data->num_phys = 3;
> + data->disc_thresh = 3;
> + } else if (of_device_is_compatible(np,
> + "allwinner,sun5i-a13-usb-phy")) {
> + data->num_phys = 2;
> + data->disc_thresh = 2;
> + } else { /* allwinner,sun7i-a20-usb-phy */
> + data->num_phys = 3;
> + data->disc_thresh = 2;
> + }
> +
> + data->clk = devm_clk_get(dev, "usb_phy");
> + if (IS_ERR(data->clk)) {
> + dev_err(dev, "could not get usb_phy clock\n");
> + return PTR_ERR(data->clk);
> + }
> +
> + /* Skip 0, 0 is the phy for otg which is not yet supported. */
> + for (i = 1; i < data->num_phys; i++) {
> + snprintf(name, sizeof(name), "usb%d_vbus", i);
> + vbus = devm_regulator_get_optional(dev, name);
> + if (IS_ERR(vbus)) {
> + if (PTR_ERR(vbus) == -EPROBE_DEFER)
> + return -EPROBE_DEFER;
> + vbus = NULL;
> + }
> +
> + snprintf(name, sizeof(name), "usb%d_reset", i);
> + reset = devm_reset_control_get(dev, name);
> + if (IS_ERR(phy)) {
> + dev_err(dev, "failed to get reset %s\n", name);
> + return PTR_ERR(phy);
> + }
> +
> + if (i) { /* No pmu_irq for usbc0 */
> + pmu_irq = devm_ioremap_resource(dev,
> + platform_get_resource(pdev, IORESOURCE_MEM, i));
> + if (IS_ERR(pmu_irq))
> + return PTR_ERR(pmu_irq);
> + }
> +
> + phy = devm_phy_create(dev, &sun4i_usb_phy_ops, NULL);
> + if (IS_ERR(phy)) {
> + dev_err(dev, "failed to create PHY %d\n", i);
> + return PTR_ERR(phy);
> + }
> +
> + data->phys[i].phy = phy;
> + data->phys[i].pmu_irq = pmu_irq;
> + data->phys[i].vbus = vbus;
> + data->phys[i].reset = reset;
> + data->phys[i].index = i;
> + phy_set_drvdata(phy, &data->phys[i]);
> + }
> +
> + data->base = devm_ioremap_resource(dev,
> + platform_get_resource(pdev, IORESOURCE_MEM, 0));
> + if (IS_ERR(data->base))
> + return PTR_ERR(data->base);
> +
> + dev_set_drvdata(dev, data);
> + phy_provider = devm_of_phy_provider_register(dev, sun4i_usb_phy_xlate);
> + if (IS_ERR(phy_provider))
> + return PTR_ERR(phy_provider);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id sun4i_usb_phy_of_match[] = {
> + { .compatible = "allwinner,sun4i-a10-usb-phy" },
> + { .compatible = "allwinner,sun5i-a13-usb-phy" },
> + { .compatible = "allwinner,sun7i-a20-usb-phy" },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, sun4i_usb_phy_of_match);
> +
> +static struct platform_driver sun4i_usb_phy_driver = {
> + .probe = sun4i_usb_phy_probe,
> + .driver = {
> + .of_match_table = sun4i_usb_phy_of_match,
> + .name = "sun4i-usb-phy",
> + .owner = THIS_MODULE,
> + }
> +};
> +module_platform_driver(sun4i_usb_phy_driver);
> +
> +MODULE_DESCRIPTION("Allwinner sun4i USB phy driver");
> +MODULE_AUTHOR("Hans de Goede <hdegoede@redhat.com>");
> +MODULE_LICENSE("GPL");
GPL v2?
This patch looks good apart from those minor comments.
Cheers
Kishon
^ permalink raw reply
* [PATCH v5 1/2] ohci-platform: Add support for devicetree instantiation
From: Hans de Goede @ 2014-01-15 15:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <Pine.LNX.4.44L0.1401141404420.1310-100000@iolanthe.rowland.org>
Hi,
On 01/14/2014 08:08 PM, Alan Stern wrote:
> On Mon, 13 Jan 2014, Hans de Goede wrote:
>
>> Add support for ohci-platform instantiation from devicetree, including
>> optionally getting clks and a phy from devicetree, and enabling / disabling
>> those on power_on / off.
>>
>> This should allow using ohci-platform from devicetree in various cases.
>> Specifically after this commit it can be used for the ohci controller found
>> on Allwinner sunxi SoCs.
>
> This is fine as far as I am concerned, except for one thing.
>
>> @@ -60,17 +127,23 @@ static int ohci_platform_probe(struct platform_device *dev)
>> struct usb_hcd *hcd;
>> struct resource *res_mem;
>> struct usb_ohci_pdata *pdata = dev_get_platdata(&dev->dev);
>> - int irq;
>> - int err = -ENOMEM;
>> -
>> - if (!pdata) {
>> - WARN_ON(1);
>> - return -ENODEV;
>> - }
>> + struct ohci_platform_priv *priv;
>> + int clk, irq, err;
>
> clk isn't initialized to anything...
Good catch, will fix and then do a v6 with this + the issue from your other mail fixed
and I'll add your ack.
>
>> -err_put_hcd:
>> - usb_put_hcd(hcd);
>> err_power:
>> if (pdata->power_off)
>> pdata->power_off(dev);
>> +err_put_clks:
>> + while (--clk >= 0)
>> + clk_put(priv->clks[clk]);
>
> ... but it gets used here. The compiler should have warned about this.
Should have yes, but it doesn't (I've just double checked).
> After fixing that, you can add
>
> Acked-by: Alan Stern <stern@rowland.harvard.edu>
Thanks & Regards,
Hans
^ permalink raw reply
* [RFC PATCH 3/9] of: mtd: add NAND timings retrieval support
From: boris brezillon @ 2014-01-15 15:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140109173505.GB8899@obsidianresearch.com>
Hello Jason,
On 09/01/2014 18:35, Jason Gunthorpe wrote:
> On Thu, Jan 09, 2014 at 09:36:18AM +0100, boris brezillon wrote:
>
>>> You might want to check if you can boil down the DT timings from the
>>> huge list to just an ONFI mode number..
>> Sure, but the sunxi driver needs at least 19 of them...
> So does mvebu's NAND driver..
>
> What I ment was you could have a
>
> onfi,nand-timing-mode = 0
>
> in the DT. Each of the modes defines all ~19 parameters, higher modes
> are faster.
>
> Pick a mode value that fits all the parameters of the connected
> non-ONFI flash.
>
> This would be instead of defining each parameter
> individually.. Provide some helpers to convert from a onfi mode number
> to all the onfi defined timing parameters so that drivers can
> configure the HW..
Are you suggesting we should provide a function that converts these
modes into a nand_timings struct, or just use the timing modes and
let the NAND controller drivers configure its IP accordingly ?
I found the ONFI timing tables in this document:
www.*onfi*.org/~/media/*ONFI*/specs/*onfi*_3_1_spec.pdf? (chapter 4.16).
I suppose my nand_timings struct should use the names described
page 110-111 (at least if we decide to use nand_timings and not
nand_timing_modes), right ?
Best Regards,
Boris
>
> Jason
^ permalink raw reply
* [RFC PATCH 1/1] of/irq: create interrupts-extended-2 property
From: Rob Herring @ 2014-01-15 15:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140115134653.GF25824@e106331-lin.cambridge.arm.com>
On Wed, Jan 15, 2014 at 7:46 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Wed, Jan 15, 2014 at 12:40:41PM +0000, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> On 12:17 Wed 15 Jan , Mark Rutland wrote:
>> > On Wed, Jan 15, 2014 at 11:47:25AM +0000, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> > > The new interrupts-extended property, which reuses the phandle+arguments
>> > > pattern used by GPIOs and other core bindings, still have some issue.
>> > >
>> > > If an SoC have already specifiy interrupt and a board want to add specific
>> > > interrupt such as GPIO (which can be optionnal) be need to re-define
>> > > interrupts-extended. So allow to have an optionnale interrupts-extended-2
>> > > property.
>> > >
>> >
>> > NAK.
>> >
>> > This is a hack that works around a dts organisation issue. This is _not_
>> > a binding or parsing issue.
>>
>> So the DT is stupid. Yes w have board and SoC information
>> so we do not want to duplicate them. Having a way to descript SoC vs board
>> specific information need to be provided.
>
> I agree that the current situation isn't fantastic. That doesn't make
> the DT stupid. There are other solutions to this problem.
>
>>
>> >
>> > Properties can be overridden - just describe all of the interrupts in
>> > the final dts file.
>> this is wrong, which mean you duplicate informaation and duplicate bug and
>> fixes
>
> It's certainly not nice, but it doesn't make it wrong.
>
> The same problem can be found with any other list property that varies
> per-board. Hacking the parsing of each property is not a solution.
>
> Today the only way to implement what you want is to have the list in the
> final file.
>
> One way of working with that would be to have the common interrupts
> described in a shared macro in the soc file:
>
> #define SOC_COMMON_INTERRUPTS <&intc1 5 1>, <&intc2 1 0>
Yuck. Please, let's not encourage this pattern.
> Then the soc file can have:
>
> interrupts = SOC_COMMON_INTERRUPTS;
>
> And the board can have:
>
> interrupts = SOC_COMMON_INTERRUPTS, <&intc1 6 1>;
Unless this is solved in dtc include mechanism, just duplicate the
interrupts in each board file. I'd rather have the duplication than
continued churn of refactoring dtsi files.
Rob
^ permalink raw reply
* device-tree: at91: irq and gpios: problem while requesting a gpio used as an interrupt source.
From: Jean-Christophe PLAGNIOL-VILLARD @ 2014-01-15 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACh+v5Oda3hDZ_nTMuWocnJfL_8OarZB9h+dnXnHzeEvva33AA@mail.gmail.com>
On 15:41 Wed 15 Jan , Jean-Jacques Hiblot wrote:
> 2014/1/15 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>:
> > On 14:44 Wed 15 Jan , Jean-Jacques Hiblot wrote:
> >> 2014/1/15 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>:
> >> > On 14:04 Wed 15 Jan , Jean-Jacques Hiblot wrote:
> >> >> 2014/1/15 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>:
> >> >> > On 12:05 Mon 13 Jan , Jean-Jacques Hiblot wrote:
> >> >> >> Hi Boris,
> >> >> >>
> >> >> >> 2014/1/13 boris brezillon <b.brezillon@overkiz.com>:
> >> >> >> > On 13/01/2014 11:29, Jean-Jacques Hiblot wrote:
> >> >> >> >>
> >> >> >> >> Hello Nicolas, Jean-Christophe,
> >> >> >> >>
> >> >> >> >> As I was trying to enable the touchscreen on the at91sam9261ek with
> >> >> >> >> device-tree support, I ran into an issue. The touchscreen driver needs
> >> >> >> >> to know the state of the pendown gpio and also needs it as an
> >> >> >> >> interrupt source.
> >> >> >> >>
> >> >> >> >> The problem is that when a gpio is used as an interrupt, it's
> >> >> >> >> requested by the pinctrl driver during the xlate stage, marking it
> >> >> >> >> unavaliable for the other driver.
> >> >> >> >> It looks like the at91 pinctrl driver is the only one to use
> >> >> >> >> gpio_request() in the xlate stage. Maybe we should remove this:
> >> >> >> >
> >> >> >> >
> >> >> >> > You should only request it as a GPIO and then use gpio_to_irq to get the
> >> >> >> > related IRQ.
> >> >> >> > Because what is done here, is to solve the case where only the irq
> >> >> >> > is request, and in this specific case we need to request the pin as a
> >> >> >> > GPIO.
> >> >> >> >
> >> >> >>
> >> >> >> That's what I did first, and was about to submit the patch for the
> >> >> >> touchscreen driver.
> >> >> >> However it doesn't feel right. Being able to get the state of a gpio
> >> >> >> that is also an interrupt seems very useful to me, not only for a
> >> >> >> touchscreen controller.
> >> >> >>
> >> >> >> I understand why it's being done here. It's a matter of being sure
> >> >> >> that the GPIO is an input and that it'll not be configured otherwise
> >> >> >> latter.
> >> >> >> But:
> >> >> >> 1) I'm wondering why the atmel pinctrl is the only one to do that.
> >> >> >
> >> >> > because this the only to start to do it right
> >> >> > I had a very long discussion woth LinusW and Grant the Gpio need to stop to
> >> >> > use gpio_to_irq & co for irq.
> >> >> How can you get the value of the gpio that is also an interrupt source then ?
> >> >> Can you give a short example?
> >> >
> >> > you just have to check the irq source
> >> >
> >> > failing or raising
> >> >
> >> > but on 9261 impossible the gpio does not have such detail
> >> >
> >> > but anyway this is the invert you need to get the information from the IRQ no the way
> >> > arround
> >>
> >> Should I modify the touchscreen driver to use irq_to_gpio() in this
> >> case then ? or is this also not proper ?
> >>
> > no as said by arnd irq_to_gpio does not exsit
> >
> > that's why I said the irq need to provide you the information as it's a
> > raising or failing irq
>
> Even when this kind of information is available it's not enough to
> know for sure the state of the gpio. Think of short pulses such as the
> glitches you have when you press a button.
this why you have debounce in the gpio IP to solve this
Best Regards,
J.
>
> >
> > Best Regards,
> > J.
^ permalink raw reply
* [RFC 0/2] Early patches to get rid of meminfo
From: Rob Herring @ 2014-01-15 15:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389765322-28582-1-git-send-email-lauraa@codeaurora.org>
On Tue, Jan 14, 2014 at 11:55 PM, Laura Abbott <lauraa@codeaurora.org> wrote:
> Hi,
>
> With the move away from bootmem and the convergence on memblock, it seems
> like meminfo should be deprecated as well to avoid duplication. This is
> a first pass attempt to just use memblock and not have meminfo integrated.
> There is still a major issue in terms of actually specifying mem at location
> on the command line but I wanted to send this out for some early feedback
> before putting any more effort into this. I've done basic boot testing on
> a simple DT target.
Nice. One thing I would like to see done in this area is ARM using the
default early_init_dt_add_memory_arch function. It currently doesn't
because of the dependency on meminfo.
Rob
^ permalink raw reply
* [RFC PATCH 1/1] of/irq: create interrupts-extended-2 property
From: Rob Herring @ 2014-01-15 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqKbFw4OSkjxYafuaDsmRPU3RXZB8dhJ4zxyaUwSRwfpPw@mail.gmail.com>
Fixing DT list address...
On Wed, Jan 15, 2014 at 9:16 AM, Rob Herring <robherring2@gmail.com> wrote:
> On Wed, Jan 15, 2014 at 7:46 AM, Mark Rutland <mark.rutland@arm.com> wrote:
>> On Wed, Jan 15, 2014 at 12:40:41PM +0000, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>> On 12:17 Wed 15 Jan , Mark Rutland wrote:
>>> > On Wed, Jan 15, 2014 at 11:47:25AM +0000, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>> > > The new interrupts-extended property, which reuses the phandle+arguments
>>> > > pattern used by GPIOs and other core bindings, still have some issue.
>>> > >
>>> > > If an SoC have already specifiy interrupt and a board want to add specific
>>> > > interrupt such as GPIO (which can be optionnal) be need to re-define
>>> > > interrupts-extended. So allow to have an optionnale interrupts-extended-2
>>> > > property.
>>> > >
>>> >
>>> > NAK.
>>> >
>>> > This is a hack that works around a dts organisation issue. This is _not_
>>> > a binding or parsing issue.
>>>
>>> So the DT is stupid. Yes w have board and SoC information
>>> so we do not want to duplicate them. Having a way to descript SoC vs board
>>> specific information need to be provided.
>>
>> I agree that the current situation isn't fantastic. That doesn't make
>> the DT stupid. There are other solutions to this problem.
>>
>>>
>>> >
>>> > Properties can be overridden - just describe all of the interrupts in
>>> > the final dts file.
>>> this is wrong, which mean you duplicate informaation and duplicate bug and
>>> fixes
>>
>> It's certainly not nice, but it doesn't make it wrong.
>>
>> The same problem can be found with any other list property that varies
>> per-board. Hacking the parsing of each property is not a solution.
>>
>> Today the only way to implement what you want is to have the list in the
>> final file.
>>
>> One way of working with that would be to have the common interrupts
>> described in a shared macro in the soc file:
>>
>> #define SOC_COMMON_INTERRUPTS <&intc1 5 1>, <&intc2 1 0>
>
> Yuck. Please, let's not encourage this pattern.
>
>> Then the soc file can have:
>>
>> interrupts = SOC_COMMON_INTERRUPTS;
>>
>> And the board can have:
>>
>> interrupts = SOC_COMMON_INTERRUPTS, <&intc1 6 1>;
>
> Unless this is solved in dtc include mechanism, just duplicate the
> interrupts in each board file. I'd rather have the duplication than
> continued churn of refactoring dtsi files.
>
> Rob
^ permalink raw reply
* device-tree: at91: irq and gpios: problem while requesting a gpio used as an interrupt source.
From: Jean-Jacques Hiblot @ 2014-01-15 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140115152514.GH9558@ns203013.ovh.net>
2014/1/15 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>:
> On 15:41 Wed 15 Jan , Jean-Jacques Hiblot wrote:
>> 2014/1/15 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>:
>> > On 14:44 Wed 15 Jan , Jean-Jacques Hiblot wrote:
>> >> 2014/1/15 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>:
>> >> > On 14:04 Wed 15 Jan , Jean-Jacques Hiblot wrote:
>> >> >> 2014/1/15 Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>:
>> >> >> > On 12:05 Mon 13 Jan , Jean-Jacques Hiblot wrote:
>> >> >> >> Hi Boris,
>> >> >> >>
>> >> >> >> 2014/1/13 boris brezillon <b.brezillon@overkiz.com>:
>> >> >> >> > On 13/01/2014 11:29, Jean-Jacques Hiblot wrote:
>> >> >> >> >>
>> >> >> >> >> Hello Nicolas, Jean-Christophe,
>> >> >> >> >>
>> >> >> >> >> As I was trying to enable the touchscreen on the at91sam9261ek with
>> >> >> >> >> device-tree support, I ran into an issue. The touchscreen driver needs
>> >> >> >> >> to know the state of the pendown gpio and also needs it as an
>> >> >> >> >> interrupt source.
>> >> >> >> >>
>> >> >> >> >> The problem is that when a gpio is used as an interrupt, it's
>> >> >> >> >> requested by the pinctrl driver during the xlate stage, marking it
>> >> >> >> >> unavaliable for the other driver.
>> >> >> >> >> It looks like the at91 pinctrl driver is the only one to use
>> >> >> >> >> gpio_request() in the xlate stage. Maybe we should remove this:
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > You should only request it as a GPIO and then use gpio_to_irq to get the
>> >> >> >> > related IRQ.
>> >> >> >> > Because what is done here, is to solve the case where only the irq
>> >> >> >> > is request, and in this specific case we need to request the pin as a
>> >> >> >> > GPIO.
>> >> >> >> >
>> >> >> >>
>> >> >> >> That's what I did first, and was about to submit the patch for the
>> >> >> >> touchscreen driver.
>> >> >> >> However it doesn't feel right. Being able to get the state of a gpio
>> >> >> >> that is also an interrupt seems very useful to me, not only for a
>> >> >> >> touchscreen controller.
>> >> >> >>
>> >> >> >> I understand why it's being done here. It's a matter of being sure
>> >> >> >> that the GPIO is an input and that it'll not be configured otherwise
>> >> >> >> latter.
>> >> >> >> But:
>> >> >> >> 1) I'm wondering why the atmel pinctrl is the only one to do that.
>> >> >> >
>> >> >> > because this the only to start to do it right
>> >> >> > I had a very long discussion woth LinusW and Grant the Gpio need to stop to
>> >> >> > use gpio_to_irq & co for irq.
>> >> >> How can you get the value of the gpio that is also an interrupt source then ?
>> >> >> Can you give a short example?
>> >> >
>> >> > you just have to check the irq source
>> >> >
>> >> > failing or raising
>> >> >
>> >> > but on 9261 impossible the gpio does not have such detail
>> >> >
>> >> > but anyway this is the invert you need to get the information from the IRQ no the way
>> >> > arround
>> >>
>> >> Should I modify the touchscreen driver to use irq_to_gpio() in this
>> >> case then ? or is this also not proper ?
>> >>
>> > no as said by arnd irq_to_gpio does not exsit
>> >
>> > that's why I said the irq need to provide you the information as it's a
>> > raising or failing irq
>>
>> Even when this kind of information is available it's not enough to
>> know for sure the state of the gpio. Think of short pulses such as the
>> glitches you have when you press a button.
>
> this why you have debounce in the gpio IP to solve this
Unfortunately, the debounce filter in the IP not appropriate to handle
the glitches such as what you have in the case of a button.
It may be good enough to filter EMI induced pulses but not mechanical
ones which are way too long.
>
> Best Regards,
> J.
>>
>> >
>> > Best Regards,
>> > J.
^ permalink raw reply
* [PATCH] mmc: dw_mmc: fix dw_mci_get_cd
From: zhangfei @ 2014-01-15 15:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <002c01cf11ff$6790a8a0$36b1f9e0$%jun@samsung.com>
On 01/15/2014 10:38 PM, Seungwon Jeon wrote:
>> Hmm, looks you are right.
>> Though not see clearly mmc_gpio_get_cd declaratoin, other drivers
>> directly set get_cd as mmc_gpio_get_cd.
>> .get_cd = mmc_gpio_get_cd
>>
>> However, in our board cd =0 when card is deteced while cd=1 when card is
>> removed.
>> In order to mmc_gpio_get_cd return 1, MMC_CAP2_CD_ACTIVE_HIGH has to be
>> set, as well as new property "caps2-mmc-cd-active-low".
>
> Ok, you could do more.
> mmc_gpio_get_cd() is expected to return non-zero if card is detection.
> I think your board seems not to use pull-up on GPIO line for card detection.
> So, MMC_CAP2_CD_ACTIVE_HIGH would be needed.
Unfortunately, the specific cd pin can not be configured.
Suspect on our board the cd =1 when card is inserted, can not measure as
no clear resister and need check with hardware guy tomorrow.
"cd-inverted" may be required as mentioned by Arnd.
Will update the patch as following if no problem.
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 9ded62c8225e..8326e54b96a8 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1042,7 +1042,7 @@ static int dw_mci_get_cd(struct mmc_host *mmc)
else if (brd->get_cd)
present = !brd->get_cd(slot->id);
else if (!IS_ERR_VALUE(gpio_cd))
- present = !gpio_cd;
+ present = gpio_cd ^ brd->cd_inverted;
else
present = (mci_readl(slot->host, CDETECT) & (1 << slot->id))
== 0 ? 1 : 0;
@@ -2414,6 +2414,9 @@ static struct dw_mci_board *dw_mci_parse_dt(struct
dw_mci *host)
if (of_find_property(np, "caps2-mmc-hs200-1_2v", NULL))
pdata->caps2 |= MMC_CAP2_HS200_1_2V_SDR;
+ if (of_get_property(np, "cd-inverted", NULL))
+ pdata->cd_inverted = 1;
+
return pdata;
}
diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h
index 6ce7d2cd3c7a..4535282589ab 100644
--- a/include/linux/mmc/dw_mmc.h
+++ b/include/linux/mmc/dw_mmc.h
@@ -238,6 +238,7 @@ struct dw_mci_board {
u32 caps; /* Capabilities */
u32 caps2; /* More capabilities */
u32 pm_caps; /* PM capabilities */
+ u8 cd_inverted;
^ permalink raw reply related
* [PATCH] mmc: dw_mmc: fix dw_mci_get_cd
From: zhangfei @ 2014-01-15 15:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9483154.XYFILpUqYN@wuerfel>
On 01/15/2014 10:20 PM, Arnd Bergmann wrote:
> On Wednesday 15 January 2014 14:59:59 Arnd Bergmann wrote:
>> On Wednesday 15 January 2014 21:56:26 zhangfei wrote:
>>> However, in our board cd =0 when card is deteced while cd=1 when card is
>>> removed.
>>> In order to mmc_gpio_get_cd return 1, MMC_CAP2_CD_ACTIVE_HIGH has to be
>>> set, as well as new property "caps2-mmc-cd-active-low".
>>>
>>> --- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
>>> +++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
>>> @@ -73,6 +73,8 @@ Optional properties:
>>> +* caps2-mmc-cd-active-low: cd pin is low when card active
>>> +
>>>
>>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>>> + if (of_find_property(np, "caps2-mmc-cd-active-low", NULL))
>>> + pdata->caps2 |= MMC_CAP2_CD_ACTIVE_HIGH;
>>> +
>>
>> The MMC_CAP2_CD_ACTIVE_HIGH flag should only be required for
>> legacy platforms. With DT parsing, you can normally specify
>> the polarity of the GPIO line in the GPIO specifier in DT.
>
> I missed the fact that we already have a "cd-inverted" property
> as specified in bindings/mmc/mmc.txt. If your GPIO controller
> does not handle polarity, you can use that.
>
Thanks Arnd
GPIO controller drivers/gpio/gpio-pl061.c still not handle polarity, so
use "cd-inverted" instead.
^ permalink raw reply
* [PATCH] arch_timer: Move delay timer to drivers clocksource
From: Rob Herring @ 2014-01-15 15:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389791227-24097-1-git-send-email-pgaikwad@nvidia.com>
On Wed, Jan 15, 2014 at 7:07 AM, Prashant Gaikwad <pgaikwad@nvidia.com> wrote:
> Now arch timer is registerd using generic sched timer, delay
> timer registration is the only part remaining in arch ports.
> Move this part to drivers clocksource and remove arch timer
> from arch ports.
>
> Signed-off-by: Prashant Gaikwad <pgaikwad@nvidia.com>
> ---
> arch/arm/include/asm/arch_timer.h | 1 -
> arch/arm/kernel/Makefile | 1 -
> arch/arm/kernel/arch_timer.c | 44 ----------------------------------
> arch/arm64/include/asm/arch_timer.h | 5 ----
> arch/arm64/include/asm/delay.h | 32 ++++++++++++++++++++++++
> arch/arm64/include/asm/timex.h | 5 +--
> arch/arm64/kernel/time.c | 9 -------
> arch/arm64/lib/delay.c | 26 ++++++++++++++++++++
> drivers/clocksource/arm_arch_timer.c | 12 ++++++++-
> 9 files changed, 71 insertions(+), 64 deletions(-)
> delete mode 100644 arch/arm/kernel/arch_timer.c
> create mode 100644 arch/arm64/include/asm/delay.h
>
> diff --git a/arch/arm/include/asm/arch_timer.h b/arch/arm/include/asm/arch_timer.h
> index 0704e0c..61ad692 100644
> --- a/arch/arm/include/asm/arch_timer.h
> +++ b/arch/arm/include/asm/arch_timer.h
> @@ -10,7 +10,6 @@
> #include <clocksource/arm_arch_timer.h>
>
> #ifdef CONFIG_ARM_ARCH_TIMER
> -int arch_timer_arch_init(void);
>
> /*
> * These register accessors are marked inline so the compiler can
> diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
> index a30fc9b..6b51cf9 100644
> --- a/arch/arm/kernel/Makefile
> +++ b/arch/arm/kernel/Makefile
> @@ -45,7 +45,6 @@ obj-$(CONFIG_SMP) += smp_tlb.o
> endif
> obj-$(CONFIG_HAVE_ARM_SCU) += smp_scu.o
> obj-$(CONFIG_HAVE_ARM_TWD) += smp_twd.o
> -obj-$(CONFIG_ARM_ARCH_TIMER) += arch_timer.o
> obj-$(CONFIG_DYNAMIC_FTRACE) += ftrace.o insn.o
> obj-$(CONFIG_FUNCTION_GRAPH_TRACER) += ftrace.o insn.o
> obj-$(CONFIG_JUMP_LABEL) += jump_label.o insn.o patch.o
> diff --git a/arch/arm/kernel/arch_timer.c b/arch/arm/kernel/arch_timer.c
> deleted file mode 100644
> index 1791f12..0000000
> --- a/arch/arm/kernel/arch_timer.c
> +++ /dev/null
> @@ -1,44 +0,0 @@
> -/*
> - * linux/arch/arm/kernel/arch_timer.c
> - *
> - * Copyright (C) 2011 ARM Ltd.
> - * All Rights Reserved
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
> - */
> -#include <linux/init.h>
> -#include <linux/types.h>
> -#include <linux/errno.h>
> -
> -#include <asm/delay.h>
> -
> -#include <clocksource/arm_arch_timer.h>
> -
> -static unsigned long arch_timer_read_counter_long(void)
> -{
> - return arch_timer_read_counter();
> -}
> -
> -static struct delay_timer arch_delay_timer;
> -
> -static void __init arch_timer_delay_timer_register(void)
> -{
> - /* Use the architected timer for the delay loop. */
> - arch_delay_timer.read_current_timer = arch_timer_read_counter_long;
> - arch_delay_timer.freq = arch_timer_get_rate();
> - register_current_timer_delay(&arch_delay_timer);
> -}
> -
> -int __init arch_timer_arch_init(void)
> -{
> - u32 arch_timer_rate = arch_timer_get_rate();
> -
> - if (arch_timer_rate == 0)
> - return -ENXIO;
> -
> - arch_timer_delay_timer_register();
> -
> - return 0;
> -}
> diff --git a/arch/arm64/include/asm/arch_timer.h b/arch/arm64/include/asm/arch_timer.h
> index 9400596..48e06bd 100644
> --- a/arch/arm64/include/asm/arch_timer.h
> +++ b/arch/arm64/include/asm/arch_timer.h
> @@ -145,9 +145,4 @@ static inline u64 arch_counter_get_cntvct(void)
> return cval;
> }
>
> -static inline int arch_timer_arch_init(void)
> -{
> - return 0;
> -}
> -
> #endif
> diff --git a/arch/arm64/include/asm/delay.h b/arch/arm64/include/asm/delay.h
> new file mode 100644
> index 0000000..ea90d99
> --- /dev/null
> +++ b/arch/arm64/include/asm/delay.h
> @@ -0,0 +1,32 @@
> +
> +/*
> + * Copyright (c) 2014, NVIDIA Corporation. All rights reserved.
> + *
> + * 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/>.
> + */
> +
> +#ifndef __ASM_ARM64_DELAY_H
> +#define __ASM_ARM64_DELAY_H
> +
> +#include <asm-generic/delay.h>
> +
> +struct delay_timer {
> + unsigned long (*read_current_timer)(void);
> + unsigned long freq;
> +};
> +
> +/* Delay-loop timer registration. */
> +#define ARCH_HAS_READ_CURRENT_TIMER
> +extern void register_current_timer_delay(const struct delay_timer *timer);
Can't all but the define be moved to a common location?
> +
> +#endif /* defined(_ARM64_DELAY_H) */
> diff --git a/arch/arm64/include/asm/timex.h b/arch/arm64/include/asm/timex.h
> index 81a076e..ca4bdfb 100644
> --- a/arch/arm64/include/asm/timex.h
> +++ b/arch/arm64/include/asm/timex.h
> @@ -16,13 +16,12 @@
> #ifndef __ASM_TIMEX_H
> #define __ASM_TIMEX_H
>
> -#include <asm/arch_timer.h>
> -
> /*
> * Use the current timer as a cycle counter since this is what we use for
> * the delay loop.
> */
> -#define get_cycles() arch_counter_get_cntvct()
> +typedef unsigned long cycles_t;
> +#define get_cycles() ({ cycles_t c; read_current_timer(&c) ? 0 : c; })
Could be in a common location conditional on ARCH_HAS_READ_CURRENT_TIMER.
> #include <asm-generic/timex.h>
>
> diff --git a/arch/arm64/kernel/time.c b/arch/arm64/kernel/time.c
> index 29c39d5..213d1a3 100644
> --- a/arch/arm64/kernel/time.c
> +++ b/arch/arm64/kernel/time.c
> @@ -63,14 +63,5 @@ EXPORT_SYMBOL(profile_pc);
>
> void __init time_init(void)
> {
> - u32 arch_timer_rate;
> -
> clocksource_of_init();
> -
> - arch_timer_rate = arch_timer_get_rate();
> - if (!arch_timer_rate)
> - panic("Unable to initialise architected timer.\n");
> -
> - /* Calibrate the delay loop directly */
> - lpj_fine = arch_timer_rate / HZ;
> }
> diff --git a/arch/arm64/lib/delay.c b/arch/arm64/lib/delay.c
> index dad4ec9..cde0a28 100644
> --- a/arch/arm64/lib/delay.c
> +++ b/arch/arm64/lib/delay.c
> @@ -24,6 +24,19 @@
> #include <linux/module.h>
> #include <linux/timex.h>
>
> +static const struct delay_timer *delay_timer;
> +static bool delay_calibrated;
> +
> +int read_current_timer(unsigned long *timer_val)
> +{
> + if (!delay_timer)
> + return -ENXIO;
> +
> + *timer_val = delay_timer->read_current_timer();
> + return 0;
> +}
> +EXPORT_SYMBOL(read_current_timer);
> +
This too could be common.
> void __delay(unsigned long cycles)
> {
> cycles_t start = get_cycles();
> @@ -53,3 +66,16 @@ void __ndelay(unsigned long nsecs)
> __const_udelay(nsecs * 0x5UL); /* 2**32 / 1000000000 (rounded up) */
> }
> EXPORT_SYMBOL(__ndelay);
> +
> +void register_current_timer_delay(const struct delay_timer *timer)
> +{
> + if (!delay_calibrated) {
> + pr_info("Switching to timer-based delay loop\n");
> + delay_timer = timer;
> + lpj_fine = timer->freq / HZ;
> +
> + delay_calibrated = true;
> + } else {
> + pr_info("Ignoring duplicate/late registration of read_current_timer delay\n");
> + }
> +}
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index 57e823c..8ee9918 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -422,6 +422,16 @@ struct timecounter *arch_timer_get_timecounter(void)
> return &timecounter;
> }
>
> +static struct delay_timer arch_delay_timer;
> +
> +static void __init arch_delay_timer_register(void)
> +{
> + /* Use the architected timer for the delay loop. */
> + arch_delay_timer.read_current_timer = arch_timer_read_counter();
> + arch_delay_timer.freq = arch_timer_rate;
> + register_current_timer_delay(&arch_delay_timer);
> +}
> +
> static void __init arch_counter_register(unsigned type)
> {
> u64 start_count;
> @@ -630,7 +640,7 @@ static void __init arch_timer_common_init(void)
>
> arch_timer_banner(arch_timers_present);
> arch_counter_register(arch_timers_present);
> - arch_timer_arch_init();
> + arch_delay_timer_register();
> }
>
> static void __init arch_timer_init(struct device_node *np)
> --
> 1.7.4.1
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] arch_timer: Move delay timer to drivers clocksource
From: Will Deacon @ 2014-01-15 15:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389791227-24097-1-git-send-email-pgaikwad@nvidia.com>
Hello,
On Wed, Jan 15, 2014 at 01:07:07PM +0000, Prashant Gaikwad wrote:
> Now arch timer is registerd using generic sched timer, delay
> timer registration is the only part remaining in arch ports.
> Move this part to drivers clocksource and remove arch timer
> from arch ports.
What's the advantage in doing this? I'd have thought consolidation, but...
> Signed-off-by: Prashant Gaikwad <pgaikwad@nvidia.com>
> ---
> arch/arm/include/asm/arch_timer.h | 1 -
> arch/arm/kernel/Makefile | 1 -
> arch/arm/kernel/arch_timer.c | 44 ----------------------------------
> arch/arm64/include/asm/arch_timer.h | 5 ----
> arch/arm64/include/asm/delay.h | 32 ++++++++++++++++++++++++
> arch/arm64/include/asm/timex.h | 5 +--
> arch/arm64/kernel/time.c | 9 -------
> arch/arm64/lib/delay.c | 26 ++++++++++++++++++++
> drivers/clocksource/arm_arch_timer.c | 12 ++++++++-
> 9 files changed, 71 insertions(+), 64 deletions(-)
... that's a positive diffstat! I also think that delaying the delay loop
initialisation for arm64 could be problematic, since we don't have anything
to fall back on (like the busy-loop on ARM) in case of early *delay calls.
What happens if I call udelay on arm64 before the counter has registered?
Will
^ permalink raw reply
* [PATCH] ARM: sunxi: Add driver for sunxi usb phy
From: Hans de Goede @ 2014-01-15 15:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D6A27A.4090600@ti.com>
Hi,
On 01/15/2014 04:00 PM, Kishon Vijay Abraham I wrote:
> On Wednesday 15 January 2014 04:28 AM, Hans de Goede wrote:
>> The Allwinner A1x / A2x SoCs have 2 or 3 usb phys which are all accessed
>> through a single set of registers. Besides this there are also some other
>> phy related bits which need poking, which are per phy, but shared between the
>> ohci and ehci controllers, so these are also controlled from this new phy
>> driver.
>>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>> .../devicetree/bindings/phy/sun4i-usb-phy.txt | 26 ++
>> drivers/phy/Kconfig | 11 +
>> drivers/phy/Makefile | 1 +
>> drivers/phy/phy-sun4i-usb.c | 318 +++++++++++++++++++++
>> 4 files changed, 356 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
>> create mode 100644 drivers/phy/phy-sun4i-usb.c
>>
>> diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
>> new file mode 100644
>> index 0000000..6c54b3b
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
>> @@ -0,0 +1,26 @@
>> +Allwinner sun4i USB PHY
>> +-----------------------
>> +
>> +Required properties:
>> +- compatible : should be one of "allwinner,sun4i-a10-usb-phy",
>> + "allwinner,sun5i-a13-usb-phy" or "allwinner,sun7i-a20-usb-phy"
>> +- reg : 2 or 3 register offset + length pairs, 1 phy base reg pair +
>> + 1 pair for the pmu-irq register of each hcd
>> +- #phy-cells : from the generic phy bindings, must be 1
>> +
>> +Optional properties:
>> +- clocks : phandle + clock specifier for the phy clock
>> +- clock-names : "usb_phy"
>> +- resets : a list of phandle + reset specifier pairs
>> +- reset-names : "usb0_reset", "usb1_reset", and / or "usb2_reset"
>> +
>> +Example:
>> + usbphy: phy at 0x01c13400 {
>> + #phy-cells = <1>;
>> + compatible = "allwinner,sun4i-a10-usb-phy";
>> + reg = <0x01c13400 0x10 0x01c14800 0x4 0x01c1c800 0x4>;
>> + clocks = <&usb_clk 8>;
>> + clock-names = "usb_phy";
>> + resets = <&usb_clk 1>, <&usb_clk 2>;
>> + reset-names = "usb1_reset", "usb2_reset";
>> + };
>> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
>> index 330ef2d..dcce4cf 100644
>> --- a/drivers/phy/Kconfig
>> +++ b/drivers/phy/Kconfig
>> @@ -51,4 +51,15 @@ config PHY_EXYNOS_DP_VIDEO
>> help
>> Support for Display Port PHY found on Samsung EXYNOS SoCs.
>>
>> +config PHY_SUN4I_USB
>> + tristate "Allwinner sunxi SoC USB PHY driver"
>> + depends on ARCH_SUNXI
>> + select GENERIC_PHY
>> + help
>> + Enable this to support the transceiver that is part of Allwinner
>> + sunxi SoCs.
>> +
>> + This driver controls the entire USB PHY block, both the USB OTG
>> + parts, as well as the 2 regular USB 2 host PHYs.
>> +
>> endmenu
>> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
>> index d0caae9..e9e82f0 100644
>> --- a/drivers/phy/Makefile
>> +++ b/drivers/phy/Makefile
>> @@ -7,3 +7,4 @@ obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-video.o
>> obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO) += phy-exynos-mipi-video.o
>> obj-$(CONFIG_OMAP_USB2) += phy-omap-usb2.o
>> obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o
>> +obj-$(CONFIG_PHY_SUN4I_USB) += phy-sun4i-usb.o
>> diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
>> new file mode 100644
>> index 0000000..a15ecc1
>> --- /dev/null
>> +++ b/drivers/phy/phy-sun4i-usb.c
>> @@ -0,0 +1,318 @@
>> +/*
>> + * Allwinner sun4i USB phy driver
>> + *
>> + * Copyright (C) 2014 Hans de Goede <hdegoede@redhat.com>
>> + *
>> + * Based on code from
>> + * Allwinner Technology Co., Ltd. <www.allwinnertech.com>
>> + *
>> + * Modelled after: Samsung S5P/EXYNOS SoC series MIPI CSIS/DSIM DPHY driver
>> + * Copyright (C) 2013 Samsung Electronics Co., Ltd.
>> + * Author: Sylwester Nawrocki <s.nawrocki@samsung.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation; either version 2 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that 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.
>> + */
>> +
>> +#include <linux/clk.h>
>> +#include <linux/io.h>
>> +#include <linux/kernel.h>
>> +#include <linux/module.h>
>> +#include <linux/mutex.h>
>> +#include <linux/of.h>
>> +#include <linux/of_address.h>
>> +#include <linux/phy/phy.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/regulator/consumer.h>
>> +#include <linux/reset.h>
>> +
>> +#define REG_ISCR 0x00
>> +#define REG_PHYCTL 0x04
>> +#define REG_PHYBIST 0x08
>> +#define REG_PHYTUNE 0x0c
>> +
>> +#define SUNXI_AHB_ICHR8_EN BIT(10)
>> +#define SUNXI_AHB_INCR4_BURST_EN BIT(9)
>> +#define SUNXI_AHB_INCRX_ALIGN_EN BIT(8)
>> +#define SUNXI_ULPI_BYPASS_EN BIT(0)
>> +
>> +#define MAX_PHYS 3
>> +
>> +struct sun4i_usb_phy_data {
>> + struct clk *clk;
>> + void __iomem *base;
>> + struct mutex mutex;
>> + int num_phys;
>> + u32 disc_thresh;
>> + struct sun4i_usb_phy {
>> + struct phy *phy;
>> + void __iomem *pmu_irq;
>
> 'pmu_irq' is misleading. Can you think of a better name?
The pmu_irq name comes from android sources, but I agree it is no good,
how about just pmu ?
> Btw Kamil uses syscon interface to set pmu bits. Is it applicable here also?
Both Kamil and syscon are now to me, do you have a pointer to example sources
for this?
>> + struct regulator *vbus;
>> + struct reset_control *reset;
>> + int index;
>> + } phys[MAX_PHYS];
>> +};
>> +
>> +#define to_sun4i_usb_phy_data(phy) \
>> + container_of((phy), struct sun4i_usb_phy_data, phys[(phy)->index])
>> +
>> +static void sun4i_usb_phy_write(struct sun4i_usb_phy *phy, u32 addr, u32 data,
>> + int len)
>> +{
>> + struct sun4i_usb_phy_data *phy_data = to_sun4i_usb_phy_data(phy);
>> + u32 temp, usbc_bit = BIT(phy->index * 2);
>> + int i;
>> +
>> + mutex_lock(&phy_data->mutex);
>> +
>> + for (i = 0; i < len; i++) {
>> + temp = readl(phy_data->base + REG_PHYCTL);
>> +
>> + /* clear the address portion */
>> + temp &= ~(0xff << 8);
>> +
>> + /* set the address */
>> + temp |= ((addr + i) << 8);
>> + writel(temp, phy_data->base + REG_PHYCTL);
>> +
>> + /* set the data bit and clear usbc bit*/
>> + temp = readb(phy_data->base + REG_PHYCTL);
>> + if (data & 0x1)
>> + temp |= BIT(7);
>> + else
>> + temp &= ~BIT(7);
>> + temp &= ~usbc_bit;
>> + writeb(temp, phy_data->base + REG_PHYCTL);
>> +
>> + /* pulse usbc_bit */
>> + temp = readb(phy_data->base + REG_PHYCTL);
>> + temp |= usbc_bit;
>> + writeb(temp, phy_data->base + REG_PHYCTL);
>> +
>> + temp = readb(phy_data->base + REG_PHYCTL);
>> + temp &= ~usbc_bit;
>> + writeb(temp, phy_data->base + REG_PHYCTL);
>> +
>> + data >>= 1;
>> + }
>> + mutex_unlock(&phy_data->mutex);
>> +}
>> +
>> +static void sun4i_usb_phy_passby(struct sun4i_usb_phy *phy, int enable)
>> +{
>> + u32 bits, reg_value;
>> +
>> + if (!phy->pmu_irq)
>> + return;
>> +
>> + bits = SUNXI_AHB_ICHR8_EN | SUNXI_AHB_INCR4_BURST_EN |
>> + SUNXI_AHB_INCRX_ALIGN_EN | SUNXI_ULPI_BYPASS_EN;
>> +
>> + reg_value = readl(phy->pmu_irq);
>> +
>> + if (enable)
>> + reg_value |= bits;
>> + else
>> + reg_value &= ~bits;
>> +
>> + writel(reg_value, phy->pmu_irq);
>> +}
>> +
>> +static int sun4i_usb_phy_init(struct phy *_phy)
>> +{
>> + struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
>> + struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
>> + int ret;
>> +
>> + ret = clk_prepare_enable(data->clk);
>> + if (ret)
>> + return ret;
>> +
>> + ret = reset_control_deassert(phy->reset);
>> + if (ret) {
>> + clk_disable_unprepare(data->clk);
>> + return ret;
>> + }
>> +
>> + /* Adjust PHY's magnitude and rate */
>> + sun4i_usb_phy_write(phy, 0x20, 0x14, 5);
>
> No magic values. Use macros instead.
We don't have docs, these values come from the Android code (and the comment
above has been translated from Chinese). I can make up some random
macros for this, but seems counter-productive, it seems best to just leave
this as magic until the day we actually have documentation and thus can use
defines with the proper register names, etc.
>> +
>> + /* Disconnect threshold adjustment */
>> + sun4i_usb_phy_write(phy, 0x2a, data->disc_thresh, 2);
>> +
>> + sun4i_usb_phy_passby(phy, 1);
>> +
>> + return 0;
>> +}
>> +
>> +static int sun4i_usb_phy_exit(struct phy *_phy)
>> +{
>> + struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
>> + struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
>> +
>> + sun4i_usb_phy_passby(phy, 0);
>> + reset_control_assert(phy->reset);
>> + clk_disable_unprepare(data->clk);
>
> Actually PHY API's can be called in interrupt context, in that case
> clk_disable_unprepare can't be used.
Erm, phy_init and phy_exit from drivers/phy/phy-core.c use mutex_lock,
so they can never be called from interrupt context.
>> +
>> + return 0;
>> +}
>> +
>> +static int sun4i_usb_phy_power_on(struct phy *_phy)
>> +{
>> + struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
>> + int ret;
>> +
>> + if (phy->vbus) {
>> + ret = regulator_enable(phy->vbus);
>> + if (ret)
>> + return ret;
>> +
>> + }
>> +
>> + return 0;
>> +}
>
> This can simply be
> int ret = 0;
> if (phy->vbus)
> ret = regulator_enable(phy->vbus);
> return ret;
Agreed, will fix as soon as its clear what to do with the other bits.
>> +
>> +static int sun4i_usb_phy_power_off(struct phy *_phy)
>> +{
>> + struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
>> +
>> + if (phy->vbus)
>> + regulator_disable(phy->vbus);
>> +
>> + return 0;
>> +}
>> +
>> +static struct phy_ops sun4i_usb_phy_ops = {
>> + .init = sun4i_usb_phy_init,
>> + .exit = sun4i_usb_phy_exit,
>> + .power_on = sun4i_usb_phy_power_on,
>> + .power_off = sun4i_usb_phy_power_off,
>> + .owner = THIS_MODULE,
>> +};
>> +
>> +static struct phy *sun4i_usb_phy_xlate(struct device *dev,
>> + struct of_phandle_args *args)
>> +{
>> + struct sun4i_usb_phy_data *data = dev_get_drvdata(dev);
>> +
>> + if (WARN_ON(args->args[0] == 0 || args->args[0] >= data->num_phys))
>> + return ERR_PTR(-ENODEV);
>> +
>> + return data->phys[args->args[0]].phy;
>> +}
>> +
>> +static int sun4i_usb_phy_probe(struct platform_device *pdev)
>> +{
>> + struct sun4i_usb_phy_data *data;
>> + struct device *dev = &pdev->dev;
>> + struct device_node *np = dev->of_node;
>> + void __iomem *pmu_irq = NULL;
>> + struct phy_provider *phy_provider;
>> + struct reset_control *reset;
>> + struct regulator *vbus;
>> + struct phy *phy;
>> + char name[16];
>> + int i;
>> +
>> + data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
>> + if (!data)
>> + return -ENOMEM;
>> +
>> + mutex_init(&data->mutex);
>> + if (of_device_is_compatible(np, "allwinner,sun4i-a10-usb-phy")) {
>> + data->num_phys = 3;
>> + data->disc_thresh = 3;
>> + } else if (of_device_is_compatible(np,
>> + "allwinner,sun5i-a13-usb-phy")) {
>> + data->num_phys = 2;
>> + data->disc_thresh = 2;
>> + } else { /* allwinner,sun7i-a20-usb-phy */
>> + data->num_phys = 3;
>> + data->disc_thresh = 2;
>> + }
>> +
>> + data->clk = devm_clk_get(dev, "usb_phy");
>> + if (IS_ERR(data->clk)) {
>> + dev_err(dev, "could not get usb_phy clock\n");
>> + return PTR_ERR(data->clk);
>> + }
>> +
>> + /* Skip 0, 0 is the phy for otg which is not yet supported. */
>> + for (i = 1; i < data->num_phys; i++) {
>> + snprintf(name, sizeof(name), "usb%d_vbus", i);
>> + vbus = devm_regulator_get_optional(dev, name);
>> + if (IS_ERR(vbus)) {
>> + if (PTR_ERR(vbus) == -EPROBE_DEFER)
>> + return -EPROBE_DEFER;
>> + vbus = NULL;
>> + }
>> +
>> + snprintf(name, sizeof(name), "usb%d_reset", i);
>> + reset = devm_reset_control_get(dev, name);
>> + if (IS_ERR(phy)) {
>> + dev_err(dev, "failed to get reset %s\n", name);
>> + return PTR_ERR(phy);
>> + }
>> +
>> + if (i) { /* No pmu_irq for usbc0 */
>> + pmu_irq = devm_ioremap_resource(dev,
>> + platform_get_resource(pdev, IORESOURCE_MEM, i));
>> + if (IS_ERR(pmu_irq))
>> + return PTR_ERR(pmu_irq);
>> + }
>> +
>> + phy = devm_phy_create(dev, &sun4i_usb_phy_ops, NULL);
>> + if (IS_ERR(phy)) {
>> + dev_err(dev, "failed to create PHY %d\n", i);
>> + return PTR_ERR(phy);
>> + }
>> +
>> + data->phys[i].phy = phy;
>> + data->phys[i].pmu_irq = pmu_irq;
>> + data->phys[i].vbus = vbus;
>> + data->phys[i].reset = reset;
>> + data->phys[i].index = i;
>> + phy_set_drvdata(phy, &data->phys[i]);
>> + }
>> +
>> + data->base = devm_ioremap_resource(dev,
>> + platform_get_resource(pdev, IORESOURCE_MEM, 0));
>> + if (IS_ERR(data->base))
>> + return PTR_ERR(data->base);
>> +
>> + dev_set_drvdata(dev, data);
>> + phy_provider = devm_of_phy_provider_register(dev, sun4i_usb_phy_xlate);
>> + if (IS_ERR(phy_provider))
>> + return PTR_ERR(phy_provider);
>> +
>> + return 0;
>> +}
>> +
>> +static const struct of_device_id sun4i_usb_phy_of_match[] = {
>> + { .compatible = "allwinner,sun4i-a10-usb-phy" },
>> + { .compatible = "allwinner,sun5i-a13-usb-phy" },
>> + { .compatible = "allwinner,sun7i-a20-usb-phy" },
>> + { },
>> +};
>> +MODULE_DEVICE_TABLE(of, sun4i_usb_phy_of_match);
>> +
>> +static struct platform_driver sun4i_usb_phy_driver = {
>> + .probe = sun4i_usb_phy_probe,
>> + .driver = {
>> + .of_match_table = sun4i_usb_phy_of_match,
>> + .name = "sun4i-usb-phy",
>> + .owner = THIS_MODULE,
>> + }
>> +};
>> +module_platform_driver(sun4i_usb_phy_driver);
>> +
>> +MODULE_DESCRIPTION("Allwinner sun4i USB phy driver");
>> +MODULE_AUTHOR("Hans de Goede <hdegoede@redhat.com>");
>> +MODULE_LICENSE("GPL");
>
> GPL v2?
It is GPL v2 or later, and using just "GPL" is the norm indeed
lately I've seen some driver use "GPL xxxxx" but the vast majority
of the drivers in the kernel has just "GPL".
Thanks for the review!
Regards,
Hans
p.s.
A question about my 2 phy-core patches, as well as this one once the
review comments are addressed. How do I get phy patches upstream, will
you take care of this, or should I send them somewhere else ?
^ permalink raw reply
* [alsa-devel] [PATCH RFC v2 REPOST 3/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
From: Jean-Francois Moine @ 2014-01-15 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D67099.1040904@ti.com>
On Wed, 15 Jan 2014 13:27:21 +0200
Jyri Sarha <jsarha@ti.com> wrote:
> From driver/gpu/drm/i2c/tda998x_drv.c. The driver configures CTS_N
> register statically to a value that works only with 4 byte samples.
> According to my tests it is possible to support 3 and 2 byte samples too
> by changing the CTS_N register value, but I am not sure if the
> configuration can be changed on the fly. My data sheet of the nxp chip
> is very vague about the register definitions, but I suppose the register
> configures some clock divider on the chip. HDMI supports only upto 24bit
> audio and the data sheet states that any extraneous least significant
> bits are ignored.
In the tda998x driver, the CTS_N is automatic (AIP_CNTRL_0_ACR_MAN is
not set).
Then, in my Cubox (Marvell A510 + tda19988), the 16, 24 and 32 bits
formats are working well with I2S input at any rate.
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [PATCH] mmc: dw_mmc: fix dw_mci_get_cd
From: Zhangfei Gao @ 2014-01-15 15:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D6A9FF.3000603@linaro.org>
Introduced from commit bf626e5550f24aec24975a0e85ad8e572ca76a6b
CDETECT is ignored since negated return value of mmc_gpio_get_cd(mmc)
can not be checked by IS_ERR_VALUE.
Add spin_lock_bh(&host->lock) for atomic accessing DW_MMC_CARD_PRESENT,
otherwise sd detect may occasionally fail.
Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
Reported-by: Kevin Hilman <khilman@linaro.org>
Reviewed-by: Sachin Kamat <sachin.kamat@linaro.org>
Tested-by: Sachin Kamat <sachin.kamat@linaro.org>
---
drivers/mmc/host/dw_mmc.c | 12 +++++++++---
include/linux/mmc/dw_mmc.h | 1 +
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index a776f24f4311..8326e54b96a8 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1033,7 +1033,8 @@ static int dw_mci_get_cd(struct mmc_host *mmc)
int present;
struct dw_mci_slot *slot = mmc_priv(mmc);
struct dw_mci_board *brd = slot->host->pdata;
- int gpio_cd = !mmc_gpio_get_cd(mmc);
+ struct dw_mci *host = slot->host;
+ int gpio_cd = mmc_gpio_get_cd(mmc);
/* Use platform get_cd function, else try onboard card detect */
if (brd->quirks & DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
@@ -1041,11 +1042,12 @@ static int dw_mci_get_cd(struct mmc_host *mmc)
else if (brd->get_cd)
present = !brd->get_cd(slot->id);
else if (!IS_ERR_VALUE(gpio_cd))
- present = !!gpio_cd;
+ present = gpio_cd ^ brd->cd_inverted;
else
present = (mci_readl(slot->host, CDETECT) & (1 << slot->id))
== 0 ? 1 : 0;
+ spin_lock_bh(&host->lock);
if (present) {
set_bit(DW_MMC_CARD_PRESENT, &slot->flags);
dev_dbg(&mmc->class_dev, "card is present\n");
@@ -1053,6 +1055,7 @@ static int dw_mci_get_cd(struct mmc_host *mmc)
clear_bit(DW_MMC_CARD_PRESENT, &slot->flags);
dev_dbg(&mmc->class_dev, "card is not present\n");
}
+ spin_unlock_bh(&host->lock);
return present;
}
@@ -2081,7 +2084,7 @@ static int dw_mci_of_get_wp_gpio(struct device *dev, u8 slot)
return gpio;
}
-/* find the cd gpio for a given slot; or -1 if none specified */
+/* find the cd gpio for a given slot */
static void dw_mci_of_get_cd_gpio(struct device *dev, u8 slot,
struct mmc_host *mmc)
{
@@ -2411,6 +2414,9 @@ static struct dw_mci_board *dw_mci_parse_dt(struct dw_mci *host)
if (of_find_property(np, "caps2-mmc-hs200-1_2v", NULL))
pdata->caps2 |= MMC_CAP2_HS200_1_2V_SDR;
+ if (of_get_property(np, "cd-inverted", NULL))
+ pdata->cd_inverted = 1;
+
return pdata;
}
diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h
index 6ce7d2cd3c7a..4535282589ab 100644
--- a/include/linux/mmc/dw_mmc.h
+++ b/include/linux/mmc/dw_mmc.h
@@ -238,6 +238,7 @@ struct dw_mci_board {
u32 caps; /* Capabilities */
u32 caps2; /* More capabilities */
u32 pm_caps; /* PM capabilities */
+ u8 cd_inverted;
/*
* Override fifo depth. If 0, autodetect it from the FIFOTH register,
* but note that this may not be reliable after a bootloader has used
--
1.7.9.5
^ permalink raw reply related
* [PATCH] mmc: dw_mmc: fix dw_mci_get_cd
From: Arnd Bergmann @ 2014-01-15 15:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D6A9FF.3000603@linaro.org>
On Wednesday 15 January 2014, zhangfei wrote:
>
> On 01/15/2014 10:38 PM, Seungwon Jeon wrote:
> >> Hmm, looks you are right.
> >> Though not see clearly mmc_gpio_get_cd declaratoin, other drivers
> >> directly set get_cd as mmc_gpio_get_cd.
> >> .get_cd = mmc_gpio_get_cd
> >>
> >> However, in our board cd =0 when card is deteced while cd=1 when card is
> >> removed.
> >> In order to mmc_gpio_get_cd return 1, MMC_CAP2_CD_ACTIVE_HIGH has to be
> >> set, as well as new property "caps2-mmc-cd-active-low".
> >
> > Ok, you could do more.
> > mmc_gpio_get_cd() is expected to return non-zero if card is detection.
>
> > I think your board seems not to use pull-up on GPIO line for card detection.
> > So, MMC_CAP2_CD_ACTIVE_HIGH would be needed.
>
> Unfortunately, the specific cd pin can not be configured.
> Suspect on our board the cd =1 when card is inserted, can not measure as
> no clear resister and need check with hardware guy tomorrow.
>
> "cd-inverted" may be required as mentioned by Arnd.
> Will update the patch as following if no problem.
The patch looks right, but I wonder if a better longer-term
solution would be to just the common mmc_of_parse() function
rather than duplicating it in dw_mmc.
Arnd
^ permalink raw reply
* [PATCH] mmc: dw_mmc: fix dw_mci_get_cd
From: Russell King - ARM Linux @ 2014-01-15 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1389801061-6023-1-git-send-email-zhangfei.gao@linaro.org>
On Wed, Jan 15, 2014 at 11:51:01PM +0800, Zhangfei Gao wrote:
> Introduced from commit bf626e5550f24aec24975a0e85ad8e572ca76a6b
> CDETECT is ignored since negated return value of mmc_gpio_get_cd(mmc)
> can not be checked by IS_ERR_VALUE.
> Add spin_lock_bh(&host->lock) for atomic accessing DW_MMC_CARD_PRESENT,
> otherwise sd detect may occasionally fail.
>
> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
> Reported-by: Kevin Hilman <khilman@linaro.org>
> Reviewed-by: Sachin Kamat <sachin.kamat@linaro.org>
> Tested-by: Sachin Kamat <sachin.kamat@linaro.org>
> ---
> drivers/mmc/host/dw_mmc.c | 12 +++++++++---
> include/linux/mmc/dw_mmc.h | 1 +
> 2 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index a776f24f4311..8326e54b96a8 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -1033,7 +1033,8 @@ static int dw_mci_get_cd(struct mmc_host *mmc)
> int present;
> struct dw_mci_slot *slot = mmc_priv(mmc);
> struct dw_mci_board *brd = slot->host->pdata;
> - int gpio_cd = !mmc_gpio_get_cd(mmc);
> + struct dw_mci *host = slot->host;
> + int gpio_cd = mmc_gpio_get_cd(mmc);
>
> /* Use platform get_cd function, else try onboard card detect */
> if (brd->quirks & DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
> @@ -1041,11 +1042,12 @@ static int dw_mci_get_cd(struct mmc_host *mmc)
> else if (brd->get_cd)
> present = !brd->get_cd(slot->id);
> else if (!IS_ERR_VALUE(gpio_cd))
> - present = !!gpio_cd;
> + present = gpio_cd ^ brd->cd_inverted;
I assume you haven't read the contents of mmc_gpio_get_cd()?
int mmc_gpio_get_cd(struct mmc_host *host)
{
struct mmc_gpio *ctx = host->slot.handler_priv;
if (!ctx || !gpio_is_valid(ctx->cd_gpio))
return -ENOSYS;
return !gpio_get_value_cansleep(ctx->cd_gpio) ^
!!(host->caps2 & MMC_CAP2_CD_ACTIVE_HIGH);
}
EXPORT_SYMBOL(mmc_gpio_get_cd);
What facility does host->caps2 give you here? Yes, you don't need
your own cd_inverted stuff. You should check that you're interpreting
this correctly. When this returns true, there is a card present.
When MMC_CAP2_CD_ACTIVE_HIGH is set, gpio_get_value_cansleep() must
return non-zero when a card is inserted. When it isn't set,
gpio_get_value_cansleep must return zero when a card is inserted.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCHv13 00/40] ARM: TI SoC clock DT conversion
From: Nishanth Menon @ 2014-01-15 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D68FFA.8000806@ti.com>
On 01/15/2014 07:41 AM, Tero Kristo wrote:
> On 01/15/2014 05:50 AM, Mike Turquette wrote:
>> Quoting Mike Turquette (2014-01-14 19:16:32)
>>> Quoting Felipe Balbi (2014-01-14 18:04:21)
>>>> Hi,
>>>>
>>>> On Tue, Jan 14, 2014 at 02:36:13PM -0600, Felipe Balbi wrote:
>>>>>> Felipe, care to run your randconfig magic for this?
>>>>>
>>>>> This branch builds just fine so far, I still have omap5 multiplaform and
>>>>> uniplatform builds, but since that was working before i'm assuming it
>>>>> won't break.
>>>>
>>>> No build failures in any of my 18 seeds (5 randconfigs of each), I'd
>>>> attach logs, but it's a 2.8MiB tarball, if anyone cares enough, I can
>>>> send it.
>>>>
>>>> FWIW:
>>>>
>>>> Acked-by: Felipe Balbi <balbi@ti.com>
>>>
>>> Felipe,
>>>
>>> That's great to hear. Thanks for testing.
>>>
>>> Tero & Tony,
>>>
>>> These 40 patches apply very cleanly on top of clk-next with 2
>>> exceptions:
>>>
>>> 1) I did not apply "[PATCH 30/42] ARM: dts: AM35xx: use DT clock data"
>>> because I do not have arch/arm/boot/dts/am3517.dtsi in clk-next (based
>>> on 3.13-rc1).
>>>
>>> 2) Minor merge conflict in arch/arm/boot/dts/omap3.dtsi which I think I
>>> resolved correctly but would like verification.
>>>
>>> I'd prefer to simply merge these patches into clk-next, which is the
>>> most straightforward route. Any ideas on how to handle the missing
>>> AM35xx dtsi data? It can always go as a separate fix after this stuff
>>> gets merged which, ironically, is how that file was created in the first
>>> place.
>>
>> I've pushed my branch. Tero can you take a look and let me know if you
>> see any problems?
>>
>> git://git.linaro.org/people/mike.turquette/linux.git clk-next-omap
>
> Hey Mike,
>
> Can't see any issues there, also gave it a quick boot test with the
> boards I have access to and seems to work fine.
>
Here are the logs with commit 12d0a30a45e3a85463a6cb2a9e886192e3123892
( i need an additional patch for legacy platform testing).
1: am335x-evm: http://slexy.org/raw/s215zNjZFv
2: am335x-sk: http://slexy.org/raw/s20uTrPG7V
3: am3517-evm: http://slexy.org/raw/s21XPhGMCt
(we should be based on .13-rc4 to get am3517 baseline patches -> So
due to the dropped am3517 patch, we stop booting here).
4: am37x-evm: http://slexy.org/raw/s20W2nuCQa
5: am43xx-epos: http://slexy.org/raw/s2I2qc961B (no boot yet)
6: beag-xm: http://slexy.org/raw/s210lX2EvT
7: bone-black: http://slexy.org/raw/s2NgHa78JC (still have the
fixed-regulator bug in rc1 so, wont boot to shell at rc1)
8: am3517-crane: http://slexy.org/raw/s2r1Bt4Hk2 (need benoit'
for-next to boot)
9: dra7: http://slexy.org/raw/s21UWF0yYd (same fixed regulator
issue)
10: ldp: http://slexy.org/raw/s2oWL6qt2t (dts for this is
pending merge in Tony's next)
11: panda-es: http://slexy.org/raw/s20NEXs51M
12: sdp2430: http://slexy.org/raw/s21kyDYjfk (dts for this pending
in Tony's next)
13: sdp3430: http://slexy.org/raw/s2EYHpcAW0
14: sdp4430: http://slexy.org/raw/s2QPK7cBUP
15: uevm: http://slexy.org/raw/s21mMF6kN3 (same regulator stuff
kicks again)
am3517-evm is concerning for 14-rc1 boot, am43xx-epos looks concerning
too(not sure if there are follow on fixes in later rcs that allow it
to boot)
- considering that both did work on tests that I did based on next[1],
only thing i am concerned in am3517 patch dropped in clk-next-omap.
- will be good to get this merged on clk-next and see what we can get
results on linux-next tag.
[1] http://marc.info/?l=devicetree&m=138930255330882&w=2
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH] mmc: dw_mmc: fix dw_mci_get_cd
From: Russell King - ARM Linux @ 2014-01-15 16:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3154671.7LPLgq8X4K@wuerfel>
On Wed, Jan 15, 2014 at 02:59:59PM +0100, Arnd Bergmann wrote:
> On Wednesday 15 January 2014 21:56:26 zhangfei wrote:
> > However, in our board cd =0 when card is deteced while cd=1 when card is
> > removed.
> > In order to mmc_gpio_get_cd return 1, MMC_CAP2_CD_ACTIVE_HIGH has to be
> > set, as well as new property "caps2-mmc-cd-active-low".
> >
> > --- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
> > +++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
> > @@ -73,6 +73,8 @@ Optional properties:
> > +* caps2-mmc-cd-active-low: cd pin is low when card active
> > +
> >
> > diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> > + if (of_find_property(np, "caps2-mmc-cd-active-low", NULL))
> > + pdata->caps2 |= MMC_CAP2_CD_ACTIVE_HIGH;
> > +
>
> The MMC_CAP2_CD_ACTIVE_HIGH flag should only be required for
> legacy platforms. With DT parsing, you can normally specify
> the polarity of the GPIO line in the GPIO specifier in DT.
Since when?
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH] mmc: dw_mmc: fix dw_mci_get_cd
From: Arnd Bergmann @ 2014-01-15 16:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140115160146.GO15937@n2100.arm.linux.org.uk>
On Wednesday 15 January 2014 16:01:46 Russell King - ARM Linux wrote:
> On Wed, Jan 15, 2014 at 02:59:59PM +0100, Arnd Bergmann wrote:
> > On Wednesday 15 January 2014 21:56:26 zhangfei wrote:
> > > However, in our board cd =0 when card is deteced while cd=1 when card is
> > > removed.
> > > In order to mmc_gpio_get_cd return 1, MMC_CAP2_CD_ACTIVE_HIGH has to be
> > > set, as well as new property "caps2-mmc-cd-active-low".
> > >
> > > --- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
> > > +++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
> > > @@ -73,6 +73,8 @@ Optional properties:
> > > +* caps2-mmc-cd-active-low: cd pin is low when card active
> > > +
> > >
> > > diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> > > + if (of_find_property(np, "caps2-mmc-cd-active-low", NULL))
> > > + pdata->caps2 |= MMC_CAP2_CD_ACTIVE_HIGH;
> > > +
> >
> > The MMC_CAP2_CD_ACTIVE_HIGH flag should only be required for
> > legacy platforms. With DT parsing, you can normally specify
> > the polarity of the GPIO line in the GPIO specifier in DT.
>
> Since when?
I just looked through the bindings and found that about half
of them allow passing polarity in the gpio specifier. I thought
it was more than that and IIRC the outcome of a previous discussion
was that when the gpio controller allows passing polarity, you
should use that rather than a separate flag.
Not a problem though, since we can use the cd-inverted and
wp-inverted properties.
Arnd
^ permalink raw reply
* [PATCH v6 0/2] ohci and ehci-platform clks, phy and dt support
From: Hans de Goede @ 2014-01-15 16:08 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
And here is v6 of my ohci and ehci-platform clks, phy and dt support patch-set,
this version addresses the 2 small bugs Alan found.
Other then that there are no changes compared to v5.
Regards,
Hans
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox