* [PATCH v5 3/3] dt-bindings: i2c: pxa: Update the documentation for the Armada 3700
From: Romain Perier @ 2016-11-21 13:32 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c-u79uwXL29TY76Z2rM5mHXA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Gregory Clement,
Thomas Petazzoni, Nadav Haklai, Omri Itach, Shadi Ammouri,
Yahuda Yitschak, Hanna Hawa, Neta Zur Hershkovits, Igal Liberman,
Marcin Wojtas <mw>
In-Reply-To: <20161121133247.29889-1-romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
This commit documents the compatible string to have the compatibility for
the I2C unit found in the Armada 3700.
Signed-off-by: Romain Perier <romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
Changes in v5:
- Added the tag 'Acked-by', by Rob Herring
Changes in v2:
- Fixed wrong compatible string, it should be "marvell,armada-3700-i2c"
and not "marvell,armada-3700".
Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
index 12b78ac..d30f0b1 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
@@ -7,6 +7,7 @@ Required properties :
compatible processor, e.g. pxa168, pxa910, mmp2, mmp3.
For the pxa2xx/pxa3xx, an additional node "mrvl,pxa-i2c" is required
as shown in the example below.
+ For the Armada 3700, the compatible should be "marvell,armada-3700-i2c".
Recommended properties :
--
2.9.3
--
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 related
* Re: [PATCH v3 1/2] mfd: pm8xxx: add support to pm8821
From: Lee Jones @ 2016-11-21 13:48 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A, Rob Herring, Andy Gross,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1479211312-1431-1-git-send-email-srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Tue, 15 Nov 2016, Srinivas Kandagatla wrote:
> This patch adds support to PM8821 PMIC and interrupt support.
> PM8821 is companion device that supplements primary PMIC PM8921 IC.
>
> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> Changes since v2:
> - removed few empty lines spotted by Bjorn
> - rephrased some debug prints suggested by Bjorn
>
> .../devicetree/bindings/mfd/qcom-pm8xxx.txt | 1 +
> drivers/mfd/qcom-pm8xxx.c | 231 ++++++++++++++++++++-
> 2 files changed, 222 insertions(+), 10 deletions(-)
Applied, thanks.
> diff --git a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
> index 37a088f..9e5eba4 100644
> --- a/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
> +++ b/Documentation/devicetree/bindings/mfd/qcom-pm8xxx.txt
> @@ -10,6 +10,7 @@ voltages and other various functionality to Qualcomm SoCs.
> Value type: <string>
> Definition: must be one of:
> "qcom,pm8058"
> + "qcom,pm8821"
> "qcom,pm8921"
>
> - #address-cells:
> diff --git a/drivers/mfd/qcom-pm8xxx.c b/drivers/mfd/qcom-pm8xxx.c
> index 7f9620e..f08758f 100644
> --- a/drivers/mfd/qcom-pm8xxx.c
> +++ b/drivers/mfd/qcom-pm8xxx.c
> @@ -39,6 +39,20 @@
> #define SSBI_REG_ADDR_IRQ_CONFIG (SSBI_REG_ADDR_IRQ_BASE + 7)
> #define SSBI_REG_ADDR_IRQ_RT_STATUS (SSBI_REG_ADDR_IRQ_BASE + 8)
>
> +#define PM8821_SSBI_REG_ADDR_IRQ_BASE 0x100
> +#define PM8821_SSBI_REG_ADDR_IRQ_MASTER0 (PM8821_SSBI_REG_ADDR_IRQ_BASE + 0x30)
> +#define PM8821_SSBI_REG_ADDR_IRQ_MASTER1 (PM8821_SSBI_REG_ADDR_IRQ_BASE + 0xb0)
> +#define PM8821_SSBI_REG(m, b, offset) \
> + ((m == 0) ? \
> + (PM8821_SSBI_REG_ADDR_IRQ_MASTER0 + b + offset) : \
> + (PM8821_SSBI_REG_ADDR_IRQ_MASTER1 + b + offset))
> +#define PM8821_SSBI_ADDR_IRQ_ROOT(m, b) PM8821_SSBI_REG(m, b, 0x0)
> +#define PM8821_SSBI_ADDR_IRQ_CLEAR(m, b) PM8821_SSBI_REG(m, b, 0x01)
> +#define PM8821_SSBI_ADDR_IRQ_MASK(m, b) PM8821_SSBI_REG(m, b, 0x08)
> +#define PM8821_SSBI_ADDR_IRQ_RT_STATUS(m, b) PM8821_SSBI_REG(m, b, 0x0f)
> +
> +#define PM8821_BLOCKS_PER_MASTER 7
> +
> #define PM_IRQF_LVL_SEL 0x01 /* level select */
> #define PM_IRQF_MASK_FE 0x02 /* mask falling edge */
> #define PM_IRQF_MASK_RE 0x04 /* mask rising edge */
> @@ -54,6 +68,7 @@
> #define REG_HWREV_2 0x0E8 /* PMIC4 revision 2 */
>
> #define PM8XXX_NR_IRQS 256
> +#define PM8821_NR_IRQS 112
>
> struct pm_irq_chip {
> struct regmap *regmap;
> @@ -65,6 +80,12 @@ struct pm_irq_chip {
> u8 config[0];
> };
>
> +struct pm_irq_data {
> + int num_irqs;
> + const struct irq_domain_ops *irq_domain_ops;
> + void (*irq_handler)(struct irq_desc *desc);
> +};
> +
> static int pm8xxx_read_block_irq(struct pm_irq_chip *chip, unsigned int bp,
> unsigned int *ip)
> {
> @@ -182,6 +203,78 @@ static void pm8xxx_irq_handler(struct irq_desc *desc)
> chained_irq_exit(irq_chip, desc);
> }
>
> +static void pm8821_irq_block_handler(struct pm_irq_chip *chip,
> + int master, int block)
> +{
> + int pmirq, irq, i, ret;
> + unsigned int bits;
> +
> + ret = regmap_read(chip->regmap,
> + PM8821_SSBI_ADDR_IRQ_ROOT(master, block), &bits);
> + if (ret) {
> + pr_err("Reading block %d failed ret=%d", block, ret);
> + return;
> + }
> +
> + /* Convert block offset to global block number */
> + block += (master * PM8821_BLOCKS_PER_MASTER) - 1;
> +
> + /* Check IRQ bits */
> + for (i = 0; i < 8; i++) {
> + if (bits & BIT(i)) {
> + pmirq = block * 8 + i;
> + irq = irq_find_mapping(chip->irqdomain, pmirq);
> + generic_handle_irq(irq);
> + }
> + }
> +}
> +
> +static inline void pm8821_irq_master_handler(struct pm_irq_chip *chip,
> + int master, u8 master_val)
> +{
> + int block;
> +
> + for (block = 1; block < 8; block++)
> + if (master_val & BIT(block))
> + pm8821_irq_block_handler(chip, master, block);
> +}
> +
> +static void pm8821_irq_handler(struct irq_desc *desc)
> +{
> + struct pm_irq_chip *chip = irq_desc_get_handler_data(desc);
> + struct irq_chip *irq_chip = irq_desc_get_chip(desc);
> + unsigned int master;
> + int ret;
> +
> + chained_irq_enter(irq_chip, desc);
> + ret = regmap_read(chip->regmap,
> + PM8821_SSBI_REG_ADDR_IRQ_MASTER0, &master);
> + if (ret) {
> + pr_err("Failed to read master 0 ret=%d\n", ret);
> + goto done;
> + }
> +
> + /* bits 1 through 7 marks the first 7 blocks in master 0 */
> + if (master & GENMASK(7, 1))
> + pm8821_irq_master_handler(chip, 0, master);
> +
> + /* bit 0 marks if master 1 contains any bits */
> + if (!(master & BIT(0)))
> + goto done;
> +
> + ret = regmap_read(chip->regmap,
> + PM8821_SSBI_REG_ADDR_IRQ_MASTER1, &master);
> + if (ret) {
> + pr_err("Failed to read master 1 ret=%d\n", ret);
> + goto done;
> + }
> +
> + pm8821_irq_master_handler(chip, 1, master);
> +
> +done:
> + chained_irq_exit(irq_chip, desc);
> +}
> +
> static void pm8xxx_irq_mask_ack(struct irq_data *d)
> {
> struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
> @@ -299,6 +392,104 @@ static const struct irq_domain_ops pm8xxx_irq_domain_ops = {
> .map = pm8xxx_irq_domain_map,
> };
>
> +static void pm8821_irq_mask_ack(struct irq_data *d)
> +{
> + struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
> + unsigned int pmirq = irqd_to_hwirq(d);
> + u8 block, master;
> + int irq_bit, rc;
> +
> + block = pmirq / 8;
> + master = block / PM8821_BLOCKS_PER_MASTER;
> + irq_bit = pmirq % 8;
> + block %= PM8821_BLOCKS_PER_MASTER;
> +
> + rc = regmap_update_bits(chip->regmap,
> + PM8821_SSBI_ADDR_IRQ_MASK(master, block),
> + BIT(irq_bit), BIT(irq_bit));
> + if (rc) {
> + pr_err("Failed to mask IRQ:%d rc=%d\n", pmirq, rc);
> + return;
> + }
> +
> + rc = regmap_update_bits(chip->regmap,
> + PM8821_SSBI_ADDR_IRQ_CLEAR(master, block),
> + BIT(irq_bit), BIT(irq_bit));
> + if (rc)
> + pr_err("Failed to CLEAR IRQ:%d rc=%d\n", pmirq, rc);
> +}
> +
> +static void pm8821_irq_unmask(struct irq_data *d)
> +{
> + struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
> + unsigned int pmirq = irqd_to_hwirq(d);
> + int irq_bit, rc;
> + u8 block, master;
> +
> + block = pmirq / 8;
> + master = block / PM8821_BLOCKS_PER_MASTER;
> + irq_bit = pmirq % 8;
> + block %= PM8821_BLOCKS_PER_MASTER;
> +
> + rc = regmap_update_bits(chip->regmap,
> + PM8821_SSBI_ADDR_IRQ_MASK(master, block),
> + BIT(irq_bit), ~BIT(irq_bit));
> + if (rc)
> + pr_err("Failed to read/write unmask IRQ:%d rc=%d\n", pmirq, rc);
> +
> +}
> +
> +static int pm8821_irq_get_irqchip_state(struct irq_data *d,
> + enum irqchip_irq_state which,
> + bool *state)
> +{
> + struct pm_irq_chip *chip = irq_data_get_irq_chip_data(d);
> + int rc, pmirq = irqd_to_hwirq(d);
> + u8 block, irq_bit, master;
> + unsigned int bits;
> +
> + block = pmirq / 8;
> + master = block / PM8821_BLOCKS_PER_MASTER;
> + irq_bit = pmirq % 8;
> + block %= PM8821_BLOCKS_PER_MASTER;
> +
> + rc = regmap_read(chip->regmap,
> + PM8821_SSBI_ADDR_IRQ_RT_STATUS(master, block), &bits);
> + if (rc) {
> + pr_err("Reading Status of IRQ %d failed rc=%d\n", pmirq, rc);
> + return rc;
> + }
> +
> + *state = !!(bits & BIT(irq_bit));
> +
> + return rc;
> +}
> +
> +static struct irq_chip pm8821_irq_chip = {
> + .name = "pm8821",
> + .irq_mask_ack = pm8821_irq_mask_ack,
> + .irq_unmask = pm8821_irq_unmask,
> + .irq_get_irqchip_state = pm8821_irq_get_irqchip_state,
> + .flags = IRQCHIP_MASK_ON_SUSPEND | IRQCHIP_SKIP_SET_WAKE,
> +};
> +
> +static int pm8821_irq_domain_map(struct irq_domain *d, unsigned int irq,
> + irq_hw_number_t hwirq)
> +{
> + struct pm_irq_chip *chip = d->host_data;
> +
> + irq_set_chip_and_handler(irq, &pm8821_irq_chip, handle_level_irq);
> + irq_set_chip_data(irq, chip);
> + irq_set_noprobe(irq);
> +
> + return 0;
> +}
> +
> +static const struct irq_domain_ops pm8821_irq_domain_ops = {
> + .xlate = irq_domain_xlate_twocell,
> + .map = pm8821_irq_domain_map,
> +};
> +
> static const struct regmap_config ssbi_regmap_config = {
> .reg_bits = 16,
> .val_bits = 8,
> @@ -308,22 +499,41 @@ static const struct regmap_config ssbi_regmap_config = {
> .reg_write = ssbi_reg_write
> };
>
> +static const struct pm_irq_data pm8xxx_data = {
> + .num_irqs = PM8XXX_NR_IRQS,
> + .irq_domain_ops = &pm8xxx_irq_domain_ops,
> + .irq_handler = pm8xxx_irq_handler,
> +};
> +
> +static const struct pm_irq_data pm8821_data = {
> + .num_irqs = PM8821_NR_IRQS,
> + .irq_domain_ops = &pm8821_irq_domain_ops,
> + .irq_handler = pm8821_irq_handler,
> +};
> +
> static const struct of_device_id pm8xxx_id_table[] = {
> - { .compatible = "qcom,pm8018", },
> - { .compatible = "qcom,pm8058", },
> - { .compatible = "qcom,pm8921", },
> + { .compatible = "qcom,pm8018", .data = &pm8xxx_data},
> + { .compatible = "qcom,pm8058", .data = &pm8xxx_data},
> + { .compatible = "qcom,pm8821", .data = &pm8821_data},
> + { .compatible = "qcom,pm8921", .data = &pm8xxx_data},
> { }
> };
> MODULE_DEVICE_TABLE(of, pm8xxx_id_table);
>
> static int pm8xxx_probe(struct platform_device *pdev)
> {
> + const struct pm_irq_data *data;
> struct regmap *regmap;
> int irq, rc;
> unsigned int val;
> u32 rev;
> struct pm_irq_chip *chip;
> - unsigned int nirqs = PM8XXX_NR_IRQS;
> +
> + data = of_device_get_match_data(&pdev->dev);
> + if (!data) {
> + dev_err(&pdev->dev, "No matching driver data found\n");
> + return -EINVAL;
> + }
>
> irq = platform_get_irq(pdev, 0);
> if (irq < 0)
> @@ -354,25 +564,26 @@ static int pm8xxx_probe(struct platform_device *pdev)
> rev |= val << BITS_PER_BYTE;
>
> chip = devm_kzalloc(&pdev->dev, sizeof(*chip) +
> - sizeof(chip->config[0]) * nirqs,
> - GFP_KERNEL);
> + sizeof(chip->config[0]) * data->num_irqs,
> + GFP_KERNEL);
> if (!chip)
> return -ENOMEM;
>
> platform_set_drvdata(pdev, chip);
> chip->regmap = regmap;
> - chip->num_irqs = nirqs;
> + chip->num_irqs = data->num_irqs;
> chip->num_blocks = DIV_ROUND_UP(chip->num_irqs, 8);
> chip->num_masters = DIV_ROUND_UP(chip->num_blocks, 8);
> spin_lock_init(&chip->pm_irq_lock);
>
> - chip->irqdomain = irq_domain_add_linear(pdev->dev.of_node, nirqs,
> - &pm8xxx_irq_domain_ops,
> + chip->irqdomain = irq_domain_add_linear(pdev->dev.of_node,
> + data->num_irqs,
> + data->irq_domain_ops,
> chip);
> if (!chip->irqdomain)
> return -ENODEV;
>
> - irq_set_chained_handler_and_data(irq, pm8xxx_irq_handler, chip);
> + irq_set_chained_handler_and_data(irq, data->irq_handler, chip);
> irq_set_irq_wake(irq, 1);
>
> rc = of_platform_populate(pdev->dev.of_node, NULL, NULL, &pdev->dev);
--
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 2/2] DW DMAC: add multi-block property to device tree
From: Arnd Bergmann @ 2016-11-21 13:53 UTC (permalink / raw)
To: Eugeniy Paltsev
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA,
vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-snps-arc-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1479496356-27834-3-git-send-email-Eugeniy.Paltsev-HKixBCOQz3hWk0Htik3J/w@public.gmane.org>
On Friday, November 18, 2016 10:12:36 PM CET Eugeniy Paltsev wrote:
> +- multi-block: Multi block transfers supported by hardware per AHB master.
> + 0 (default): not supported, 1: supported.
Please clarify that this is an array with one cell per master.
My first thought was "why is this not a boolean property", and
I'm sure others might misread it the same way.
Arnd
--
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] ARM: dts: at91: sama5d3_uart: fix reg sizes to match documentation
From: Alexandre Belloni @ 2016-11-21 14:01 UTC (permalink / raw)
To: Peter Rosin
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Nicolas Ferre,
Jean-Christophe Plagniol-Villard, Rob Herring, Mark Rutland,
Russell King, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1478764000-32233-1-git-send-email-peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
On 10/11/2016 at 08:46:40 +0100, Peter Rosin wrote :
> The new size (0x100) also matches the size given in sama5d3.dtsi
>
> Documentation reference: section 43.6 "Universal Asynchronous
> Receiver Transmitter (UART) User Interface", table 43-4 "Register
> Mapping" in [1].
>
> [1] Atmel-11121F-ATARM-SAMA5D3-Series-Datasheet_02-Feb-16
>
> Signed-off-by: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
> ---
> arch/arm/boot/dts/sama5d3_uart.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Applied, thanks.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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] ARM: at91/dt: add dts file for sama5d36ek CMP board
From: Alexandre Belloni @ 2016-11-21 14:02 UTC (permalink / raw)
To: Wenyou Yang
Cc: Nicolas Ferre, Russell King, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Wenyou Yang,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1479705283-3052-1-git-send-email-wenyou.yang-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
Hi,
I fixed it up this time but please use the proper subject prefix next
time (ARM: dts: at91:).
On 21/11/2016 at 13:14:42 +0800, Wenyou Yang wrote :
> The sama5d36ek CMP board is the variant of sama5d3xek board.
> It is equipped with the low-power DDR2 SDRAM, PMIC ACT8865 and
> some power rail. Its main purpose is used to measure the power
> consumption.
> The difference of the sama5d36ek CMP dts from sama5d36ek dts is
> listed as below.
> 1. The USB host nodes are removed, that is, the USB host is disabled.
> 2. The gpio_keys node is added to wake up from the sleep.
> 3. The LCD isn't supported due to the pins for LCD are conflicted
> with gpio_keys.
> 4. The adc0 node support the pinctrl sleep state to fix the over
> consumption on VDDANA.
>
> As said in errata, "When the USB host ports are used in high speed
> mode (EHCI), it is not possible to suspend the ports if no device is
> attached on each port. This leads to increased power consumption even
> if the system is in a low power mode." That is why the the USB host
> is disabled.
>
> Signed-off-by: Wenyou Yang <wenyou.yang-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
> ---
>
> Changes in v3:
> - Use a dual license scheme for DT files.
> - Use the proper model name and the compatible string to reflect
> the nature of this new "CMP" board.
> - Change name of wakeup property to "wakeup-source".
> - Remove unnecessary comments.
> - Remove bootargs.
>
> Changes in v2:
> - Add the pinctrl sleep state for adc0 node to fix the over
> consumption on VDDANA.
> - Improve the commit log.
>
> arch/arm/boot/dts/sama5d36ek_cmp.dts | 87 ++++++++++
> arch/arm/boot/dts/sama5d3xcm_cmp.dtsi | 201 +++++++++++++++++++++++
> arch/arm/boot/dts/sama5d3xmb_cmp.dtsi | 301 ++++++++++++++++++++++++++++++++++
> 3 files changed, 589 insertions(+)
> create mode 100644 arch/arm/boot/dts/sama5d36ek_cmp.dts
> create mode 100644 arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
> create mode 100644 arch/arm/boot/dts/sama5d3xmb_cmp.dtsi
>
Applied, thanks.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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 4/4] [media] dt-bindings: add TI VPIF documentation
From: Arnd Bergmann @ 2016-11-21 14:15 UTC (permalink / raw)
To: Kevin Hilman
Cc: linux-media, Hans Verkuil, devicetree, Sekhar Nori, Axel Haslam,
Bartosz Gołaszewski, Alexandre Bailon, David Lechner,
Rob Herring
In-Reply-To: <20161119003208.10550-4-khilman@baylibre.com>
On Friday, November 18, 2016 4:32:08 PM CET Kevin Hilman wrote:
> +
> +Required properties:
> +- compatible: must be "ti,vpif-capture"
> +- reg: physical base address and length of the registers set for the device;
> +- interrupts: should contain IRQ line for the VPIF
> +
>
Shouldn't this have a SoC specific identifier or a version number
in the compatible string? "vpif" seems rather generic, so it's
likely that TI made more than one variant of it.
Arnd
^ permalink raw reply
* Re: [PATCH v3 5/7] iio: multiplexer: new iio category and iio-mux driver
From: kbuild test robot @ 2016-11-21 14:33 UTC (permalink / raw)
Cc: kbuild-all, linux-kernel, Peter Rosin, Wolfram Sang, Rob Herring,
Mark Rutland, Jonathan Cameron, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler, Jonathan Corbet,
Arnd Bergmann, Greg Kroah-Hartman, linux-i2c, devicetree,
linux-iio, linux-doc
In-Reply-To: <1479734235-18837-6-git-send-email-peda@axentia.se>
[-- Attachment #1: Type: text/plain, Size: 6412 bytes --]
Hi Peter,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.9-rc6]
[cannot apply to next-20161117]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Peter-Rosin/mux-controller-abstraction-and-iio-i2c-muxes/20161121-215311
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/iio/multiplexer/iio-mux.c: In function 'mux_read_avail':
>> drivers/iio/multiplexer/iio-mux.c:134:9: error: implicit declaration of function 'iio_read_avail_channel_raw' [-Werror=implicit-function-declaration]
ret = iio_read_avail_channel_raw(mux->parent, vals, length);
^~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/iio/multiplexer/iio-mux.c: At top level:
>> drivers/iio/multiplexer/iio-mux.c:174:2: error: unknown field 'read_avail' specified in initializer
.read_avail = mux_read_avail,
^
>> drivers/iio/multiplexer/iio-mux.c:174:16: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.read_avail = mux_read_avail,
^~~~~~~~~~~~~~
drivers/iio/multiplexer/iio-mux.c:174:16: note: (near initialization for 'mux_info.read_raw_multi')
drivers/iio/multiplexer/iio-mux.c: In function 'mux_configure_channel':
>> drivers/iio/multiplexer/iio-mux.c:267:6: error: implicit declaration of function 'iio_channel_has_available' [-Werror=implicit-function-declaration]
if (iio_channel_has_available(pchan, IIO_CHAN_INFO_RAW))
^~~~~~~~~~~~~~~~~~~~~~~~~
>> drivers/iio/multiplexer/iio-mux.c:268:7: error: 'struct iio_chan_spec' has no member named 'info_mask_separate_available'; did you mean 'info_mask_separate'?
chan->info_mask_separate_available |= BIT(IIO_CHAN_INFO_RAW);
^~
cc1: some warnings being treated as errors
vim +/iio_read_avail_channel_raw +134 drivers/iio/multiplexer/iio-mux.c
128 if (ret < 0)
129 return ret;
130
131 switch (mask) {
132 case IIO_CHAN_INFO_RAW:
133 *type = IIO_VAL_INT;
> 134 ret = iio_read_avail_channel_raw(mux->parent, vals, length);
135 break;
136
137 default:
138 ret = -EINVAL;
139 }
140
141 iio_mux_deselect(mux);
142
143 return ret;
144 }
145
146 static int mux_write_raw(struct iio_dev *indio_dev,
147 struct iio_chan_spec const *chan,
148 int val, int val2, long mask)
149 {
150 struct mux *mux = iio_priv(indio_dev);
151 int idx = chan - mux->chan;
152 int ret;
153
154 ret = iio_mux_select(mux, idx);
155 if (ret < 0)
156 return ret;
157
158 switch (mask) {
159 case IIO_CHAN_INFO_RAW:
160 ret = iio_write_channel_raw(mux->parent, val);
161 break;
162
163 default:
164 ret = -EINVAL;
165 }
166
167 iio_mux_deselect(mux);
168
169 return ret;
170 }
171
172 static const struct iio_info mux_info = {
173 .read_raw = mux_read_raw,
> 174 .read_avail = mux_read_avail,
175 .write_raw = mux_write_raw,
176 .driver_module = THIS_MODULE,
177 };
178
179 static ssize_t mux_read_ext_info(struct iio_dev *indio_dev, uintptr_t private,
180 struct iio_chan_spec const *chan, char *buf)
181 {
182 struct mux *mux = iio_priv(indio_dev);
183 int idx = chan - mux->chan;
184 ssize_t ret;
185
186 ret = iio_mux_select(mux, idx);
187 if (ret < 0)
188 return ret;
189
190 ret = iio_read_channel_ext_info(mux->parent,
191 mux->ext_info[private].name,
192 buf);
193
194 iio_mux_deselect(mux);
195
196 return ret;
197 }
198
199 static ssize_t mux_write_ext_info(struct iio_dev *indio_dev, uintptr_t private,
200 struct iio_chan_spec const *chan,
201 const char *buf, size_t len)
202 {
203 struct device *dev = indio_dev->dev.parent;
204 struct mux *mux = iio_priv(indio_dev);
205 int idx = chan - mux->chan;
206 char *new;
207 ssize_t ret;
208
209 ret = iio_mux_select(mux, idx);
210 if (ret < 0)
211 return ret;
212
213 new = devm_kmemdup(dev, buf, len + 1, GFP_KERNEL);
214 if (!new) {
215 iio_mux_deselect(mux);
216 return -ENOMEM;
217 }
218
219 new[len] = 0;
220
221 ret = iio_write_channel_ext_info(mux->parent,
222 mux->ext_info[private].name,
223 buf, len);
224 if (ret < 0) {
225 iio_mux_deselect(mux);
226 devm_kfree(dev, new);
227 return ret;
228 }
229
230 devm_kfree(dev, mux->child[idx].ext_info_cache[private].data);
231 mux->child[idx].ext_info_cache[private].data = new;
232 mux->child[idx].ext_info_cache[private].size = len;
233
234 iio_mux_deselect(mux);
235
236 return ret;
237 }
238
239 static int mux_configure_channel(struct device *dev, struct mux *mux,
240 struct device_node *child_np, int idx)
241 {
242 struct mux_child *child = &mux->child[idx];
243 struct iio_chan_spec *chan = &mux->chan[idx];
244 struct iio_chan_spec const *pchan = mux->parent->channel;
245 u32 state;
246 char *page = NULL;
247 int num_ext_info;
248 int i;
249 int ret;
250
251 chan->indexed = 1;
252 chan->output = pchan->output;
253 chan->datasheet_name = child_np->name;
254 chan->ext_info = mux->ext_info;
255
256 ret = iio_get_channel_type(mux->parent, &chan->type);
257 if (ret < 0) {
258 dev_err(dev, "failed to get parent channel type\n");
259 return ret;
260 }
261
262 if (iio_channel_has_info(pchan, IIO_CHAN_INFO_RAW))
263 chan->info_mask_separate |= BIT(IIO_CHAN_INFO_RAW);
264 if (iio_channel_has_info(pchan, IIO_CHAN_INFO_SCALE))
265 chan->info_mask_separate |= BIT(IIO_CHAN_INFO_SCALE);
266
> 267 if (iio_channel_has_available(pchan, IIO_CHAN_INFO_RAW))
> 268 chan->info_mask_separate_available |= BIT(IIO_CHAN_INFO_RAW);
269
270 ret = of_property_read_u32(child_np, "reg", &state);
271 if (ret < 0) {
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 56692 bytes --]
^ permalink raw reply
* Re: [PATCH 2/4] [media] davinci: vpif_capture: don't lock over s_stream
From: Hans Verkuil @ 2016-11-21 14:37 UTC (permalink / raw)
To: Kevin Hilman, linux-media
Cc: devicetree, Sekhar Nori, Axel Haslam, Bartosz Gołaszewski,
Alexandre Bailon, David Lechner
In-Reply-To: <20161119003208.10550-2-khilman@baylibre.com>
On 19/11/16 01:32, Kevin Hilman wrote:
> Video capture subdevs may be over I2C and may sleep during xfer, so we
> cannot do IRQ-disabled locking when calling the subdev.
>
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
> ---
> drivers/media/platform/davinci/vpif_capture.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/media/platform/davinci/vpif_capture.c b/drivers/media/platform/davinci/vpif_capture.c
> index 79cef74e164f..becc3e63b472 100644
> --- a/drivers/media/platform/davinci/vpif_capture.c
> +++ b/drivers/media/platform/davinci/vpif_capture.c
> @@ -193,12 +193,16 @@ static int vpif_start_streaming(struct vb2_queue *vq, unsigned int count)
> }
> }
>
> + spin_unlock_irqrestore(&common->irqlock, flags);
> +
> ret = v4l2_subdev_call(ch->sd, video, s_stream, 1);
> if (ret && ret != -ENOIOCTLCMD && ret != -ENODEV) {
> vpif_dbg(1, debug, "stream on failed in subdev\n");
> goto err;
> }
>
> + spin_lock_irqsave(&common->irqlock, flags);
This needs to be moved to right after the v4l2_subdev_call, otherwise the
goto err above will not have the spinlock.
Hans
> +
> /* Call vpif_set_params function to set the parameters and addresses */
> ret = vpif_set_video_params(vpif, ch->channel_id);
> if (ret < 0) {
>
^ permalink raw reply
* Re: [PATCH v6 3/3] arm: dts: mt2701: Add node for Mediatek JPEG Decoder
From: Hans Verkuil @ 2016-11-21 14:51 UTC (permalink / raw)
To: Rick Chang, Hans Verkuil, Laurent Pinchart, Mauro Carvalho Chehab,
Matthias Brugger, Rob Herring
Cc: linux-kernel, linux-media, srv_heupstream, linux-mediatek,
linux-arm-kernel, devicetree, Minghsiu Tsai
In-Reply-To: <1479353915-5043-4-git-send-email-rick.chang@mediatek.com>
On 17/11/16 04:38, Rick Chang wrote:
> Signed-off-by: Rick Chang <rick.chang@mediatek.com>
> Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
> ---
> This patch depends on:
> CCF "Add clock support for Mediatek MT2701"[1]
> iommu and smi "Add the dtsi node of iommu and smi for mt2701"[2]
>
> [1] http://lists.infradead.org/pipermail/linux-mediatek/2016-October/007271.html
> [2] https://patchwork.kernel.org/patch/9164013/
I assume that 1 & 2 will appear in 4.10? So this patch needs to go in
after the
other two are merged in 4.10?
Regards,
Hans
> ---
> arch/arm/boot/dts/mt2701.dtsi | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
> index 8f13c70..4dd5048 100644
> --- a/arch/arm/boot/dts/mt2701.dtsi
> +++ b/arch/arm/boot/dts/mt2701.dtsi
> @@ -298,6 +298,20 @@
> power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>;
> };
>
> + jpegdec: jpegdec@15004000 {
> + compatible = "mediatek,mt2701-jpgdec";
> + reg = <0 0x15004000 0 0x1000>;
> + interrupts = <GIC_SPI 143 IRQ_TYPE_LEVEL_LOW>;
> + clocks = <&imgsys CLK_IMG_JPGDEC_SMI>,
> + <&imgsys CLK_IMG_JPGDEC>;
> + clock-names = "jpgdec-smi",
> + "jpgdec";
> + power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>;
> + mediatek,larb = <&larb2>;
> + iommus = <&iommu MT2701_M4U_PORT_JPGDEC_WDMA>,
> + <&iommu MT2701_M4U_PORT_JPGDEC_BSDMA>;
> + };
> +
> vdecsys: syscon@16000000 {
> compatible = "mediatek,mt2701-vdecsys", "syscon";
> reg = <0 0x16000000 0 0x1000>;
>
^ permalink raw reply
* Re: [PATCH v6 0/3] Add Mediatek JPEG Decoder
From: Hans Verkuil @ 2016-11-21 14:53 UTC (permalink / raw)
To: Rick Chang, Hans Verkuil, Laurent Pinchart, Mauro Carvalho Chehab,
Matthias Brugger, Rob Herring
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-media-u79uwXL29TY76Z2rM5mHXA,
srv_heupstream-NuS5LvNUpcJWk0Htik3J/w,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Minghsiu Tsai
In-Reply-To: <1479353915-5043-1-git-send-email-rick.chang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
I'm missing a MAINTAINERS patch for this new driver.
Can you post a patch for that?
It's the only thing preventing this from being merged.
Regards,
Hans
On 17/11/16 04:38, Rick Chang wrote:
> This series of patches provide a v4l2 driver to control Mediatek JPEG decoder
> for decoding JPEG image and Motion JPEG bitstream.
>
> changes since v5:
> - remove redundant name from struct mtk_jpeg_fmt
> - Set state of all buffers to VB2_BUF_STATE_QUEUED if fail in start streaming
> - Remove VB2_USERPTR
> - Add check for buffer index
>
> changes since v4:
> - Change file name of binding documentation
> - Revise DT binding documentation
> - Revise compatible string
>
> changes since v3:
> - Revise DT binding documentation
> - Revise compatible string
>
> changes since v2:
> - Revise DT binding documentation
>
> changes since v1:
> - Rebase for v4.9-rc1.
> - Update Compliance test version and result
> - Remove redundant path in Makefile
> - Fix potential build error without CONFIG_PM_RUNTIME and CONFIG_PM_SLEEP
> - Fix warnings from patch check and smatch check
>
> * Dependency
> The patch "arm: dts: mt2701: Add node for JPEG decoder" depends on:
> CCF "Add clock support for Mediatek MT2701"[1]
> iommu and smi "Add the dtsi node of iommu and smi for mt2701"[2]
>
> [1] http://lists.infradead.org/pipermail/linux-mediatek/2016-October/007271.html
> [2] https://patchwork.kernel.org/patch/9164013/
>
> * Compliance test
> v4l2-compliance SHA : 4ad7174b908a36c4f315e3fe2efa7e2f8a6f375a
>
> Driver Info:
> Driver name : mtk-jpeg decode
> Card type : mtk-jpeg decoder
> Bus info : platform:15004000.jpegdec
> Driver version: 4.9.0
> Capabilities : 0x84204000
> Video Memory-to-Memory Multiplanar
> Streaming
> Extended Pix Format
> Device Capabilities
> Device Caps : 0x04204000
> Video Memory-to-Memory Multiplanar
> Streaming
> Extended Pix Format
>
> Compliance test for device /dev/video3 (not using libv4l2):
>
> Required ioctls:
> test VIDIOC_QUERYCAP: OK
>
> Allow for multiple opens:
> test second video open: OK
> test VIDIOC_QUERYCAP: OK
> test VIDIOC_G/S_PRIORITY: OK
> test for unlimited opens: OK
>
> Debug ioctls:
> test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
> test VIDIOC_LOG_STATUS: OK (Not Supported)
>
> Input ioctls:
> test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
> test VIDIOC_ENUMAUDIO: OK (Not Supported)
> test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
> test VIDIOC_G/S_AUDIO: OK (Not Supported)
> Inputs: 0 Audio Inputs: 0 Tuners: 0
>
> Output ioctls:
> test VIDIOC_G/S_MODULATOR: OK (Not Supported)
> test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> test VIDIOC_ENUMAUDOUT: OK (Not Supported)
> test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
> test VIDIOC_G/S_AUDOUT: OK (Not Supported)
> Outputs: 0 Audio Outputs: 0 Modulators: 0
>
> Input/Output configuration ioctls:
> test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
> test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
> test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
> test VIDIOC_G/S_EDID: OK (Not Supported)
>
> Control ioctls:
> test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
> test VIDIOC_QUERYCTRL: OK (Not Supported)
> test VIDIOC_G/S_CTRL: OK (Not Supported)
> test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
> test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> Standard Controls: 0 Private Controls: 0
>
> Format ioctls:
> test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
> test VIDIOC_G/S_PARM: OK (Not Supported)
> test VIDIOC_G_FBUF: OK (Not Supported)
> test VIDIOC_G_FMT: OK
> test VIDIOC_TRY_FMT: OK
> test VIDIOC_S_FMT: OK
> test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
> test Cropping: OK (Not Supported)
> test Composing: OK
> test Scaling: OK
>
> Codec ioctls:
> test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
> test VIDIOC_G_ENC_INDEX: OK (Not Supported)
> test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
>
> Buffer ioctls:
> test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
> test VIDIOC_EXPBUF: OK
>
> Test input 0:
>
>
> Total: 43, Succeeded: 43, Failed: 0, Warnings: 0
>
> Rick Chang (3):
> dt-bindings: mediatek: Add a binding for Mediatek JPEG Decoder
> vcodec: mediatek: Add Mediatek JPEG Decoder Driver
> arm: dts: mt2701: Add node for Mediatek JPEG Decoder
>
> .../bindings/media/mediatek-jpeg-decoder.txt | 37 +
> arch/arm/boot/dts/mt2701.dtsi | 14 +
> drivers/media/platform/Kconfig | 15 +
> drivers/media/platform/Makefile | 2 +
> drivers/media/platform/mtk-jpeg/Makefile | 2 +
> drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 1303 ++++++++++++++++++++
> drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h | 139 +++
> drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c | 417 +++++++
> drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h | 91 ++
> drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c | 160 +++
> drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h | 25 +
> drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h | 58 +
> 12 files changed, 2263 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt
> create mode 100644 drivers/media/platform/mtk-jpeg/Makefile
> create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_core.h
> create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.c
> create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_hw.h
> create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.c
> create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_parse.h
> create mode 100644 drivers/media/platform/mtk-jpeg/mtk_jpeg_reg.h
>
--
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 2/3] drm/bridge: Add ti-tfp410 DVI transmitter driver
From: Rob Herring @ 2016-11-21 14:55 UTC (permalink / raw)
To: Jyri Sarha
Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA,
bcousson-rdvid1DuHRBWk0Htik3J/w, khilman-rdvid1DuHRBWk0Htik3J/w,
bgolaszewski-rdvid1DuHRBWk0Htik3J/w, tomi.valkeinen-l0cyMroinI0,
laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw
In-Reply-To: <6eaa1b5d467cd354f7d5dc5ff8da1b9bf732ff11.1479388871.git.jsarha-l0cyMroinI0@public.gmane.org>
On Thu, Nov 17, 2016 at 03:28:47PM +0200, Jyri Sarha wrote:
> Add very basic ti-ftp410 DVI transmitter driver. The only feature
> separating this from a completely dummy bridge is the EDID read
> support trough DDC I2C. Even that functionality should be in a
> separate generic connector driver. However, because of missing DRM
> infrastructure support the connector is implemented within the bridge
> driver. Some tfp410 HW specific features may be added later if needed,
> because there is a set of registers behind i2c if it is connected.
>
> This implementation is tested against my new tilcdc bridge support
> and it works with BeagleBone DVI-D Cape Rev A3. A DT binding document
> is also added.
>
> Signed-off-by: Jyri Sarha <jsarha-l0cyMroinI0@public.gmane.org>
> ---
> .../bindings/display/bridge/ti,tfp410.txt | 40 +++
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> drivers/gpu/drm/bridge/Kconfig | 7 +
> drivers/gpu/drm/bridge/Makefile | 1 +
> drivers/gpu/drm/bridge/ti-tfp410.c | 287 +++++++++++++++++++++
> 4 files changed, 335 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/bridge/ti,tfp410.txt
> create mode 100644 drivers/gpu/drm/bridge/ti-tfp410.c
--
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 v4 2/2] Add support for OV5647 sensor
From: Ramiro Oliveira @ 2016-11-21 15:00 UTC (permalink / raw)
To: Pavel Machek, Ramiro Oliveira
Cc: mchehab-DgEjT+Ai2ygdnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-media-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
linux-0h96xk9xTtrk1uMJSBkQmQ, hverkuil-qWit8jRvyhVmR6Xm/wNWPw,
dheitmueller-eb9eJ82Ua7k9XoPSrs7Ehg,
slongerbeam-Re5JQEeQqe8AvxtiuMwx3w, lars-Qo5EllUWu/uELgA04lAiVw,
robert.jarzmik-GANU6spQydw, pali.rohar-Re5JQEeQqe8AvxtiuMwx3w,
sakari.ailus-VuQAYsv1563Yd54FQh9/CA, mark.rutland-5wv7dgnIgG8,
CARLOS.PALMINHA-HKixBCOQz3hWk0Htik3J/w
In-Reply-To: <20161115121032.GB7018@amd>
Hi Pavel!
On 11/15/2016 12:10 PM, Pavel Machek wrote:
> Hi!
>
>> Add support for OV5647 sensor.
>>
>
>> +static int ov5647_write(struct v4l2_subdev *sd, u16 reg, u8 val)
>> +{
>> + int ret;
>> + unsigned char data[3] = { reg >> 8, reg & 0xff, val};
>> + struct i2c_client *client = v4l2_get_subdevdata(sd);
>> +
>> + ret = i2c_master_send(client, data, 3);
>> + if (ret != 3) {
>> + dev_dbg(&client->dev, "%s: i2c write error, reg: %x\n",
>> + __func__, reg);
>> + return ret < 0 ? ret : -EIO;
>> + }
>> + return 0;
>> +}
>
> Sorry, this is wrong. It should something <0 any time error is detected.
>
>> +static int ov5647_write_array(struct v4l2_subdev *sd,
>> + struct regval_list *regs, int array_size)
>> +{
>> + int i = 0;
>> + int ret = 0;
>> +
>> + if (!regs)
>> + return -EINVAL;
>> +
>> + while (i < array_size) {
>> + ret = ov5647_write(sd, regs->addr, regs->data);
>> + if (ret < 0)
>> + return ret;
>> + i++;
>> + regs++;
>> + }
>> + return 0;
>> +}
>
> For example this expects <0 on error.
>
>> +static int set_sw_standby(struct v4l2_subdev *sd, bool standby)
>> +{
>> + int ret;
>> + unsigned char rdval;
>> +
>> + ret = ov5647_read(sd, 0x0100, &rdval);
>> + if (ret != 0)
>> + return ret;
>> +
>> + if (standby)
>> + ret = ov5647_write(sd, 0x0100, rdval&0xfe);
>> + else
>> + ret = ov5647_write(sd, 0x0100, rdval|0x01);
>> +
>> + return ret;
>
> if (standby)
> rdval &= 0xfe;
> else
> rdval |= 0x01;
>
> ret = ov5647_write(sd, 0x0100, rdval);
>
> ?
>
>
>> +/**
>> + * @short Store information about the video data format.
>> + */
>> +static struct sensor_format_struct {
>> + __u8 *desc;
>> + u32 mbus_code;
>
> u8 is suitable here.
>
>
>> + ov5647_read(sd, 0x0100, &resetval);
>> + if (!resetval&0x01) {
>
> add ()s here.
>
>> +static int sensor_power(struct v4l2_subdev *sd, int on)
>> +{
>> + int ret;
>> + struct ov5647 *ov5647 = to_state(sd);
>> + struct i2c_client *client = v4l2_get_subdevdata(sd);
>> +
>> + ret = 0;
>> + mutex_lock(&ov5647->lock);
>> +
>> + if (on) {
>> + dev_dbg(&client->dev, "OV5647 power on!\n");
>> +
>> + ret = ov5647_write_array(sd, sensor_oe_enable_regs,
>> + ARRAY_SIZE(sensor_oe_enable_regs));
>> +
>> + ret = __sensor_init(sd);
>> +
>> + if (ret < 0)
>> + dev_err(&client->dev,
>> + "Camera not available! Check Power!\n");
>> + } else {
>> + dev_dbg(&client->dev, "OV5647 power off!\n");
>> +
>> + dev_dbg(&client->dev, "disable oe\n");
>> + ret = ov5647_write_array(sd, sensor_oe_disable_regs,
>> + ARRAY_SIZE(sensor_oe_disable_regs));
>> +
>> + if (ret < 0)
>> + dev_dbg(&client->dev, "disable oe failed!\n");
>> +
>> + ret = set_sw_standby(sd, true);
>> +
>> + if (ret < 0)
>> + dev_dbg(&client->dev, "soft stby failed!\n");
>
> dev_err for errors? Little less "!"s in the output?
>
>> +static int sensor_get_register(struct v4l2_subdev *sd,
>> + struct v4l2_dbg_register *reg)
>> +{
>> + unsigned char val = 0;
>> + int ret;
>> +
>> + ret = ov5647_read(sd, reg->reg & 0xff, &val);
>> + reg->val = val;
>> + reg->size = 1;
>> + return ret;
>> +}
>
> Filling reg->* when read failed is strange.
>
>> +static int sensor_set_register(struct v4l2_subdev *sd,
>> + const struct v4l2_dbg_register *reg)
>> +{
>> + ov5647_write(sd, reg->reg & 0xff, reg->val & 0xff);
>> + return 0;
>> +}
>
> error handling?
>
> Best regards,
> Pavel
>
Thanks for the feedback, I've corrected all the issues you pointed out, except
the one regarding the error handling in the ov5647_write function.
Best Regards,
Ramiro
--
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
* [PATCH v5 0/2] drm/panel: simple: add support for Sharp LQ150X1LG11 panels
From: Peter Rosin @ 2016-11-21 15:00 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Peter Rosin, Thierry Reding, David Airlie, Rob Herring,
Mark Rutland, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA
Hi!
This patch seems to have been forgotten? Thierry said that a
resend was not needed, but time is passing and the merge window
is nearing, so I'm resending anyway with the squashed .bpc-fix.
v4 -> v5 changes:
- change sharp_lq150x1lg11.bpc to 6 as noted by Thierry
- rebased onto v4.9-rc6
v3 -> v4 changes:
- addressed review comments from Rob (lvds -> sellvds and a couple of typos).
Cheers,
Peter
Gustaf Lindström (1):
drm/panel: simple: add support for Sharp LQ150X1LG11 panels
Peter Rosin (1):
dt-bindings: display: Add Sharp LQ150X1LG11 panel binding
.../bindings/display/panel/sharp,lq150x1lg11.txt | 36 ++++++++++++++++++++++
drivers/gpu/drm/panel/panel-simple.c | 27 ++++++++++++++++
2 files changed, 63 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.txt
--
2.1.4
--
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
* [PATCH v5 1/2] dt-bindings: display: Add Sharp LQ150X1LG11 panel binding
From: Peter Rosin @ 2016-11-21 15:00 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Peter Rosin, Thierry Reding, David Airlie, Rob Herring,
Mark Rutland, dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1479740449-20201-1-git-send-email-peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
The Sharp 15" LQ150X1LG11 panel is an XGA TFT LCD panel.
Signed-off-by: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
---
.../bindings/display/panel/sharp,lq150x1lg11.txt | 36 ++++++++++++++++++++++
1 file changed, 36 insertions(+)
create mode 100644 Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.txt
diff --git a/Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.txt b/Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.txt
new file mode 100644
index 000000000000..0f57c3143506
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.txt
@@ -0,0 +1,36 @@
+Sharp 15" LQ150X1LG11 XGA TFT LCD panel
+
+Required properties:
+- compatible: should be "sharp,lq150x1lg11"
+- power-supply: regulator to provide the VCC supply voltage (3.3 volts)
+
+Optional properties:
+- backlight: phandle of the backlight device
+- rlud-gpios: a single GPIO for the RL/UD (rotate 180 degrees) pin.
+- sellvds-gpios: a single GPIO for the SELLVDS pin.
+
+If rlud-gpios and/or sellvds-gpios are not specified, the RL/UD and/or SELLVDS
+pins are assumed to be handled appropriately by the hardware.
+
+Example:
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm 0 100000>; /* VBR */
+
+ brightness-levels = <0 20 40 60 80 100>;
+ default-brightness-level = <2>;
+
+ power-supply = <&vdd_12v_reg>; /* VDD */
+ enable-gpios = <&gpio 42 GPIO_ACTIVE_HIGH>; /* XSTABY */
+ };
+
+ panel {
+ compatible = "sharp,lq150x1lg11";
+
+ power-supply = <&vcc_3v3_reg>; /* VCC */
+
+ backlight = <&backlight>;
+ rlud-gpios = <&gpio 17 GPIO_ACTIVE_HIGH>; /* RL/UD */
+ sellvds-gpios = <&gpio 18 GPIO_ACTIVE_HIGH>; /* SELLVDS */
+ };
--
2.1.4
--
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 related
* [PATCH v5 2/2] drm/panel: simple: add support for Sharp LQ150X1LG11 panels
From: Peter Rosin @ 2016-11-21 15:00 UTC (permalink / raw)
To: linux-kernel
Cc: Gustaf Lindström, Thierry Reding, David Airlie, Rob Herring,
Mark Rutland, dri-devel, devicetree, Peter Rosin
In-Reply-To: <1479740449-20201-1-git-send-email-peda@axentia.se>
From: Gustaf Lindström <gl@axentia.se>
The Sharp 15" LQ150X1LG11 panel is an XGA TFT LCD panel.
The simple-panel driver is used to get support for essential
functionality of the panel.
Signed-off-by: Gustaf Lindström <gl@axentia.se>
Signed-off-by: Peter Rosin <peda@axentia.se>
---
drivers/gpu/drm/panel/panel-simple.c | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 113db3c4a633..76f0ef7e5b7c 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1420,6 +1420,30 @@ static const struct panel_desc sharp_lq123p1jx31 = {
},
};
+static const struct drm_display_mode sharp_lq150x1lg11_mode = {
+ .clock = 71100,
+ .hdisplay = 1024,
+ .hsync_start = 1024 + 168,
+ .hsync_end = 1024 + 168 + 64,
+ .htotal = 1024 + 168 + 64 + 88,
+ .vdisplay = 768,
+ .vsync_start = 768 + 37,
+ .vsync_end = 768 + 37 + 2,
+ .vtotal = 768 + 37 + 2 + 8,
+ .vrefresh = 60,
+};
+
+static const struct panel_desc sharp_lq150x1lg11 = {
+ .modes = &sharp_lq150x1lg11_mode,
+ .num_modes = 1,
+ .bpc = 6,
+ .size = {
+ .width = 304,
+ .height = 228,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB565_1X16,
+};
+
static const struct drm_display_mode shelly_sca07010_bfn_lnn_mode = {
.clock = 33300,
.hdisplay = 800,
@@ -1683,6 +1707,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "sharp,lq123p1jx31",
.data = &sharp_lq123p1jx31,
}, {
+ .compatible = "sharp,lq150x1lg11",
+ .data = &sharp_lq150x1lg11,
+ }, {
.compatible = "shelly,sca07010-bfn-lnn",
.data = &shelly_sca07010_bfn_lnn,
}, {
--
2.1.4
^ permalink raw reply related
* Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol
From: Ryan Harkin @ 2016-11-21 15:04 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Sudeep Holla, Philippe Robin, devicetree-u79uwXL29TY76Z2rM5mHXA,
Neil Armstrong, lkml, Olof Johansson,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <20161108174622.GW1041-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
On 8 November 2016 at 17:46, Russell King - ARM Linux
<linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org> wrote:
> On Tue, Nov 08, 2016 at 05:37:25PM +0000, Sudeep Holla wrote:
>>
>>
>> On 08/11/16 16:06, Russell King - ARM Linux wrote:
>> >On Tue, Nov 08, 2016 at 03:40:38PM +0000, Russell King - ARM Linux wrote:
>> >>As it contains a zero sized Image and .dtb files, I tried copying my
>> >>Image and .dtb over, and also copied my original config.txt (only
>> >>change is AUTORUN: FALSE). It still doesn't appear to boot beyond
>> >>this point.
>> >
>> >Well, it seems that I can't even go back to my original set of firmware
>> >as UEFI has stopped working:
>> >
>> >NOTICE: Booting Trusted Firmware
>> >NOTICE: BL1: v1.0(release):14b6608
>> >NOTICE: BL1: Built : 14:15:51, Sep 1 2014
>> >NOTICE: BL1: Booting BL2
>> >NOTICE: BL2: v1.0(release):14b6608
>> >NOTICE: BL2: Built : 14:15:51, Sep 1 2014
>> >NOTICE: BL1: Booting BL3-1
>> >NOTICE: BL3-1: v1.0(release):14b6608
>> >NOTICE: BL3-1: Built : 14:15:53, Sep 1 2014
>> >UEFI firmware (version v2.1 built at 14:41:56 on Oct 23 2014)
>> >Warning: Fail to load FDT file 'juno.dtb'.
>> >
>>
>> This again because of incompatibility of the configuration data saved in
>> NOR flash. The erase command I gave early is to erase that when you
>> switched between the UEFI binaries. It's really horrible mess UEFI
>> created in the initial days of Juno, and hopefully they have moved to
>> some standard format these days.
>
> Yea, what it means is I've no possibility to go back to what was
> originally working now, since I don't understand how to get UEFI to
> behave (Will set the machine up for me, I don't have any information
> on how it was originally configured other than what was on the uSD
> card, which appears incomplete.)
>
>> >and UEFI is the most unfriendly thing going - the "boot manager" thing
>> >doesn't let you view the configuration:
>> >
>>
>> I completely agree. I had real bad times in past dealing with such
>> things in UEFI.
>>
>> >[1] Linux from NOR Flash
>> >[2] Shell
>> >[3] Boot Manager
>> >Start: 3
>> >[1] Add Boot Device Entry
>> >[2] Update Boot Device Entry
>> >[3] Remove Boot Device Entry
>> >[4] Reorder Boot Device Entries
>> >[5] Update FDT path
>> >[6] Set Boot Timeout
>> >[7] Return to main menu
>> >Choice:
>> >
>> >and dropping into the shell... well, I've no idea how to get a listing
>> >of what it thinks is in the NOR device (or even how to refer to the
>> >NOR device.) "devices" shows nothing that's even remotely English.
>> >
Using UEFI is painful enough on Juno. Using a 2 year old version with
"that" menu system is even worse.
So I'll just pitch in here and recommend you switch to using u-boot.
Then you can see your config with "printenv" and you'll probably
understand it too.
The board will boot my prebuilt kernel/DTB using u-boot if you erase
the uSD card and unzip this firmware image to it:
http://releases.linaro.org/members/arm/platforms/16.10/juno-latest-oe-uboot.zip
Then you can copy over your own kernel & DTB for your own testing,
configure u-boot for TFTP, or whatever you like.
Switching to u-boot won't solve any thermal sensor calibration problems.
>>
>> I think startup.nsh needs some edits. Just replace it with something like:
>>
>> "norkern dtb=board.dtb console=ttyAMA0,115200n8 root=/dev/nfs rw
>> rootwait ip=dhcp systemd.log_target=null nfsroot=..." or something
>> alike. Currently it just echos and stops.
>>
>> Regarding the new firmware stopping abruptly, I have no clue, except
>> asking you to erase the flash completely when switching between the
>> firmware versions. That has worked for me for all UEFI related issues in
>> the past. It's really annoying I understand.
>>
>> flash> eraseall
>
> I've tried that, it still stops at the same point, after:
>
> FV2 Hob 0xFE07B000 - 0xFE8253BF
>
> and remains unresponsive.
>
> I do notice that the uSD card becomes visible through USB at this point
> though.
>
> Okay, well, I'm going to have to disable Juno from the nightly boots
> until we get some kind of resolution on this, as my Juno is now
> incapable of booting anything.
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
> according to speedtest.net.
--
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 1/2] PM / Domains: Introduce domain-performance-state binding
From: Rob Herring @ 2016-11-21 15:07 UTC (permalink / raw)
To: Viresh Kumar
Cc: Rafael Wysocki, linaro-kernel, linux-pm, linux-kernel,
Mark Rutland, Kevin Hilman, Ulf Hansson, Vincent Guittot,
Lina Iyer, devicetree, Stephen Boyd, Nayak Rajendra
In-Reply-To: <cce951c7159aa235792959ce27546be3aaa554ec.1479459752.git.viresh.kumar@linaro.org>
On Fri, Nov 18, 2016 at 02:53:12PM +0530, Viresh Kumar wrote:
> Some platforms have the capability to configure the performance state of
> their Power Domains. The performance levels are represented by positive
> integer values, a lower value represents lower performance state.
>
> The power-domains until now were only concentrating on the idle state
> management of the device and this needs to change in order to reuse the
> infrastructure of power domains for active state management.
>
> This patch introduces a new optional property for the consumers of the
> power-domains: domain-performance-state.
>
> If the consumers don't need the capability of switching to different
> domain performance states at runtime, then they can simply define their
> required domain performance state in their node directly. Otherwise the
> consumers can define their requirements with help of other
> infrastructure, for example the OPP table.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> Documentation/devicetree/bindings/power/power_domain.txt | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/power/power_domain.txt b/Documentation/devicetree/bindings/power/power_domain.txt
> index e1650364b296..db42eacf8b5c 100644
> --- a/Documentation/devicetree/bindings/power/power_domain.txt
> +++ b/Documentation/devicetree/bindings/power/power_domain.txt
> @@ -106,6 +106,12 @@ domain provided by the 'parent' power controller.
> - power-domains : A phandle and PM domain specifier as defined by bindings of
> the power controller specified by phandle.
>
> +Optional properties:
> +- domain-performance-state: A positive integer value representing the minimum
> + performance level (of the parent domain) required by the consumer for its
> + working. The integer value '1' represents the lowest performance level and the
> + highest value represents the highest performance level.
How does one come up with the range of values? It seems like you are
just making up numbers. Couldn't the domain performance level be an OPP
in the sense that it is a collection of clock frequencies and voltage
settings?
Rob
^ permalink raw reply
* Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol
From: Sudeep Holla @ 2016-11-21 15:12 UTC (permalink / raw)
To: Ryan Harkin
Cc: Russell King - ARM Linux, Sudeep Holla, Philippe Robin,
devicetree-u79uwXL29TY76Z2rM5mHXA, Neil Armstrong, lkml,
Olof Johansson, linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <CAD0U-hK982V+kUArjVSG7pTs5CLpNsgJaC5t8aPg8XuoiMRU0A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 21/11/16 15:04, Ryan Harkin wrote:
[...]
> Switching to u-boot won't solve any thermal sensor calibration problems.
>
Indeed. The board Russell had was one of those early ones which was not
calibrated properly. He is now able to use the 16.10 release after
calibration.
--
Regards,
Sudeep
--
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 V2] usb: xhci: add support for performing fake doorbell
From: Mathias Nyman @ 2016-11-21 15:31 UTC (permalink / raw)
To: Rafał Miłecki, Mathias Nyman
Cc: Greg Kroah-Hartman, Hauke Mehrtens, Rob Herring, Mark Rutland,
linux-usb@vger.kernel.org, devicetree@vger.kernel.org,
Linux Kernel Mailing List, Rafał Miłecki,
Florian Fainelli, BCM Kernel Feedback
In-Reply-To: <CACna6rw0tnjEOSqjd=q66yWZWa+oNAkH-tk=RLiLzz_=i0x-sA@mail.gmail.com>
On 21.11.2016 09:57, Rafał Miłecki wrote:
> Hi Mathias,
>
> On 17 October 2016 at 22:30, Rafał Miłecki <zajec5@gmail.com> wrote:
>> From: Rafał Miłecki <rafal@milecki.pl>
>>
>> Broadcom's Northstar XHCI controllers seem to need a special start
>> procedure to work correctly. There isn't any official documentation of
>> this, the problem is that controller doesn't detect any connected
>> devices with default setup. Moreover connecting USB device to controller
>> that doesn't run properly can cause SoC's watchdog issues.
>>
>> A workaround that was successfully tested on multiple devices is to
>> perform a fake doorbell. This patch adds code for doing this and enables
>> it on BCM4708 family.
>>
>> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
>> ---
>> V2: Enable quirk for brcm,bcm4708 machines instead of adding separated binding
>> for it. Thanks Rob for your comment on this.
>
> Do you think you can pick & push this one? V2 follows Rob's suggestion
> and he has some DT knowledge for sure, so I guess it should be OK.
> --
Is there some more background information on this?
I don't have any contacts to Broadcom myself, adding the BMC Kernel Feedback list to CC.
Maybe someone over there has an errata, documentation or just general feedback.
How was this workaround even figured out? ringing the doorbell for the first
device doesn't seem like something found by trial and error, especially when
xhci specs state that:
"Software shall not write the Doorbell of an endpoint until after it has issued a
Configure Endpoint Command for the endpoint and received a successful Command
Completion Event."
The whole workaround is a bit intrusive, allocating a fake device, ring a doorbell for a
fake device in the wrong state, clearing off HSE (host system error) which should only be set
when things really go bad, some random usleeps, and possible calling xhci_start() twice.
I can't take this as is without some more info.
-Mathias
^ permalink raw reply
* [RFC PATCH net v2 0/3] Fix OdroidC2 Gigabit Tx link issue
From: Jerome Brunet @ 2016-11-21 15:35 UTC (permalink / raw)
To: netdev, devicetree, Florian Fainelli
Cc: Jerome Brunet, Carlo Caione, Kevin Hilman, Giuseppe Cavallaro,
Alexandre TORGUE, Martin Blumenstingl, Andre Roth, Neil Armstrong,
linux-amlogic, linux-arm-kernel, linux-kernel
This patchset fixes an issue with the OdroidC2 board (DWMAC + RTL8211F).
Initially reported as a low Tx throughput issue at gigabit speed, the
platform enters LPI too often. This eventually break the link (both Tx
and Rx), and require to bring the interface down and up again to get the
Rx path working again.
The root cause of this issue is not fully understood yet but disabling EEE
advertisement on the PHY prevent this feature to be negotiated.
With this change, the link is stable and reliable, with the expected
throughput performance.
The patchset adds options in the generic phy driver to disable EEE
advertisement, through device tree. The way it is done is very similar
to the handling of the max-speed property.
This V2 is posted is posted as an RFC. Since it changes the generic PHY
it propably requires to be a bit more careful.
If you are not confortable taking for the coming rc, I can rebase on
net-next instead.
Chnages since V1: [1]
- Disable the advertisement of EEE in the generic code instead of the
realtek driver.
[1] : http://lkml.kernel.org/r/1479220154-25851-1-git-send-email-jbrunet@baylibre.com
Jerome Brunet (3):
net: phy: add an option to disable EEE advertisement
dt: bindings: add ethernet phy eee-disable-advert option documentation
ARM64: dts: meson: odroidc2: disable advertisement EEE for GbE.
Documentation/devicetree/bindings/net/phy.txt | 5 ++
.../arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 15 ++++
drivers/net/phy/phy.c | 3 +
drivers/net/phy/phy_device.c | 80 +++++++++++++++++++---
include/linux/phy.h | 3 +
5 files changed, 97 insertions(+), 9 deletions(-)
--
2.7.4
^ permalink raw reply
* [RFC PATCH net v2 1/3] net: phy: add an option to disable EEE advertisement
From: Jerome Brunet @ 2016-11-21 15:35 UTC (permalink / raw)
To: netdev, devicetree, Florian Fainelli
Cc: Jerome Brunet, Carlo Caione, Kevin Hilman, Giuseppe Cavallaro,
Alexandre TORGUE, Martin Blumenstingl, Andre Roth, Neil Armstrong,
linux-amlogic, linux-arm-kernel, linux-kernel
In-Reply-To: <1479742524-30222-1-git-send-email-jbrunet@baylibre.com>
This patch adds an option to disable EEE advertisement in the generic PHY
by providing a mask of prohibited modes corresponding to the value found in
the MDIO_AN_EEE_ADV register.
On some platforms, PHY Low power idle seems to be causing issues, even
breaking the link some cases. The patch provides a convenient way for these
platforms to disable EEE advertisement and work around the issue.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
drivers/net/phy/phy.c | 3 ++
drivers/net/phy/phy_device.c | 80 +++++++++++++++++++++++++++++++++++++++-----
include/linux/phy.h | 3 ++
3 files changed, 77 insertions(+), 9 deletions(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index f424b867f73e..a44ee14bd953 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -1348,6 +1348,9 @@ int phy_ethtool_set_eee(struct phy_device *phydev, struct ethtool_eee *data)
{
int val = ethtool_adv_to_mmd_eee_adv_t(data->advertised);
+ /* Mask prohibited EEE modes */
+ val &= ~phydev->eee_advert_disabled;
+
phy_write_mmd_indirect(phydev, MDIO_AN_EEE_ADV, MDIO_MMD_AN, val);
return 0;
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index 1a4bf8acad78..74c628e046cb 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1116,6 +1116,43 @@ static int genphy_config_advert(struct phy_device *phydev)
}
/**
+ * genphy_config_eee_advert - disable unwanted eee mode advertisement
+ * @phydev: target phy_device struct
+ *
+ * Description: Writes MDIO_AN_EEE_ADV after disabling unsupported energy
+ * efficent ethernet modes. Returns 0 if the PHY's advertisement hasn't
+ * changed, and 1 if it has changed.
+ */
+static int genphy_config_eee_advert(struct phy_device *phydev)
+{
+ u32 disabled = phydev->eee_advert_disabled;
+ u32 old_adv, adv;
+
+ /* Nothing to disable */
+ if (!disabled)
+ return 0;
+
+ /* If the following call fails, we assume that EEE is not
+ * supported by the phy. If we read 0, EEE is not advertised
+ * In both case, we don't need to continue
+ */
+ adv = phy_read_mmd_indirect(phydev, MDIO_AN_EEE_ADV, MDIO_MMD_AN);
+ if (adv <= 0)
+ return 0;
+
+ old_adv = adv;
+ adv &= ~disabled;
+
+ /* Advertising remains unchanged with the ban */
+ if (old_adv == adv)
+ return 0;
+
+ phy_write_mmd_indirect(phydev, MDIO_AN_EEE_ADV, MDIO_MMD_AN, adv);
+
+ return 1;
+}
+
+/**
* genphy_setup_forced - configures/forces speed/duplex from @phydev
* @phydev: target phy_device struct
*
@@ -1173,15 +1210,20 @@ EXPORT_SYMBOL(genphy_restart_aneg);
*/
int genphy_config_aneg(struct phy_device *phydev)
{
- int result;
+ int err, changed;
+
+ changed = genphy_config_eee_advert(phydev);
if (AUTONEG_ENABLE != phydev->autoneg)
return genphy_setup_forced(phydev);
- result = genphy_config_advert(phydev);
- if (result < 0) /* error */
- return result;
- if (result == 0) {
+ err = genphy_config_advert(phydev);
+ if (err < 0) /* error */
+ return err;
+
+ changed |= err;
+
+ if (changed == 0) {
/* Advertisement hasn't changed, but maybe aneg was never on to
* begin with? Or maybe phy was isolated?
*/
@@ -1191,16 +1233,16 @@ int genphy_config_aneg(struct phy_device *phydev)
return ctl;
if (!(ctl & BMCR_ANENABLE) || (ctl & BMCR_ISOLATE))
- result = 1; /* do restart aneg */
+ changed = 1; /* do restart aneg */
}
/* Only restart aneg if we are advertising something different
* than we were before.
*/
- if (result > 0)
- result = genphy_restart_aneg(phydev);
+ if (changed > 0)
+ return genphy_restart_aneg(phydev);
- return result;
+ return 0;
}
EXPORT_SYMBOL(genphy_config_aneg);
@@ -1558,6 +1600,21 @@ static void of_set_phy_supported(struct phy_device *phydev)
__set_phy_supported(phydev, max_speed);
}
+static void of_set_phy_eee_disable(struct phy_device *phydev)
+{
+ struct device_node *node = phydev->mdio.dev.of_node;
+ u32 disabled;
+
+ if (!IS_ENABLED(CONFIG_OF_MDIO))
+ return;
+
+ if (!node)
+ return;
+
+ if (!of_property_read_u32(node, "eee-advert-disable", &disabled))
+ phydev->eee_advert_disabled = disabled;
+}
+
/**
* phy_probe - probe and init a PHY device
* @dev: device to probe and init
@@ -1595,6 +1652,11 @@ static int phy_probe(struct device *dev)
of_set_phy_supported(phydev);
phydev->advertising = phydev->supported;
+ /* Get the EEE modes we want to prohibit. We will ask
+ * the PHY stop advertising these mode later on
+ */
+ of_set_phy_eee_disable(phydev);
+
/* Set the state to READY by default */
phydev->state = PHY_READY;
diff --git a/include/linux/phy.h b/include/linux/phy.h
index e25f1830fbcf..7f2ea0af16d1 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -401,6 +401,9 @@ struct phy_device {
u32 advertising;
u32 lp_advertising;
+ /* Energy efficient ethernet modes which should be prohibited */
+ u32 eee_advert_disabled;
+
int autoneg;
int link_timeout;
--
2.7.4
^ permalink raw reply related
* [RFC PATCH net v2 2/3] dt: bindings: add ethernet phy eee-disable-advert option documentation
From: Jerome Brunet @ 2016-11-21 15:35 UTC (permalink / raw)
To: netdev, devicetree, Florian Fainelli
Cc: Jerome Brunet, Carlo Caione, Kevin Hilman, Giuseppe Cavallaro,
Alexandre TORGUE, Martin Blumenstingl, Andre Roth, Neil Armstrong,
linux-amlogic, linux-arm-kernel, linux-kernel
In-Reply-To: <1479742524-30222-1-git-send-email-jbrunet@baylibre.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
Documentation/devicetree/bindings/net/phy.txt | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/phy.txt b/Documentation/devicetree/bindings/net/phy.txt
index bc1c3c8bf8fa..7f066b7c1e2c 100644
--- a/Documentation/devicetree/bindings/net/phy.txt
+++ b/Documentation/devicetree/bindings/net/phy.txt
@@ -35,6 +35,11 @@ Optional Properties:
- broken-turn-around: If set, indicates the PHY device does not correctly
release the turn around line low at the end of a MDIO transaction.
+- eee-advert-disable: Bits to clear in the MDIO_AN_EEE_ADV register to
+ disable EEE modes. Example
+ * 0x4: disable EEE for 1000T,
+ * 0x6: disable EEE for 100TX and 1000T
+
Example:
ethernet-phy@0 {
--
2.7.4
^ permalink raw reply related
* [RFC PATCH net v2 3/3] ARM64: dts: meson: odroidc2: disable advertisement EEE for GbE.
From: Jerome Brunet @ 2016-11-21 15:35 UTC (permalink / raw)
To: netdev, devicetree, Florian Fainelli
Cc: Alexandre TORGUE, Neil Armstrong, Martin Blumenstingl,
Kevin Hilman, linux-kernel, Andre Roth, linux-amlogic,
Carlo Caione, Giuseppe Cavallaro, linux-arm-kernel, Jerome Brunet
In-Reply-To: <1479742524-30222-1-git-send-email-jbrunet@baylibre.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index e6e3491d48a5..b34da077b2f8 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -98,3 +98,18 @@
pinctrl-0 = <&i2c_a_pins>;
pinctrl-names = "default";
};
+
+ðmac {
+ phy-handle = <ð_phy0>;
+
+ mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ eth_phy0: ethernet-phy@0 {
+ reg = <0>;
+ eee-advert-disable = <0x4>;
+ };
+ };
+};
--
2.7.4
^ permalink raw reply related
* Re: [RFC PATCH v2 3/7] iio: inkern: api for manipulating ext_info of iio channels
From: Lars-Peter Clausen @ 2016-11-21 15:45 UTC (permalink / raw)
To: Jonathan Cameron, Peter Rosin,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Wolfram Sang, Rob Herring, Mark Rutland, Hartmut Knaack,
Peter Meerwald-Stadler, Arnd Bergmann, Greg Kroah-Hartman,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <d5cd7550-2cde-5beb-2cdb-ad6d501fc0ef-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
On 11/19/2016 04:38 PM, Jonathan Cameron wrote:
> On 17/11/16 21:48, Peter Rosin wrote:
>> Extend the inkern api with functions for reading and writing ext_info
>> of iio channels.
> I'd like Lars' feedback on this one.
>
> Superficially looks fine to me but I am not as familiar with this interface
> as Lars is ;) (he wrote it IIRC:)
The implementation looks OK. I'm not necessarily convinced about the concept
though, but the code is manageable so I guess it is OK.
The final version should add kernel API documentation for the new functions.
>> ---
>> drivers/iio/inkern.c | 55 ++++++++++++++++++++++++++++++++++++++++++++
>> include/linux/iio/consumer.h | 6 +++++
>> 2 files changed, 61 insertions(+)
>>
>> diff --git a/drivers/iio/inkern.c b/drivers/iio/inkern.c
>> index cfca17ba2535..a8099b164222 100644
>> --- a/drivers/iio/inkern.c
>> +++ b/drivers/iio/inkern.c
>> @@ -850,3 +850,58 @@ int iio_write_channel_raw(struct iio_channel *chan, int val)
>> return ret;
>> }
>> EXPORT_SYMBOL_GPL(iio_write_channel_raw);
>> +
>> +int iio_get_channel_ext_info_count(struct iio_channel *chan)
should be unsigned.
>> +{
>> + const struct iio_chan_spec_ext_info *ext_info;
>> + unsigned int i = 0;
>> +
>> + if (!chan->channel->ext_info)
>> + return i;
>> +
>> + for (ext_info = chan->channel->ext_info; ext_info->name; ext_info++)
>> + ++i;
>> +
>> + return i;
>> +}
>> +EXPORT_SYMBOL_GPL(iio_get_channel_ext_info_count);
>> +
>> +ssize_t iio_read_channel_ext_info(struct iio_channel *chan,
>> + const char *attr, char *buf)
>> +{
>> + const struct iio_chan_spec_ext_info *ext_info;
>> +
>> + if (!chan->channel->ext_info)
>> + return -EINVAL;
>> +
>> + for (ext_info = chan->channel->ext_info; ext_info->name; ++ext_info) {
>> + if (strcmp(attr, ext_info->name))
>> + continue;
You could factor the lookup out into a helper function that is used for both
read and write. And also stop searching once a match was found.
>> +
>> + return ext_info->read(chan->indio_dev, ext_info->private,
>> + chan->channel, buf);
>> + }
>> +
>> + return -EINVAL;
>> +}
>> +EXPORT_SYMBOL_GPL(iio_read_channel_ext_info);
>> +
>> +ssize_t iio_write_channel_ext_info(struct iio_channel *chan, const char *attr,
>> + const char *buf, size_t len)
>> +{
>> + const struct iio_chan_spec_ext_info *ext_info;
>> +
>> + if (!chan->channel->ext_info)
>> + return -EINVAL;
>> +
>> + for (ext_info = chan->channel->ext_info; ext_info->name; ++ext_info) {
>> + if (strcmp(attr, ext_info->name))
>> + continue;
>> +
>> + return ext_info->write(chan->indio_dev, ext_info->private,
>> + chan->channel, buf, len);
>> + }
>> +
>> + return -EINVAL;
>> +}
>> +EXPORT_SYMBOL_GPL(iio_write_channel_ext_info);
>> diff --git a/include/linux/iio/consumer.h b/include/linux/iio/consumer.h
>> index 9a4f336d8b4a..471dece8729a 100644
>> --- a/include/linux/iio/consumer.h
>> +++ b/include/linux/iio/consumer.h
>> @@ -299,4 +299,10 @@ int iio_read_channel_scale(struct iio_channel *chan, int *val,
>> int iio_convert_raw_to_processed(struct iio_channel *chan, int raw,
>> int *processed, unsigned int scale);
>>
>> +int iio_get_channel_ext_info_count(struct iio_channel *chan);
>> +ssize_t iio_read_channel_ext_info(struct iio_channel *chan,
>> + const char *attr, char *buf);
>> +ssize_t iio_write_channel_ext_info(struct iio_channel *chan, const char *attr,
>> + const char *buf, size_t len);
>> +
>> #endif
>>
>
^ permalink raw reply
* Re: [RFC PATCH net v2 2/3] dt: bindings: add ethernet phy eee-disable-advert option documentation
From: Andrew Lunn @ 2016-11-21 16:01 UTC (permalink / raw)
To: Jerome Brunet
Cc: netdev, devicetree, Florian Fainelli, Alexandre TORGUE,
Neil Armstrong, Martin Blumenstingl, Kevin Hilman, linux-kernel,
Andre Roth, linux-amlogic, Carlo Caione, Giuseppe Cavallaro,
linux-arm-kernel
In-Reply-To: <1479742524-30222-3-git-send-email-jbrunet@baylibre.com>
On Mon, Nov 21, 2016 at 04:35:23PM +0100, Jerome Brunet wrote:
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> ---
> Documentation/devicetree/bindings/net/phy.txt | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/phy.txt b/Documentation/devicetree/bindings/net/phy.txt
> index bc1c3c8bf8fa..7f066b7c1e2c 100644
> --- a/Documentation/devicetree/bindings/net/phy.txt
> +++ b/Documentation/devicetree/bindings/net/phy.txt
> @@ -35,6 +35,11 @@ Optional Properties:
> - broken-turn-around: If set, indicates the PHY device does not correctly
> release the turn around line low at the end of a MDIO transaction.
>
> +- eee-advert-disable: Bits to clear in the MDIO_AN_EEE_ADV register to
> + disable EEE modes. Example
> + * 0x4: disable EEE for 1000T,
> + * 0x6: disable EEE for 100TX and 1000T
> +
Hi Jerome
I like the direction this patchset is taking. But hex values are
pretty unfriendly. Please add a set of boolean properties, and do the
mapping to hex in the C code.
That would also make extending this API easier. e.g. say you have a
10Gbps PHY with EEE, and you need to disable it. This hex value
quickly gets ugly, eee-advert-disable-10000 is nice and simple.
Andrew
^ 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