* [PATCH v7 3/6] kernel/reboot.c: export pm_power_off_prepare
From: Oleksij Rempel @ 2018-05-17 5:50 UTC (permalink / raw)
To: Shawn Guo, Mark Brown, Rafael J. Wysocki
Cc: Oleksij Rempel, kernel, devicetree, linux-arm-kernel, linux-clk,
linux-kernel, Andrew Morton, Liam Girdwood, Leonard Crestez,
Rob Herring, Mark Rutland, Michael Turquette, Stephen Boyd,
Fabio Estevam, Russell King
In-Reply-To: <20180517055014.6607-1-o.rempel@pengutronix.de>
Export pm_power_off_prepare. It is needed to implement power off on
Freescale/NXP iMX6 based boards with external power management
integrated circuit (PMIC).
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
kernel/reboot.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/reboot.c b/kernel/reboot.c
index e4ced883d8de..83810d726f3e 100644
--- a/kernel/reboot.c
+++ b/kernel/reboot.c
@@ -49,6 +49,7 @@ int reboot_force;
*/
void (*pm_power_off_prepare)(void);
+EXPORT_SYMBOL_GPL(pm_power_off_prepare);
/**
* emergency_restart - reboot the system
--
2.17.0
^ permalink raw reply related
* [PATCH v7 2/6] ARM: imx6: register pm_power_off handler if "fsl,pmic-stby-poweroff" is set
From: Oleksij Rempel @ 2018-05-17 5:50 UTC (permalink / raw)
To: Shawn Guo, Mark Brown, Rafael J. Wysocki
Cc: Oleksij Rempel, kernel, devicetree, linux-arm-kernel, linux-clk,
linux-kernel, Andrew Morton, Liam Girdwood, Leonard Crestez,
Rob Herring, Mark Rutland, Michael Turquette, Stephen Boyd,
Fabio Estevam, Russell King
In-Reply-To: <20180517055014.6607-1-o.rempel@pengutronix.de>
One of the Freescale recommended sequences for power off with external
PMIC is the following:
...
3. SoC is programming PMIC for power off when standby is asserted.
4. In CCM STOP mode, Standby is asserted, PMIC gates SoC supplies.
See:
http://www.nxp.com/assets/documents/data/en/reference-manuals/IMX6DQRM.pdf
page 5083
This patch implements step 4. of this sequence.
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
---
arch/arm/mach-imx/pm-imx6.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/arch/arm/mach-imx/pm-imx6.c b/arch/arm/mach-imx/pm-imx6.c
index 017539dd712b..2f5c643f62fb 100644
--- a/arch/arm/mach-imx/pm-imx6.c
+++ b/arch/arm/mach-imx/pm-imx6.c
@@ -601,6 +601,28 @@ static void __init imx6_pm_common_init(const struct imx6_pm_socdata
IMX6Q_GPR1_GINT);
}
+static void imx6_pm_stby_poweroff(void)
+{
+ imx6_set_lpm(STOP_POWER_OFF);
+ imx6q_suspend_finish(0);
+
+ mdelay(1000);
+
+ pr_emerg("Unable to poweroff system\n");
+}
+
+static int imx6_pm_stby_poweroff_probe(void)
+{
+ if (pm_power_off) {
+ pr_warn("%s: pm_power_off already claimed %p %pf!\n",
+ __func__, pm_power_off, pm_power_off);
+ return -EBUSY;
+ }
+
+ pm_power_off = imx6_pm_stby_poweroff;
+ return 0;
+}
+
void __init imx6_pm_ccm_init(const char *ccm_compat)
{
struct device_node *np;
@@ -617,6 +639,9 @@ void __init imx6_pm_ccm_init(const char *ccm_compat)
val = readl_relaxed(ccm_base + CLPCR);
val &= ~BM_CLPCR_LPM;
writel_relaxed(val, ccm_base + CLPCR);
+
+ if (of_property_read_bool(np, "fsl,pmic-stby-poweroff"))
+ imx6_pm_stby_poweroff_probe();
}
void __init imx6q_pm_init(void)
--
2.17.0
^ permalink raw reply related
* [PATCH v7 1/6] ARM: imx6q: provide documentation for new fsl,pmic-stby-poweroff property
From: Oleksij Rempel @ 2018-05-17 5:50 UTC (permalink / raw)
To: Shawn Guo, Mark Brown, Rafael J. Wysocki
Cc: Oleksij Rempel, kernel, devicetree, linux-arm-kernel, linux-clk,
linux-kernel, Andrew Morton, Liam Girdwood, Leonard Crestez,
Rob Herring, Mark Rutland, Michael Turquette, Stephen Boyd,
Fabio Estevam, Russell King
In-Reply-To: <20180517055014.6607-1-o.rempel@pengutronix.de>
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Acked-by: Rob Herring <robh@kernel.org>
---
Documentation/devicetree/bindings/clock/imx6q-clock.txt | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
index a45ca67a9d5f..e1308346e00d 100644
--- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
@@ -6,6 +6,14 @@ Required properties:
- interrupts: Should contain CCM interrupt
- #clock-cells: Should be <1>
+Optional properties:
+- fsl,pmic-stby-poweroff: Configure CCM to assert PMIC_STBY_REQ signal
+ on power off.
+ Use this property if the SoC should be powered off by external power
+ management IC (PMIC) triggered via PMIC_STBY_REQ signal.
+ Boards that are designed to initiate poweroff on PMIC_ON_REQ signal should
+ be using "syscon-poweroff" driver instead.
+
The clock consumer should specify the desired clock by having the clock
ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx6qdl-clock.h
for the full list of i.MX6 Quad and DualLite clock IDs.
--
2.17.0
^ permalink raw reply related
* [PATCH v7 0/6] provide power off support for iMX6 with external PMIC
From: Oleksij Rempel @ 2018-05-17 5:50 UTC (permalink / raw)
To: Shawn Guo, Mark Brown, Rafael J. Wysocki
Cc: Mark Rutland, devicetree, Michael Turquette, Stephen Boyd,
linux-kernel, Liam Girdwood, Oleksij Rempel, Rob Herring, kernel,
Fabio Estevam, Russell King, Andrew Morton, Leonard Crestez,
linux-clk, linux-arm-kernel
2018.05.17:
update patches to version v7
This patch series is providing power off support for Freescale/NXP iMX6 based
boards with external power management integrated circuit (PMIC).
As a first step the PMIC is configured to turn off the system if the
standby pin is asserted. On second step we assert the standby pin.
For this reason we need to use pm_power_off_prepare.
Usage of stnadby pin for power off is described in official iMX6
documentation.
2018.03.05:
As this patch set touches multiple subsystems I think it would make
sense for Shawn Guo to take the all patch set.
The only part which didn't receive an ACK is regulator stuff. So I would
hope that Mark Brown can ACK it.
Kind regards,
Oleksij Rempel
2017.12.06:
Adding Linus. Probably there is no maintainer for this patch set.
No changes are made, tested on v4.15-rc1.
2017.10.27:
Last version of this patch set was send at 20 Jun 2017, this is a rebase against
kernel v4.14-rc6. Probably this set got lost. If I forgot to address some comments,
please point me.
changes:
v7:
- use EXPORT_SYMBOL_GPL(pm_power_off_prepare) instead of EXPORT_SYMBOL
- call imx6q_suspend_finish() directly without cpu_suspend()
v6:
- rename imx6_pm_poweroff to imx6_pm_stby_poweroff
- fix "MPIC_STBY_REQ" typo in the comment.
v5:
- remove useless includes from pm-imx6.c patch
- add Acked-by to "regulator: pfuze100: add fsl,pmic-stby-poweroff property"
patch
v4:
- update comment in "regulator: pfuze100: add fsl,pmic-stby-poweroff ..."
patch
- add Acked-by to "ARM: imx6q: provide documentation for new ..."
patch
v3:
- set pm_power_off_prepare = NULL on .remove.
- documentation and spelling fixes.
- use %pf instead of lookup_symbol_name.
Oleksij Rempel (6):
ARM: imx6q: provide documentation for new fsl,pmic-stby-poweroff
property
ARM: imx6: register pm_power_off handler if "fsl,pmic-stby-poweroff"
is set
kernel/reboot.c: export pm_power_off_prepare
regulator: pfuze100: add fsl,pmic-stby-poweroff property
regulator: pfuze100-regulator: provide pm_power_off_prepare handler
ARM: dts: imx6: RIoTboard provide standby on power off option
.../devicetree/bindings/clock/imx6q-clock.txt | 8 ++
.../bindings/regulator/pfuze100.txt | 7 ++
arch/arm/boot/dts/imx6dl-riotboard.dts | 5 +
arch/arm/mach-imx/pm-imx6.c | 25 +++++
drivers/regulator/pfuze100-regulator.c | 92 +++++++++++++++++++
kernel/reboot.c | 1 +
6 files changed, 138 insertions(+)
--
2.17.0
^ permalink raw reply
* Re: [PATCH v3 5/6] spi: at91-usart: add driver for at91-usart as spi
From: Mark Brown @ 2018-05-17 5:04 UTC (permalink / raw)
To: Radu Pirea
Cc: devicetree, linux-serial, linux-kernel, linux-arm-kernel,
linux-spi, mark.rutland, robh+dt, lee.jones, gregkh, jslaby,
richard.genoud, alexandre.belloni, nicolas.ferre
In-Reply-To: <20180511103822.31698-6-radu.pirea@microchip.com>
[-- Attachment #1: Type: text/plain, Size: 1903 bytes --]
On Fri, May 11, 2018 at 01:38:21PM +0300, Radu Pirea wrote:
> +config SPI_AT91_USART
> + tristate "Atmel USART Controller as SPI"
> + depends on HAS_DMA
> + depends on (ARCH_AT91 || COMPILE_TEST)
> + select MFD_AT91_USART
> + help
> + This selects a driver for the AT91 USART Controller as SPI Master,
> + present on AT91 and SAMA5 SoC series.
> +
This looks like there's some tab/space mixing going on here.
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Driver for AT91 USART Controllers as SPI
> + *
> + * Copyright (C) 2018 Microchip Technology Inc.
Make the entire block a C++ comment so it looks more intentional rather
tha mixing C and C++.
> +static inline void at91_usart_spi_tx(struct at91_usart_spi *aus)
> +{
> + unsigned int len = aus->current_transfer->len;
> + unsigned int remaining = aus->current_tx_remaining_bytes;
> + const u8 *tx_buf = aus->current_transfer->tx_buf;
> +
> + if (tx_buf && remaining) {
> + if (at91_usart_spi_tx_ready(aus))
> + spi_writel(aus, THR, tx_buf[len - remaining]);
> + aus->current_tx_remaining_bytes--;
Missing braces here - we only write to the FIFO if there's space but we
unconditionally decrement the counter.
> + } else {
> + if (at91_usart_spi_tx_ready(aus))
> + spi_writel(aus, THR, US_DUMMY_TX);
> + }
> +}
This looks like you're open coding SPI_CONTROLLER_MUST_TX
> + int len = aus->current_transfer->len;
> + int remaining = aus->current_rx_remaining_bytes;
> + u8 *rx_buf = aus->current_transfer->rx_buf;
> +
> + if (aus->current_rx_remaining_bytes) {
> + rx_buf[len - remaining] = spi_readb(aus, RHR);
> + aus->current_rx_remaining_bytes--;
> + } else {
> + spi_readb(aus, RHR);
> + }
Similarly for _MUST_RX.
> + controller->flags = SPI_MASTER_MUST_RX | SPI_MASTER_MUST_TX;
You're actually setting both flags... this means that the handling for
cases with missing TX or RX buffers can't happen.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH v7 3/3] gpio: pca953x: fix address calculation for pcal6524
From: H. Nikolaus Schaller @ 2018-05-17 4:59 UTC (permalink / raw)
To: galak, andy.shevchenko, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Linus Walleij, Alexandre Courbot
Cc: devicetree, linux-gpio, linux-kernel, letux-kernel, kernel,
H. Nikolaus Schaller
In-Reply-To: <cover.1526533188.git.hns@goldelico.com>
The register constants are so far defined in a way that they fit
for the pcal9555a when shifted by the number of banks, i.e. are
multiplied by 2 in the accessor function.
Now, the pcal6524 has 3 banks which means the relative offset
is multiplied by 4 for the standard registers.
Simply applying the bit shift to the extended registers gives
a wrong result, since the base offset is already included in
the offset.
Therefore, we have to add code to the 24 bit accessor functions
that adjusts the register number for these exended registers.
The formula finally used was developed and proposed by
Andy Shevchenko <andy.shevchenko@gmail.com>.
Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
---
drivers/gpio/gpio-pca953x.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index c682921d7019..4ad553f4e41f 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -222,9 +222,11 @@ static int pca957x_write_regs_16(struct pca953x_chip *chip, int reg, u8 *val)
static int pca953x_write_regs_24(struct pca953x_chip *chip, int reg, u8 *val)
{
int bank_shift = fls((chip->gpio_chip.ngpio - 1) / BANK_SZ);
+ int addr = (reg & PCAL_GPIO_MASK) << bank_shift;
+ int pinctrl = (reg & PCAL_PINCTRL_MASK) << 1;
return i2c_smbus_write_i2c_block_data(chip->client,
- (reg << bank_shift) | REG_ADDR_AI,
+ pinctrl | addr | REG_ADDR_AI,
NBANK(chip), val);
}
@@ -264,9 +266,11 @@ static int pca953x_read_regs_16(struct pca953x_chip *chip, int reg, u8 *val)
static int pca953x_read_regs_24(struct pca953x_chip *chip, int reg, u8 *val)
{
int bank_shift = fls((chip->gpio_chip.ngpio - 1) / BANK_SZ);
+ int addr = (reg & PCAL_GPIO_MASK) << bank_shift;
+ int pinctrl = (reg & PCAL_PINCTRL_MASK) << 1;
return i2c_smbus_read_i2c_block_data(chip->client,
- (reg << bank_shift) | REG_ADDR_AI,
+ pinctrl | addr | REG_ADDR_AI,
NBANK(chip), val);
}
--
2.12.2
^ permalink raw reply related
* [PATCH v7 2/3] gpio: pca953x: define masks for addressing common and extended registers
From: H. Nikolaus Schaller @ 2018-05-17 4:59 UTC (permalink / raw)
To: galak, andy.shevchenko, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Linus Walleij, Alexandre Courbot
Cc: devicetree, linux-gpio, linux-kernel, letux-kernel, kernel,
H. Nikolaus Schaller
In-Reply-To: <cover.1526533188.git.hns@goldelico.com>
These mask bits are to be used to map the extended register
addreseses (which are defined for an unsupported 8-bit pcal chip)
to 16 and 24 bit chips (pcal6524).
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
---
drivers/gpio/gpio-pca953x.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 2b667166e855..c682921d7019 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -56,6 +56,10 @@
#define PCAL6524_DEBOUNCE 0x2d
#define PCA_GPIO_MASK 0x00FF
+
+#define PCAL_GPIO_MASK 0x1f
+#define PCAL_PINCTRL_MASK 0xe0
+
#define PCA_INT 0x0100
#define PCA_PCAL 0x0200
#define PCA_LATCH_INT (PCA_PCAL | PCA_INT)
--
2.12.2
^ permalink raw reply related
* [PATCH v7 1/3] gpio: pca953x: set the PCA_PCAL flag also when matching by DT
From: H. Nikolaus Schaller @ 2018-05-17 4:59 UTC (permalink / raw)
To: galak, andy.shevchenko, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Linus Walleij, Alexandre Courbot
Cc: devicetree, linux-gpio, linux-kernel, letux-kernel, kernel,
H. Nikolaus Schaller
In-Reply-To: <cover.1526533188.git.hns@goldelico.com>
The of_device_table is missing the PCA_PCAL flag so the
pcal6524 would be operated in tca6424 compatibility mode which
does not handle the new interrupt mask registers.
Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
---
drivers/gpio/gpio-pca953x.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 7d37692d672e..2b667166e855 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -58,6 +58,7 @@
#define PCA_GPIO_MASK 0x00FF
#define PCA_INT 0x0100
#define PCA_PCAL 0x0200
+#define PCA_LATCH_INT (PCA_PCAL | PCA_INT)
#define PCA953X_TYPE 0x1000
#define PCA957X_TYPE 0x2000
#define PCA_TYPE_MASK 0xF000
@@ -946,8 +947,8 @@ static const struct of_device_id pca953x_dt_ids[] = {
{ .compatible = "nxp,pca9575", .data = OF_957X(16, PCA_INT), },
{ .compatible = "nxp,pca9698", .data = OF_953X(40, 0), },
- { .compatible = "nxp,pcal6524", .data = OF_953X(24, PCA_INT), },
- { .compatible = "nxp,pcal9555a", .data = OF_953X(16, PCA_INT), },
+ { .compatible = "nxp,pcal6524", .data = OF_953X(24, PCA_LATCH_INT), },
+ { .compatible = "nxp,pcal9555a", .data = OF_953X(16, PCA_LATCH_INT), },
{ .compatible = "maxim,max7310", .data = OF_953X( 8, 0), },
{ .compatible = "maxim,max7312", .data = OF_953X(16, PCA_INT), },
--
2.12.2
^ permalink raw reply related
* [PATCH v7 0/3] pcal6524 extensions and fixes for pca953x driver
From: H. Nikolaus Schaller @ 2018-05-17 4:59 UTC (permalink / raw)
To: galak, andy.shevchenko, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Linus Walleij, Alexandre Courbot
Cc: devicetree, linux-gpio, linux-kernel, letux-kernel, kernel,
H. Nikolaus Schaller
V7:
* replace PCAL register masks by hex constants
2018-05-16 19:01:29: V6:
* added proper attribution to the formula used for fixing the
pcal6524 register address (changes commit message only)
* add back missing first patch from V2 that defines the
PCA_LATCH_INT constant
* removed patches already merged
2018-04-28 18:33:42: V5:
* fix wrong split up between patches 1/7 and 2/7.
2018-04-26 19:35:07: V4:
* introduced PCA_LATCH_INT constant to make of_table more
readable (suggested by Andy Shevchenko)
* converted all register constants to hex in a separate
patch (suggested by Andy Shevchenko)
* separated additional pcal953x and pcal6524 register
definitions into separate patches (suggested by Andy Shevchenko)
* made special pcal6524 address adjustment more readable
(suggested by Andy Shevchenko)
* moved gpio-controller and interrupt-controller to the
"required" section (reviewed by Rob Herring)
2018-04-10 18:07:07: V3:
* add Reported-by: and Reviewed-by:
* fix wording for bindings description and example
* convert all register offsets to hex
* omit the LEVEL-IRQ RFC/hack commit
2018-04-04 21:00:27: V2:
* added PCA_PCAL flags if matched through of-table
* fix address calculation for extended PCAL6524 registers
* hack to map LEVEL_LOW to EDGE_FALLING to be able to
test in combination with ts3a227e driver
* improve description of bindings for optional vcc-supply
and interrupt-controller;
2018-03-10 09:32:53: no initial description
H. Nikolaus Schaller (3):
gpio: pca953x: set the PCA_PCAL flag also when matching by DT
gpio: pca953x: define masks for addressing common and extended
registers
gpio: pca953x: fix address calculation for pcal6524
drivers/gpio/gpio-pca953x.c | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
--
2.12.2
^ permalink raw reply
* Re: [PATCH v3 5/6] spi: at91-usart: add driver for at91-usart as spi
From: Mark Brown @ 2018-05-17 4:54 UTC (permalink / raw)
To: Radu Pirea
Cc: Andy Shevchenko, devicetree, open list:SERIAL DRIVERS,
Linux Kernel Mailing List, linux-arm Mailing List, linux-spi,
Mark Rutland, Rob Herring, Lee Jones, Greg Kroah-Hartman,
Jiri Slaby, Richard Genoud, alexandre.belloni, Nicolas Ferre
In-Reply-To: <c23cdde58b9f724f51787c6c38478df983be6efa.camel@microchip.com>
[-- Attachment #1: Type: text/plain, Size: 526 bytes --]
On Tue, May 15, 2018 at 12:22:24PM +0300, Radu Pirea wrote:
> On Mon, 2018-05-14 at 20:38 +0300, Andy Shevchenko wrote:
> > So, what is not going as expected in "SPI core takes care of CSs"
> > case?
> > Did you use oscilloscope for that?
> Yes, I used and CSs was not asserted. Anyway, I will will try again.
If the core chip select handling is not working properly for some reason
then the core chip select handling should be fixed rather than just open
coding in your driver - probably it's also broken for other users.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [bug report] of: Introduce Device Tree resolve support.
From: Frank Rowand @ 2018-05-17 4:21 UTC (permalink / raw)
To: Dan Carpenter, pantelis.antoniou; +Cc: devicetree
In-Reply-To: <20180516141119.GA27580@mwanda>
Hi Dan,
On 05/16/18 07:11, Dan Carpenter wrote:
> Hello Pantelis Antoniou,
>
> The patch 7941b27b16e3: "of: Introduce Device Tree resolve support."
> from Jul 4, 2014, leads to the following static checker warning:
>
> drivers/of/resolver.c:125 update_usages_of_a_phandle_reference()
> error: buffer underflow 'prop->value' 's32min-s32max'
>
> drivers/of/resolver.c
> 72 static int update_usages_of_a_phandle_reference(struct device_node *overlay,
> 73 struct property *prop_fixup, phandle phandle)
> 74 {
> 75 struct device_node *refnode;
> 76 struct property *prop;
> 77 char *value, *cur, *end, *node_path, *prop_name, *s;
> 78 int offset, len;
> ^^^^^^
> 79 int err = 0;
> 80
> 81 value = kmemdup(prop_fixup->value, prop_fixup->length, GFP_KERNEL);
> 82 if (!value)
> 83 return -ENOMEM;
> 84
> 85 /* prop_fixup contains a list of tuples of path:property_name:offset */
> 86 end = value + prop_fixup->length;
> 87 for (cur = value; cur < end; cur += len + 1) {
> 88 len = strlen(cur);
> 89
> 90 node_path = cur;
> 91 s = strchr(cur, ':');
> 92 if (!s) {
> 93 err = -EINVAL;
> 94 goto err_fail;
> 95 }
> 96 *s++ = '\0';
> 97
> 98 prop_name = s;
> 99 s = strchr(s, ':');
> 100 if (!s) {
> 101 err = -EINVAL;
> 102 goto err_fail;
> 103 }
> 104 *s++ = '\0';
> 105
> 106 err = kstrtoint(s, 10, &offset);
> ^^^^^^^
> Smatch marks data that we get from the kstrtoint() as untrusted.
>
> 107 if (err)
> 108 goto err_fail;
> 109
> 110 refnode = __of_find_node_by_full_path(of_node_get(overlay), node_path);
> 111 if (!refnode)
> 112 continue;
> 113
> 114 for_each_property_of_node(refnode, prop) {
> 115 if (!of_prop_cmp(prop->name, prop_name))
> 116 break;
> 117 }
> 118 of_node_put(refnode);
> 119
> 120 if (!prop) {
> 121 err = -ENOENT;
> 122 goto err_fail;
> 123 }
> 124
> 125 *(__be32 *)(prop->value + offset) = cpu_to_be32(phandle);
> ^^^^^^^^^^^^^^^^^^^^
> So then it complains about this...
>
> We probably trust this data and are fine with it writing to where ever
Thanks for reporting this.
No, we should not trust this data.
Patch sent to validate the value of offset.
-Frank
> but it would be nice for reviewers to prevent the array
> underflow/overflow warning. I'm not even sure how big prop->value is
> though so I don't know what the bounds check should be.
>
> 126 }
> 127
> 128 err_fail:
> 129 kfree(value);
> 130 return err;
>
> regards,
> dan carpenter
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH] of: overlay: validate offset from property fixups
From: frowand.list @ 2018-05-17 4:19 UTC (permalink / raw)
To: Rob Herring, pantelis.antoniou, Pantelis Antoniou
Cc: Dan Carpenter, devicetree, linux-kernel
From: Frank Rowand <frank.rowand@sony.com>
The smatch static checker marks the data in offset as untrusted,
leading it to warn:
drivers/of/resolver.c:125 update_usages_of_a_phandle_reference()
error: buffer underflow 'prop->value' 's32min-s32max'
Add check to verify that offset is within the property data.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Frank Rowand <frank.rowand@sony.com>
---
drivers/of/resolver.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/of/resolver.c b/drivers/of/resolver.c
index 65d0b7adfcd4..7edfac6f1914 100644
--- a/drivers/of/resolver.c
+++ b/drivers/of/resolver.c
@@ -122,6 +122,11 @@ static int update_usages_of_a_phandle_reference(struct device_node *overlay,
goto err_fail;
}
+ if (offset < 0 || offset + sizeof(__be32) > prop->length) {
+ err = -EINVAL;
+ goto err_fail;
+ }
+
*(__be32 *)(prop->value + offset) = cpu_to_be32(phandle);
}
--
Frank Rowand <frank.rowand@sony.com>
^ permalink raw reply related
* Re: [PATCH v3 08/14] media: v4l: Add definitions for MPEG2 frame format and header metadata
From: kbuild test robot @ 2018-05-17 4:00 UTC (permalink / raw)
Cc: kbuild-all, linux-media, devicetree, linux-arm-kernel,
linux-kernel, Mauro Carvalho Chehab, Rob Herring, Mark Rutland,
Maxime Ripard, Chen-Yu Tsai, Paul Kocialkowski,
Greg Kroah-Hartman, David S . Miller, Andrew Morton,
Linus Walleij, Randy Dunlap, Hans Verkuil, Arnd Bergmann,
Stanimir Varbanov, Sakari Ailus
In-Reply-To: <20180507124500.20434-9-paul.kocialkowski@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 967 bytes --]
Hi Florent,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linuxtv-media/master]
[also build test WARNING on v4.17-rc5 next-20180516]
[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/Paul-Kocialkowski/Sunxi-Cedrus-driver-for-the-Allwinner-Video-Engine-using-media-requests/20180508-004955
base: git://linuxtv.org/media_tree.git master
config: x86_64-acpi-redef (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
>> ./usr/include/linux/v4l2-controls.h:1082: found __[us]{8,16,32,64} type without #include <linux/types.h>
---
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: 30376 bytes --]
^ permalink raw reply
* 答复: 答复: [PATCH v9 2/5] dt-bindings: scsi: ufs: add document for hisi-ufs
From: liwei (CM) @ 2018-05-17 0:50 UTC (permalink / raw)
To: Rob Herring
Cc: mark.rutland@arm.com, catalin.marinas@arm.com,
will.deacon@arm.com, vinholikatti@gmail.com,
jejb@linux.vnet.ibm.com, martin.petersen@oracle.com,
khilman@baylibre.com, arnd@arndb.de,
gregory.clement@free-electrons.com,
thomas.petazzoni@free-electrons.com,
yamada.masahiro@socionext.com, riku.voipio@linaro.org,
treding@nvidia.com, krzk@kernel.org
In-Reply-To: <CAL_JsqLf_r=NHHP2ZNEJOoLORXztF1KnU+tq-+COt4CPMLAsiA@mail.gmail.com>
Hi, Rob
-----邮件原件-----
发件人: Rob Herring [mailto:robh@kernel.org]
发送时间: 2018年5月16日 21:16
收件人: liwei (CM)
抄送: mark.rutland@arm.com; catalin.marinas@arm.com; will.deacon@arm.com; vinholikatti@gmail.com; jejb@linux.vnet.ibm.com; martin.petersen@oracle.com; khilman@baylibre.com; arnd@arndb.de; gregory.clement@free-electrons.com; thomas.petazzoni@free-electrons.com; yamada.masahiro@socionext.com; riku.voipio@linaro.org; treding@nvidia.com; krzk@kernel.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-scsi@vger.kernel.org; zangleigang; Gengjianfeng; guodong.xu@linaro.org
主题: Re: 答复: [PATCH v9 2/5] dt-bindings: scsi: ufs: add document for hisi-ufs
On Tue, Apr 24, 2018 at 8:54 AM, liwei (CM) <liwei213@huawei.com> wrote:
> Hi, Rob
>
> Thanks for your patience.
>
> Hi, Arnd
>
> From Rob's suggestion, we have to list the properties node in ufs-hisi.txt bingings even if documented in the common binding.
>
> -----邮件原件-----
> 发件人: Rob Herring [mailto:robh@kernel.org]
> 发送时间: 2018年4月24日 20:58
> 收件人: liwei (CM)
> 抄送: mark.rutland@arm.com; catalin.marinas@arm.com; will.deacon@arm.com; vinholikatti@gmail.com; jejb@linux.vnet.ibm.com; martin.petersen@oracle.com; khilman@baylibre.com; arnd@arndb.de; gregory.clement@free-electrons.com; thomas.petazzoni@free-electrons.com; yamada.masahiro@socionext.com; riku.voipio@linaro.org; treding@nvidia.com; krzk@kernel.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-scsi@vger.kernel.org; zangleigang; Gengjianfeng; guodong.xu@linaro.org
> 主题: Re: [PATCH v9 2/5] dt-bindings: scsi: ufs: add document for hisi-ufs
>
> On Tue, Apr 17, 2018 at 10:08:11PM +0800, Li Wei wrote:
>> add ufs node document for Hisilicon.
>>
>> Signed-off-by: Li Wei <liwei213@huawei.com>
>> ---
>> Documentation/devicetree/bindings/ufs/ufs-hisi.txt | 29 ++++++++++++++++++++++
>> .../devicetree/bindings/ufs/ufshcd-pltfrm.txt | 10 +++++---
>> 2 files changed, 36 insertions(+), 3 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/ufs/ufs-hisi.txt
>>
>> diff --git a/Documentation/devicetree/bindings/ufs/ufs-hisi.txt b/Documentation/devicetree/bindings/ufs/ufs-hisi.txt
>> new file mode 100644
>> index 000000000000..d49ab7d8f31d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/ufs/ufs-hisi.txt
>> @@ -0,0 +1,29 @@
>> +* Hisilicon Universal Flash Storage (UFS) Host Controller
>> +
>> +UFS nodes are defined to describe on-chip UFS hardware macro.
>> +Each UFS Host Controller should have its own node.
>> +
>> +Required properties:
>> +- compatible : compatible list, contains one of the following -
>> + "hisilicon,hi3660-ufs", "jedec,ufs-1.1" for hisi ufs
>> + host controller present on Hi36xx chipset.
>> +- reg : should contain UFS register address space & UFS SYS CTRL register address,
>> +- interrupt-parent : interrupt device
>> +- interrupts : interrupt number
>> +- resets : reset node register, the "arst" corresponds to reset the APB/AXI bus.
>
> arst belongs in reset-names.
>
> OK, I will fix it in next patch;
>
>> +- reset-names : describe reset node register
>
> What happened to clocks? You still have to list which ones apply even if
> documented in the common binding.
>
> OK, I will fix it in next patch;
>
>> +
>> +Example:
>> +
>> + ufs: ufs@ff3b0000 {
>> + compatible = "hisilicon,hi3660-ufs", "jedec,ufs-1.1";
>> + /* 0: HCI standard */
>> + /* 1: UFS SYS CTRL */
>> + reg = <0x0 0xff3b0000 0x0 0x1000>,
>> + <0x0 0xff3b1000 0x0 0x1000>;
>> + interrupt-parent = <&gic>;
>> + interrupts = <GIC_SPI 278 IRQ_TYPE_LEVEL_HIGH>;
>> + /* offset: 0x84; bit: 7 */
>> + resets = <&crg_rst 0x84 7>;
>> + reset-names = "arst";
>> + };
>> diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
>> index c39dfef76a18..adcfb79f63f5 100644
>> --- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
>> +++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
>> @@ -41,6 +41,8 @@ Optional properties:
>> -lanes-per-direction : number of lanes available per direction - either 1 or 2.
>> Note that it is assume same number of lanes is used both
>> directions at once. If not specified, default is 2 lanes per direction.
>> +- resets : reset node register, the "rst" corresponds to reset the whole UFS IP.
>> +- reset-names : describe reset node register
>
> Does your controller have 1 or 2 resets? There's no point in adding this
> here if it doesn't apply to your controller.
>
> There are 2 reset in our soc init, the "rst" corresponds to reset the whole UFS IP, and " arst " only reset the APB/AXI bus.
> Discussed with our soc colleagues that "arst" is assert by default and needs to deassert,but it done in bootloader,so will remove 'arst' in next patch.
>
> About the 'reset' property，it seems that Arnd Bergmann has different suggestion，he suggested that add 'rst' to ufshcd-pltfrm because it seems common.
> But it looks like only our soc init needs it. What's your opinion? Does it still needs add to common bindings?
For a single reset, then I'm fine with it being in the common
bindings. If there are multiple then it should be in the specific
bindings as the reset names are likely different.
OK, I will remove the 'arst' and keep only 'rst' in tne common bingings.
Rob
^ permalink raw reply
* Re: [PATCH v10 00/27] ARM: davinci: convert to common clock framework
From: Adam Ford @ 2018-05-17 0:46 UTC (permalink / raw)
To: David Lechner
Cc: linux-clk, devicetree, arm-soc, Michael Turquette, Stephen Boyd,
Rob Herring, Mark Rutland, Sekhar Nori, Kevin Hilman,
Bartosz Golaszewski, Linux Kernel Mailing List
In-Reply-To: <20180509172606.29387-1-david@lechnology.com>
On Wed, May 9, 2018 at 12:25 PM, David Lechner <david@lechnology.com> wrote:
> This series converts mach-davinci to use the common clock framework.
>
> The series works like this, the first 3 patches fix some issues with the clock
> drivers that have already been accepted into the mainline kernel.
>
> Then, starting with "ARM: davinci: pass clock as parameter to
> davinci_timer_init()", we get the mach code ready for the switch by adding the
> code needed for the new clock drivers and adding #ifndef CONFIG_COMMON_CLK
> around the legacy clocks so that we can switch easily between the old and the
> new.
>
> "ARM: davinci: switch to common clock framework" actually flips the switch
> to start using the new clock drivers. Then the next 8 patches remove all
> of the old clock code.
>
> The final four patches add device tree clock support to the one SoC that
> supports it.
>
> This series has been tested on TI OMAP-L138 LCDK (both device tree and legacy
> board file).
>
I am find. I don't know what I did wrong, but it's working fine. If
you want to add my 'tested-by' go ahead.
Tested-by: Adam Ford <aford173@gmail.com> #da850-evm, ethernet, spi
flash, SD, UART
>
> Changes:
>
> v10 changes (also see individual patches for details):
> - Reworked device tree bindings for DaVinci timer.
> - Dropped helper functions to conditionally call devm_* versions of functions
> - Fix some typos
> - Fix some rebasing issues introduced in v9
>
> v9 changes (also see individual patches for details):
> - Rebased on linux-davnci/master (f5e3203bb775)
> - Dropped drivers/clk patches that landed in v4.17
> - New drivers/clk patches for early boot special case
> - New patch for ti,davinci-timer device tree bindings
> - Updated mach/davinci patches to register clocks in early boot when needed
>
> v8 changes (also see individual patches for details):
> - Rebased on linux-davinci/master
> - Dropped use of __init and __initconst attributes in clk drivers
> - Add clkdev lookups for PLL SYSCLKs
> - Fix genpd clock reference counting issue
> - Fix PSC clock driver loading order issue
> - Fix typo in device tree and add more power-domains properties
>
> v7 changes (also see individual patches for details):
> - Rebased on linux-davinci/master (v4.16-rc)
> - Convert clock drivers to platform devices
> - New patch "ARM: davinci: pass clock as parameter to davinci_timer_init()"
> - Fix issues with lcdk and aemif clock lookups and power domains
> - Fixed other minor issues brought up in v6 review
>
> v6 changes (also see individual patches for details):
> - All of the device tree bindings are changed
> - All of the clock drivers are changed significantly
> - Fixed issues brought up during review of v5
> - "ARM: davinci: move davinci_clk_init() to init_time" is removed from this
> series and submitted separately
>
> v5 changes:
> - Basically, this is an entirely new series
> - Patches are broken up into bite-sized pieces
> - Converted PSC clock driver to use regmap
> - Restored "force" flag for certain DA850 clocks
> - Added device tree bindings
> - Moved more of the clock init to drivers/clk
> - Fixed frequency scaling (maybe*)
>
> * I have frequency scaling using cpufreq-dt, so I know the clocks are doing
> what they need to do to make this work, but I haven't figured out how to
> test davinci-cpufreq driver yet. (Patches to make cpufreq-dt work will be
> sent separately after this series has landed.)
>
>
> Dependencies:
>
> There are still some outstanding fixes to get everything working correctly.
> These are all just runtime dependencies and only needed for certain platforms.
>
> - "drm/tilcdc: Fix setting clock divider for omap-l138"[1]
> - "clk: davinci: pll-dm355: fix SYSCLKn parent names"[2]
> - "remoteproc/davinci: common clock framework related fixes"[3]
>
> [1]: https://patchwork.freedesktop.org/patch/210696/
> [2]: https://lkml.org/lkml/2018/5/9/626
> [3]: https://lkml.org/lkml/2018/5/2/201
>
> You can find a working branch with everything included (plus a few extras, like
> cpufreq-dt) in the "common-clk-v10" branch of https://github.com/dlech/ev3dev-kernel.git.
>
>
> Testing/debugging for the uninitiated:
>
> I only have one device to test with, which is based on da850, so I will
> have to rely on others to do some testing here. Since we are dealing with
> clocks, if something isn't working, you most likely won't see output on
> the serial port. To figure out what is going on, you need to enable...
>
> CONFIG_DEBUG_LL=y
> CONFIG_EARLY_PRINTK=y
>
> and add "earlyprintk clk_ignore_unused" to the kernel command line options.
> You may need to select a different UART for this depending on your board. I
> think UART1 is the default in the kernel configuration.
>
> On da850 devices comment out the lines:
>
> /* pll1_sysclk2 is not affected by CPU scaling, so use it for async3 */
> parent = clk_hw_get_parent_by_index(&mux->hw, 1);
> if (parent)
> clk_set_parent(mux->hw.clk, parent->clk);
> else
> dev_warn(dev, "Failed to find async3 parent clock\n");
>
> in da8xx-cfgchip.c or, if using device tree, comment out the lines:
>
> assigned-clocks = <&async3_clk>;
> assigned-clock-parents = <&pll1_sysclk 2>;
>
> in da850.dtsi when doing earlyprintk, otherwise the UART1 and UART2 clock
> source will change during boot and cause garbled output after a point.
>
>
> David Lechner (27):
> clk: davinci: pll: allow dev == NULL
> clk: davinci: da850-pll: change PLL0 to CLK_OF_DECLARE
> clk: davinci: psc: allow for dev == NULL
> ARM: davinci: pass clock as parameter to davinci_timer_init()
> ARM: davinci: da830: add new clock init using common clock framework
> ARM: davinci: da850: add new clock init using common clock framework
> ARM: davinci: dm355: add new clock init using common clock framework
> ARM: davinci: dm365: add new clock init using common clock framework
> ARM: davinci: dm644x: add new clock init using common clock framework
> ARM: davinci: dm646x: add new clock init using common clock framework
> ARM: davinci: da8xx: add new USB PHY clock init using common clock
> framework
> ARM: davinci: da8xx: add new sata_refclk init using common clock
> framework
> ARM: davinci: remove CONFIG_DAVINCI_RESET_CLOCKS
> ARM: davinci_all_defconfig: remove CONFIG_DAVINCI_RESET_CLOCKS
> ARM: davinci: switch to common clock framework
> ARM: davinci: da830: Remove legacy clock init
> ARM: davinci: da850: Remove legacy clock init
> ARM: davinci: dm355: Remove legacy clock init
> ARM: davinci: dm365: Remove legacy clock init
> ARM: davinci: dm644x: Remove legacy clock init
> ARM: davinci: dm646x: Remove legacy clock init
> ARM: davinci: da8xx: Remove legacy USB and SATA clock init
> ARM: davinci: remove legacy clocks
> dt-bindings: timer: new bindings for TI DaVinci timer
> ARM: davinci: add device tree support to timer
> ARM: davinci: da8xx-dt: switch to device tree clocks
> ARM: dts: da850: Add clocks
>
> .../bindings/timer/ti,davinci-timer.txt | 37 +
> arch/arm/Kconfig | 5 +-
> arch/arm/boot/dts/da850-enbw-cmc.dts | 4 +
> arch/arm/boot/dts/da850-evm.dts | 4 +
> arch/arm/boot/dts/da850-lcdk.dts | 9 +
> arch/arm/boot/dts/da850-lego-ev3.dts | 4 +
> arch/arm/boot/dts/da850.dtsi | 168 ++++
> arch/arm/configs/davinci_all_defconfig | 1 -
> arch/arm/mach-davinci/Kconfig | 13 +-
> arch/arm/mach-davinci/Makefile | 4 +-
> arch/arm/mach-davinci/board-da830-evm.c | 12 +-
> arch/arm/mach-davinci/board-da850-evm.c | 2 +
> arch/arm/mach-davinci/board-dm355-evm.c | 2 +
> arch/arm/mach-davinci/board-dm355-leopard.c | 2 +
> arch/arm/mach-davinci/board-dm365-evm.c | 2 +
> arch/arm/mach-davinci/board-dm644x-evm.c | 2 +
> arch/arm/mach-davinci/board-dm646x-evm.c | 2 +
> arch/arm/mach-davinci/board-mityomapl138.c | 2 +
> arch/arm/mach-davinci/board-neuros-osd2.c | 2 +
> arch/arm/mach-davinci/board-omapl138-hawk.c | 11 +-
> arch/arm/mach-davinci/board-sffsdr.c | 2 +
> arch/arm/mach-davinci/clock.c | 745 -----------------
> arch/arm/mach-davinci/clock.h | 76 --
> arch/arm/mach-davinci/common.c | 3 -
> arch/arm/mach-davinci/da830.c | 462 ++---------
> arch/arm/mach-davinci/da850.c | 778 +++---------------
> arch/arm/mach-davinci/da8xx-dt.c | 66 --
> arch/arm/mach-davinci/davinci.h | 8 +
> arch/arm/mach-davinci/devices-da8xx.c | 43 +-
> arch/arm/mach-davinci/devices.c | 1 -
> arch/arm/mach-davinci/dm355.c | 406 ++-------
> arch/arm/mach-davinci/dm365.c | 485 +----------
> arch/arm/mach-davinci/dm644x.c | 344 +-------
> arch/arm/mach-davinci/dm646x.c | 372 +--------
> arch/arm/mach-davinci/include/mach/clock.h | 3 -
> arch/arm/mach-davinci/include/mach/common.h | 11 +-
> arch/arm/mach-davinci/include/mach/da8xx.h | 6 +-
> arch/arm/mach-davinci/pm_domain.c | 5 +
> arch/arm/mach-davinci/psc.c | 137 ---
> arch/arm/mach-davinci/psc.h | 12 -
> arch/arm/mach-davinci/time.c | 39 +-
> arch/arm/mach-davinci/usb-da8xx.c | 242 +-----
> drivers/clk/davinci/pll-da830.c | 4 +-
> drivers/clk/davinci/pll-da850.c | 36 +-
> drivers/clk/davinci/pll-dm355.c | 8 +-
> drivers/clk/davinci/pll-dm365.c | 8 +-
> drivers/clk/davinci/pll-dm644x.c | 8 +-
> drivers/clk/davinci/pll-dm646x.c | 8 +-
> drivers/clk/davinci/pll.c | 110 +--
> drivers/clk/davinci/pll.h | 30 +-
> drivers/clk/davinci/psc-dm355.c | 2 +-
> drivers/clk/davinci/psc-dm365.c | 2 +-
> drivers/clk/davinci/psc-dm644x.c | 2 +-
> drivers/clk/davinci/psc-dm646x.c | 2 +-
> drivers/clk/davinci/psc.c | 27 +-
> include/linux/clk/davinci.h | 29 +
> 56 files changed, 860 insertions(+), 3950 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/timer/ti,davinci-timer.txt
> delete mode 100644 arch/arm/mach-davinci/clock.c
> delete mode 100644 arch/arm/mach-davinci/psc.c
> create mode 100644 include/linux/clk/davinci.h
>
> --
> 2.17.0
>
^ permalink raw reply
* Re: [PATCH v4 4/4] drm/rockchip: support dp training outside dp firmware
From: Brian Norris @ 2018-05-16 23:51 UTC (permalink / raw)
To: Lin Huang
Cc: devicetree, airlied, dianders, linux-kernel, linux-rockchip,
robh+dt, dri-devel, zyw, daniel.vetter, Kishon Vijay Abraham I,
linux-arm-kernel
In-Reply-To: <1526354560-23135-4-git-send-email-hl@rock-chips.com>
+ Kishon
Hi,
On Tue, May 15, 2018 at 11:22:40AM +0800, Lin Huang wrote:
> DP firmware uses fixed phy config values to do training, but some
> boards need to adjust these values to fit for their unique hardware
> design. So get phy config values from dts and use software link training
> instead of relying on firmware, if software training fail, keep firmware
> training as a fallback if sw training fails.
>
>
> Signed-off-by: Chris Zhong <zyw@rock-chips.com>
> Signed-off-by: Lin Huang <hl@rock-chips.com>
> ---
> Changes in v2:
> - update patch following Enric suggest
> Changes in v3:
> - use variable fw_training instead sw_training_success
> - base on DP SPCE, if training fail use lower link rate to retry training
> Changes in v4:
> - improve cdn_dp_get_lower_link_rate() and cdn_dp_software_train_link() follow Sean suggest
>
> drivers/gpu/drm/rockchip/Makefile | 3 +-
> drivers/gpu/drm/rockchip/cdn-dp-core.c | 24 +-
> drivers/gpu/drm/rockchip/cdn-dp-core.h | 2 +
> drivers/gpu/drm/rockchip/cdn-dp-link-training.c | 420 ++++++++++++++++++++++++
> drivers/gpu/drm/rockchip/cdn-dp-reg.c | 31 +-
> drivers/gpu/drm/rockchip/cdn-dp-reg.h | 38 ++-
> 6 files changed, 505 insertions(+), 13 deletions(-)
> create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-link-training.c
...
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-link-training.c b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
> new file mode 100644
> index 0000000..7efd070
> --- /dev/null
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-link-training.c
> @@ -0,0 +1,420 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
> + * Author: Chris Zhong <zyw@rock-chips.com>
> + */
> +
> +#include <linux/device.h>
> +#include <linux/delay.h>
> +#include <linux/phy/phy.h>
> +#include <soc/rockchip/rockchip_phy_typec.h>
> +
> +#include "cdn-dp-core.h"
> +#include "cdn-dp-reg.h"
> +
> +static void cdn_dp_set_signal_levels(struct cdn_dp_device *dp)
> +{
> + struct cdn_dp_port *port = dp->port[dp->active_port];
> + struct rockchip_typec_phy *tcphy = phy_get_drvdata(port->phy);
This is still antithetical to the PHY framework; you're assuming that
this is a particular type of PHY here.
> +
> + int rate = drm_dp_bw_code_to_link_rate(dp->link.rate);
> + u8 swing = (dp->train_set[0] & DP_TRAIN_VOLTAGE_SWING_MASK) >>
> + DP_TRAIN_VOLTAGE_SWING_SHIFT;
> + u8 pre_emphasis = (dp->train_set[0] & DP_TRAIN_PRE_EMPHASIS_MASK)
> + >> DP_TRAIN_PRE_EMPHASIS_SHIFT;
> +
> + tcphy->typec_phy_config(port->phy, rate, dp->link.num_lanes,
> + swing, pre_emphasis);
Is this something generic that could be added as a new PHY API instead?
> +}
Brian
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v6 1/2] dt-bindings: Documentation for qcom, llcc
From: rishabhb @ 2018-05-16 23:32 UTC (permalink / raw)
To: Stephen Boyd
Cc: devicetree, linux-arm-kernel, linux-arm-msm, linux-kernel,
linux-arm, tsoni, ckadabi, evgreen, robh
In-Reply-To: <152649413707.210890.2655572242392552759@swboyd.mtv.corp.google.com>
On 2018-05-16 11:08, Stephen Boyd wrote:
> Quoting rishabhb@codeaurora.org (2018-05-16 10:33:14)
>> On 2018-05-16 10:03, Stephen Boyd wrote:
>> > Quoting Rishabh Bhatnagar (2018-05-08 13:22:00)
>>
>> >> +
>> >> +- max-slices:
>> >> + usage: required
>> >> + Value Type: <u32>
>> >> + Definition: Number of cache slices supported by hardware
>> >> +
>> >> +Example:
>> >> +
>> >> + llcc: qcom,llcc@1100000 {
>> >
>> > cache-controller@1100000 ?
>> >
>> We have tried to use consistent naming convention as in llcc_*
>> everywhere.
>> Using cache-controller will mix and match the naming convention. Also
>> in
>> the documentation it is explained what llcc is and its full form.
>>
>
> DT prefers standard node names as opposed to vendor specific node
> names.
> Isn't it a cache controller? I fail to see why this can't be done.
Hi Stephen,
The driver is vendor specific and also for uniformity purposes we
preferred
to go with this name.
^ permalink raw reply
* [PATCH] dt-bindings: media: rcar_vin: fix style for ports and endpoints
From: Niklas Söderlund @ 2018-05-16 23:32 UTC (permalink / raw)
To: Rob Herring, devicetree
Cc: linux-media, linux-renesas-soc, Geert Uytterhoeven,
Niklas Söderlund
The style for referring to ports and endpoint are wrong. Refer to them
using lowercase and a unit address, port@x and endpoint@x.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
.../devicetree/bindings/media/rcar_vin.txt | 20 +++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/rcar_vin.txt b/Documentation/devicetree/bindings/media/rcar_vin.txt
index c2c57dcf73f4851b..a574b9c037c05a3c 100644
--- a/Documentation/devicetree/bindings/media/rcar_vin.txt
+++ b/Documentation/devicetree/bindings/media/rcar_vin.txt
@@ -45,23 +45,23 @@ The per-board settings Gen2 platforms:
The per-board settings Gen3 platforms:
Gen3 platforms can support both a single connected parallel input source
-from external SoC pins (port0) and/or multiple parallel input sources
-from local SoC CSI-2 receivers (port1) depending on SoC.
+from external SoC pins (port@0) and/or multiple parallel input sources
+from local SoC CSI-2 receivers (port@1) depending on SoC.
- renesas,id - ID number of the VIN, VINx in the documentation.
- ports
- - port 0 - sub-node describing a single endpoint connected to the VIN
+ - port@0 - sub-node describing a single endpoint connected to the VIN
from external SoC pins described in video-interfaces.txt[1].
- Describing more then one endpoint in port 0 is invalid. Only VIN
- instances that are connected to external pins should have port 0.
- - port 1 - sub-nodes describing one or more endpoints connected to
+ Describing more then one endpoint in port@0 is invalid. Only VIN
+ instances that are connected to external pins should have port@0.
+ - port@1 - sub-nodes describing one or more endpoints connected to
the VIN from local SoC CSI-2 receivers. The endpoint numbers must
use the following schema.
- - Endpoint 0 - sub-node describing the endpoint connected to CSI20
- - Endpoint 1 - sub-node describing the endpoint connected to CSI21
- - Endpoint 2 - sub-node describing the endpoint connected to CSI40
- - Endpoint 3 - sub-node describing the endpoint connected to CSI41
+ - endpoint@0 - sub-node describing the endpoint connected to CSI20
+ - endpoint@1 - sub-node describing the endpoint connected to CSI21
+ - endpoint@2 - sub-node describing the endpoint connected to CSI40
+ - endpoint@3 - sub-node describing the endpoint connected to CSI41
Device node example for Gen2 platforms
--------------------------------------
--
2.17.0
^ permalink raw reply related
* Re: [PATCH v2 03/40] iommu/sva: Manage process address spaces
From: Jacob Pan @ 2018-05-16 23:31 UTC (permalink / raw)
To: Jean-Philippe Brucker
Cc: kvm-u79uwXL29TY76Z2rM5mHXA, linux-pci-u79uwXL29TY76Z2rM5mHXA,
xuzaibo-hv44wF8Li93QT0dZR+AlfA, will.deacon-5wv7dgnIgG8,
okaya-sgV2jX0FEOL9JmXXK+q4OQ, linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
ashok.raj-ral2JQCrhuEAvxtiuMwx3w, bharatku-gjFFaj9aHVfQT0dZR+AlfA,
linux-acpi-u79uwXL29TY76Z2rM5mHXA, rfranz-YGCgFSpz5w/QT0dZR+AlfA,
devicetree-u79uwXL29TY76Z2rM5mHXA, rgummal-gjFFaj9aHVfQT0dZR+AlfA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
dwmw2-wEGCiKHe2LqWVfeAwA7xHQ,
ilias.apalodimas-QSEj5FYQhm4dnm+yROfE0A,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
christian.koenig-5C7GfCeVMHo
In-Reply-To: <20180511190641.23008-4-jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org>
On Fri, 11 May 2018 20:06:04 +0100
Jean-Philippe Brucker <jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org> wrote:
> Allocate IOMMU mm structures and binding them to devices. Four
> operations are added to IOMMU drivers:
>
> * mm_alloc(): to create an io_mm structure and perform architecture-
> specific operations required to grab the process (for instance on
> ARM, pin down the CPU ASID so that the process doesn't get assigned a
> new ASID on rollover).
>
> There is a single valid io_mm structure per Linux mm. Future
> extensions may also use io_mm for kernel-managed address spaces,
> populated with map()/unmap() calls instead of bound to process
> address spaces. This patch focuses on "shared" io_mm.
>
> * mm_attach(): attach an mm to a device. The IOMMU driver checks that
> the device is capable of sharing an address space, and writes the
> PASID table entry to install the pgd.
>
> Some IOMMU drivers will have a single PASID table per domain, for
> convenience. Other can implement it differently but to help these
> drivers, mm_attach and mm_detach take 'attach_domain' and
> 'detach_domain' parameters, that tell whether they need to set and
> clear the PASID entry or only send the required TLB invalidations.
>
> * mm_detach(): detach an mm from a device. The IOMMU driver removes
> the PASID table entry and invalidates the IOTLBs.
>
> * mm_free(): free a structure allocated by mm_alloc(), and let arch
> release the process.
>
> mm_attach and mm_detach operations are serialized with a spinlock.
> When trying to optimize this code, we should at least prevent
> concurrent attach()/detach() on the same domain (so multi-level PASID
> table code can allocate tables lazily). mm_alloc() can sleep, but
> mm_free must not (because we'll have to call it from call_srcu later
> on).
>
> At the moment we use an IDR for allocating PASIDs and retrieving
> contexts. We also use a single spinlock. These can be refined and
> optimized later (a custom allocator will be needed for top-down PASID
> allocation).
>
> Keeping track of address spaces requires the use of MMU notifiers.
> Handling process exit with regard to unbind() is tricky, so it is
> left for another patch and we explicitly fail mm_alloc() for the
> moment.
>
> Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker-5wv7dgnIgG8@public.gmane.org>
>
> ---
> v1->v2: sanity-check of flags
> ---
> drivers/iommu/iommu-sva.c | 380
> +++++++++++++++++++++++++++++++++++++- drivers/iommu/iommu.c |
> 1 + include/linux/iommu.h | 28 +++
> 3 files changed, 406 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iommu/iommu-sva.c b/drivers/iommu/iommu-sva.c
> index 8d98f9c09864..6ac679c48f3c 100644
> --- a/drivers/iommu/iommu-sva.c
> +++ b/drivers/iommu/iommu-sva.c
> @@ -5,8 +5,298 @@
> * Copyright (C) 2018 ARM Ltd.
> */
>
> +#include <linux/idr.h>
> #include <linux/iommu.h>
> +#include <linux/sched/mm.h>
> #include <linux/slab.h>
> +#include <linux/spinlock.h>
> +
> +/**
> + * DOC: io_mm model
> + *
> + * The io_mm keeps track of process address spaces shared between
> CPU and IOMMU.
> + * The following example illustrates the relation between structures
> + * iommu_domain, io_mm and iommu_bond. An iommu_bond is a link
> between io_mm and
> + * device. A device can have multiple io_mm and an io_mm may be
> bound to
> + * multiple devices.
> + * ___________________________
> + * | IOMMU domain A |
> + * | ________________ |
> + * | | IOMMU group | +------- io_pgtables
> + * | | | |
> + * | | dev 00:00.0 ----+------- bond --- io_mm X
> + * | |________________| \ |
> + * | '----- bond ---.
> + * |___________________________| \
> + * ___________________________ \
> + * | IOMMU domain B | io_mm Y
> + * | ________________ | / /
> + * | | IOMMU group | | / /
> + * | | | | / /
> + * | | dev 00:01.0 ------------ bond -' /
> + * | | dev 00:01.1 ------------ bond --'
> + * | |________________| |
> + * | +------- io_pgtables
> + * |___________________________|
> + *
> + * In this example, device 00:00.0 is in domain A, devices 00:01.*
> are in domain
> + * B. All devices within the same domain access the same address
> spaces. Device
> + * 00:00.0 accesses address spaces X and Y, each corresponding to an
> mm_struct.
> + * Devices 00:01.* only access address space Y. In addition each
> + * IOMMU_DOMAIN_DMA domain has a private address space, io_pgtable,
> that is
> + * managed with iommu_map()/iommu_unmap(), and isn't shared with the
> CPU MMU.
> + *
> + * To obtain the above configuration, users would for instance issue
> the
> + * following calls:
> + *
> + * iommu_sva_bind_device(dev 00:00.0, mm X, ...) -> PASID 1
> + * iommu_sva_bind_device(dev 00:00.0, mm Y, ...) -> PASID 2
> + * iommu_sva_bind_device(dev 00:01.0, mm Y, ...) -> PASID 2
> + * iommu_sva_bind_device(dev 00:01.1, mm Y, ...) -> PASID 2
> + *
> + * A single Process Address Space ID (PASID) is allocated for each
> mm. In the
> + * example, devices use PASID 1 to read/write into address space X
> and PASID 2
> + * to read/write into address space Y.
> + *
> + * Hardware tables describing this configuration in the IOMMU would
> typically
> + * look like this:
> + *
> + * PASID tables
> + * of domain A
> + * .->+--------+
> + * / 0 | |-------> io_pgtable
> + * / +--------+
> + * Device tables / 1 | |-------> pgd X
> + * +--------+ / +--------+
> + * 00:00.0 | A |-' 2 | |--.
> + * +--------+ +--------+ \
> + * : : 3 | | \
> + * +--------+ +--------+ --> pgd Y
> + * 00:01.0 | B |--. /
> + * +--------+ \ |
> + * 00:01.1 | B |----+ PASID tables |
> + * +--------+ \ of domain B |
> + * '->+--------+ |
> + * 0 | |-- | --> io_pgtable
> + * +--------+ |
> + * 1 | | |
> + * +--------+ |
> + * 2 | |---'
> + * +--------+
> + * 3 | |
> + * +--------+
> + *
I am a little confused about domain vs. pasid relationship. If
each domain represents a address space, should there be a domain for
each pasid?
> + * With this model, a single call binds all devices in a given
> domain to an
> + * address space. Other devices in the domain will get the same bond
> implicitly.
> + * However, users must issue one bind() for each device, because
> IOMMUs may
> + * implement SVA differently. Furthermore, mandating one bind() per
> device
> + * allows the driver to perform sanity-checks on device capabilities.
> + *
> + * On Arm and AMD IOMMUs, entry 0 of the PASID table can be used to
> hold
> + * non-PASID translations. In this case PASID 0 is reserved and
> entry 0 points
> + * to the io_pgtable base. On Intel IOMMU, the io_pgtable base would
> be held in
> + * the device table and PASID 0 would be available to the allocator.
> + */
> +
> +struct iommu_bond {
> + struct io_mm *io_mm;
> + struct device *dev;
> + struct iommu_domain *domain;
> +
> + struct list_head mm_head;
> + struct list_head dev_head;
> + struct list_head domain_head;
> +
> + void *drvdata;
> +};
> +
> +/*
> + * Because we're using an IDR, PASIDs are limited to 31 bits (the
> sign bit is
> + * used for returning errors). In practice implementations will use
> at most 20
> + * bits, which is the PCI limit.
> + */
> +static DEFINE_IDR(iommu_pasid_idr);
> +
> +/*
> + * For the moment this is an all-purpose lock. It serializes
> + * access/modifications to bonds, access/modifications to the PASID
> IDR, and
> + * changes to io_mm refcount as well.
> + */
> +static DEFINE_SPINLOCK(iommu_sva_lock);
> +
> +static struct io_mm *
> +io_mm_alloc(struct iommu_domain *domain, struct device *dev,
> + struct mm_struct *mm, unsigned long flags)
> +{
> + int ret;
> + int pasid;
> + struct io_mm *io_mm;
> + struct iommu_sva_param *param = dev->iommu_param->sva_param;
> +
> + if (!domain->ops->mm_alloc || !domain->ops->mm_free)
> + return ERR_PTR(-ENODEV);
> +
> + io_mm = domain->ops->mm_alloc(domain, mm, flags);
> + if (IS_ERR(io_mm))
> + return io_mm;
> + if (!io_mm)
> + return ERR_PTR(-ENOMEM);
> +
> + /*
> + * The mm must not be freed until after the driver frees the
> io_mm
> + * (which may involve unpinning the CPU ASID for instance,
> requiring a
> + * valid mm struct.)
> + */
> + mmgrab(mm);
> +
> + io_mm->flags = flags;
> + io_mm->mm = mm;
> + io_mm->release = domain->ops->mm_free;
> + INIT_LIST_HEAD(&io_mm->devices);
> +
> + idr_preload(GFP_KERNEL);
> + spin_lock(&iommu_sva_lock);
> + pasid = idr_alloc(&iommu_pasid_idr, io_mm, param->min_pasid,
> + param->max_pasid + 1, GFP_ATOMIC);
> + io_mm->pasid = pasid;
> + spin_unlock(&iommu_sva_lock);
> + idr_preload_end();
> +
> + if (pasid < 0) {
> + ret = pasid;
> + goto err_free_mm;
> + }
> +
> + /* TODO: keep track of mm. For the moment, abort. */
> + ret = -ENOSYS;
> + spin_lock(&iommu_sva_lock);
> + idr_remove(&iommu_pasid_idr, io_mm->pasid);
> + spin_unlock(&iommu_sva_lock);
> +
> +err_free_mm:
> + domain->ops->mm_free(io_mm);
> + mmdrop(mm);
> +
> + return ERR_PTR(ret);
> +}
> +
> +static void io_mm_free(struct io_mm *io_mm)
> +{
> + struct mm_struct *mm = io_mm->mm;
> +
> + io_mm->release(io_mm);
> + mmdrop(mm);
> +}
> +
> +static void io_mm_release(struct kref *kref)
> +{
> + struct io_mm *io_mm;
> +
> + io_mm = container_of(kref, struct io_mm, kref);
> + WARN_ON(!list_empty(&io_mm->devices));
> +
> + idr_remove(&iommu_pasid_idr, io_mm->pasid);
> +
> + io_mm_free(io_mm);
> +}
> +
> +/*
> + * Returns non-zero if a reference to the io_mm was successfully
> taken.
> + * Returns zero if the io_mm is being freed and should not be used.
> + */
> +static int io_mm_get_locked(struct io_mm *io_mm)
> +{
> + if (io_mm)
> + return kref_get_unless_zero(&io_mm->kref);
> +
> + return 0;
> +}
> +
> +static void io_mm_put_locked(struct io_mm *io_mm)
> +{
> + kref_put(&io_mm->kref, io_mm_release);
> +}
> +
> +static void io_mm_put(struct io_mm *io_mm)
> +{
> + spin_lock(&iommu_sva_lock);
> + io_mm_put_locked(io_mm);
> + spin_unlock(&iommu_sva_lock);
> +}
> +
> +static int io_mm_attach(struct iommu_domain *domain, struct device
> *dev,
> + struct io_mm *io_mm, void *drvdata)
> +{
> + int ret;
> + bool attach_domain = true;
> + int pasid = io_mm->pasid;
> + struct iommu_bond *bond, *tmp;
> + struct iommu_sva_param *param = dev->iommu_param->sva_param;
> +
> + if (!domain->ops->mm_attach || !domain->ops->mm_detach)
> + return -ENODEV;
> +
> + if (pasid > param->max_pasid || pasid < param->min_pasid)
> + return -ERANGE;
> +
> + bond = kzalloc(sizeof(*bond), GFP_KERNEL);
> + if (!bond)
> + return -ENOMEM;
> +
> + bond->domain = domain;
> + bond->io_mm = io_mm;
> + bond->dev = dev;
> + bond->drvdata = drvdata;
> +
> + spin_lock(&iommu_sva_lock);
> + /*
> + * Check if this io_mm is already bound to the domain. In
> which case the
> + * IOMMU driver doesn't have to install the PASID table
> entry.
> + */
> + list_for_each_entry(tmp, &domain->mm_list, domain_head) {
> + if (tmp->io_mm == io_mm) {
> + attach_domain = false;
> + break;
> + }
> + }
> +
> + ret = domain->ops->mm_attach(domain, dev, io_mm,
> attach_domain);
> + if (ret) {
> + kfree(bond);
> + spin_unlock(&iommu_sva_lock);
> + return ret;
> + }
> +
> + list_add(&bond->mm_head, &io_mm->devices);
> + list_add(&bond->domain_head, &domain->mm_list);
> + list_add(&bond->dev_head, ¶m->mm_list);
> + spin_unlock(&iommu_sva_lock);
> +
> + return 0;
> +}
> +
> +static void io_mm_detach_locked(struct iommu_bond *bond)
> +{
> + struct iommu_bond *tmp;
> + bool detach_domain = true;
> + struct iommu_domain *domain = bond->domain;
> +
> + list_for_each_entry(tmp, &domain->mm_list, domain_head) {
> + if (tmp->io_mm == bond->io_mm && tmp->dev !=
> bond->dev) {
> + detach_domain = false;
> + break;
> + }
> + }
> +
> + domain->ops->mm_detach(domain, bond->dev, bond->io_mm,
> detach_domain); +
> + list_del(&bond->mm_head);
> + list_del(&bond->domain_head);
> + list_del(&bond->dev_head);
> + io_mm_put_locked(bond->io_mm);
> +
> + kfree(bond);
> +}
>
> /**
> * iommu_sva_device_init() - Initialize Shared Virtual Addressing
> for a device @@ -47,6 +337,7 @@ int iommu_sva_device_init(struct
> device *dev, unsigned long features,
> param->features = features;
> param->max_pasid = max_pasid;
> + INIT_LIST_HEAD(¶m->mm_list);
>
> /*
> * IOMMU driver updates the limits depending on the IOMMU
> and device @@ -114,13 +405,87 @@
> EXPORT_SYMBOL_GPL(iommu_sva_device_shutdown); int
> __iommu_sva_bind_device(struct device *dev, struct mm_struct *mm, int
> *pasid, unsigned long flags, void *drvdata) {
> - return -ENOSYS; /* TODO */
> + int i, ret = 0;
> + struct io_mm *io_mm = NULL;
> + struct iommu_domain *domain;
> + struct iommu_bond *bond = NULL, *tmp;
> + struct iommu_sva_param *param = dev->iommu_param->sva_param;
> +
> + domain = iommu_get_domain_for_dev(dev);
> + if (!domain)
> + return -EINVAL;
> +
> + /*
> + * The device driver does not call sva_device_init/shutdown
> and
> + * bind/unbind concurrently, so no need to take the param
> lock.
> + */
> + if (WARN_ON_ONCE(!param) || (flags & ~param->features))
> + return -EINVAL;
> +
> + /* If an io_mm already exists, use it */
> + spin_lock(&iommu_sva_lock);
> + idr_for_each_entry(&iommu_pasid_idr, io_mm, i) {
> + if (io_mm->mm == mm && io_mm_get_locked(io_mm)) {
> + /* ... Unless it's already bound to this
> device */
> + list_for_each_entry(tmp, &io_mm->devices,
> mm_head) {
> + if (tmp->dev == dev) {
> + bond = tmp;
> + io_mm_put_locked(io_mm);
> + break;
> + }
> + }
> + break;
> + }
> + }
> + spin_unlock(&iommu_sva_lock);
> +
> + if (bond)
> + return -EEXIST;
> +
> + /* Require identical features within an io_mm for now */
> + if (io_mm && (flags != io_mm->flags)) {
> + io_mm_put(io_mm);
> + return -EDOM;
> + }
> +
> + if (!io_mm) {
> + io_mm = io_mm_alloc(domain, dev, mm, flags);
> + if (IS_ERR(io_mm))
> + return PTR_ERR(io_mm);
> + }
> +
> + ret = io_mm_attach(domain, dev, io_mm, drvdata);
> + if (ret)
> + io_mm_put(io_mm);
> + else
> + *pasid = io_mm->pasid;
> +
> + return ret;
> }
> EXPORT_SYMBOL_GPL(__iommu_sva_bind_device);
>
> int __iommu_sva_unbind_device(struct device *dev, int pasid)
> {
> - return -ENOSYS; /* TODO */
> + int ret = -ESRCH;
> + struct iommu_domain *domain;
> + struct iommu_bond *bond = NULL;
> + struct iommu_sva_param *param = dev->iommu_param->sva_param;
> +
> + domain = iommu_get_domain_for_dev(dev);
> + if (!param || WARN_ON(!domain))
> + return -EINVAL;
> +
> + spin_lock(&iommu_sva_lock);
> + list_for_each_entry(bond, ¶m->mm_list, dev_head) {
> + if (bond->io_mm->pasid == pasid) {
> + io_mm_detach_locked(bond);
> + ret = 0;
> + break;
> + }
> + }
> + spin_unlock(&iommu_sva_lock);
> +
> + return ret;
> }
> EXPORT_SYMBOL_GPL(__iommu_sva_unbind_device);
>
> @@ -132,6 +497,15 @@ EXPORT_SYMBOL_GPL(__iommu_sva_unbind_device);
> */
> void __iommu_sva_unbind_dev_all(struct device *dev)
> {
> - /* TODO */
> + struct iommu_sva_param *param;
> + struct iommu_bond *bond, *next;
> +
> + param = dev->iommu_param->sva_param;
> + if (param) {
> + spin_lock(&iommu_sva_lock);
> + list_for_each_entry_safe(bond, next,
> ¶m->mm_list, dev_head)
> + io_mm_detach_locked(bond);
> + spin_unlock(&iommu_sva_lock);
> + }
> }
> EXPORT_SYMBOL_GPL(__iommu_sva_unbind_dev_all);
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index bd2819deae5b..333801e1519c 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -1463,6 +1463,7 @@ static struct iommu_domain
> *__iommu_domain_alloc(struct bus_type *bus, domain->type = type;
> /* Assume all sizes by default; the driver may override this
> later */ domain->pgsize_bitmap = bus->iommu_ops->pgsize_bitmap;
> + INIT_LIST_HEAD(&domain->mm_list);
>
> return domain;
> }
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index da59c20c4f12..d5f21719a5a0 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -100,6 +100,20 @@ struct iommu_domain {
> void *handler_token;
> struct iommu_domain_geometry geometry;
> void *iova_cookie;
> +
> + struct list_head mm_list;
> +};
> +
> +struct io_mm {
> + int pasid;
> + /* IOMMU_SVA_FEAT_* */
> + unsigned long flags;
> + struct list_head devices;
> + struct kref kref;
> + struct mm_struct *mm;
> +
> + /* Release callback for this mm */
> + void (*release)(struct io_mm *io_mm);
> };
>
> enum iommu_cap {
> @@ -216,6 +230,7 @@ struct iommu_sva_param {
> unsigned long features;
> unsigned int min_pasid;
> unsigned int max_pasid;
> + struct list_head mm_list;
> };
>
> /**
> @@ -227,6 +242,11 @@ struct iommu_sva_param {
> * @detach_dev: detach device from an iommu domain
> * @sva_device_init: initialize Shared Virtual Adressing for a device
> * @sva_device_shutdown: shutdown Shared Virtual Adressing for a
> device
> + * @mm_alloc: allocate io_mm
> + * @mm_free: free io_mm
> + * @mm_attach: attach io_mm to a device. Install PASID entry if
> necessary
> + * @mm_detach: detach io_mm from a device. Remove PASID entry and
> + * flush associated TLB entries.
> * @map: map a physically contiguous memory region to an iommu domain
> * @unmap: unmap a physically contiguous memory region from an iommu
> domain
> * @map_sg: map a scatter-gather list of physically contiguous
> memory chunks @@ -268,6 +288,14 @@ struct iommu_ops {
> struct iommu_sva_param *param);
> void (*sva_device_shutdown)(struct device *dev,
> struct iommu_sva_param *param);
> + struct io_mm *(*mm_alloc)(struct iommu_domain *domain,
> + struct mm_struct *mm,
> + unsigned long flags);
> + void (*mm_free)(struct io_mm *io_mm);
> + int (*mm_attach)(struct iommu_domain *domain, struct device
> *dev,
> + struct io_mm *io_mm, bool attach_domain);
> + void (*mm_detach)(struct iommu_domain *domain, struct device
> *dev,
> + struct io_mm *io_mm, bool detach_domain);
> int (*map)(struct iommu_domain *domain, unsigned long iova,
> phys_addr_t paddr, size_t size, int prot);
> size_t (*unmap)(struct iommu_domain *domain, unsigned long
> iova,
[Jacob Pan]
^ permalink raw reply
* Re: [PATCH v4 4/4] drm/rockchip: support dp training outside dp firmware
From: Brian Norris @ 2018-05-16 23:28 UTC (permalink / raw)
To: Lin Huang
Cc: devicetree, airlied, dianders, linux-kernel, linux-rockchip,
robh+dt, dri-devel, zyw, daniel.vetter, linux-arm-kernel
In-Reply-To: <1526354560-23135-4-git-send-email-hl@rock-chips.com>
On Tue, May 15, 2018 at 11:22:40AM +0800, Lin Huang wrote:
> DP firmware uses fixed phy config values to do training, but some
> boards need to adjust these values to fit for their unique hardware
> design. So get phy config values from dts and use software link training
> instead of relying on firmware, if software training fail, keep firmware
> training as a fallback if sw training fails.
>
>
> Signed-off-by: Chris Zhong <zyw@rock-chips.com>
> Signed-off-by: Lin Huang <hl@rock-chips.com>
> ---
> Changes in v2:
> - update patch following Enric suggest
> Changes in v3:
> - use variable fw_training instead sw_training_success
> - base on DP SPCE, if training fail use lower link rate to retry training
> Changes in v4:
> - improve cdn_dp_get_lower_link_rate() and cdn_dp_software_train_link() follow Sean suggest
>
> drivers/gpu/drm/rockchip/Makefile | 3 +-
> drivers/gpu/drm/rockchip/cdn-dp-core.c | 24 +-
> drivers/gpu/drm/rockchip/cdn-dp-core.h | 2 +
> drivers/gpu/drm/rockchip/cdn-dp-link-training.c | 420 ++++++++++++++++++++++++
> drivers/gpu/drm/rockchip/cdn-dp-reg.c | 31 +-
> drivers/gpu/drm/rockchip/cdn-dp-reg.h | 38 ++-
> 6 files changed, 505 insertions(+), 13 deletions(-)
> create mode 100644 drivers/gpu/drm/rockchip/cdn-dp-link-training.c
Please rerun checkpatch next time. You've got a bunch of whitespace
issues in cdn_dp_get_lower_link_rate() and cdn_dp_software_train_link().
Brian
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: renesas: draak: Describe HDMI input
From: Niklas Söderlund @ 2018-05-16 22:23 UTC (permalink / raw)
To: Jacopo Mondi
Cc: laurent.pinchart, horms, geert, magnus.damm, robh+dt,
linux-renesas-soc, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <1526478129-16465-4-git-send-email-jacopo+renesas@jmondi.org>
Hi Jacopo,
Thanks for your patch.
On 2018-05-16 15:42:09 +0200, Jacopo Mondi wrote:
> Describe HDMI input connector and ADV7612 HDMI decoder installed on
> R-Car Gen3 Draak board.
>
> The video signal routing to the HDMI decoder to the video input interface
> VIN4 is multiplexed with CVBS input path, and enabled/disabled through
> on-board switches SW-49, SW-50, SW-51 and SW-52.
>
> As the default board switches configuration connects CVBS input to VIN4,
> leave the HDMI decoder unconnected in DTS.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
I'm not sure we have a policy about describing hardware which can't be
used without flipping switches. I have no opinion on if we should do
that or not I leave that to others, but for the change itself.
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
I think it's good we describe it as it's part of the Draak board itself
and not an expansion board which we have seen a lot of :-) Maybe even
add a commented out line in the adv7612 port@2 which hints which VIN
this is connected to if the switches are flipped?
> ---
> arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 38 ++++++++++++++++++++++++++
> 1 file changed, 38 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> index 9aba28f..ea99dc9 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> @@ -59,6 +59,17 @@
> };
> };
>
> + hdmi-in {
> + compatible = "hdmi-connector";
> + type = "a";
> +
> + port {
> + hdmi_con_in: endpoint {
> + remote-endpoint = <&adv7612_in>;
> + };
> + };
> + };
> +
> memory@48000000 {
> device_type = "memory";
> /* first 128MB is reserved for secure area. */
> @@ -170,6 +181,33 @@
> };
> };
> };
> +
> + hdmi-decoder@4c {
> + compatible = "adi,adv7612";
> + reg = <0x4c>;
> + default-input = <0>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + adv7612_in: endpoint {
> + remote-endpoint = <&hdmi_con_in>;
> + };
> + };
> +
> + port@2 {
> + reg = <2>;
> + adv7612_out: endpoint {
> + pclk-sample = <0>;
> + hsync-active = <0>;
> + vsync-active = <0>;
> + };
> + };
> + };
> + };
> };
>
> &i2c1 {
> --
> 2.7.4
>
--
Regards,
Niklas Söderlund
^ permalink raw reply
* Re: [PATCH v6 2/2] leds: lm3601x: Introduce the lm3601x LED driver
From: Andy Shevchenko @ 2018-05-16 22:19 UTC (permalink / raw)
To: Dan Murphy
Cc: Rob Herring, Mark Rutland, Jacek Anaszewski, Pavel Machek,
devicetree, Linux Kernel Mailing List, Linux LED Subsystem
In-Reply-To: <CAHp75Vd-cyR7zVofP7g+4Z1ouqawV+Rqp5s5BcDhpGiHheUgpg@mail.gmail.com>
On Thu, May 17, 2018 at 1:11 AM, Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Wed, May 16, 2018 at 11:43 PM, Dan Murphy <dmurphy@ti.com> wrote:
>> On 05/15/2018 05:24 PM, Andy Shevchenko wrote:
>>> On Wed, May 16, 2018 at 1:08 AM, Dan Murphy <dmurphy@ti.com> wrote:
>>>> On 05/15/2018 04:56 PM, Andy Shevchenko wrote:
>>>>>> +static const struct lm3601x_max_timeouts strobe_timeouts[] = {
>>>>>> + { 40000, 0x00 },
>>>>>> + { 80000, 0x01 },
>>>>>> + { 120000, 0x02 },
>>>>>> + { 160000, 0x03 },
>>>>>> + { 200000, 0x04 },
>>>>>> + { 240000, 0x05 },
>>>>>> + { 280000, 0x06 },
>>>>>> + { 320000, 0x07 },
>>>>>> + { 360000, 0x08 },
>>>>>> + { 400000, 0x09 },
>>>>>> + { 600000, 0x0a },
>>>>>> + { 800000, 0x0b },
>>>>>> + { 1000000, 0x0c },
>>>>>> + { 1200000, 0x0d },
>>>>>> + { 1400000, 0x0e },
>>>>>> + { 1600000, 0x0f },
>>> if (x < 9)
>>> strobe_timeout = (x + 1) * 40 * MSECS_IN_SEC;
>>> else
>>> strobe_timeout = (x - 7) * 200 * MSECS_IN_SEC;
>>
>> Not sure if this will produce the register value I am looking for. I have to run through the
>> algorithim. The idea is to take in the timeout and get the reg value to program.
>>
>> If it yields the expected output, or with a modified equation, then I can pull it in.
>
> So, you need a reversed calculus in this case.
>
> u8 regval;
>
> /* To make it in range... */
> timeout = clamp_val(timeout, 40000, 1600000);
> /* ...other possibility to issue an error */
>
> if (timeout >= 400000)
> regval = timeout / 200000 + 0x07;
> else
> regval = timeout / 40000 - 0x01;
Forgot to mention that there are also three approaches (considering
division here):
- round up
- round down
- round to closest
>
> In any case, please double check it gives a correct values.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v2 2/3] arm64: dts: renesas: draak: Describe CVBS input
From: Niklas Söderlund @ 2018-05-16 22:18 UTC (permalink / raw)
To: Jacopo Mondi
Cc: laurent.pinchart, horms, geert, magnus.damm, robh+dt,
linux-renesas-soc, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <1526478129-16465-3-git-send-email-jacopo+renesas@jmondi.org>
Hi Jacopo,
Thanks for your patch.
On 2018-05-16 15:42:08 +0200, Jacopo Mondi wrote:
> Describe CVBS video input through analog video decoder ADV7180
> connected to video input interface VIN4.
>
> The video input signal path is shared with HDMI video input, and
> selected by on-board switches SW-53 and SW-54 with CVBS input selected
> by the default switches configuration.
You are missing your SoB line :-)
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> ---
> arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 36 ++++++++++++++++++++++++++
> 1 file changed, 36 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> index d03f194..9aba28f 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> +++ b/arch/arm64/boot/dts/renesas/r8a77995-draak.dts
> @@ -142,6 +142,11 @@
> groups = "usb0";
> function = "usb0";
> };
> +
> + vin4_pins_cvbs: vin4 {
> + groups = "vin4_data8", "vin4_sync", "vin4_clk";
> + function = "vin4";
> + };
> };
>
> &i2c0 {
> @@ -154,6 +159,17 @@
> reg = <0x50>;
> pagesize = <8>;
> };
> +
> + analog-video@20 {
> + compatible = "adi,adv7180";
> + reg = <0x20>;
> +
> + port {
> + adv7180_out: endpoint {
> + remote-endpoint = <&vin4_in>;
> + };
> + };
> + };
> };
>
> &i2c1 {
> @@ -246,3 +262,23 @@
> timeout-sec = <60>;
> status = "okay";
> };
> +
> +&vin4 {
> + pinctrl-0 = <&vin4_pins_cvbs>;
> + pinctrl-names = "default";
> +
> + status = "okay";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + vin4_in: endpoint {
> + remote-endpoint = <&adv7180_out>;
> + };
> + };
> + };
> +};
> --
> 2.7.4
>
--
Regards,
Niklas Söderlund
^ permalink raw reply
* Re: [PATCH 6/6] ARM: dts: rcar-gen2: Add 'data-active' property
From: Niklas Söderlund @ 2018-05-16 22:15 UTC (permalink / raw)
To: Jacopo Mondi
Cc: devicetree, robh+dt, linux-renesas-soc, horms, geert,
laurent.pinchart, linux-arm-kernel, linux-media
In-Reply-To: <1526488352-898-7-git-send-email-jacopo+renesas@jmondi.org>
Hi Jacopo,
Thanks for your work.
On 2018-05-16 18:32:32 +0200, Jacopo Mondi wrote:
> The 'data-active' property needs to be specified when using embedded
> synchronization. Add it to the Gen-2 boards using composite video input.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> ---
> arch/arm/boot/dts/r8a7790-lager.dts | 1 +
> arch/arm/boot/dts/r8a7791-koelsch.dts | 1 +
> arch/arm/boot/dts/r8a7791-porter.dts | 1 +
> arch/arm/boot/dts/r8a7793-gose.dts | 1 +
> arch/arm/boot/dts/r8a7794-alt.dts | 1 +
> arch/arm/boot/dts/r8a7794-silk.dts | 1 +
> 6 files changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/r8a7790-lager.dts b/arch/arm/boot/dts/r8a7790-lager.dts
> index b56b309..48fcb44 100644
> --- a/arch/arm/boot/dts/r8a7790-lager.dts
> +++ b/arch/arm/boot/dts/r8a7790-lager.dts
> @@ -893,6 +893,7 @@
>
> vin1ep0: endpoint {
> remote-endpoint = <&adv7180>;
> + data-active = <1>;
> };
> };
> };
> diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts b/arch/arm/boot/dts/r8a7791-koelsch.dts
> index 9967666..fa0b25f 100644
> --- a/arch/arm/boot/dts/r8a7791-koelsch.dts
> +++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
> @@ -868,6 +868,7 @@
>
> vin1ep: endpoint {
> remote-endpoint = <&adv7180>;
> + data-active = <1>;
Depending on how we interpret the data-active property this can be good
or bad. But if we interpret it as the polarity of the VIn_CLKENB pin
this is not good as this is not connected for the adv7180 on Koelsch.
I have not checked all the Gen2 schematics as I'm still not sure how to
interpret the property.
> };
> };
> };
> diff --git a/arch/arm/boot/dts/r8a7791-porter.dts b/arch/arm/boot/dts/r8a7791-porter.dts
> index 055a7f1..96b9605 100644
> --- a/arch/arm/boot/dts/r8a7791-porter.dts
> +++ b/arch/arm/boot/dts/r8a7791-porter.dts
> @@ -391,6 +391,7 @@
>
> vin0ep: endpoint {
> remote-endpoint = <&adv7180>;
> + data-active = <1>;
> };
> };
> };
> diff --git a/arch/arm/boot/dts/r8a7793-gose.dts b/arch/arm/boot/dts/r8a7793-gose.dts
> index 9d3fba2..80b4fa8 100644
> --- a/arch/arm/boot/dts/r8a7793-gose.dts
> +++ b/arch/arm/boot/dts/r8a7793-gose.dts
> @@ -779,6 +779,7 @@
>
> vin1ep: endpoint {
> remote-endpoint = <&adv7180_out>;
> + data-active = <1>;
> };
> };
> };
> diff --git a/arch/arm/boot/dts/r8a7794-alt.dts b/arch/arm/boot/dts/r8a7794-alt.dts
> index 4bbb9cc..00df605d 100644
> --- a/arch/arm/boot/dts/r8a7794-alt.dts
> +++ b/arch/arm/boot/dts/r8a7794-alt.dts
> @@ -380,6 +380,7 @@
>
> vin0ep: endpoint {
> remote-endpoint = <&adv7180>;
> + data-active = <1>;
> };
> };
> };
> diff --git a/arch/arm/boot/dts/r8a7794-silk.dts b/arch/arm/boot/dts/r8a7794-silk.dts
> index c0c5d31..ed17376 100644
> --- a/arch/arm/boot/dts/r8a7794-silk.dts
> +++ b/arch/arm/boot/dts/r8a7794-silk.dts
> @@ -480,6 +480,7 @@
>
> vin0ep: endpoint {
> remote-endpoint = <&adv7180>;
> + data-active = <1>;
> };
> };
> };
> --
> 2.7.4
>
--
Regards,
Niklas Söderlund
^ permalink raw reply
* Re: [PATCH 5/6] ARM: dts: rcar-gen2: Remove unused VIN properties
From: Niklas Söderlund @ 2018-05-16 22:13 UTC (permalink / raw)
To: Jacopo Mondi
Cc: devicetree, robh+dt, linux-renesas-soc, horms, geert,
laurent.pinchart, linux-arm-kernel, linux-media
In-Reply-To: <1526488352-898-6-git-send-email-jacopo+renesas@jmondi.org>
Hi Jacopo,
Thanks for your work.
On 2018-05-16 18:32:31 +0200, Jacopo Mondi wrote:
> The 'bus-width' and 'pclk-sample' properties are not parsed by the VIN
> driver and only confuse users. Remove them in all Gen2 SoC that used
> them.
>
> Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org>
> ---
> arch/arm/boot/dts/r8a7790-lager.dts | 3 ---
> arch/arm/boot/dts/r8a7791-koelsch.dts | 3 ---
> arch/arm/boot/dts/r8a7791-porter.dts | 1 -
> arch/arm/boot/dts/r8a7793-gose.dts | 3 ---
> arch/arm/boot/dts/r8a7794-alt.dts | 1 -
> arch/arm/boot/dts/r8a7794-silk.dts | 1 -
> 6 files changed, 12 deletions(-)
>
> diff --git a/arch/arm/boot/dts/r8a7790-lager.dts b/arch/arm/boot/dts/r8a7790-lager.dts
> index 063fdb6..b56b309 100644
> --- a/arch/arm/boot/dts/r8a7790-lager.dts
> +++ b/arch/arm/boot/dts/r8a7790-lager.dts
> @@ -873,10 +873,8 @@
> port {
> vin0ep2: endpoint {
> remote-endpoint = <&adv7612_out>;
> - bus-width = <24>;
I can't really make up my mind if this is a good thing or not. Device
tree describes the hardware and not what the drivers make use of. And
the fact is that this bus is 24 bits wide. So I'm not sure we should
remove these properties. But I would love to hear what others think
about this.
> hsync-active = <0>;
> vsync-active = <0>;
> - pclk-sample = <1>;
> data-active = <1>;
> };
> };
> @@ -895,7 +893,6 @@
>
> vin1ep0: endpoint {
> remote-endpoint = <&adv7180>;
> - bus-width = <8>;
> };
> };
> };
> diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts b/arch/arm/boot/dts/r8a7791-koelsch.dts
> index f40321a..9967666 100644
> --- a/arch/arm/boot/dts/r8a7791-koelsch.dts
> +++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
> @@ -849,10 +849,8 @@
>
> vin0ep2: endpoint {
> remote-endpoint = <&adv7612_out>;
> - bus-width = <24>;
> hsync-active = <0>;
> vsync-active = <0>;
> - pclk-sample = <1>;
> data-active = <1>;
> };
> };
> @@ -870,7 +868,6 @@
>
> vin1ep: endpoint {
> remote-endpoint = <&adv7180>;
> - bus-width = <8>;
> };
> };
> };
> diff --git a/arch/arm/boot/dts/r8a7791-porter.dts b/arch/arm/boot/dts/r8a7791-porter.dts
> index c14e6fe..055a7f1 100644
> --- a/arch/arm/boot/dts/r8a7791-porter.dts
> +++ b/arch/arm/boot/dts/r8a7791-porter.dts
> @@ -391,7 +391,6 @@
>
> vin0ep: endpoint {
> remote-endpoint = <&adv7180>;
> - bus-width = <8>;
> };
> };
> };
> diff --git a/arch/arm/boot/dts/r8a7793-gose.dts b/arch/arm/boot/dts/r8a7793-gose.dts
> index 9ed6961..9d3fba2 100644
> --- a/arch/arm/boot/dts/r8a7793-gose.dts
> +++ b/arch/arm/boot/dts/r8a7793-gose.dts
> @@ -759,10 +759,8 @@
>
> vin0ep2: endpoint {
> remote-endpoint = <&adv7612_out>;
> - bus-width = <24>;
> hsync-active = <0>;
> vsync-active = <0>;
> - pclk-sample = <1>;
> data-active = <1>;
> };
> };
> @@ -781,7 +779,6 @@
>
> vin1ep: endpoint {
> remote-endpoint = <&adv7180_out>;
> - bus-width = <8>;
> };
> };
> };
> diff --git a/arch/arm/boot/dts/r8a7794-alt.dts b/arch/arm/boot/dts/r8a7794-alt.dts
> index 26a8834..4bbb9cc 100644
> --- a/arch/arm/boot/dts/r8a7794-alt.dts
> +++ b/arch/arm/boot/dts/r8a7794-alt.dts
> @@ -380,7 +380,6 @@
>
> vin0ep: endpoint {
> remote-endpoint = <&adv7180>;
> - bus-width = <8>;
> };
> };
> };
> diff --git a/arch/arm/boot/dts/r8a7794-silk.dts b/arch/arm/boot/dts/r8a7794-silk.dts
> index 351cb3b..c0c5d31 100644
> --- a/arch/arm/boot/dts/r8a7794-silk.dts
> +++ b/arch/arm/boot/dts/r8a7794-silk.dts
> @@ -480,7 +480,6 @@
>
> vin0ep: endpoint {
> remote-endpoint = <&adv7180>;
> - bus-width = <8>;
> };
> };
> };
> --
> 2.7.4
>
--
Regards,
Niklas Söderlund
^ 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