* Re: [PATCH v4 5/7] pinctrl: aramda-37xx: Add irqchip support
From: Linus Walleij @ 2017-04-24 12:14 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: linux-gpio@vger.kernel.org, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Thomas Petazzoni,
linux-arm-kernel@lists.infradead.org, Rob Herring,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Nadav Haklai, Victor Gu, Marcin Wojtas, Wilson Ding, Hua Jing,
Neta Zur Hershkovits
In-Reply-To: <70ffe3343c13d01737bf74e5de4898d0c0be07a0.1491405475.git-series.gregory.clement@free-electrons.com>
On Wed, Apr 5, 2017 at 5:18 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> The Armada 37xx SoCs can handle interrupt through GPIO. However it can
> only manage the edge ones.
>
> The way the interrupt are managed are classical so we can use the generic
> interrupt chip model.
>
> The only unusual "feature" is that many interrupts are connected to the
> parent interrupt controller. But we do not take advantage of this and use
> the chained irq with all of them.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
There are some issues with this patch.
First:
You need to add
select GPIOLIB_IRQCHIP
to the Kconfig entry. It's only working in your setup
because something else is selecting this for you, probably.
At all places like this:
> + u32 mask = d->mask;
(...)
> + if (on)
> + val |= mask;
> + else
> + val &= ~mask;
Isn't it simpler to just use d->mask directly in the code and skip the local
variable?
if (on)
val |= d->mask;
(...)
> +static void armada_37xx_irq_handler(struct irq_desc *desc)
> +{
> + struct gpio_chip *gc = irq_desc_get_handler_data(desc);
> + struct irq_chip *chip = irq_desc_get_chip(desc);
> + struct armada_37xx_pinctrl *info = gpiochip_get_data(gc);
> + struct irq_domain *d = gc->irqdomain;
> + int i;
> +
> + chained_irq_enter(chip, desc);
> + for (i = 0; i <= d->revmap_size / GPIO_PER_REG; i++) {
> + u32 status;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&info->irq_lock, flags);
> + status = readl_relaxed(info->base + IRQ_STATUS + 4 * i);
> + /* Manage only the interrupt that was enabled */
> + status &= readl_relaxed(info->base + IRQ_EN + 4 * i);
> + spin_unlock_irqrestore(&info->irq_lock, flags);
> + while (status) {
> + u32 hwirq = ffs(status) - 1;
> + u32 virq = irq_find_mapping(d, hwirq +
> + i * GPIO_PER_REG);
> +
> + generic_handle_irq(virq);
> + status &= ~BIT(hwirq);
> + }
You hae a problem here is a new IRQ appears while you are inside
of this loop. You need to re-read the status register for each iteration
(and &= with the IRQ_EN I guess).
> +static int armada_37xx_irqchip_register(struct platform_device *pdev,
> + struct armada_37xx_pinctrl *info)
> +{
> + struct device_node *np = info->dev->of_node;
> + int nrirqs = info->data->nr_pins;
> + struct gpio_chip *gc = &info->gpio_chip;
> + struct irq_chip *irqchip = &info->irq_chip;
> + struct resource res;
> + int ret = -ENODEV, i, nr_irq_parent;
> +
This warrants a comment:
/* Check if we have at least one gpio-controller child node */
> + for_each_child_of_node(info->dev->of_node, np) {
> + if (of_find_property(np, "gpio-controller", NULL)) {
> + ret = 0;
> + break;
> + }
Rewrite:
if (of_property_read_bool(np, "gpio-controller"))
> + };
> + if (ret)
> + return ret;
> +
> + nr_irq_parent = of_irq_count(np);
> + spin_lock_init(&info->irq_lock);
> +
> + if (!nr_irq_parent) {
> + dev_err(&pdev->dev, "Invalid or no IRQ\n");
> + return 0;
> + }
> +
> + if (of_address_to_resource(info->dev->of_node, 1, &res)) {
> + dev_err(info->dev, "cannot find IO resource\n");
> + return -ENOENT;
> + }
> +
> + info->base = devm_ioremap_resource(info->dev, &res);
> + if (IS_ERR(info->base))
> + return PTR_ERR(info->base);
> +
> + irqchip->irq_ack = armada_37xx_irq_ack;
> + irqchip->irq_mask = armada_37xx_irq_mask;
> + irqchip->irq_unmask = armada_37xx_irq_unmask;
> + irqchip->irq_set_wake = armada_37xx_irq_set_wake;
> + irqchip->irq_set_type = armada_37xx_irq_set_type;
> + irqchip->name = info->data->name;
> +
> + ret = gpiochip_irqchip_add(gc, irqchip, 0,
> + handle_edge_irq, IRQ_TYPE_NONE);
> + if (ret) {
> + dev_info(&pdev->dev, "could not add irqchip\n");
> + return ret;
> + }
> +
> + /*
> + * Many interrupts are connected to the parent interrupt
> + * controller. But we do not take advantage of this and use
> + * the chained irq with all of them.
> + */
> + for (i = 0; i < nrirqs; i++) {
> + struct irq_data *d = irq_get_irq_data(gc->irq_base + i);
> +
> + /*
> + * The mask field is a "precomputed bitmask for
> + * accessing the chip registers" which was introduced
> + * for the generic irqchip framework. As we don't use
> + * this framework, we can reuse this field for our own
> + * usage.
> + */
> + d->mask = BIT(i % GPIO_PER_REG);
> + }
> +
> + for (i = 0; i < nr_irq_parent; i++) {
> + int irq = irq_of_parse_and_map(np, i);
> +
> + if (irq < 0)
> + continue;
> +
> + gpiochip_set_chained_irqchip(gc, irqchip, irq,
> + armada_37xx_irq_handler);
> + }
> +
> + return 0;
> +}
> +
> static int armada_37xx_gpiochip_register(struct platform_device *pdev,
> struct armada_37xx_pinctrl *info)
> {
> @@ -496,6 +714,9 @@ static int armada_37xx_gpiochip_register(struct platform_device *pdev,
> ret = devm_gpiochip_add_data(&pdev->dev, gc, info);
> if (ret)
> return ret;
> + ret = armada_37xx_irqchip_register(pdev, info);
> + if (ret)
> + return ret;
>
> return 0;
> }
> --
> git-series 0.9.1
^ permalink raw reply
* Re: [PATCH v3 07/12] dt-bindings: add AXP803's regulator info
From: Lee Jones @ 2017-04-24 12:09 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Rob Herring, Chen-Yu Tsai, Maxime Ripard, Liam Girdwood,
Mark Brown, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170417115747.7300-8-icenowy-h8G6r0blFSE@public.gmane.org>
On Mon, 17 Apr 2017, Icenowy Zheng wrote:
> AXP803 have the most regulators in currently supported AXP PMICs.
>
> Add info for the regulators in the dt-bindings document.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> Changes in v3:
> - Added Rob's ACK.
> Changes in v2:
> - Place AXP803 regulators before AXP806/809 ones.
>
> Documentation/devicetree/bindings/mfd/axp20x.txt | 27 ++++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
Applied, thanks.
> diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
> index 44df88be3c89..aca09af66514 100644
> --- a/Documentation/devicetree/bindings/mfd/axp20x.txt
> +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
> @@ -96,6 +96,33 @@ LDO_IO1 : LDO : ips-supply : GPIO 1
> RTC_LDO : LDO : ips-supply : always on
> DRIVEVBUS : Enable output : drivevbus-supply : external regulator
>
> +AXP803 regulators, type, and corresponding input supply names:
> +
> +Regulator Type Supply Name Notes
> +--------- ---- ----------- -----
> +DCDC1 : DC-DC buck : vin1-supply
> +DCDC2 : DC-DC buck : vin2-supply : poly-phase capable
> +DCDC3 : DC-DC buck : vin3-supply : poly-phase capable
> +DCDC4 : DC-DC buck : vin4-supply
> +DCDC5 : DC-DC buck : vin5-supply : poly-phase capable
> +DCDC6 : DC-DC buck : vin6-supply : poly-phase capable
> +DC1SW : On/Off Switch : : DCDC1 secondary output
> +ALDO1 : LDO : aldoin-supply : shared supply
> +ALDO2 : LDO : aldoin-supply : shared supply
> +ALDO3 : LDO : aldoin-supply : shared supply
> +DLDO1 : LDO : dldoin-supply : shared supply
> +DLDO2 : LDO : dldoin-supply : shared supply
> +DLDO3 : LDO : dldoin-supply : shared supply
> +DLDO4 : LDO : dldoin-supply : shared supply
> +ELDO1 : LDO : eldoin-supply : shared supply
> +ELDO2 : LDO : eldoin-supply : shared supply
> +ELDO3 : LDO : eldoin-supply : shared supply
> +FLDO1 : LDO : fldoin-supply : shared supply
> +FLDO2 : LDO : fldoin-supply : shared supply
> +LDO_IO0 : LDO : ips-supply : GPIO 0
> +LDO_IO1 : LDO : ips-supply : GPIO 1
> +RTC_LDO : LDO : ips-supply : always on
> +
> AXP806 regulators, type, and corresponding input supply names:
>
> Regulator Type Supply Name Notes
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 05/12] mfd: axp20x: support AXP803 variant
From: Lee Jones @ 2017-04-24 12:09 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Rob Herring, Chen-Yu Tsai, Maxime Ripard, Liam Girdwood,
Mark Brown, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170417115747.7300-6-icenowy-h8G6r0blFSE@public.gmane.org>
On Mon, 17 Apr 2017, Icenowy Zheng wrote:
> AXP803 is a new PMIC chip produced by X-Powers, usually paired with A64
> via RSB bus. The PMIC itself is like AXP288, but with RSB support and
> dedicated VBUS and ACIN.
>
> Add support for it in the axp20x mfd driver.
>
> Currently only power key function is supported.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> ---
> This patch is said to be applied by Lee Jones, however, I didn't see it
> in the linux-next, so I included it in the patchset now.
>
> Changes in v2:
> - Share regmap configs with AXP288.
> - Place AXP803 bits before AXP806/809.
>
> drivers/mfd/axp20x-rsb.c | 1 +
> drivers/mfd/axp20x.c | 79 ++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/mfd/axp20x.h | 40 ++++++++++++++++++++++-
> 3 files changed, 119 insertions(+), 1 deletion(-)
Applied, thanks.
> diff --git a/drivers/mfd/axp20x-rsb.c b/drivers/mfd/axp20x-rsb.c
> index a732cb50bcff..fd5c7267b136 100644
> --- a/drivers/mfd/axp20x-rsb.c
> +++ b/drivers/mfd/axp20x-rsb.c
> @@ -61,6 +61,7 @@ static int axp20x_rsb_remove(struct sunxi_rsb_device *rdev)
>
> static const struct of_device_id axp20x_rsb_of_match[] = {
> { .compatible = "x-powers,axp223", .data = (void *)AXP223_ID },
> + { .compatible = "x-powers,axp803", .data = (void *)AXP803_ID },
> { .compatible = "x-powers,axp806", .data = (void *)AXP806_ID },
> { .compatible = "x-powers,axp809", .data = (void *)AXP809_ID },
> { },
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index e6f55079876e..1dc6235778eb 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -41,6 +41,7 @@ static const char * const axp20x_model_names[] = {
> "AXP221",
> "AXP223",
> "AXP288",
> + "AXP803",
> "AXP806",
> "AXP809",
> };
> @@ -117,6 +118,7 @@ static const struct regmap_access_table axp22x_volatile_table = {
> .n_yes_ranges = ARRAY_SIZE(axp22x_volatile_ranges),
> };
>
> +/* AXP288 ranges are shared with the AXP803, as they cover the same range */
> static const struct regmap_range axp288_writeable_ranges[] = {
> regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ6_STATE),
> regmap_reg_range(AXP20X_DCDC_MODE, AXP288_FG_TUNE5),
> @@ -264,6 +266,20 @@ static struct resource axp288_fuel_gauge_resources[] = {
> },
> };
>
> +static struct resource axp803_pek_resources[] = {
> + {
> + .name = "PEK_DBR",
> + .start = AXP803_IRQ_PEK_RIS_EDGE,
> + .end = AXP803_IRQ_PEK_RIS_EDGE,
> + .flags = IORESOURCE_IRQ,
> + }, {
> + .name = "PEK_DBF",
> + .start = AXP803_IRQ_PEK_FAL_EDGE,
> + .end = AXP803_IRQ_PEK_FAL_EDGE,
> + .flags = IORESOURCE_IRQ,
> + },
> +};
> +
> static struct resource axp809_pek_resources[] = {
> {
> .name = "PEK_DBR",
> @@ -457,6 +473,43 @@ static const struct regmap_irq axp288_regmap_irqs[] = {
> INIT_REGMAP_IRQ(AXP288, BC_USB_CHNG, 5, 1),
> };
>
> +static const struct regmap_irq axp803_regmap_irqs[] = {
> + INIT_REGMAP_IRQ(AXP803, ACIN_OVER_V, 0, 7),
> + INIT_REGMAP_IRQ(AXP803, ACIN_PLUGIN, 0, 6),
> + INIT_REGMAP_IRQ(AXP803, ACIN_REMOVAL, 0, 5),
> + INIT_REGMAP_IRQ(AXP803, VBUS_OVER_V, 0, 4),
> + INIT_REGMAP_IRQ(AXP803, VBUS_PLUGIN, 0, 3),
> + INIT_REGMAP_IRQ(AXP803, VBUS_REMOVAL, 0, 2),
> + INIT_REGMAP_IRQ(AXP803, BATT_PLUGIN, 1, 7),
> + INIT_REGMAP_IRQ(AXP803, BATT_REMOVAL, 1, 6),
> + INIT_REGMAP_IRQ(AXP803, BATT_ENT_ACT_MODE, 1, 5),
> + INIT_REGMAP_IRQ(AXP803, BATT_EXIT_ACT_MODE, 1, 4),
> + INIT_REGMAP_IRQ(AXP803, CHARG, 1, 3),
> + INIT_REGMAP_IRQ(AXP803, CHARG_DONE, 1, 2),
> + INIT_REGMAP_IRQ(AXP803, BATT_CHG_TEMP_HIGH, 2, 7),
> + INIT_REGMAP_IRQ(AXP803, BATT_CHG_TEMP_HIGH_END, 2, 6),
> + INIT_REGMAP_IRQ(AXP803, BATT_CHG_TEMP_LOW, 2, 5),
> + INIT_REGMAP_IRQ(AXP803, BATT_CHG_TEMP_LOW_END, 2, 4),
> + INIT_REGMAP_IRQ(AXP803, BATT_ACT_TEMP_HIGH, 2, 3),
> + INIT_REGMAP_IRQ(AXP803, BATT_ACT_TEMP_HIGH_END, 2, 2),
> + INIT_REGMAP_IRQ(AXP803, BATT_ACT_TEMP_LOW, 2, 1),
> + INIT_REGMAP_IRQ(AXP803, BATT_ACT_TEMP_LOW_END, 2, 0),
> + INIT_REGMAP_IRQ(AXP803, DIE_TEMP_HIGH, 3, 7),
> + INIT_REGMAP_IRQ(AXP803, GPADC, 3, 2),
> + INIT_REGMAP_IRQ(AXP803, LOW_PWR_LVL1, 3, 1),
> + INIT_REGMAP_IRQ(AXP803, LOW_PWR_LVL2, 3, 0),
> + INIT_REGMAP_IRQ(AXP803, TIMER, 4, 7),
> + INIT_REGMAP_IRQ(AXP803, PEK_RIS_EDGE, 4, 6),
> + INIT_REGMAP_IRQ(AXP803, PEK_FAL_EDGE, 4, 5),
> + INIT_REGMAP_IRQ(AXP803, PEK_SHORT, 4, 4),
> + INIT_REGMAP_IRQ(AXP803, PEK_LONG, 4, 3),
> + INIT_REGMAP_IRQ(AXP803, PEK_OVER_OFF, 4, 2),
> + INIT_REGMAP_IRQ(AXP803, GPIO1_INPUT, 4, 1),
> + INIT_REGMAP_IRQ(AXP803, GPIO0_INPUT, 4, 0),
> + INIT_REGMAP_IRQ(AXP803, BC_USB_CHNG, 5, 1),
> + INIT_REGMAP_IRQ(AXP803, MV_CHNG, 5, 0),
> +};
> +
> static const struct regmap_irq axp806_regmap_irqs[] = {
> INIT_REGMAP_IRQ(AXP806, DIE_TEMP_HIGH_LV1, 0, 0),
> INIT_REGMAP_IRQ(AXP806, DIE_TEMP_HIGH_LV2, 0, 1),
> @@ -557,6 +610,18 @@ static const struct regmap_irq_chip axp288_regmap_irq_chip = {
>
> };
>
> +static const struct regmap_irq_chip axp803_regmap_irq_chip = {
> + .name = "axp803",
> + .status_base = AXP20X_IRQ1_STATE,
> + .ack_base = AXP20X_IRQ1_STATE,
> + .mask_base = AXP20X_IRQ1_EN,
> + .mask_invert = true,
> + .init_ack_masked = true,
> + .irqs = axp803_regmap_irqs,
> + .num_irqs = ARRAY_SIZE(axp803_regmap_irqs),
> + .num_regs = 6,
> +};
> +
> static const struct regmap_irq_chip axp806_regmap_irq_chip = {
> .name = "axp806",
> .status_base = AXP20X_IRQ1_STATE,
> @@ -778,6 +843,14 @@ static struct mfd_cell axp288_cells[] = {
> },
> };
>
> +static struct mfd_cell axp803_cells[] = {
> + {
> + .name = "axp20x-pek",
> + .num_resources = ARRAY_SIZE(axp803_pek_resources),
> + .resources = axp803_pek_resources,
> + }
> +};
> +
> static struct mfd_cell axp806_cells[] = {
> {
> .id = 2,
> @@ -864,6 +937,12 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
> axp20x->regmap_irq_chip = &axp288_regmap_irq_chip;
> axp20x->irq_flags = IRQF_TRIGGER_LOW;
> break;
> + case AXP803_ID:
> + axp20x->nr_cells = ARRAY_SIZE(axp803_cells);
> + axp20x->cells = axp803_cells;
> + axp20x->regmap_cfg = &axp288_regmap_config;
> + axp20x->regmap_irq_chip = &axp803_regmap_irq_chip;
> + break;
> case AXP806_ID:
> axp20x->nr_cells = ARRAY_SIZE(axp806_cells);
> axp20x->cells = axp806_cells;
> diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
> index dc8798cf2a24..cde56cfe8446 100644
> --- a/include/linux/mfd/axp20x.h
> +++ b/include/linux/mfd/axp20x.h
> @@ -20,6 +20,7 @@ enum axp20x_variants {
> AXP221_ID,
> AXP223_ID,
> AXP288_ID,
> + AXP803_ID,
> AXP806_ID,
> AXP809_ID,
> NR_AXP20X_VARIANTS,
> @@ -234,7 +235,7 @@ enum axp20x_variants {
> #define AXP22X_TS_ADC_L 0x59
> #define AXP22X_BATLOW_THRES1 0xe6
>
> -/* AXP288 specific registers */
> +/* AXP288/AXP803 specific registers */
> #define AXP288_POWER_REASON 0x02
> #define AXP288_BC_GLOBAL 0x2c
> #define AXP288_BC_VBUS_CNTL 0x2d
> @@ -475,6 +476,43 @@ enum axp288_irqs {
> AXP288_IRQ_BC_USB_CHNG,
> };
>
> +enum axp803_irqs {
> + AXP803_IRQ_ACIN_OVER_V = 1,
> + AXP803_IRQ_ACIN_PLUGIN,
> + AXP803_IRQ_ACIN_REMOVAL,
> + AXP803_IRQ_VBUS_OVER_V,
> + AXP803_IRQ_VBUS_PLUGIN,
> + AXP803_IRQ_VBUS_REMOVAL,
> + AXP803_IRQ_BATT_PLUGIN,
> + AXP803_IRQ_BATT_REMOVAL,
> + AXP803_IRQ_BATT_ENT_ACT_MODE,
> + AXP803_IRQ_BATT_EXIT_ACT_MODE,
> + AXP803_IRQ_CHARG,
> + AXP803_IRQ_CHARG_DONE,
> + AXP803_IRQ_BATT_CHG_TEMP_HIGH,
> + AXP803_IRQ_BATT_CHG_TEMP_HIGH_END,
> + AXP803_IRQ_BATT_CHG_TEMP_LOW,
> + AXP803_IRQ_BATT_CHG_TEMP_LOW_END,
> + AXP803_IRQ_BATT_ACT_TEMP_HIGH,
> + AXP803_IRQ_BATT_ACT_TEMP_HIGH_END,
> + AXP803_IRQ_BATT_ACT_TEMP_LOW,
> + AXP803_IRQ_BATT_ACT_TEMP_LOW_END,
> + AXP803_IRQ_DIE_TEMP_HIGH,
> + AXP803_IRQ_GPADC,
> + AXP803_IRQ_LOW_PWR_LVL1,
> + AXP803_IRQ_LOW_PWR_LVL2,
> + AXP803_IRQ_TIMER,
> + AXP803_IRQ_PEK_RIS_EDGE,
> + AXP803_IRQ_PEK_FAL_EDGE,
> + AXP803_IRQ_PEK_SHORT,
> + AXP803_IRQ_PEK_LONG,
> + AXP803_IRQ_PEK_OVER_OFF,
> + AXP803_IRQ_GPIO1_INPUT,
> + AXP803_IRQ_GPIO0_INPUT,
> + AXP803_IRQ_BC_USB_CHNG,
> + AXP803_IRQ_MV_CHNG,
> +};
> +
> enum axp806_irqs {
> AXP806_IRQ_DIE_TEMP_HIGH_LV1,
> AXP806_IRQ_DIE_TEMP_HIGH_LV2,
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH v3 04/12] dt-bindings: add device tree binding for X-Powers AXP803 PMIC
From: Lee Jones @ 2017-04-24 12:08 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Rob Herring, Chen-Yu Tsai, Maxime Ripard, Liam Girdwood,
Mark Brown, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170417115747.7300-5-icenowy-h8G6r0blFSE@public.gmane.org>
On Mon, 17 Apr 2017, Icenowy Zheng wrote:
> AXP803 is a PMIC produced by Shenzhen X-Powers, with either I2C or RSB
> bus.
>
> Add a compatible for it.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> Changes in v3:
> - Make the compatible one-liner.
> Changes in v2:
> - Place AXP803 before AXP806/809.
> - Added Chen-Yu's ACK.
>
> Documentation/devicetree/bindings/mfd/axp20x.txt | 2 ++
> 1 file changed, 2 insertions(+)
Applied, thanks.
> diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
> index a3e813f6060a..44df88be3c89 100644
> --- a/Documentation/devicetree/bindings/mfd/axp20x.txt
> +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
> @@ -6,6 +6,7 @@ axp202 (X-Powers)
> axp209 (X-Powers)
> axp221 (X-Powers)
> axp223 (X-Powers)
> +axp803 (X-Powers)
> axp809 (X-Powers)
>
> Required properties:
> @@ -15,6 +16,7 @@ Required properties:
> * "x-powers,axp209"
> * "x-powers,axp221"
> * "x-powers,axp223"
> + * "x-powers,axp803"
> * "x-powers,axp806"
> * "x-powers,axp809"
> - reg: The I2C slave address or RSB hardware address for the AXP chip
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH v3 03/12] dt-bindings: make AXP20X compatible strings one per line
From: Lee Jones @ 2017-04-24 12:07 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Rob Herring, Chen-Yu Tsai, Maxime Ripard, Liam Girdwood,
Mark Brown, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170417115747.7300-4-icenowy-h8G6r0blFSE@public.gmane.org>
On Mon, 17 Apr 2017, Icenowy Zheng wrote:
> In the binding documentation of AXP20X mfd, the compatible strings used
> to be listed for three per line, which leads to some mess when trying to
> add AXP803 compatible string (as we have already AXP806 and AXP809
> compatibles, which is after AXP803 in ascending order).
>
> Make the compatible strings one per line, so that inserting a new
> compatible string will be directly a new line.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> ---
> New patch in v3.
>
> Documentation/devicetree/bindings/mfd/axp20x.txt | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
Applied, thanks.
> diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
> index b41d2601c6ba..a3e813f6060a 100644
> --- a/Documentation/devicetree/bindings/mfd/axp20x.txt
> +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
> @@ -9,9 +9,14 @@ axp223 (X-Powers)
> axp809 (X-Powers)
>
> Required properties:
> -- compatible: "x-powers,axp152", "x-powers,axp202", "x-powers,axp209",
> - "x-powers,axp221", "x-powers,axp223", "x-powers,axp806",
> - "x-powers,axp809"
> +- compatible: should be one of:
> + * "x-powers,axp152"
> + * "x-powers,axp202"
> + * "x-powers,axp209"
> + * "x-powers,axp221"
> + * "x-powers,axp223"
> + * "x-powers,axp806"
> + * "x-powers,axp809"
> - reg: The I2C slave address or RSB hardware address for the AXP chip
> - interrupt-parent: The parent interrupt controller
> - interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH v2 1/2] extcon: cros-ec: Add extcon-cros-ec driver to support display out.
From: Lee Jones @ 2017-04-24 11:58 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: Chanwoo Choi, MyungJoo Ham, Rob Herring, linux-kernel, devicetree,
Benson Leung
In-Reply-To: <cb06a494-3bce-0240-9a87-74a7942d4bf6@collabora.com>
On Mon, 10 Apr 2017, Enric Balletbo i Serra wrote:
>
>
> On 05/04/17 03:21, Chanwoo Choi wrote:
> > Hi Enric,
> >
> > On 2017년 03월 02일 16:29, Chanwoo Choi wrote:
> >> Hi,
> >>
> >> On 2017년 03월 01일 20:19, Enric Balletbo i Serra wrote:
> >>> From: Benson Leung <bleung@chromium.org>
> >>>
> >>> This is the driver for the USB Type C cable detection mechanism
> >>> built into the ChromeOS Embedded Controller on systems that
> >>> have USB Type-C ports.
> >>>
> >>> At present, this allows for the presence of display out, but in
> >>> future, it may also be used to notify host and device type cables
> >>> and the presence of power.
> >>>
> >>> Signed-off-by: Benson Leung <bleung@chromium.org>
> >>> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> >>> ---
> >>> Changes since v1:
> >>> Requested by Chanwoo Choi
> >>> - Rename files changing _ for -
> >>> - Remove the unneeded blank line on bottom of header.
> >>> - Remove kobject.h and cros_ec_commands.h includes.
> >>> - Remove the debug message as is not necessary.
> >>> - Use the tab for indentation instead of space for if sentence.
> >>> - Define each variable on different lines when the variables should be
> >>> initialized.
> >>> - Remove EXTCON_USB and EXTCON_USB_HOST as are not really used for now.
> >>> - Add one blank line to split out between state and property setting.
> >>> - Add the author information (header and module)
> >>>
> >>> Enric Balletbo
> >>> - As Rob suggested to rename the compatible name to something indicating that
> >>> is USB Type C related I also renamed the file names, extcon-cros-ec ->
> >>> extcon-usbc-cros-ec, I think it's more clear.
> >>>
> >>> drivers/extcon/Kconfig | 7 +
> >>> drivers/extcon/Makefile | 1 +
> >>> drivers/extcon/extcon-usbc-cros-ec.c | 415 +++++++++++++++++++++++++++++++++++
> >>> include/linux/mfd/cros_ec_commands.h | 75 +++++++
> >>> 4 files changed, 498 insertions(+)
> >>> create mode 100644 drivers/extcon/extcon-usbc-cros-ec.c
> >>>
> >>
> >> Looks good to me.
> >> Acked-by: Chanwoo Choi <cw00.chio@samsung.com>
> >>
> >> I think this patch should be handled with patches[1].
> >> [1] https://lkml.org/lkml/2017/2/14/655
> >>
> >> I think that one maintainer among following subsystems
> >> (mfd, chrome h/w platform, rtc and extcon)
> >> will apply their git repository, and then one maintainer
> >> will send the pull request of immutable branch for these patches.
> >>
> >
> > As I mentioned, these patch should be handled with related patches[1].
> > [1] https://lkml.org/lkml/2017/2/14/655
> >
> > So, I can't apply these patch on extcon git because there is a merge conflict
> > and we should handle these patches with immutable branch between subsystem maintainer.
> >
> > The v4.11-rc5 was released, if you want to apply this patch to the v4.12-rc1,
> > please take care of these patches.
> >
>
> Thanks, unfortunately the above patch dependency is not merged yet, I'll take
> care of these an resend this series rebased again once I have the confirmation
> of the above patch is merged or in a immutable branch.
I guess this patch will have to wait until v3.13 now.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v4 4/7] pinctrl: armada-37xx: Add gpio support
From: Linus Walleij @ 2017-04-24 11:48 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: linux-gpio@vger.kernel.org, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Thomas Petazzoni,
linux-arm-kernel@lists.infradead.org, Rob Herring,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Nadav Haklai, Victor Gu, Marcin Wojtas, Wilson Ding, Hua Jing,
Neta Zur Hershkovits
In-Reply-To: <83a4f4c08275b41333a2583f01ceb0453b009d9f.1491405475.git-series.gregory.clement@free-electrons.com>
On Wed, Apr 5, 2017 at 5:18 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> GPIO management is pretty simple and is part of the same IP than the pin
> controller for the Armada 37xx SoCs. This patch adds the GPIO support to
> the pinctrl-armada-37xx.c file, it also allows sharing common functions
> between the gpiolib and the pinctrl drivers.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v14 00/11] mux controller abstraction and iio/i2c muxes
From: Peter Rosin @ 2017-04-24 11:37 UTC (permalink / raw)
To: Philipp Zabel
Cc: Jonathan Cameron, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
Greg Kroah-Hartman, Wolfram Sang, Rob Herring, Mark Rutland,
Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
Jonathan Corbet, linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Andrew Morton, Colin Ian King,
Paul Gortmaker, kernel-bIcnvbaLZ9MEGnE8C9+IrQ
In-Reply-To: <1493031179.2446.9.camel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On 2017-04-24 12:52, Philipp Zabel wrote:
> On Mon, 2017-04-24 at 10:36 +0200, Peter Rosin wrote:
>> Hi!
>>
>> The big change since v13 is that the mux state is now locked with a mutex
>> instead of an rwsem. Other that that, it is mostly restructuring and doc
>> changes. There are a few other "real" changes as well, but those changes
>> feel kind of minor. I guess what I'm trying to say is that although the
>> list of changes for v14 is longish, it's still basically the same as last
>> time.
>
> I have hooked this up to the video-multiplexer and now I trigger
> the lockdep debug_check_no_locks_held error message when selecting the
> mux input from userspace:
>
> $ media-ctl --links "'imx6-mipi-csi2':1->'ipu1_csi0_mux':0[1]"
> [ 66.258368]
> [ 66.259919] =====================================
> [ 66.265369] [ BUG: media-ctl/258 still has locks held! ]
> [ 66.270810] 4.11.0-rc8-20170424-1+ #1305 Not tainted
> [ 66.275863] -------------------------------------
> [ 66.282158] 1 lock held by media-ctl/258:
> [ 66.286464] #0: (&mux->lock){+.+.+.}, at: [<8074a6c0>] mux_control_select+0x24/0x50
> [ 66.294424]
> [ 66.294424] stack backtrace:
> [ 66.298980] CPU: 0 PID: 258 Comm: media-ctl Not tainted 4.11.0-rc8+ #1305
> [ 66.306771] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
> [ 66.313334] Backtrace:
> [ 66.315858] [<8010e5a4>] (dump_backtrace) from [<8010e8ac>] (show_stack+0x20/0x24)
> [ 66.323473] r7:80e518d0 r6:80e518d0 r5:600d0013 r4:00000000
> [ 66.329190] [<8010e88c>] (show_stack) from [<80496cf4>] (dump_stack+0xb0/0xdc)
> [ 66.336470] [<80496c44>] (dump_stack) from [<8017e404>] (debug_check_no_locks_held+0xb8/0xbc)
> [ 66.345043] r9:ae8566b8 r8:ad88dc84 r7:ad88df58 r6:ad88dc84 r5:ad88df58 r4:ae856400
> [ 66.352837] [<8017e34c>] (debug_check_no_locks_held) from [<8012b258>] (do_exit+0x79c/0xcc8)
> [ 66.361321] [<8012aabc>] (do_exit) from [<8012d25c>] (do_group_exit+0x4c/0xcc)
> [ 66.368581] r7:000000f8
> [ 66.371161] [<8012d210>] (do_group_exit) from [<8012d2fc>] (__wake_up_parent+0x0/0x30)
> [ 66.379120] r7:000000f8 r6:76f71798 r5:00000000 r4:00000001
> [ 66.384837] [<8012d2dc>] (SyS_exit_group) from [<80109380>] (ret_fast_syscall+0x0/0x1c)
>
> That correctly warns that the media-ctl process caused the mux->lock to
> be locked and still held when the process exited. Do we need a usage
> counter based mechanism for muxes that are (indirectly) controlled from
> userspace?
Ok, so the difference is probably that the rwsem locking primitive
don't have any lockdep checking hooked up. Because the rwsem was
definitely held in the same way in v13 as the mutex is now held in
v14, so there's no fundamental difference.
So, yes, we can use some kind of refcount scheme to not hold an actual
mutex for the duration of the mux select/deselect, but that doesn't
really change anything. Userspace is still locking something, and that
seems dangerous. How do you make sure that mux_control_deselect is
called as it should?
What I don't like about abandoning the lock is that there is still a
need to support the multi-consumer case and then you need some way
of keeping track of waiters. A lock does this, and any attempt to open
code that will get messy.
What might be better is to support some kind of exclusive mux, i.e. a
mux that only allows one consumer per mux controller. Then the mux core
could trust that exclusive consumer to not fuck things up for itself and
thus have no lock at all for select/deselect for the exclusive case. Or
perhaps keep a refcount (as you suggested) for the exclusive case so
that mux_control_try_select still makes sense, because you still want
that, right?
The question then becomes how to best tell the mux core that you want
an exclusive mux. I see two options. Either you declare a mux controller
as exclusive up front somehow (in the device tree presumably), or you
add a mux_control_get_exclusive call that makes further calls to
mux_control_get{,_exclusive} fail with -EBUSY. I think I like the
latter better, if that can be made to work...
Cheers,
peda
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] fix ptr_ret.cocci warnings
From: Daniel Thompson @ 2017-04-24 11:26 UTC (permalink / raw)
To: Lee Jones, Olimpiu Dejeu
Cc: kbuild test robot, fengguang.wu, kbuild-all, Rob Herring,
linux-kernel, linux-fbdev, devicetree, jingoohan1, Brian Dodge,
joe, Matthew D'Asaro
In-Reply-To: <20170424105756.im6hjljqvyktzh6n@dell>
On 24/04/17 11:57, Lee Jones wrote:
> On Mon, 17 Apr 2017, Olimpiu Dejeu wrote:
>
>> On Tue, Mar 21, 2017 at 11:07 AM, Daniel Thompson <
>> daniel.thompson@linaro.org> wrote:
>>
>>> On 21/03/17 14:58, Olimpiu Dejeu wrote:
>>>
>>>> On Fri, Mar 17, 2017 at 10:48 AM, kbuild test robot <lkp@intel.com>
>>>> wrote:
>>>>
>>>>> drivers/video/backlight/arcxcnn_bl.c:183:1-3: WARNING: PTR_ERR_OR_ZERO
>>>>> can be used
>>>>>
>>>>>
>>>>> Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
>>>>>
>>>>> Generated by: scripts/coccinelle/api/ptr_ret.cocci
>>>>>
>>>>> CC: Olimpiu Dejeu <olimpiu@arcticsand.com>
>>>>> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
>>>>> ---
>>>>>
>>>>> arcxcnn_bl.c | 5 +----
>>>>> 1 file changed, 1 insertion(+), 4 deletions(-)
>>>>>
>>>>> --- a/drivers/video/backlight/arcxcnn_bl.c
>>>>> +++ b/drivers/video/backlight/arcxcnn_bl.c
>>>>> @@ -180,10 +180,7 @@ static int arcxcnn_backlight_register(st
>>>>>
>>>>> lp->bl = devm_backlight_device_register(lp->dev, name, lp->dev,
>>>>> lp,
>>>>> &arcxcnn_bl_ops, props);
>>>>> - if (IS_ERR(lp->bl))
>>>>> - return PTR_ERR(lp->bl);
>>>>> -
>>>>> - return 0;
>>>>> + return PTR_ERR_OR_ZERO(lp->bl);
>>>>> }
>>>>>
>>>>> static void arcxcnn_parse_dt(struct arcxcnn *lp)
>>>>>
>>>>
>>>> Acked-by: Olimpiu Dejeu <olimpiu@arcticsand.com>
>>>>
>>>
>>> Glad you approve! Could you apply this change and re-post the patch
>>> series? Thanks.
>>>
>>>
>>> Daniel.
>>>
>>>
>> Applied change, re-posted series on March 21st. No sure what next. Please
>> advise. Thanks.
>
> Yes you did.
>
> Daniel, do you see v9?
Yep. All fine at my end... it has my Reviewed-by: which is an even more
emphatic statement than my Acked-by: ;-) .
I think from this point on I think I'll start posting
"[vX-is-still-]Acked-by:" replies so you don't have to worry about
whether I've seen new versions.
> FYI, if this happens again, it's best to wait a couple of weeks then
> send the patch again like "[RESEND v9] ..." to gain attention.
RESENDs are a good way to go. Also, if there are questions about the
code its better to reply to the code rather than the side discussion.
Daniel.
^ permalink raw reply
* Re: [PATCH RFC 1/7] clk: samsung: Add enable/disable operation for PLL36XX clocks
From: Krzysztof Kozlowski @ 2017-04-24 11:18 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: devicetree, alsa-devel, linux-samsung-soc, jy0922.shim,
Javier Martinez Canillas,
Bartłomiej Żołnierkiewicz, Seung Woo Kim,
dri-devel, Inki Dae, Chanwoo Choi, broonie, robh+dt, linux-clk
In-Reply-To: <017b3ec8-c185-c29a-2944-12f519b461fe@samsung.com>
On Mon, Apr 24, 2017 at 1:12 PM, Sylwester Nawrocki
<s.nawrocki@samsung.com> wrote:
> On 04/22/2017 05:22 PM, Krzysztof Kozlowski wrote:
>>> @@ -354,10 +359,12 @@ static int samsung_pll36xx_set_rate(struct clk_hw
>>> *hw, unsigned long drate,
>>> writel_relaxed(pll_con1, pll->con_reg + 4);
>>>
>>> /* wait_lock_time */
>>> - do {
>>> - cpu_relax();
>>> - tmp = readl_relaxed(pll->con_reg);
>>> - } while (!(tmp & (1 << PLL36XX_LOCK_STAT_SHIFT)));
>
>
> I will add a comment here like:
> /* Wait until the PLL is locked if it is enabled. */
>
>>> + if (pll_con0 & BIT(pll->enable_offs)) {
>>
>>
>> Why this additional if() is needed?
>
>
> The PLL will never transition to a locked state if it is disabled, without
> this test we would end up with an indefinite loop below.
Hmmm... shouldn't this be split from this change? Or maybe this is
needed only because you added enable/disable for pl36xx and previously
this was not existing?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH RFC 1/7] clk: samsung: Add enable/disable operation for PLL36XX clocks
From: Sylwester Nawrocki @ 2017-04-24 11:12 UTC (permalink / raw)
To: Stephen Boyd
Cc: devicetree, alsa-devel, linux-samsung-soc, javier, b.zolnierkie,
sw0312.kim, dri-devel, cw00.choi, broonie, krzk, robh+dt,
linux-clk
In-Reply-To: <20170422025127.GS7065@codeaurora.org>
On 04/22/2017 04:51 AM, Stephen Boyd wrote:
>> +static int samsung_pll3xxx_enable(struct clk_hw *hw)
>> +{
>> + struct samsung_clk_pll *pll = to_clk_pll(hw);
>> + u32 tmp;
>> +
>> + tmp = readl_relaxed(pll->con_reg);
>> + tmp |= BIT(pll->enable_offs);
>> + writel_relaxed(tmp, pll->con_reg);
>> +
>> + /* wait lock time */
>> + do {
>> + cpu_relax();
>> + tmp = readl_relaxed(pll->con_reg);
>> + } while (!(tmp & BIT(pll->lock_offs)));
>
> Not a problem with this patch because we're moving code around,
> but this is a potential infinite loop that should have some sort
> of timeout so we don't sit here forever trying to see a bit
> toggle.
Yes, I will add some protection in new patch, like it is done
for newer PLLs. Thanks for you review.
--
Regards,
Sylwester
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH RFC 1/7] clk: samsung: Add enable/disable operation for PLL36XX clocks
From: Sylwester Nawrocki @ 2017-04-24 11:12 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: devicetree, alsa-devel, linux-samsung-soc, javier, b.zolnierkie,
sw0312.kim, dri-devel, cw00.choi, broonie, robh+dt, linux-clk
In-Reply-To: <20170422152236.tbf4iuoadqrvoc2n@kozik-lap>
On 04/22/2017 05:22 PM, Krzysztof Kozlowski wrote:
[...]
>> +static void samsung_pll3xxx_disable(struct clk_hw *hw)
>> +{
>> + struct samsung_clk_pll *pll = to_clk_pll(hw);
>> + u32 tmp;
>> +
>> + tmp = readl_relaxed(pll->con_reg);
>> + tmp |= BIT(pll->enable_offs);
>
> I think you meant here:
> tmp &= ~BIT()
Yes, I messed it up while copy/pasting from samsung_pll3xxx_enable().
>> + writel_relaxed(tmp, pll->con_reg);
>> +}
>> static unsigned long samsung_pll36xx_recalc_rate(struct clk_hw *hw,
>> unsigned long parent_rate)
>> @@ -354,10 +359,12 @@ static int samsung_pll36xx_set_rate(struct clk_hw *hw, unsigned long drate,
>> writel_relaxed(pll_con1, pll->con_reg + 4);
>>
>> /* wait_lock_time */
>> - do {
>> - cpu_relax();
>> - tmp = readl_relaxed(pll->con_reg);
>> - } while (!(tmp & (1 << PLL36XX_LOCK_STAT_SHIFT)));
I will add a comment here like:
/* Wait until the PLL is locked if it is enabled. */
>> + if (pll_con0 & BIT(pll->enable_offs)) {
>
> Why this additional if() is needed?
The PLL will never transition to a locked state if it is disabled, without
this test we would end up with an indefinite loop below.
>> + do {
>> + cpu_relax();
>> + tmp = readl_relaxed(pll->con_reg);
>> + } while (!(tmp & BIT(PLL36XX_LOCK_STAT_SHIFT)));
>
> To be consistent:
> BIT(pll->lock_offs)?
Yes, fixed.
Thanks for your review!
--
Regards,
Sylwester
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [GIT PULL] Immutable branch between MFD and IIO due for the v4.12 merge window
From: Lee Jones @ 2017-04-24 11:02 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Quentin Schulz, sre-DgEjT+Ai2ygdnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
wens-jdAy2FN1RRM, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
knaack.h-Mmb7MZpHnFY, lars-Qo5EllUWu/uELgA04lAiVw,
pmeerw-jW+XmwGofnusTnJN9+BGXg, icenowy-ymACFijhrKM,
liam-RYWXG+zxWwBdeoIcmNTgJF6hYfS7NtTn,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <0f30afec-ff42-e125-96d6-35893324f7ef-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
On Fri, 14 Apr 2017, Jonathan Cameron wrote:
> On 11/04/17 11:05, Lee Jones wrote:
> > Enjoy!
> >
> > The following changes since commit c1ae3cfa0e89fa1a7ecc4c99031f5e9ae99d9201:
> >
> > Linux 4.11-rc1 (2017-03-05 12:59:56 -0800)
> >
> > are available in the git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-iio-v4.12
> >
> > for you to fetch changes up to f2499ab450d3052097ba53a7d763f767935c0c59:
> >
> > iio: adc: add support for X-Powers AXP20X and AXP22X PMICs ADCs (2017-04-11 11:02:33 +0100)
> >
> > ----------------------------------------------------------------
> > Immutable branch between MFD and IIO due for the v4.12 merge window
> >
> > ----------------------------------------------------------------
> > Quentin Schulz (1):
> > iio: adc: add support for X-Powers AXP20X and AXP22X PMICs ADCs
> >
> > drivers/iio/adc/Kconfig | 10 +
> > drivers/iio/adc/Makefile | 1 +
> > drivers/iio/adc/axp20x_adc.c | 617 +++++++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 628 insertions(+)
> > create mode 100644 drivers/iio/adc/axp20x_adc.c
> >
> Hi Lee,
>
> Thanks for doing this, but the reason it was going to go through your
> tree in the first place was a dependency on
> commit 4707274714ef ("mfd: axp20x: Correct name of temperature data ADC registers")
>
> Not present in the immutable branch.
>
> There isn't much time for anything else going on around this driver though
> so other than a possible merge conflict on the Kconfig and Makefile shouldn't
> matter if this just goes through mfd. (famous last words ;)
It's not as though you committed it to text and sent it out to a
public mailing list for us all to reference though is it? Doh!
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH] fix ptr_ret.cocci warnings
From: Lee Jones @ 2017-04-24 10:57 UTC (permalink / raw)
To: Olimpiu Dejeu
Cc: Daniel Thompson, kbuild test robot,
fengguang.wu-ral2JQCrhuEAvxtiuMwx3w, kbuild-all-JC7UmRfGjtg,
Rob Herring, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
jingoohan1-Re5JQEeQqe8AvxtiuMwx3w, Brian Dodge,
joe-6d6DIl74uiNBDgjK7y7TUQ, Matthew D'Asaro
In-Reply-To: <CAF-XLWL_w3OqafbLzcM=kOkS1nPb0VSCAyDaudQh2UwE4Gw0gg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, 17 Apr 2017, Olimpiu Dejeu wrote:
> On Tue, Mar 21, 2017 at 11:07 AM, Daniel Thompson <
> daniel.thompson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>
> > On 21/03/17 14:58, Olimpiu Dejeu wrote:
> >
> >> On Fri, Mar 17, 2017 at 10:48 AM, kbuild test robot <lkp-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> >> wrote:
> >>
> >>> drivers/video/backlight/arcxcnn_bl.c:183:1-3: WARNING: PTR_ERR_OR_ZERO
> >>> can be used
> >>>
> >>>
> >>> Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
> >>>
> >>> Generated by: scripts/coccinelle/api/ptr_ret.cocci
> >>>
> >>> CC: Olimpiu Dejeu <olimpiu-eV7fy4qpoLhpLGFMi4vTTA@public.gmane.org>
> >>> Signed-off-by: Fengguang Wu <fengguang.wu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> >>> ---
> >>>
> >>> arcxcnn_bl.c | 5 +----
> >>> 1 file changed, 1 insertion(+), 4 deletions(-)
> >>>
> >>> --- a/drivers/video/backlight/arcxcnn_bl.c
> >>> +++ b/drivers/video/backlight/arcxcnn_bl.c
> >>> @@ -180,10 +180,7 @@ static int arcxcnn_backlight_register(st
> >>>
> >>> lp->bl = devm_backlight_device_register(lp->dev, name, lp->dev,
> >>> lp,
> >>> &arcxcnn_bl_ops, props);
> >>> - if (IS_ERR(lp->bl))
> >>> - return PTR_ERR(lp->bl);
> >>> -
> >>> - return 0;
> >>> + return PTR_ERR_OR_ZERO(lp->bl);
> >>> }
> >>>
> >>> static void arcxcnn_parse_dt(struct arcxcnn *lp)
> >>>
> >>
> >> Acked-by: Olimpiu Dejeu <olimpiu-eV7fy4qpoLhpLGFMi4vTTA@public.gmane.org>
> >>
> >
> > Glad you approve! Could you apply this change and re-post the patch
> > series? Thanks.
> >
> >
> > Daniel.
> >
> >
> Applied change, re-posted series on March 21st. No sure what next. Please
> advise. Thanks.
Yes you did.
Daniel, do you see v9?
FYI, if this happens again, it's best to wait a couple of weeks then
send the patch again like "[RESEND v9] ..." to gain attention.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH RFC 0/5] *** SPI Slave mode support ***
From: Geert Uytterhoeven @ 2017-04-24 10:55 UTC (permalink / raw)
To: Jiada Wang
Cc: Mark Brown, Rob Herring, Mark Rutland, Shawn Guo, Sascha Hauer,
Fabio Estevam, linux-spi,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <58F06092.9080409-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
Hi Jiada,
On Fri, Apr 14, 2017 at 7:39 AM, Jiada Wang <jiada_wang-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org> wrote:
> On 04/13/2017 12:47 PM, Geert Uytterhoeven wrote:
>> On Thu, Apr 13, 2017 at 2:59 PM, Mark Brown<broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>>> On Thu, Apr 13, 2017 at 05:13:59AM -0700, jiada_wang-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org wrote:
>>>> From: Jiada Wang<jiada_wang-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
>>>>
>>>> v1:
>>>> add Slave mode support in SPI core
>>>> spidev create slave device when SPI controller work in slave mode
>>>> spi-imx support to work in slave mode
>>>
>>> Adding Geert who also had a series doing this in progress that was
>>> getting very near to being merged.
>>
>> Thank you!
>>
>> Actually my plan is to fix the last remaining issues and resubmit for
>> v4.13.
>
> I noticed your patch set for SPI slave support,
> (I am sure you can find out some of the change
> in this patch set is based on your work).
> we have similar requirement to add slave mode support to ecspi IP on imx6
> Soc.
>
> Our use case is to use spidev as an interface to communicate with external
> SPI master devices.
> meanwhile the SPI bus controller can also act as master device to send data
> to other
> SPI slave devices on the board.
That sounds a bit hackish to me. SPI was never meant to be a multi-master bus.
While it can be done, you will need external synchronization (signals) to
avoid conflicts between the SPI masters.
> I found in your implementation, SPI bus controller is limited to either work
> in master mode or
> slave mode, is there any reasoning to not configure SPI mode based on SPI
> devices use case?
If you really need both master and slave support, you can use 2 subnodes
in DT, the first representing the master, the second the slave.
Mark, what's your opinion about this?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v14 00/11] mux controller abstraction and iio/i2c muxes
From: Philipp Zabel @ 2017-04-24 10:52 UTC (permalink / raw)
To: Peter Rosin
Cc: Jonathan Cameron, linux-kernel, Greg Kroah-Hartman, Wolfram Sang,
Rob Herring, Mark Rutland, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler, Jonathan Corbet, linux-i2c, devicetree,
linux-iio, linux-doc, Andrew Morton, Colin Ian King,
Paul Gortmaker, kernel
In-Reply-To: <1493022995-16917-1-git-send-email-peda@axentia.se>
On Mon, 2017-04-24 at 10:36 +0200, Peter Rosin wrote:
> Hi!
>
> The big change since v13 is that the mux state is now locked with a mutex
> instead of an rwsem. Other that that, it is mostly restructuring and doc
> changes. There are a few other "real" changes as well, but those changes
> feel kind of minor. I guess what I'm trying to say is that although the
> list of changes for v14 is longish, it's still basically the same as last
> time.
I have hooked this up to the video-multiplexer and now I trigger
the lockdep debug_check_no_locks_held error message when selecting the
mux input from userspace:
$ media-ctl --links "'imx6-mipi-csi2':1->'ipu1_csi0_mux':0[1]"
[ 66.258368]
[ 66.259919] =====================================
[ 66.265369] [ BUG: media-ctl/258 still has locks held! ]
[ 66.270810] 4.11.0-rc8-20170424-1+ #1305 Not tainted
[ 66.275863] -------------------------------------
[ 66.282158] 1 lock held by media-ctl/258:
[ 66.286464] #0: (&mux->lock){+.+.+.}, at: [<8074a6c0>] mux_control_select+0x24/0x50
[ 66.294424]
[ 66.294424] stack backtrace:
[ 66.298980] CPU: 0 PID: 258 Comm: media-ctl Not tainted 4.11.0-rc8+ #1305
[ 66.306771] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[ 66.313334] Backtrace:
[ 66.315858] [<8010e5a4>] (dump_backtrace) from [<8010e8ac>] (show_stack+0x20/0x24)
[ 66.323473] r7:80e518d0 r6:80e518d0 r5:600d0013 r4:00000000
[ 66.329190] [<8010e88c>] (show_stack) from [<80496cf4>] (dump_stack+0xb0/0xdc)
[ 66.336470] [<80496c44>] (dump_stack) from [<8017e404>] (debug_check_no_locks_held+0xb8/0xbc)
[ 66.345043] r9:ae8566b8 r8:ad88dc84 r7:ad88df58 r6:ad88dc84 r5:ad88df58 r4:ae856400
[ 66.352837] [<8017e34c>] (debug_check_no_locks_held) from [<8012b258>] (do_exit+0x79c/0xcc8)
[ 66.361321] [<8012aabc>] (do_exit) from [<8012d25c>] (do_group_exit+0x4c/0xcc)
[ 66.368581] r7:000000f8
[ 66.371161] [<8012d210>] (do_group_exit) from [<8012d2fc>] (__wake_up_parent+0x0/0x30)
[ 66.379120] r7:000000f8 r6:76f71798 r5:00000000 r4:00000001
[ 66.384837] [<8012d2dc>] (SyS_exit_group) from [<80109380>] (ret_fast_syscall+0x0/0x1c)
That correctly warns that the media-ctl process caused the mux->lock to
be locked and still held when the process exited. Do we need a usage
counter based mechanism for muxes that are (indirectly) controlled from
userspace?
regards
Philipp
^ permalink raw reply
* Re: [PATCH v2 1/5] dt-bindings: gpu: add bindings for the ARM Mali Midgard GPU
From: Guillaume Tucker @ 2017-04-24 10:43 UTC (permalink / raw)
To: Rob Herring
Cc: Heiko Stuebner, Mark Rutland, Sjoerd Simons,
Enric Balletbo i Serra, John Reitan, Wookey,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <b8cf7acd-83e9-49fb-0800-19a76b8dcce5-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
On 18/04/17 10:15, Guillaume Tucker wrote:
> Hi Rob,
>
> On 04/04/17 03:00, Rob Herring wrote:
>> On Sun, Apr 02, 2017 at 08:59:44AM +0100, Guillaume Tucker wrote:
>>> +- operating-points : Refer to Documentation/devicetree/bindings/power/opp.txt
>>> + for details.
>>
>> Is this going to be sufficient vs. operating-points-v2? Or should it be
>> a power domain with OPPs?
>
> In principle, switching to operating-points-v2 should be very
> straightforward. I have smoke-tested the driver with an
> operating-points-v2 table and a phandle to it inside the gpu node
> in place of operating-points and it seems to be working fine. At
> least it parsed the OPPs and got initialised correctly.
>
> My understanding is that operating-points (v1) are not deprecated
> so we could keep the bindings as-is, but please let me know
> otherwise and I can try to address that in my next patch version.
> In the documentation, it should only be the case of replacing
> operating-points with operating-points-v2.
While the opp bindings documentation doesn't mention anything
about operating-points being deprecated, the code and comments in
of.c are pretty clear about this:
/*
* OPPs have two version of bindings now. The older one is deprecated,
* try for the new binding first.
*/
So I shall use operating-points-v2 in my patch v4.
Thanks,
Guillaume
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH V7 4/7] mfd: da9061: MFD core support
From: Steve Twiss @ 2017-04-24 10:37 UTC (permalink / raw)
To: Lee Jones
Cc: LINUX-KERNEL, DEVICETREE, Dmitry Torokhov, Eduardo Valentin,
Guenter Roeck, LINUX-INPUT, LINUX-PM, LINUX-WATCHDOG,
Liam Girdwood, Mark Brown, Mark Rutland, Rob Herring,
Support Opensource, Wim Van Sebroeck, Zhang Rui
In-Reply-To: <20170404083902.ywo3pdxptgfcqvga@dell>
On 04 April 2017 09:39, Lee Jones wrote:
> Subject: Re: [PATCH V7 4/7] mfd: da9061: MFD core support
>
> On Mon, 03 Apr 2017, Steve Twiss wrote:
> > From: Steve Twiss <stwiss.opensource@diasemi.com>
> > MFD support for DA9061 is provided as part of the DA9062 device driver.
> >
> > The registers header file adds two new chip variant IDs defined in DA9061
> > and DA9062 hardware. The core header file adds new software enumerations
> > for listing the valid DA9061 IRQs and a da9062_compatible_types enumeration
> > for distinguishing between DA9061/62 devices in software.
> >
> > The core source code adds a new .compatible of_device_id entry. This is
> > extended from DA9062 to support both "dlg,da9061" and "dlg,da9062". The
> > .data entry now holds a reference to the enumerated device type.
> >
> > A new regmap_irq_chip model is added for DA9061 and this supports the new
> > list of regmap_irq entries. A new mfd_cell da9061_devs[] array lists the
> > new sub system components for DA9061. Support is added for a new DA9061
> > regmap_config which lists the correct readable, writable and volatile
> > ranges for this chip.
> >
> > The probe function uses the device tree compatible string to switch on the
> > da9062_compatible_types and configure the correct mfd cells, irq chip and
> > regmap config.
> >
> > Kconfig is updated to reflect support for DA9061 and DA9062 PMICs.
> >
> > Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
>
> Ah, here it is.
>
> Applied, thanks.
Hi Lee,
I noticed the DA9061 core support has been added into linux-next, however
the commit message was changed from the original title:
"mfd: da9061: MFD core support"
to add the mistake:
"mfd: Add suppfor for DA9061"
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=d3fe0806025cacdab1462d5704e1c98ab9db4564
Can this be fixed please?
This patch has not been upstreamed into linux-mainline and is still in linux-next.
Regards,
Steve
^ permalink raw reply
* Re: Re: [PATCH v5 02/11] clk: sunxi-ng: add support for DE2 CCU
From: icenowy-h8G6r0blFSE @ 2017-04-24 10:26 UTC (permalink / raw)
To: maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8
Cc: Rob Herring, Chen-Yu Tsai, Jernej Skrabec,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170424085109.p44bmzbyjkuf7ckv@lukather>
在 2017-04-24 16:51,Maxime Ripard 写道:
> Hi,
>
> On Sun, Apr 23, 2017 at 06:37:45PM +0800, Icenowy Zheng wrote:
>> +static const struct of_device_id sunxi_de2_clk_ids[] = {
>> + {
>> + .compatible = "allwinner,sun8i-a83t-de2-clk",
>> + .data = &sun8i_a83t_de2_clk_desc,
>> + },
>> + {
>> + .compatible = "allwinner,sun50i-h5-de2-clk",
>> + .data = &sun50i_a64_de2_clk_desc,
>> + },
>> + /*
>> + * The Allwinner A64 SoC needs some bit to be poke in syscon to make
>> + * DE2 really working.
>> + * So there's currently no A64 compatible here.
>> + * H5 shares the same reset line with A64, so here H5 is using the
>> + * clock description of A64.
>> + */
>> + { }
>> +};
>
> So that A64 driver would require more than just what you defined in
> the binding in order to operate?
Yes. When trying to do A64 driver, I will send out first a patch to
add the needed binding bit.
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: Re: [PATCH v3 02/12] arm64: allwinner: a64: add NMI controller on A64
From: icenowy-h8G6r0blFSE @ 2017-04-24 10:25 UTC (permalink / raw)
To: Maxime Ripard
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Mark Brown,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Liam Girdwood,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Chen-Yu Tsai, Rob Herring,
Lee Jones, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170424071746.u2lrk43kmvvd7m25@lukather>
在 2017-04-24 15:17,Maxime Ripard 写道:
> On Thu, Apr 20, 2017 at 03:03:38PM +0800, icenowy-h8G6r0blFSE@public.gmane.org wrote:
>> 在 2017-04-20 13:58,Maxime Ripard 写道:
>> > On Tue, Apr 18, 2017 at 06:56:43PM +0800, Icenowy Zheng wrote:
>> > >
>> > >
>> > > 于 2017年4月18日 GMT+08:00 下午3:00:16, Maxime Ripard
>> > > <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> 写到:
>> > > >On Mon, Apr 17, 2017 at 07:57:37PM +0800, Icenowy Zheng wrote:
>> > > >> Allwinner A64 SoC features a NMI controller, which is usually
>> > > >connected
>> > > >> to the AXP PMIC.
>> > > >>
>> > > >> Add support for it.
>> > > >>
>> > > >> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>> > > >> Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
>> > > >> ---
>> > > >> Changes in v2:
>> > > >> - Added Chen-Yu's ACK.
>> > > >>
>> > > >> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 8 ++++++++
>> > > >> 1 file changed, 8 insertions(+)
>> > > >>
>> > > >> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> > > >b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> > > >> index 05ec9fc5e81f..53c18ca372ea 100644
>> > > >> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> > > >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
>> > > >> @@ -403,6 +403,14 @@
>> > > >> <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
>> > > >> };
>> > > >>
>> > > >> + nmi_intc: interrupt-controller@01f00c0c {
>> > > >> + compatible = "allwinner,sun6i-a31-sc-nmi";
>> > > >> + interrupt-controller;
>> > > >> + #interrupt-cells = <2>;
>> > > >> + reg = <0x01f00c0c 0x38>;
>> > > >
>> > > >The base address is not correct, and there's uncertainty on whether
>> > > >this is this particular controller or not. Did you even test this?
>> > >
>> > > Tested by axp20x-pek.
>> >
>> > Still, the base address is wrong, which is yet another hint that this
>> > is not the same interrupt controller, and just works by accident.
>>
>> No, it's the same as other post-sun6i device trees.
>> See other post-sun6i device trees: (or maybe they're all wrong, but
>> as we have no document for it, we should temporarily keep them)
>>
>> sun6i-a31.dtsi
>> ```
>> nmi_intc: interrupt-controller@01f00c0c {
>> compatible = "allwinner,sun6i-a31-sc-nmi";
>> interrupt-controller;
>> #interrupt-cells = <2>;
>> reg = <0x01f00c0c 0x38>;
>> interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
>> };
>> ```
>>
>> sun8i-a23-a33.dtsi
>> ```
>> nmi_intc: interrupt-controller@01f00c0c {
>> compatible = "allwinner,sun6i-a31-sc-nmi";
>> interrupt-controller;
>> #interrupt-cells = <2>;
>> reg = <0x01f00c0c 0x38>;
>> interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
>> };
>> ```
>>
>> But according to the BSP device tree, the base address should be
>> 0x01f00c00. Should I send some patch to fix all of them? (but it will
>> break device tree compatibility)
>
> I'm really not a big fan of "if we see something that is broken, just
> let it rot" to be honest.
>
> We have no idea how this controller works exactly, just like we have
> no idea if it is exactly the same controller or not.
>
> The only thing we have today is the memory map, and it tells us that
> it has more registers than what you express here.
>
> Because of the DT backward compatibility, you have to think of it the
> other way around: what will happen if it turns out we need to setup
> any register outside of that region you described in the DT, in
> something like a year or so?
>
> We can't, really. While if you have the full memory region from the
> beginning, then you just have to add a single writel in your driver.
So things are now already broken, and we may need to fix also A31 and
A23/33.
How should we do this?
>
> Maxime
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH 02/16] mfd: madera: Add common support for Cirrus Logic Madera codecs
From: Lee Jones @ 2017-04-24 10:03 UTC (permalink / raw)
To: Richard Fitzgerald
Cc: linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
gnurou-Re5JQEeQqe8AvxtiuMwx3w, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
tglx-hfZtesqFncYOwBW4kG4KsQ, jason-NLaQJdtUoK4Be96aLqz0jA,
broonie-DgEjT+Ai2ygdnm+yROfE0A, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1492620124.4826.47.camel-WeElTRBN8n0bEPBeyYQi64iQ8/zYDDdY1BehtkLrGTY@public.gmane.org>
On Wed, 19 Apr 2017, Richard Fitzgerald wrote:
> On Wed, 2017-04-12 at 13:54 +0100, Lee Jones wrote:
> > On Wed, 05 Apr 2017, Richard Fitzgerald wrote:
> >
> > > This adds the generic core support for Cirrus Logic "Madera" class codecs.
> > > These are complex audio codec SoCs with a variety of digital and analogue
> > > I/O, onboard audio processing and DSPs, and other features.
> > >
> > > These codecs are all based off a common set of hardware IP so can be
> > > supported by a core of common code (with a few minor device-to-device
> > > variations).
> > >
> > > Signed-off-by: Charles Keepax <ckeepax-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
> > > Signed-off-by: Nikesh Oswal <Nikesh.Oswal-UVNVL95qEvAciDkP5Hr2oA@public.gmane.org>
> > > Signed-off-by: Richard Fitzgerald <rf-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org>
> > > ---
> > > Documentation/devicetree/bindings/mfd/madera.txt | 79 +++
> > > MAINTAINERS | 3 +
> > > drivers/mfd/Kconfig | 23 +
> > > drivers/mfd/Makefile | 4 +
> > > drivers/mfd/madera-core.c | 689 +++++++++++++++++++++++
> > > drivers/mfd/madera-i2c.c | 130 +++++
> > > drivers/mfd/madera-spi.c | 131 +++++
> > > drivers/mfd/madera.h | 52 ++
> > > include/linux/mfd/madera/core.h | 175 ++++++
> > > include/linux/mfd/madera/pdata.h | 88 +++
> > > 10 files changed, 1374 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/mfd/madera.txt
> > > create mode 100644 drivers/mfd/madera-core.c
> > > create mode 100644 drivers/mfd/madera-i2c.c
> > > create mode 100644 drivers/mfd/madera-spi.c
> > > create mode 100644 drivers/mfd/madera.h
> > > create mode 100644 include/linux/mfd/madera/core.h
> > > create mode 100644 include/linux/mfd/madera/pdata.h
> > >
> > > diff --git a/Documentation/devicetree/bindings/mfd/madera.txt b/Documentation/devicetree/bindings/mfd/madera.txt
> > > new file mode 100644
> > > index 0000000..a6c3260
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/mfd/madera.txt
> > > @@ -0,0 +1,79 @@
> > > +Cirrus Logic Madera class audio codecs multi-function device
> > > +
> > > +These devices are audio SoCs with extensive digital capabilities and a range
> > > +of analogue I/O.
> > > +
> > > +See also the child driver bindings in:
> > > +bindings/extcon/extcon-madera.txt
> > > +bindings/gpio/gpio-madera.txt
> > > +bindings/interrupt-controller/cirrus,madera.txt
> > > +bindings/pinctrl/cirrus,madera-pinctrl.txt
> > > +bindings/regulator/madera-ldo1.txt
> > > +bindings/regulator/madera-micsupp.txt
> > > +bindings/sound/madera.txt
> > > +
> > > +Required properties:
> > > +
> > > + - compatible : One of the following chip-specific strings:
> > > + "cirrus,cs47l35"
> > > + "cirrus,cs47l85"
> > > + "cirrus,cs47l90"
> > > + "cirrus,cs47l91"
> > > + "cirrus,wm1840"
> > > +
> > > + - reg : I2C slave address when connected using I2C, chip select number when
> > > + using SPI.
> > > +
> > > + - DCVDD-supply : Power supply for the device as defined in
> > > + bindings/regulator/regulator.txt
> > > + Mandatory on CS47L35, CS47L90, CS47L91
> > > + Optional on CS47L85, WM1840
> > > +
> > > + - AVDD-supply, DBVDD1-supply, DBVDD2-supply, CPVDD1-supply, CPVDD2-supply :
> > > + Power supplies for the device
> > > +
> > > + - DBVDD3-supply, DBVDD4-supply : Power supplies for the device
> > > + (CS47L85, CS47L90, CS47L91, WM1840)
> > > +
> > > + - SPKVDDL-supply, SPKVDDR-supply : Power supplies for the device
> > > + (CS47L85, WM1840)
> > > +
> > > + - SPKVDD-supply : Power supply for the device
> > > + (CS47L35)
> > > +
> > > +Optional properties:
> > > +
> > > + - MICVDD-supply : Power supply, only need to be specified if
> > > + powered externally
> > > +
> > > + - reset-gpios : One entry specifying the GPIO controlling /RESET.
> > > + As defined in bindings/gpio.txt.
> > > + Although optional, it is strongly recommended to use a hardware reset
> > > +
> > > + - MICBIASx : Initial data for the MICBIAS regulators, as covered in
> > > + Documentation/devicetree/bindings/regulator/regulator.txt.
> > > + One for each MICBIAS generator (MICBIAS1, MICBIAS2, ...)
> > > + (all codecs)
> > > +
> > > + One for each output pin (MICBIAS1A, MIBCIAS1B, MICBIAS2A, ...)
> > > + (all except CS47L85, WM1840)
> > > +
> > > + The following following additional property is supported for the generator
> > > + nodes:
> > > + - cirrus,ext-cap : Set to 1 if the MICBIAS has external decoupling
> > > + capacitors attached.
> > > +
> > > +Example:
> > > +
> > > +codec: cs47l85@0 {
> >
> > Node names should be generic.
> >
> > You can swap these round if you want, so:
> >
> > cs47l85: codec@0 {
> >
> > ... is valid.
> >
> > > + compatible = "cirrus,cs47l85";
> > > + reg = <0>;
> > > +
> > > + reset-gpios = <&gpio 0>;
> > > +
> > > + MICBIAS1 {
> > > + regulator-min-microvolt = <900000>;
> > > + regulator-max-microvolt = <3300000>;
> > > + cirrus,ext-cap = <1>;
> > > + };
> > > +};
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index 02995c9..d28e53f 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -3266,7 +3266,10 @@ L: patches-yzvPICuk2AATkU/dhu1WVueM+bqZidxxQQ4Iyu8u01E@public.gmane.org
> > > T: git https://github.com/CirrusLogic/linux-drivers.git
> > > W: https://github.com/CirrusLogic/linux-drivers/wiki
> > > S: Supported
> > > +F: Documentation/devicetree/bindings/mfd/madera.txt
> > > F: include/linux/mfd/madera/*
> > > +F: drivers/mfd/madera*
> > > +F: drivers/mfd/cs47l*
> > >
> > > CLEANCACHE API
> > > M: Konrad Rzeszutek Wilk <konrad.wilk-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
> > > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> > > index ce3a918..f0f9979 100644
> > > --- a/drivers/mfd/Kconfig
> > > +++ b/drivers/mfd/Kconfig
> > > @@ -203,6 +203,29 @@ config MFD_CROS_EC_SPI
> > > response time cannot be guaranteed, we support ignoring
> > > 'pre-amble' bytes before the response actually starts.
> > >
> > > +config MFD_MADERA
> > > + bool
> > > + select REGMAP
> > > + select MFD_CORE
> > > +
> > > +config MFD_MADERA_I2C
> > > + tristate "Cirrus Logic Madera codecs with I2C"
> > > + select MFD_MADERA
> > > + select REGMAP_I2C
> > > + depends on I2C
> > > + help
> > > + Support for the Cirrus Logic Madera platform audio SoC
> > > + core functionality controlled via I2C.
> > > +
> > > +config MFD_MADERA_SPI
> > > + tristate "Cirrus Logic Madera codecs with SPI"
> > > + select MFD_MADERA
> > > + select REGMAP_SPI
> > > + depends on SPI_MASTER
> > > + help
> > > + Support for the Cirrus Logic Madera platform audio SoC
> > > + core functionality controlled via SPI.
> > > +
> > > config MFD_ASIC3
> > > bool "Compaq ASIC3"
> > > depends on GPIOLIB && ARM
> > > diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> > > index fa86dbe..c41f6c9 100644
> > > --- a/drivers/mfd/Makefile
> > > +++ b/drivers/mfd/Makefile
> > > @@ -72,6 +72,10 @@ obj-$(CONFIG_MFD_WM8350_I2C) += wm8350-i2c.o
> > > wm8994-objs := wm8994-core.o wm8994-irq.o wm8994-regmap.o
> > > obj-$(CONFIG_MFD_WM8994) += wm8994.o
> > >
> > > +obj-$(CONFIG_MFD_MADERA) += madera-core.o
> > > +obj-$(CONFIG_MFD_MADERA_I2C) += madera-i2c.o
> > > +obj-$(CONFIG_MFD_MADERA_SPI) += madera-spi.o
> > > +
> > > obj-$(CONFIG_TPS6105X) += tps6105x.o
> > > obj-$(CONFIG_TPS65010) += tps65010.o
> > > obj-$(CONFIG_TPS6507X) += tps6507x.o
> > > diff --git a/drivers/mfd/madera-core.c b/drivers/mfd/madera-core.c
> > > new file mode 100644
> > > index 0000000..ab5fe9b
> > > --- /dev/null
> > > +++ b/drivers/mfd/madera-core.c
> > > @@ -0,0 +1,689 @@
> > > +/*
> > > + * Core MFD support for Cirrus Logic Madera codecs
> > > + *
> > > + * Copyright 2015-2017 Cirrus Logic
> > > + *
> > > + * 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/device.h>
> > > +#include <linux/delay.h>
> > > +#include <linux/err.h>
> > > +#include <linux/gpio.h>
> > > +#include <linux/mfd/core.h>
> > > +#include <linux/module.h>
> > > +#include <linux/notifier.h>
> > > +#include <linux/of.h>
> > > +#include <linux/of_device.h>
> > > +#include <linux/of_gpio.h>
> > > +#include <linux/platform_device.h>
> > > +#include <linux/pm_runtime.h>
> > > +#include <linux/regmap.h>
> > > +#include <linux/regulator/consumer.h>
> > > +#include <linux/regulator/machine.h>
> > > +#include <linux/regulator/of_regulator.h>
> > > +
> > > +#include <linux/mfd/madera/core.h>
> > > +#include <linux/mfd/madera/registers.h>
> > > +
> > > +#include "madera.h"
> > > +
> > > +#define CS47L35_SILICON_ID 0x6360
> > > +#define CS47L85_SILICON_ID 0x6338
> > > +#define CS47L90_SILICON_ID 0x6364
> > > +
> > > +#define MADERA_32KZ_MCLK2 1
> > > +
> > > +static const char * const madera_core_supplies[] = {
> > > + "AVDD",
> > > + "DBVDD1",
> > > +};
> > > +
> > > +static const struct mfd_cell madera_ldo1_devs[] = {
> > > + { .name = "madera-ldo1", .of_compatible = "cirrus,madera-ldo1" },
> > > +};
> > > +
> > > +static const struct mfd_cell cs47l35_devs[] = {
> > > + { .name = "madera-pinctrl", .of_compatible = "cirrus,madera-pinctrl" },
> > > + { .name = "madera-irq", },
> >
> > I believe this should be "interrupt-controller".
> >
>
> I don't think that's the case. I checked other irchip drivers and they
> have no particular standard naming. At least one is called
> "something-irq", none are called "something-interrupt-controller"
>
> > irq is ambiguous.
> >
>
> I can't really see what other driver this could be confused with,
> especially as it's specified as madera-* so the alternative drivers are
> limited. Given the limited set of drivers I think it's clear enough it's
> the driver for the IRQ and a longer name doesn't add information.
>
> > Same goes for the ones below.
> >
>
> Ditto. madera-micsupp will be replaced by the existing arizona-micsupp.
> Most gpio drivers are called "something-gpio". Extcon is the name of a
> driver subsystem so should be sufficiently clear. Likewise madera-codec.
I meant just the "-irq" entries.
... but I'm not 100% convinced that calling it "-irq" a terrible idea,
just that "irq-controller" or "interrupt-controller" would be better.
Either way, it's not a blocking point.
> > > + { .name = "madera-micsupp", .of_compatible = "cirrus,madera-micsupp" },
> > > + { .name = "madera-gpio", .of_compatible = "cirrus,madera-gpio" },
> > > + { .name = "madera-extcon", .of_compatible = "cirrus,madera-extcon" },
> > > + { .name = "cs47l35-codec", .of_compatible = "cirrus,cs47l35-codec" },
> > > + { .name = "madera-haptics", .of_compatible = "cirrus,madera-haptics" },
> > > +};
> > > +
> > > +static const struct mfd_cell cs47l85_devs[] = {
> > > + { .name = "madera-pinctrl", .of_compatible = "cirrus,madera-pinctrl" },
> > > + { .name = "madera-irq", },
> > > + { .name = "madera-micsupp", .of_compatible = "cirrus,madera-micsupp" },
> > > + { .name = "madera-gpio", .of_compatible = "cirrus,madera-gpio" },
> > > + { .name = "madera-extcon", .of_compatible = "cirrus,madera-extcon" },
> > > + { .name = "cs47l85-codec", .of_compatible = "cirrus,cs47l85-codec" },
> > > + { .name = "madera-haptics", .of_compatible = "cirrus,madera-haptics" },
> > > +};
> > > +
> > > +static const struct mfd_cell cs47l90_devs[] = {
> > > + { .name = "madera-pinctrl", .of_compatible = "cirrus,madera-pinctrl" },
> > > + { .name = "madera-irq", },
> > > + { .name = "madera-micsupp", .of_compatible = "cirrus,madera-micsupp" },
> > > + { .name = "madera-gpio", .of_compatible = "cirrus,madera-gpio" },
> > > + { .name = "madera-extcon", .of_compatible = "cirrus,madera-extcon" },
> > > + { .name = "cs47l90-codec", .of_compatible = "cirrus,cs47l90-codec" },
> > > + { .name = "madera-haptics", .of_compatible = "cirrus,madera-haptics" },
> > > +};
> > > +
> > > +const char *madera_name_from_type(enum madera_type type)
> > > +{
> > > + switch (type) {
> > > + case CS47L35:
> > > + return "CS47L35";
> > > + case CS47L85:
> > > + return "CS47L85";
> > > + case CS47L90:
> > > + return "CS47L90";
> > > + case CS47L91:
> > > + return "CS47L91";
> > > + case WM1840:
> > > + return "WM1840";
> > > + default:
> > > + return "Unknown";
> > > + }
> > > +}
> > > +EXPORT_SYMBOL_GPL(madera_name_from_type);
> > > +
> > > +#define MADERA_BOOT_POLL_MAX_INTERVAL_US 5000
> > > +#define MADERA_BOOT_POLL_TIMEOUT_US 25000
> > > +
> > > +static int madera_wait_for_boot(struct madera *madera)
> > > +{
> > > + unsigned int val;
> > > + int ret;
> > > +
> > > + /*
> > > + * We can't use an interrupt as we need to runtime resume to do so,
> > > + * so we poll the status bit. This won't race with the interrupt
> > > + * handler because it will be blocked on runtime resume.
> > > + */
> > > + ret = regmap_read_poll_timeout(madera->regmap,
> > > + MADERA_IRQ1_RAW_STATUS_1,
> > > + val,
> > > + (val & MADERA_BOOT_DONE_STS1),
> > > + MADERA_BOOT_POLL_MAX_INTERVAL_US,
> > > + MADERA_BOOT_POLL_TIMEOUT_US);
> > > + /*
> > > + * BOOT_DONE defaults to unmasked on boot so we must ack it.
> > > + * Do this unconditionally to avoid interrupt storms
> > > + */
> > > + regmap_write(madera->regmap, MADERA_IRQ1_STATUS_1,
> > > + MADERA_BOOT_DONE_EINT1);
> > > +
> > > + if (ret)
> > > + dev_err(madera->dev, "Polling BOOT_DONE_STS failed: %d\n", ret);
> >
> > Why isn't this under the call to regmap_read_poll_timeout()?
> >
>
> It was intended to make it clear that we must ack the BOOT_DONE now no
> matter what and to avoid the potential with them the other way around of
> someone adding more code in the if (or just a ret) and so accidentally
> failing to do the ack. I could swap them but I think I prefer keeping
> them this way and changing the comment to say this.
Okay.
I'm going to assume that we are in agreement for all points that you
did not answer (which is good). I look forward to the next version.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Applied "ASoC: Add Odroid sound DT bindings documentation" to the asoc tree
From: Mark Brown @ 2017-04-24 9:57 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Sylwester Nawrocki, linux-samsung-soc, linux-clk, dri-devel,
alsa-devel, devicetree, jy0922.shim, Javier Martinez Canillas,
Bartłomiej Żołnierkiewicz, Seung Woo Kim, Inki Dae,
Chanwoo Choi, robh+dt
In-Reply-To: <20170421180710.6gdaosnk2gn2leoo@kozik-lap>
[-- Attachment #1: Type: text/plain, Size: 368 bytes --]
On Fri, Apr 21, 2017 at 08:07:10PM +0200, Krzysztof Kozlowski wrote:
> Mutt is complaining that your key used to sign the mails has expired:
> gpg: Note: This key has expired!
> Primary key fingerprint: 3F25 68AA C269 98F9 E813 A1C5 C3F4 36CA 30F5 D8EB
> Subkey fingerprint: ADE6 68AA 6757 18B5 9FE2 9FEA 24D6 8B72 5D54 87D0
gpg --refresh-keys should fix that.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH V2] clk: hi6220: Add the hi655x's pmic clock
From: Daniel Lezcano @ 2017-04-24 9:43 UTC (permalink / raw)
To: Lee Jones
Cc: sboyd, mturquette, xuwei5, devicetree, linux-kernel,
linux-arm-kernel, linux-clk
In-Reply-To: <20170424093154.ffo7zsr66a2yjy74@dell>
On Mon, Apr 24, 2017 at 10:31:54AM +0100, Lee Jones wrote:
> On Sat, 08 Apr 2017, Daniel Lezcano wrote:
>
> > The hi655x multi function device is a PMIC providing regulators.
> >
> > The PMIC also provides a clock for the WiFi and the Bluetooth, let's implement
> > this clock in order to add it in the hi655x MFD and allow proper wireless
> > initialization.
> >
> > Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> > ---
> >
> > Changelog:
> >
> > V2:
> > - Added COMPILE_TEST option, compiled on x86
> > - Removed useless parenthesis
> > - Used of_clk_hw_simple_get() instead of deref dance
> > - Do bailout if the clock-names is not specified
> > - Rollback on error
> > - Folded mfd line change and binding
> > - Added #clock-cells binding documentation
> > - Added #clock-cells in the DT
> >
> > V1: initial post
> > ---
>
> ??
>
> > ---
>
> I'm unsure if this as been mentioned before, but bundling;
> driver & architecture changes and documentation into a single patch is
> very seldom a good idea. In this case, you should split this into at
> least 3, perhaps 4 patches.
>
> > .../devicetree/bindings/mfd/hisilicon,hi655x.txt | 6 +
>
> Patch 1
>
> > arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 1 +
>
> Patch 2
>
> > drivers/clk/Kconfig | 8 ++
> > drivers/clk/Makefile | 1 +
> > drivers/clk/clk-hi655x.c | 140 +++++++++++++++++++++
>
> Patch 3
>
> > drivers/mfd/hi655x-pmic.c | 3 +-
>
> Patch 4
>
> [...]
Yep. Will do that next time.
Thanks.
-- Daniel
^ permalink raw reply
* Re: [PATCH V2] clk: hi6220: Add the hi655x's pmic clock
From: Lee Jones @ 2017-04-24 9:31 UTC (permalink / raw)
To: Daniel Lezcano
Cc: sboyd, mturquette, xuwei5, devicetree, linux-kernel,
linux-arm-kernel, linux-clk
In-Reply-To: <1491683412-12237-1-git-send-email-daniel.lezcano@linaro.org>
On Sat, 08 Apr 2017, Daniel Lezcano wrote:
> The hi655x multi function device is a PMIC providing regulators.
>
> The PMIC also provides a clock for the WiFi and the Bluetooth, let's implement
> this clock in order to add it in the hi655x MFD and allow proper wireless
> initialization.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> ---
>
> Changelog:
>
> V2:
> - Added COMPILE_TEST option, compiled on x86
> - Removed useless parenthesis
> - Used of_clk_hw_simple_get() instead of deref dance
> - Do bailout if the clock-names is not specified
> - Rollback on error
> - Folded mfd line change and binding
> - Added #clock-cells binding documentation
> - Added #clock-cells in the DT
>
> V1: initial post
> ---
??
> ---
I'm unsure if this as been mentioned before, but bundling;
driver & architecture changes and documentation into a single patch is
very seldom a good idea. In this case, you should split this into at
least 3, perhaps 4 patches.
> .../devicetree/bindings/mfd/hisilicon,hi655x.txt | 6 +
Patch 1
> arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 1 +
Patch 2
> drivers/clk/Kconfig | 8 ++
> drivers/clk/Makefile | 1 +
> drivers/clk/clk-hi655x.c | 140 +++++++++++++++++++++
Patch 3
> drivers/mfd/hi655x-pmic.c | 3 +-
Patch 4
[...]
> 6 files changed, 158 insertions(+), 1 deletion(-)
> create mode 100644 drivers/clk/clk-hi655x.c
>
> diff --git a/Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt b/Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt
> index 0548569..194e2a9fd 100644
> --- a/Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt
> +++ b/Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt
> @@ -16,6 +16,11 @@ Required properties:
> - reg: Base address of PMIC on Hi6220 SoC.
> - interrupt-controller: Hi655x has internal IRQs (has own IRQ domain).
> - pmic-gpios: The GPIO used by PMIC IRQ.
> +- #clock-cells: From common clock binding; shall be set to 0
> +
> +Optional properties:
> +- clock-output-names: From common clock binding to override the
> + default output clock name
>
> Example:
> pmic: pmic@f8000000 {
> @@ -24,4 +29,5 @@ Example:
> interrupt-controller;
> #interrupt-cells = <2>;
> pmic-gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>;
> + clock-cells = <0>;
> }
> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> index dba3c13..bb9afb1 100644
> --- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> +++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
> @@ -328,6 +328,7 @@
> interrupt-controller;
> #interrupt-cells = <2>;
> pmic-gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>;
> + #clock-cells = <0>;
>
> regulators {
> ldo2: LDO2 {
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index 9356ab4..36cfea3 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -47,6 +47,14 @@ config COMMON_CLK_RK808
> clocked at 32KHz each. Clkout1 is always on, Clkout2 can off
> by control register.
>
> +config COMMON_CLK_HI655X
> + tristate "Clock driver for Hi655x"
> + depends on MFD_HI655X_PMIC || COMPILE_TEST
> + ---help---
> + This driver supports the hi655x PMIC clock. This
> + multi-function device has one fixed-rate oscillator, clocked
> + at 32KHz.
> +
> config COMMON_CLK_SCPI
> tristate "Clock driver controlled via SCPI interface"
> depends on ARM_SCPI_PROTOCOL || COMPILE_TEST
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 92c12b8..c19983a 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -36,6 +36,7 @@ obj-$(CONFIG_COMMON_CLK_PALMAS) += clk-palmas.o
> obj-$(CONFIG_COMMON_CLK_PWM) += clk-pwm.o
> obj-$(CONFIG_CLK_QORIQ) += clk-qoriq.o
> obj-$(CONFIG_COMMON_CLK_RK808) += clk-rk808.o
> +obj-$(CONFIG_COMMON_CLK_HI655X) += clk-hi655x.o
> obj-$(CONFIG_COMMON_CLK_S2MPS11) += clk-s2mps11.o
> obj-$(CONFIG_COMMON_CLK_SCPI) += clk-scpi.o
> obj-$(CONFIG_COMMON_CLK_SI5351) += clk-si5351.o
> diff --git a/drivers/clk/clk-hi655x.c b/drivers/clk/clk-hi655x.c
> new file mode 100644
> index 0000000..b2bea32
> --- /dev/null
> +++ b/drivers/clk/clk-hi655x.c
> @@ -0,0 +1,140 @@
> +/*
> + * Clock driver for Hi655x
> + *
> + * Copyright (c) 2016, Linaro Ltd.
> + *
> + * Author: Daniel Lezcano <daniel.lezcano@linaro.org>
> + *
> + * 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.
> + */
> +#include <linux/clk-provider.h>
> +#include <linux/clkdev.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/slab.h>
> +#include <linux/mfd/core.h>
> +#include <linux/mfd/hi655x-pmic.h>
> +
> +#define HI655X_CLK_BASE HI655X_BUS_ADDR(0x1c)
> +#define HI655X_CLK_SET BIT(6)
> +
> +struct hi655x_clk {
> + struct hi655x_pmic *hi655x;
> + struct clk_hw clk_hw;
> +};
> +
> +static unsigned long hi655x_clk_recalc_rate(struct clk_hw *hw,
> + unsigned long parent_rate)
> +{
> + return 32768;
> +}
> +
> +static int hi655x_clk_enable(struct clk_hw *hw, bool enable)
> +{
> + struct hi655x_clk *hi655x_clk =
> + container_of(hw, struct hi655x_clk, clk_hw);
> +
> + struct hi655x_pmic *hi655x = hi655x_clk->hi655x;
> +
> + return regmap_update_bits(hi655x->regmap, HI655X_CLK_BASE,
> + HI655X_CLK_SET, enable ? HI655X_CLK_SET : 0);
> +}
> +
> +static int hi655x_clk_prepare(struct clk_hw *hw)
> +{
> + return hi655x_clk_enable(hw, true);
> +}
> +
> +static void hi655x_clk_unprepare(struct clk_hw *hw)
> +{
> + hi655x_clk_enable(hw, false);
> +}
> +
> +static int hi655x_clk_is_prepared(struct clk_hw *hw)
> +{
> + struct hi655x_clk *hi655x_clk =
> + container_of(hw, struct hi655x_clk, clk_hw);
> + struct hi655x_pmic *hi655x = hi655x_clk->hi655x;
> + int ret;
> + uint32_t val;
> +
> + ret = regmap_read(hi655x->regmap, HI655X_CLK_BASE, &val);
> + if (ret < 0)
> + return ret;
> +
> + return val & HI655X_CLK_BASE;
> +}
> +
> +static const struct clk_ops hi655x_clk_ops = {
> + .prepare = hi655x_clk_prepare,
> + .unprepare = hi655x_clk_unprepare,
> + .is_prepared = hi655x_clk_is_prepared,
> + .recalc_rate = hi655x_clk_recalc_rate,
> +};
> +
> +static int hi655x_clk_probe(struct platform_device *pdev)
> +{
> + struct device *parent = pdev->dev.parent;
> + struct hi655x_pmic *hi655x = dev_get_drvdata(parent);
> + struct clk_init_data *hi655x_clk_init;
> + struct hi655x_clk *hi655x_clk;
> + const char *clk_name = "hi655x-clk";
> + int ret;
> +
> + hi655x_clk = devm_kzalloc(&pdev->dev, sizeof(*hi655x_clk), GFP_KERNEL);
> + if (!hi655x_clk)
> + return -ENOMEM;
> +
> + hi655x_clk_init = devm_kzalloc(&pdev->dev, sizeof(*hi655x_clk_init),
> + GFP_KERNEL);
> + if (!hi655x_clk_init)
> + return -ENOMEM;
> +
> + of_property_read_string_index(parent->of_node, "clock-output-names",
> + 0, &clk_name);
> +
> + hi655x_clk_init->name = clk_name;
> + hi655x_clk_init->ops = &hi655x_clk_ops;
> +
> + hi655x_clk->clk_hw.init = hi655x_clk_init;
> + hi655x_clk->hi655x = hi655x;
> +
> + platform_set_drvdata(pdev, hi655x_clk);
> +
> + ret = devm_clk_hw_register(&pdev->dev, &hi655x_clk->clk_hw);
> + if (ret)
> + return ret;
> +
> + ret = of_clk_add_hw_provider(parent->of_node, of_clk_hw_simple_get,
> + &hi655x_clk->clk_hw);
> + if (ret)
> + return ret;
> +
> + ret = clk_hw_register_clkdev(&hi655x_clk->clk_hw, clk_name, NULL);
> + if (ret)
> + of_clk_del_provider(parent->of_node);
> +
> + return ret;
> +}
> +
> +static struct platform_driver hi655x_clk_driver = {
> + .probe = hi655x_clk_probe,
> + .driver = {
> + .name = "hi655x-clk",
> + },
> +};
> +
> +module_platform_driver(hi655x_clk_driver);
> +
> +MODULE_DESCRIPTION("Clk driver for the hi655x series PMICs");
> +MODULE_AUTHOR("Daniel Lezcano <daniel.lezcano@linaro.org>");
> +MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:hi655x-clk");
> diff --git a/drivers/mfd/hi655x-pmic.c b/drivers/mfd/hi655x-pmic.c
> index ba706ad..c37ccbf 100644
> --- a/drivers/mfd/hi655x-pmic.c
> +++ b/drivers/mfd/hi655x-pmic.c
> @@ -77,7 +77,8 @@
> .num_resources = ARRAY_SIZE(pwrkey_resources),
> .resources = &pwrkey_resources[0],
> },
> - { .name = "hi655x-regulator", },
> + { .name = "hi655x-regulator", },
> + { .name = "hi655x-clk", },
> };
>
> static void hi655x_local_irq_clear(struct regmap *map)
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v4 1/7] pinctrl: dt-bindings: Add documentation for Armada 37xx pin controllers
From: Linus Walleij @ 2017-04-24 9:29 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Nadav Haklai, Victor Gu, Marcin Wojtas, Wilson Ding, Hua Jing,
Neta Zur Hershkovits
In-Reply-To: <941d03c9a3bdfd5e789aada29b35184ec9fed9fe.1491405475.git-series.gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Wed, Apr 5, 2017 at 5:18 PM, Gregory CLEMENT
<gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> Document the device tree binding for the pin controllers found on the
> Armada 37xx SoCs.
>
> Update the binding documention of the xtal clk which is a subnode of this
> syscon node.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Patch applied, fixed up Rob's comment and added his ACK in the process.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ 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