* [PATCH v4 1/5] dt-bindings: Document the STM32 I2C bindings
From: M'boumba Cedric Madianga @ 2016-12-07 16:51 UTC (permalink / raw)
To: wsa, robh+dt, mcoquelin.stm32, alexandre.torgue, linus.walleij,
patrice.chotard, linux, linux-i2c, devicetree, linux-arm-kernel,
linux-kernel
Cc: M'boumba Cedric Madianga
In-Reply-To: <1481129492-26600-1-git-send-email-cedric.madianga@gmail.com>
This patch adds documentation of device tree bindings for the STM32 I2C
controller.
Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/i2c/i2c-stm32.txt | 33 ++++++++++++++++++++++
1 file changed, 33 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-stm32.txt
diff --git a/Documentation/devicetree/bindings/i2c/i2c-stm32.txt b/Documentation/devicetree/bindings/i2c/i2c-stm32.txt
new file mode 100644
index 0000000..78eaf7b
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-stm32.txt
@@ -0,0 +1,33 @@
+* I2C controller embedded in STMicroelectronics STM32 I2C platform
+
+Required properties :
+- compatible : Must be "st,stm32f4-i2c"
+- reg : Offset and length of the register set for the device
+- interrupts : Must contain the interrupt id for I2C event and then the
+ interrupt id for I2C error.
+- resets: Must contain the phandle to the reset controller.
+- clocks: Must contain the input clock of the I2C instance.
+- A pinctrl state named "default" must be defined to set pins in mode of
+ operation for I2C transfer
+- #address-cells = <1>;
+- #size-cells = <0>;
+
+Optional properties :
+- clock-frequency : Desired I2C bus clock frequency in Hz. If not specified,
+ the default 100 kHz frequency will be used. As only Normal and Fast modes
+ are supported, possible values are 100000 and 400000.
+
+Example :
+
+ i2c@40005400 {
+ compatible = "st,stm32f4-i2c";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x40005400 0x400>;
+ interrupts = <31>,
+ <32>;
+ resets = <&rcc 277>;
+ clocks = <&rcc 0 149>;
+ pinctrl-0 = <&i2c1_sda_pin>, <&i2c1_scl_pin>;
+ pinctrl-names = "default";
+ };
--
1.9.1
^ permalink raw reply related
* [PATCH v4 0/5] Add support for the STM32F4 I2C
From: M'boumba Cedric Madianga @ 2016-12-07 16:51 UTC (permalink / raw)
To: wsa, robh+dt, mcoquelin.stm32, alexandre.torgue, linus.walleij,
patrice.chotard, linux, linux-i2c, devicetree, linux-arm-kernel,
linux-kernel
Cc: M'boumba Cedric Madianga
This patchset adds support for the I2C controller embedded in STM32F4xx SoC.
It enables I2C transfer in interrupt mode with Standard-mode and Fast-mode bus
speed.
Changes since v3 after Wolfram's review:
- Add COMPILE_TEST flag in Kconfig
- Use correct driver name in Kconfig i.e i2c-stm32f4 instead of i2c-st
- Use more comprehensible name stm32f4_i2c_msg for client specific data
- Don't store reset control node as just needed in probe
- Use clamp() function to test value between 2 ranges
- Use new "i2c_8bit_addr_from_msg() function to build I2C address
- Don't write error messages for timeout
- Remove error message when i2c_add_adapter() fails as it is already handled by
the i2c core driver
M'boumba Cedric Madianga (5):
dt-bindings: Document the STM32 I2C bindings
i2c: Add STM32F4 I2C driver
ARM: dts: Add I2C1 support for STM32F429 SoC
ARM: dts: Add I2C1 support for STM32429 eval board
ARM: configs: Add I2C support for STM32 defconfig
.../devicetree/bindings/i2c/i2c-stm32.txt | 33 +
arch/arm/boot/dts/stm32429i-eval.dts | 6 +
arch/arm/boot/dts/stm32f429.dtsi | 23 +
arch/arm/configs/stm32_defconfig | 3 +
drivers/i2c/busses/Kconfig | 10 +
drivers/i2c/busses/Makefile | 1 +
drivers/i2c/busses/i2c-stm32f4.c | 857 +++++++++++++++++++++
7 files changed, 933 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-stm32.txt
create mode 100644 drivers/i2c/busses/i2c-stm32f4.c
--
1.9.1
^ permalink raw reply
* [PATCH v2 00/10] perf: arm64: Support for Hisilicon SoC Hardware event counters
From: Anurup M @ 2016-12-07 16:50 UTC (permalink / raw)
To: robh+dt, gregkh, catalin.marinas, arnd, geert+renesas, davem,
akpm, corbet, mark.rutland, will.deacon
Cc: linux-kernel, devicetree, linux-arm-kernel, anurup.m,
zhangshaokun, tanxiaojun, xuwei5, sanil.kumar, john.garry,
gabriele.paoloni, shiju.jose, wangkefeng.wang, linuxarm, shyju.pv,
anurupvasu
From: John Garry <john.garry@huawei.com>
Provide Support for Hisilicon SoC(HiP05/06/07) Hardware event counters.
The Hisilicon SoC HiP0x series has many uncore or non-CPU performance
events and counters units.
This patch series is implemented refering to arm-cci, Intel/AMD uncore and
also the cavium thunderX and xgene uncore pmu patches.
This v2 version has addressed the review comments of v1 version.
Support for Hisilicon L3 cache(L3C) and Misclennaneous nodes(MN) hardware
events and counters are added in this implementation.
The Hisilicon uncore PMUs can be found under /sys/bus/event_source/devices.
The counters are exported via sysfs in the corresponding events files
under the PMU directory so the perf tool can list the event names.
ToDo:
1) The counter overflow handling is currently unsupported in this
patch series.
2) ACPI support.
Version history
---------------
v2
--
- Fix review comments of v2 version.
- Move djtag driver to drivers/perf/hisilicon.
- Have separate PMU instance for each L3 cache banks.
- Modify device properties in DTS as per review comments.
- Handle hardware version difference.
- Change compatible names of djtag so use prefix hisi-
and remove chip version as driver only depend on djtag
hw version.
- use devm_kzalloc.
- Remove DDRC changes in this series. As the DDRC PMU doesnot
depend on djtag it will be send separately.
v1
--
-Initial version with support for L3C, MN and DDRC event counters
-Djtag driver is used to access registers of L3 cache and MN.
Anurup M (7):
arm64: MAINTAINERS: hisi: Add hisilicon SoC PMU support
dt-bindings: perf: hisi: Add Devicetree bindings for Hisilicon SoC PMU
Documentation: perf: hisi: Documentation for HIP05/06/07 PMU event
counting.
perf: hisi: Update Kconfig for Hisilicon PMU support
perf: hisi: Add support for Hisilicon SoC event counters
perf: hisi: Add sysfs attributes for L3 cache(L3C) PMU
dts: arm64: hip06: Add Hisilicon SoC PMU support
Shaokun Zhang (1):
perf: hisi: Miscellanous node(MN) event counting in perf
Tan Xiaojun (2):
dt-bindings: hisi: Add Hisilicon HiP05/06/07 Djtag dts bindings
drivers: perf: hisi: Add support for Hisilicon Djtag driver
.../devicetree/bindings/arm/hisilicon/djtag.txt | 66 ++
.../devicetree/bindings/arm/hisilicon/pmu.txt | 98 +++
Documentation/perf/hisi-pmu.txt | 75 +++
MAINTAINERS | 9 +
arch/arm64/boot/dts/hisilicon/hip06.dtsi | 78 +++
drivers/perf/Kconfig | 8 +
drivers/perf/Makefile | 1 +
drivers/perf/hisilicon/Makefile | 1 +
drivers/perf/hisilicon/djtag.c | 729 +++++++++++++++++++++
drivers/perf/hisilicon/djtag.h | 39 ++
drivers/perf/hisilicon/hisi_uncore_l3c.c | 629 ++++++++++++++++++
drivers/perf/hisilicon/hisi_uncore_mn.c | 516 +++++++++++++++
drivers/perf/hisilicon/hisi_uncore_pmu.c | 365 +++++++++++
drivers/perf/hisilicon/hisi_uncore_pmu.h | 128 ++++
14 files changed, 2742 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/djtag.txt
create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
create mode 100644 Documentation/perf/hisi-pmu.txt
create mode 100644 drivers/perf/hisilicon/Makefile
create mode 100644 drivers/perf/hisilicon/djtag.c
create mode 100644 drivers/perf/hisilicon/djtag.h
create mode 100644 drivers/perf/hisilicon/hisi_uncore_l3c.c
create mode 100644 drivers/perf/hisilicon/hisi_uncore_mn.c
create mode 100644 drivers/perf/hisilicon/hisi_uncore_pmu.c
create mode 100644 drivers/perf/hisilicon/hisi_uncore_pmu.h
--
2.1.4
^ permalink raw reply
* Re: [PATCH 8/9] arm64: dts: rockchip: partially describe PWM regulators for Gru
From: Heiko Stuebner @ 2016-12-07 16:48 UTC (permalink / raw)
To: Brian Norris
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Doug Anderson,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring,
Chris Zhong, Stephen Barber,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Caesar Wang
In-Reply-To: <1480645653-36943-9-git-send-email-briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Hi Brian,
Am Donnerstag, 1. Dezember 2016, 18:27:32 CET schrieb Brian Norris:
> We need to add regulators to the CPU nodes, so cpufreq doesn't think it
> can crank up the clock speed without changing the voltage. However, we
> don't yet have the DT bindings to fully describe the Over Voltage
> Protection (OVP) circuits on these boards. Without that description, we
> might end up changing the voltage too much, too fast.
>
> Add the pwm-regulator descriptions and associate the CPU OPPs, but leave
> them disabled.
>
> Signed-off-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
is there a specific reason for keeping this change separate?
While it is nice for documentation reasons, as it stands now the previous
patch introduces a regression (cpufreq trying to scale without regulators) and
immediately fixes it here.
So if you're ok with it, I'd like to merge this one back into the previous
patch when applying.
Heiko
^ permalink raw reply
* Re: [PATCH net-next v2] dsa:mv88e6xxx: dispose irq mapping for chip->irq
From: Volodymyr Bendiuga @ 2016-12-07 16:40 UTC (permalink / raw)
To: Andrew Lunn
Cc: vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, netdev-u79uwXL29TY76Z2rM5mHXA,
volodymyr.bendiuga-Re5JQEeQqe8AvxtiuMwx3w, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161207141144.GJ18817-g2DYL2Zd6BY@public.gmane.org>
Yes, most of the users of of_irq_get() do not use irq_dispose_mapping().
But some of them do (some irq chips), and I believe the correct way of
doing this is to
dispose irq mapping, as the description for this function says that it
unmaps
the irq, which is mapped by of_irq_parse_and_map(). Not disposing irq
might not make
any affect on most drivers, but some, that get EPROBE_DEFER error do
need to dispose.
This is what I get when I run the code.
of_irq_put() could be implemented, and it would be a wrapper for
irq_dispose_mapping()
as I can see it. Should I do it this way?
On 2016-12-07 15:11, Andrew Lunn wrote:
> On Wed, Dec 07, 2016 at 11:35:07AM +0100, Volodymyr Bendiuga wrote:
>> Signed-off-by: Volodymyr Bendiuga <volodymyr.bendiuga-qeDNsGSBLoYwFerOooGFRg@public.gmane.org>
> You need some text in the Change log. Say why this change is needed,
> etc.
>
> Looking through other users of of_irq_get(), i don't see any disposing
> of the mapping. It is not obvious you need to do this. The name does
> not give any hint.
>
> Maybe we should add an of_irq_put() which would clean up the mapping?
>
> Andrew
>
>
>> ---
>> drivers/net/dsa/mv88e6xxx/chip.c | 6 +++++-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c
>> index 173ea97..0c3271d 100644
>> --- a/drivers/net/dsa/mv88e6xxx/chip.c
>> +++ b/drivers/net/dsa/mv88e6xxx/chip.c
>> @@ -4483,7 +4483,7 @@ static int mv88e6xxx_probe(struct mdio_device *mdiodev)
>> mutex_unlock(&chip->reg_lock);
>>
>> if (err)
>> - goto out;
>> + goto out_dispose;
>>
>> if (mv88e6xxx_has(chip, MV88E6XXX_FLAG_G2_INT)) {
>> err = mv88e6xxx_g2_irq_setup(chip);
>> @@ -4513,6 +4513,9 @@ static int mv88e6xxx_probe(struct mdio_device *mdiodev)
>> mv88e6xxx_g1_irq_free(chip);
>> mutex_unlock(&chip->reg_lock);
>> }
>> +
>> +out_dispose:
>> + irq_dispose_mapping(chip->irq);
>> out:
>> return err;
>> }
>> @@ -4530,6 +4533,7 @@ static void mv88e6xxx_remove(struct mdio_device *mdiodev)
>> if (mv88e6xxx_has(chip, MV88E6XXX_FLAG_G2_INT))
>> mv88e6xxx_g2_irq_free(chip);
>> mv88e6xxx_g1_irq_free(chip);
>> + irq_dispose_mapping(chip->irq);
>> }
>> }
>>
>> --
>> 2.7.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
* Re: [PATCH v3 2/5] spi: armada-3700: Add support for the FIFO mode
From: Mark Brown @ 2016-12-07 16:34 UTC (permalink / raw)
To: Romain Perier
Cc: linux-spi-u79uwXL29TY76Z2rM5mHXA, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Nadav Haklai, xigu-eYqpPyKDWXRBDgjK7y7TUQ,
dingwei-eYqpPyKDWXRBDgjK7y7TUQ
In-Reply-To: <a9b86043-b631-8154-edc8-5abe49e47114-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1329 bytes --]
On Wed, Dec 07, 2016 at 05:19:57PM +0100, Romain Perier wrote:
> Le 05/12/2016 à 14:37, Mark Brown a écrit :
> > Why? If the hardware supports a more efficient mode of operation it
> > doesn't seem sensible not to use it.
> That's just that our customer want to keep both modes, this is why I decided
> to use the more efficient mode by default and disable it via a module
> parameter. Previously the more efficient mode was always enabled, based on
> the "compatible string" of the DT (the PIO mode was simply useless in this
> case and dead code)
Keep that out of tree, if the user wants to do silly things then let
them pay the cost.
> > > + if (xfer->rx_buf) {
> > > + /* Set read data length */
> > > + spireg_write(a3700_spi, A3700_SPI_IF_DIN_CNT_REG,
> > > + a3700_spi->buf_len);
> > > + /* Start READ transfer */
> > > + val = spireg_read(a3700_spi, A3700_SPI_IF_CFG_REG);
> > > + val &= ~A3700_SPI_RW_EN;
> > > + val |= A3700_SPI_XFER_START;
> > > + spireg_write(a3700_spi, A3700_SPI_IF_CFG_REG, val);
> > > + } else if (xfer->tx_buf) {
> > > + /* Start Write transfer */
> > So this only supports single duplex transfers but there doesn't seem to
> > be anything that enforces this.
> A flag or a capability, typically? I will investigate
SPI_MASTER_HALF_DUPLEX.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] i2c: rk3x: keep i2c irq ON in suspend
From: Grygorii Strashko @ 2016-12-07 16:27 UTC (permalink / raw)
To: David.Wu, Doug Anderson
Cc: Heiko Stuebner, Wolfram Sang,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
open list:ARM/Rockchip SoC...,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <a6694d7d-6fca-e5ef-7bbd-9956562132a2-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
On 12/06/2016 09:37 PM, David.Wu wrote:
> Hi Doug,
>
> 在 2016/12/7 0:31, Doug Anderson 写道:
>> Hi,
>>
>> On Tue, Dec 6, 2016 at 12:12 AM, David.Wu <david.wu-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
>> wrote:
>>> Hi Heiko,
>>>
>>> 在 2016/12/5 18:54, Heiko Stuebner 写道:
>>>>
>>>> Hi David,
>>>>
>>>> Am Montag, 5. Dezember 2016, 16:02:59 CET schrieb David Wu:
>>>>>
>>>>> During suspend there may still be some i2c access happening.
>>>>> And if we don't keep i2c irq ON, there may be i2c access timeout if
>>>>> i2c is in irq mode of operation.
>>>>
>>>>
>>>> can you describe the issue you're trying to fix a bit more please?
>>>
>>>
>>> Sometimes we could see the i2c timeout errors during suspend/resume,
>>> which
>>> makes the duration of suspend/resume too longer.
>>>
>>> [ 484.171541] CPU4: Booted secondary processor [410fd082]
>>> [ 485.172777] rk3x-i2c ff3c0000.i2c: timeout, ipd: 0x10, state: 1
>>> [ 486.172760] rk3x-i2c ff3c0000.i2c: timeout, ipd: 0x10, state: 1
>>> [ 487.172759] rk3x-i2c ff3c0000.i2c: timeout, ipd: 0x10, state: 1
>>> [ 487.172840] cpu cpu4: _set_opp_voltage: failed to set voltage (800000
>>> 800000 800000 mV): -110
>>> [ 487.172874] cpu cpu4: failed to set volt 800000
>>>
>>>>
>>>> I.e. I'd think the i2c-core does suspend i2c-client devices first,
>>>> so that
>>>> these should be able to finish up their ongoing transfers and not start
>>>> any
>>>> new ones instead?
>>>>
>>>> Your irq can still happen slightly after the system started going to
>>>> actually
>>>> sleep, so to me it looks like you just widened the window where irqs
>>>> can
>>>> be
>>>> handled. Especially as your irq could also just simply stem from the
>>>> start
>>>> state, so you cannot even be sure if your transaction actually is
>>>> finished.
>>>
>>>
>>> Okay, you are right. I want to give it a double insurance at first,
>>> but it
>>> may hide the unhappend issue.
>>>
>>>>
>>>> So to me it looks like the i2c-connected device driver should be fixed
>>>> instead?
>>>
>>>
>>> I tell them to fix it in rk808 driver.
>>
>> To me it seems like perhaps cpufreq should not be changing frequencies
>> until it is resumed properly. Presumably if all the ordering is done
>> right then cpufreq should be resumed _after_ the i2c regulator so you
>> should be OK. ...or am I somehow confused about that?
>
> yes，the cpufreq and regulator should start i2c job after they resume
> properly.
>
>>
>> Also note that previous i2c busses I worked with simply returned -EIO
>> in the case where they were called when suspended. See
>> "i2c-exynos5.c" and "i2c-s3c2410.c".
>
> In "i2c-exynos5.c", it seems that using the "i2c->suspended" to protect
> i2c transfer works most of the time. Of course it could prevent the next
> new i2c transfer to start. But in one case, if the current i2c job was
> not finished until the i2c irq was disabled by system suspend, the i2c
> timeout error would also happen, as the current i2c job may have a large
> data to transfer and it lasts from a long time.
And this means you have bug in some of I2C client drivers which do not stop
their activities during suspend properly (most usual case - driver uses work
and this work still active during suspend and can run on one CPU while suspend
runs on another).
At the moment .suspend_noirq() callback is called there should be no active
I2C transactions in general.
>
> So is it necessary to add a mutex lock to wait the current job to be
> finished before the "i2c->suspended" is changed in i2c_suspend_noirq()?
>
You need to catch and fix all driver who will try to access I2C after your
I2C bus driver passes suspend_noirq stage. Smth, like [1], uses i2c_lock_adapter().
[1] https://git.ti.com/android-sdk/kernel-omap/commit/125ef8f7016e7b205886f93862288a45a312b1d8
--
regards,
-grygorii
--
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/5] spi: armada-3700: Add support for the FIFO mode
From: Romain Perier @ 2016-12-07 16:19 UTC (permalink / raw)
To: Mark Brown
Cc: linux-spi-u79uwXL29TY76Z2rM5mHXA, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Nadav Haklai, xigu-eYqpPyKDWXRBDgjK7y7TUQ,
dingwei-eYqpPyKDWXRBDgjK7y7TUQ
In-Reply-To: <20161205133728.sza2pt4tfkywu35k-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
Hello,
Le 05/12/2016 à 14:37, Mark Brown a écrit :
> On Thu, Dec 01, 2016 at 11:27:16AM +0100, Romain Perier wrote:
>
>> Changes in v3:
>> - Don't enable the fifo mode based on the compatible string, we introduce
>> a module parameter "pio_mode". By default this option is set to zero, so
>> the fifo mode is enabled. Pass pio_mode=1 to the driver enables the PIO
>> mode.
>
> Why? If the hardware supports a more efficient mode of operation it
> doesn't seem sensible not to use it.
That's just that our customer want to keep both modes, this is why I
decided to use the more efficient mode by default and disable it via a
module parameter. Previously the more efficient mode was always enabled,
based on the "compatible string" of the DT (the PIO mode was simply
useless in this case and dead code)
>
>> - int i;
>> + int i, ret = 0;
>
> Coding style - don't combine initialized and non-initalized variables on
> one line.
Ok
>
>> static int a3700_spi_transfer_one(struct spi_master *master,
>> struct spi_device *spi,
>> struct spi_transfer *xfer)
>> {
>> struct a3700_spi *a3700_spi = spi_master_get_devdata(master);
>> - int ret = 0;
>> + int ret;
>>
>> a3700_spi_transfer_setup(spi, xfer);
>>
>> @@ -505,6 +737,151 @@ static int a3700_spi_transfer_one(struct spi_master *master,
>> return ret;
>> }
>
> This appears to be a random unrelated change, should probably be part of
> the initial driver commit.
Good catch
>
>> +static int a3700_spi_fifo_transfer_one(struct spi_master *master,
>> + struct spi_device *spi,
>> + struct spi_transfer *xfer)
>> +{
>> + struct a3700_spi *a3700_spi = spi_master_get_devdata(master);
>> + int ret = 0, timeout = A3700_SPI_TIMEOUT;
>> + unsigned int nbits = 0;
>> + u32 val;
>> +
>> + a3700_spi_transfer_setup(spi, xfer);
>> +
>> + a3700_spi->tx_buf = xfer->tx_buf;
>> + a3700_spi->rx_buf = xfer->rx_buf;
>> + a3700_spi->buf_len = xfer->len;
>> +
>> + /* SPI transfer headers */
>> + a3700_spi_header_set(a3700_spi);
>> +
>> + if (xfer->tx_buf)
>> + nbits = xfer->tx_nbits;
>> + else if (xfer->rx_buf)
>> + nbits = xfer->rx_nbits;
>> +
>> + a3700_spi_pin_mode_set(a3700_spi, nbits);
>> +
>> + if (xfer->rx_buf) {
>> + /* Set read data length */
>> + spireg_write(a3700_spi, A3700_SPI_IF_DIN_CNT_REG,
>> + a3700_spi->buf_len);
>> + /* Start READ transfer */
>> + val = spireg_read(a3700_spi, A3700_SPI_IF_CFG_REG);
>> + val &= ~A3700_SPI_RW_EN;
>> + val |= A3700_SPI_XFER_START;
>> + spireg_write(a3700_spi, A3700_SPI_IF_CFG_REG, val);
>> + } else if (xfer->tx_buf) {
>> + /* Start Write transfer */
>
> So this only supports single duplex transfers but there doesn't seem to
> be anything that enforces this.
>
A flag or a capability, typically? I will investigate
Thanks,
Romain
--
Romain Perier, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 00/13] net: ethernet: ti: cpts: update and fixes
From: David Miller @ 2016-12-07 16:14 UTC (permalink / raw)
To: grygorii.strashko
Cc: netdev, mugunthanvnm, richardcochran, nsekhar, linux-kernel,
linux-omap, devicetree, m-karicheri2, w-kwok2, tglx
In-Reply-To: <20161207000045.28333-1-grygorii.strashko@ti.com>
From: Grygorii Strashko <grygorii.strashko@ti.com>
Date: Tue, 6 Dec 2016 18:00:32 -0600
> It is preparation series intended to clean up and optimize TI CPTS driver to
> facilitate further integration with other TI's SoCs like Keystone 2.
...
Series applied.
^ permalink raw reply
* Re: [PATCH v4 1/4] [media] davinci: vpif_capture: don't lock over s_stream
From: Kevin Hilman @ 2016-12-07 16:06 UTC (permalink / raw)
To: Laurent Pinchart
Cc: linux-media-u79uwXL29TY76Z2rM5mHXA, Hans Verkuil, Sakari Ailus,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Sekhar Nori,
Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4999781.kd7ueUSsQd@avalon>
Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org> writes:
> Hi Kevin,
>
> On Tuesday 06 Dec 2016 08:49:38 Kevin Hilman wrote:
>> Laurent Pinchart writes:
>> > On Tuesday 29 Nov 2016 15:57:09 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-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>> >> ---
>> >> drivers/media/platform/davinci/vpif_capture.c | 3 +++
>> >> 1 file changed, 3 insertions(+)
>> >>
>> >> diff --git a/drivers/media/platform/davinci/vpif_capture.c
>> >> b/drivers/media/platform/davinci/vpif_capture.c index
>> >> 5104cc0ee40e..9f8f41c0f251 100644
>> >> --- a/drivers/media/platform/davinci/vpif_capture.c
>> >> +++ b/drivers/media/platform/davinci/vpif_capture.c
>> >> @@ -193,7 +193,10 @@ 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);
>> >> + spin_lock_irqsave(&common->irqlock, flags);
>> >
>> > I always get anxious when I see a spinlock being released randomly with an
>> > operation in the middle of a protected section. Looking at the code it
>> > looks like the spinlock is abused here. irqlock should only protect the
>> > dma_queue and should thus only be taken around the following code:
>> >
>> > spin_lock_irqsave(&common->irqlock, flags);
>> > /* Get the next frame from the buffer queue */
>> > common->cur_frm = common->next_frm = list_entry(common->dma_queue.next,
>> > struct vpif_cap_buffer, list);
>> >
>> > /* Remove buffer from the buffer queue */
>> > list_del(&common->cur_frm->list);
>> > spin_unlock_irqrestore(&common->irqlock, flags);
>>
>> Yes, that looks correct. Will update.
>>
>> > The code that is currently protected by the lock in the start and stop
>> > streaming functions should be protected by a mutex instead.
>>
>> I tried taking the mutex here, but lockdep pointed out a deadlock. I
>> may not be fully understanding the V4L2 internals here, but it seems
>> that the ioctl is already taking a mutex, so taking it again in
>> start/stop streaming is a deadlock. Unless you think the locking should
>> be nested here, it seems to me that the mutex isn't needed.
>
> The V4L2 core can lock all ioctls using struct video_device::lock. For buffer-
> related ioctls, it can optionally use a separate lock from struct
> vb2_queue::lock. See v4l2_ioctl_get_lock() in drivers/media/v4l2-core/v4l2-
> ioctl.c.
>
> The vpif-capture driver sets both the video_device and vb2_queue locks to the
> same lock (which would have the same effect as leaving the vb2_queue lock
> NULL). All ioctls are thus serialized. You would only need to handle locking
> in start_streaming and stop_streaming manually if you didn't rely on the core
> serializing the ioctls.
OK, thanks for clarifying how that works.
Kevin
--
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 2/3] crypto: brcm: Add Broadcom SPU driver
From: Rob (William) Rice @ 2016-12-07 15:49 UTC (permalink / raw)
To: Mark Rutland
Cc: Herbert Xu, David S. Miller, Rob Herring, linux-crypto,
devicetree, linux-kernel, Ray Jui, Scott Branden, Jon Mason,
bcm-kernel-feedback-list, Catalin Marinas, Will Deacon,
linux-arm-kernel, Steve Lin
In-Reply-To: <20161206141826.GC24177@leverpostej>
Mark,
Thanks for the comments. Replies below.
Rob
On 12/6/2016 9:18 AM, Mark Rutland wrote:
> On Wed, Nov 30, 2016 at 03:07:32PM -0500, Rob Rice wrote:
>> +static const struct of_device_id bcm_spu_dt_ids[] = {
>> + {
>> + .compatible = "brcm,spum-crypto",
>> + .data = &spum_ns2_types,
>> + },
>> + {
>> + .compatible = "brcm,spum-nsp-crypto",
>> + .data = &spum_nsp_types,
>> + },
>> + {
>> + .compatible = "brcm,spu2-crypto",
>> + .data = &spu2_types,
>> + },
>> + {
>> + .compatible = "brcm,spu2-v2-crypto",
>> + .data = &spu2_v2_types,
>> + },
> These last two weren't in the binding document.
yes, I'll add them.
>
>> + { /* sentinel */ }
>> +};
>> +
>> +MODULE_DEVICE_TABLE(of, bcm_spu_dt_ids);
>> +
>> +static int spu_dt_read(struct platform_device *pdev)
>> +{
>> + struct device *dev = &pdev->dev;
>> + struct spu_hw *spu = &iproc_priv.spu;
>> + struct device_node *dn = pdev->dev.of_node;
>> + struct resource *spu_ctrl_regs;
>> + const struct of_device_id *match;
>> + struct spu_type_subtype *matched_spu_type;
>> + void __iomem *spu_reg_vbase[MAX_SPUS];
>> + int i;
>> + int err;
>> +
>> + if (!of_device_is_available(dn)) {
>> + dev_crit(dev, "SPU device not available");
>> + return -ENODEV;
>> + }
> How can this happen?
You are correct. This is unnecessary. I will remove.
>
>> + /* Count number of mailbox channels */
>> + spu->num_chan = of_count_phandle_with_args(dn, "mboxes", "#mbox-cells");
>> + dev_dbg(dev, "Device has %d SPU channels", spu->num_chan);
>> +
>> + match = of_match_device(of_match_ptr(bcm_spu_dt_ids), dev);
>> + matched_spu_type = (struct spu_type_subtype *)match->data;
> This cast usn't necessary.
Ok, will remove.
>
>> + spu->spu_type = matched_spu_type->type;
>> + spu->spu_subtype = matched_spu_type->subtype;
>> +
>> + /* Read registers and count number of SPUs */
>> + i = 0;
>> + while ((i < MAX_SPUS) && ((spu_ctrl_regs =
>> + platform_get_resource(pdev, IORESOURCE_MEM, i)) != NULL)) {
>> + dev_dbg(dev,
>> + "SPU %d control register region res.start = %#x, res.end = %#x",
>> + i,
>> + (unsigned int)spu_ctrl_regs->start,
>> + (unsigned int)spu_ctrl_regs->end);
>> +
>> + spu_reg_vbase[i] = devm_ioremap_resource(dev, spu_ctrl_regs);
>> + if (IS_ERR(spu_reg_vbase[i])) {
>> + err = PTR_ERR(spu_reg_vbase[i]);
>> + dev_err(&pdev->dev, "Failed to map registers: %d\n",
>> + err);
>> + spu_reg_vbase[i] = NULL;
>> + return err;
>> + }
>> + i++;
>> + }
> These *really* sound like independent devices. There are no shared
> registers, and each has its own mbox.
>
> Why do we group them like this?
As I said in the previous email, I want one instance of the driver to
register crypto algos once with the crypto API and to distribute crypto
requests among all available SPU hw blocks.
>
> Thanks,
> Mark.
^ permalink raw reply
* Re: [PATCH v4 1/4] [media] davinci: vpif_capture: don't lock over s_stream
From: Laurent Pinchart @ 2016-12-07 15:47 UTC (permalink / raw)
To: Kevin Hilman
Cc: linux-media-u79uwXL29TY76Z2rM5mHXA, Hans Verkuil, Sakari Ailus,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Sekhar Nori,
Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <m237i1gfz1.fsf-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Hi Kevin,
On Tuesday 06 Dec 2016 08:49:38 Kevin Hilman wrote:
> Laurent Pinchart writes:
> > On Tuesday 29 Nov 2016 15:57:09 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-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> >> ---
> >> drivers/media/platform/davinci/vpif_capture.c | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >> diff --git a/drivers/media/platform/davinci/vpif_capture.c
> >> b/drivers/media/platform/davinci/vpif_capture.c index
> >> 5104cc0ee40e..9f8f41c0f251 100644
> >> --- a/drivers/media/platform/davinci/vpif_capture.c
> >> +++ b/drivers/media/platform/davinci/vpif_capture.c
> >> @@ -193,7 +193,10 @@ 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);
> >> + spin_lock_irqsave(&common->irqlock, flags);
> >
> > I always get anxious when I see a spinlock being released randomly with an
> > operation in the middle of a protected section. Looking at the code it
> > looks like the spinlock is abused here. irqlock should only protect the
> > dma_queue and should thus only be taken around the following code:
> >
> > spin_lock_irqsave(&common->irqlock, flags);
> > /* Get the next frame from the buffer queue */
> > common->cur_frm = common->next_frm = list_entry(common->dma_queue.next,
> > struct vpif_cap_buffer, list);
> >
> > /* Remove buffer from the buffer queue */
> > list_del(&common->cur_frm->list);
> > spin_unlock_irqrestore(&common->irqlock, flags);
>
> Yes, that looks correct. Will update.
>
> > The code that is currently protected by the lock in the start and stop
> > streaming functions should be protected by a mutex instead.
>
> I tried taking the mutex here, but lockdep pointed out a deadlock. I
> may not be fully understanding the V4L2 internals here, but it seems
> that the ioctl is already taking a mutex, so taking it again in
> start/stop streaming is a deadlock. Unless you think the locking should
> be nested here, it seems to me that the mutex isn't needed.
The V4L2 core can lock all ioctls using struct video_device::lock. For buffer-
related ioctls, it can optionally use a separate lock from struct
vb2_queue::lock. See v4l2_ioctl_get_lock() in drivers/media/v4l2-core/v4l2-
ioctl.c.
The vpif-capture driver sets both the video_device and vb2_queue locks to the
same lock (which would have the same effect as leaving the vb2_queue lock
NULL). All ioctls are thus serialized. You would only need to handle locking
in start_streaming and stop_streaming manually if you didn't rely on the core
serializing the ioctls.
--
Regards,
Laurent Pinchart
--
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/3] crypto: brcm: DT documentation for Broadcom SPU driver
From: Rob (William) Rice @ 2016-12-07 15:46 UTC (permalink / raw)
To: Mark Rutland
Cc: Herbert Xu, David S. Miller, Rob Herring, linux-crypto,
devicetree, linux-kernel, Ray Jui, Scott Branden, Jon Mason,
bcm-kernel-feedback-list, Catalin Marinas, Will Deacon,
linux-arm-kernel, Steve Lin
In-Reply-To: <20161206140607.GB24177@leverpostej>
Mark,
Thanks for your comments. Replies below.
Rob
On 12/6/2016 9:06 AM, Mark Rutland wrote:
> On Wed, Nov 30, 2016 at 03:07:31PM -0500, Rob Rice wrote:
>> Device tree documentation for Broadcom Secure Processing Unit
>> (SPU) crypto driver.
>>
>> Signed-off-by: Steve Lin <steven.lin1@broadcom.com>
>> Signed-off-by: Rob Rice <rob.rice@broadcom.com>
>> ---
>> .../devicetree/bindings/crypto/brcm,spu-crypto.txt | 25 ++++++++++++++++++++++
>> 1 file changed, 25 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt
>>
>> diff --git a/Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt b/Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt
>> new file mode 100644
>> index 0000000..e5fe942
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt
>> @@ -0,0 +1,25 @@
>> +The Broadcom Secure Processing Unit (SPU) driver supports symmetric
>> +cryptographic offload for Broadcom SoCs with SPU hardware. A SoC may have
>> +multiple SPU hardware blocks.
> Bindings shound describe *hardware*, not *drivers*. Please drop mention
> of the driver, and just decribe the hardware.
Makes sense. I'll change it.
>
>> +Required properties:
>> +- compatible : Should be "brcm,spum-crypto" for devices with SPU-M hardware
>> + (e.g., Northstar2) or "brcm,spum-nsp-crypto" for the Northstar Plus variant
>> + of the SPU-M hardware.
>> +
>> +- reg: Should contain SPU registers location and length.
>> +- mboxes: A list of mailbox channels to be used by the kernel driver. Mailbox
>> +channels correspond to DMA rings on the device.
>> +
>> +Example:
>> + spu-crypto@612d0000 {
>> + compatible = "brcm,spum-crypto";
>> + reg = <0 0x612d0000 0 0x900>, /* SPU 0 control regs */
>> + <0 0x612f0000 0 0x900>, /* SPU 1 control regs */
>> + <0 0x61310000 0 0x900>, /* SPU 2 control regs */
>> + <0 0x61330000 0 0x900>; /* SPU 3 control regs */
> The above didn't mention there were several register sets, and the
> comment beside each makes them sound like they're separate SPU
> instances, so I don't think it makes sense to group them as one node.
>
> What's going on here?
That's right. For the SoC I used as the example, there are four SPU
hardware blocks. The driver round robins crypto requests to the hardware
blocks to handle requests in parallel and increase throughput. I want
one instance of the SPU driver that registers algos once with the crypto
API and manages all the mailbox channels. Maybe I can achieve that with
separate device tree entries for each SPU block, I'm not sure. I'll look
into it.
>
>> + mboxes = <&pdc0 0>,
>> + <&pdc1 0>,
>> + <&pdc2 0>,
>> + <&pdc3 0>;
> Does each mbox correspond to one of the SPUs above? Or is there a shared
> pool?
Yes, each of these mailbox channels corresponds to a different SPU. PDC
is a DMA ring manager for DMAs to the SPUs.
>
> Thanks,
> Mark.
^ permalink raw reply
* Re: [PATCH] ARM: dts: armada-{370,xp}: drop "marvell,orion-spi" from SPI controllers
From: Uwe Kleine-König @ 2016-12-07 15:41 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <87eg1jhi4l.fsf-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Hello Gregory,
On Wed, Dec 07, 2016 at 04:30:02PM +0100, Gregory CLEMENT wrote:
> On mer., déc. 07 2016, Uwe Kleine-König <uwe-rXY34ruvC2xidJT2blvkqNi2O/JbrIOy@public.gmane.org> wrote:
>
> > From: Uwe Kleine-König <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> >
> > The SPI controllers on Armada 370 and XP differ from the original Orion
> > SPI controllers (at least) in the configuration of the baud rate. So
> > it's wrong to claim compatibility which results in bogus baud rates.
>
> Until two years ago with the commits
> df59fa7f4bca9658b75f0f5fee225b3a057475c5 and
> 4dacccfac69494ba70248b134352f299171c41b7
> we used "marvell,orion-spi" compatible on Armada XP and Armada 370
> without any problem.
>
> The new compatible "marvell,armada-xp-spi" and "marvell,armada-xp-spi"
> allows to have more choice for the baudrate for a given clock but it is
> not true that Armada 370 and Armada XP are not compatible with
> "marvell,orion-spi".
The issue I was faced with that made me create this patch is that in
barebox no special case for 370/XP was active. The result was that a
device that could be operated at 60 MHz only got a clock of 11 MHz and
the driver assumed it configured 41.666 MHz. I didn't check if the same
can happen in the opposite direction (or if there are other important
incompatibilities) but still I'd say this is a bug with my patch being
the obvious fix.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
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: armada-{370,xp}: drop "marvell,orion-spi" from SPI controllers
From: Gregory CLEMENT @ 2016-12-07 15:30 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Uwe Kleine-König
In-Reply-To: <20161207152109.17545-1-uwe-rXY34ruvC2xidJT2blvkqNi2O/JbrIOy@public.gmane.org>
Hi Uwe,
On mer., déc. 07 2016, Uwe Kleine-König <uwe-rXY34ruvC2xidJT2blvkqNi2O/JbrIOy@public.gmane.org> wrote:
> From: Uwe Kleine-König <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>
> The SPI controllers on Armada 370 and XP differ from the original Orion
> SPI controllers (at least) in the configuration of the baud rate. So
> it's wrong to claim compatibility which results in bogus baud rates.
Until two years ago with the commits
df59fa7f4bca9658b75f0f5fee225b3a057475c5 and
4dacccfac69494ba70248b134352f299171c41b7
we used "marvell,orion-spi" compatible on Armada XP and Armada 370
without any problem.
The new compatible "marvell,armada-xp-spi" and "marvell,armada-xp-spi"
allows to have more choice for the baudrate for a given clock but it is
not true that Armada 370 and Armada XP are not compatible with
"marvell,orion-spi".
Gregory
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> ---
> arch/arm/boot/dts/armada-370.dtsi | 4 ++--
> arch/arm/boot/dts/armada-xp.dtsi | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
> index b4258105e91f..b9377c11b379 100644
> --- a/arch/arm/boot/dts/armada-370.dtsi
> +++ b/arch/arm/boot/dts/armada-370.dtsi
> @@ -435,13 +435,13 @@
> * board level if a different configuration is used.
> */
> &spi0 {
> - compatible = "marvell,armada-370-spi", "marvell,orion-spi";
> + compatible = "marvell,armada-370-spi";
> pinctrl-0 = <&spi0_pins1>;
> pinctrl-names = "default";
> };
>
> &spi1 {
> - compatible = "marvell,armada-370-spi", "marvell,orion-spi";
> + compatible = "marvell,armada-370-spi";
> pinctrl-0 = <&spi1_pins>;
> pinctrl-names = "default";
> };
> diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
> index 4a5f99e65b51..3a416834d80b 100644
> --- a/arch/arm/boot/dts/armada-xp.dtsi
> +++ b/arch/arm/boot/dts/armada-xp.dtsi
> @@ -367,13 +367,13 @@
> };
>
> &spi0 {
> - compatible = "marvell,armada-xp-spi", "marvell,orion-spi";
> + compatible = "marvell,armada-xp-spi";
> pinctrl-0 = <&spi0_pins>;
> pinctrl-names = "default";
> };
>
> &spi1 {
> - compatible = "marvell,armada-xp-spi", "marvell,orion-spi";
> + compatible = "marvell,armada-xp-spi";
> pinctrl-0 = <&spi1_pins>;
> pinctrl-names = "default";
> };
> --
> 2.10.2
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
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
* [PATCH] ARM: dts: armada-{370,xp}: drop "marvell,orion-spi" from SPI controllers
From: Uwe Kleine-König @ 2016-12-07 15:21 UTC (permalink / raw)
To: Jason Cooper, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Uwe Kleine-König
From: Uwe Kleine-König <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
The SPI controllers on Armada 370 and XP differ from the original Orion
SPI controllers (at least) in the configuration of the baud rate. So
it's wrong to claim compatibility which results in bogus baud rates.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
---
arch/arm/boot/dts/armada-370.dtsi | 4 ++--
arch/arm/boot/dts/armada-xp.dtsi | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
index b4258105e91f..b9377c11b379 100644
--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -435,13 +435,13 @@
* board level if a different configuration is used.
*/
&spi0 {
- compatible = "marvell,armada-370-spi", "marvell,orion-spi";
+ compatible = "marvell,armada-370-spi";
pinctrl-0 = <&spi0_pins1>;
pinctrl-names = "default";
};
&spi1 {
- compatible = "marvell,armada-370-spi", "marvell,orion-spi";
+ compatible = "marvell,armada-370-spi";
pinctrl-0 = <&spi1_pins>;
pinctrl-names = "default";
};
diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index 4a5f99e65b51..3a416834d80b 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -367,13 +367,13 @@
};
&spi0 {
- compatible = "marvell,armada-xp-spi", "marvell,orion-spi";
+ compatible = "marvell,armada-xp-spi";
pinctrl-0 = <&spi0_pins>;
pinctrl-names = "default";
};
&spi1 {
- compatible = "marvell,armada-xp-spi", "marvell,orion-spi";
+ compatible = "marvell,armada-xp-spi";
pinctrl-0 = <&spi1_pins>;
pinctrl-names = "default";
};
--
2.10.2
--
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 v3 4/4] powerpc/fsl/dts: add FMan node for t1042d4rdb
From: Madalin Bucur @ 2016-12-07 15:14 UTC (permalink / raw)
To: devicetree; +Cc: oss, linuxppc-dev
In-Reply-To: <1481123696-21028-1-git-send-email-madalin.bucur@nxp.com>
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
---
arch/powerpc/boot/dts/fsl/t1042d4rdb.dts | 52 ++++++++++++++++++++++++++++++++
1 file changed, 52 insertions(+)
diff --git a/arch/powerpc/boot/dts/fsl/t1042d4rdb.dts b/arch/powerpc/boot/dts/fsl/t1042d4rdb.dts
index 2a5a90d..fcd2aeb 100644
--- a/arch/powerpc/boot/dts/fsl/t1042d4rdb.dts
+++ b/arch/powerpc/boot/dts/fsl/t1042d4rdb.dts
@@ -48,6 +48,58 @@
"fsl,deepsleep-cpld";
};
};
+
+ soc: soc@ffe000000 {
+ fman0: fman@400000 {
+ ethernet@e0000 {
+ phy-handle = <&phy_sgmii_0>;
+ phy-connection-type = "sgmii";
+ };
+
+ ethernet@e2000 {
+ phy-handle = <&phy_sgmii_1>;
+ phy-connection-type = "sgmii";
+ };
+
+ ethernet@e4000 {
+ phy-handle = <&phy_sgmii_2>;
+ phy-connection-type = "sgmii";
+ };
+
+ ethernet@e6000 {
+ phy-handle = <&phy_rgmii_0>;
+ phy-connection-type = "rgmii";
+ };
+
+ ethernet@e8000 {
+ phy-handle = <&phy_rgmii_1>;
+ phy-connection-type = "rgmii";
+ };
+
+ mdio0: mdio@fc000 {
+ phy_sgmii_0: ethernet-phy@02 {
+ reg = <0x02>;
+ };
+
+ phy_sgmii_1: ethernet-phy@03 {
+ reg = <0x03>;
+ };
+
+ phy_sgmii_2: ethernet-phy@01 {
+ reg = <0x01>;
+ };
+
+ phy_rgmii_0: ethernet-phy@04 {
+ reg = <0x04>;
+ };
+
+ phy_rgmii_1: ethernet-phy@05 {
+ reg = <0x05>;
+ };
+ };
+ };
+ };
+
};
#include "t1042si-post.dtsi"
--
2.1.0
^ permalink raw reply related
* [PATCH v3 3/4] powerpc/fsl/dts: add sg_2500_aqr105_phy4 alias on t1024rdb
From: Madalin Bucur @ 2016-12-07 15:14 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ, mpe-Gsx/Oe8HsFggBc27wqDAHg,
oss-fOR+EgIDQEHk1uMJSBkQmQ
In-Reply-To: <1481123696-21028-1-git-send-email-madalin.bucur-3arQi8VN3Tc@public.gmane.org>
The alias is used by the boot loader to perform a device tree
fixup.
Signed-off-by: Madalin Bucur <madalin.bucur-3arQi8VN3Tc@public.gmane.org>
---
arch/powerpc/boot/dts/fsl/t1024rdb.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/boot/dts/fsl/t1024rdb.dts b/arch/powerpc/boot/dts/fsl/t1024rdb.dts
index c7f4f62..73a6453 100644
--- a/arch/powerpc/boot/dts/fsl/t1024rdb.dts
+++ b/arch/powerpc/boot/dts/fsl/t1024rdb.dts
@@ -41,6 +41,10 @@
#size-cells = <2>;
interrupt-parent = <&mpic>;
+ aliases {
+ sg_2500_aqr105_phy4 = &sg_2500_aqr105_phy4;
+ };
+
reserved-memory {
#address-cells = <2>;
#size-cells = <2>;
--
2.1.0
--
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 v3 2/4] powerpc/fsl/dts: add QMan and BMan nodes on t1024
From: Madalin Bucur @ 2016-12-07 15:14 UTC (permalink / raw)
To: devicetree; +Cc: oss, linuxppc-dev
In-Reply-To: <1481123696-21028-1-git-send-email-madalin.bucur@nxp.com>
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
---
arch/powerpc/boot/dts/fsl/t1024qds.dts | 29 +++++++++++++++++++++++++++++
arch/powerpc/boot/dts/fsl/t1024rdb.dts | 29 +++++++++++++++++++++++++++++
2 files changed, 58 insertions(+)
diff --git a/arch/powerpc/boot/dts/fsl/t1024qds.dts b/arch/powerpc/boot/dts/fsl/t1024qds.dts
index 772143d..d6858b7 100644
--- a/arch/powerpc/boot/dts/fsl/t1024qds.dts
+++ b/arch/powerpc/boot/dts/fsl/t1024qds.dts
@@ -41,6 +41,27 @@
#size-cells = <2>;
interrupt-parent = <&mpic>;
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ bman_fbpr: bman-fbpr {
+ size = <0 0x1000000>;
+ alignment = <0 0x1000000>;
+ };
+
+ qman_fqd: qman-fqd {
+ size = <0 0x400000>;
+ alignment = <0 0x400000>;
+ };
+
+ qman_pfdr: qman-pfdr {
+ size = <0 0x2000000>;
+ alignment = <0 0x2000000>;
+ };
+ };
+
ifc: localbus@ffe124000 {
reg = <0xf 0xfe124000 0 0x2000>;
ranges = <0 0 0xf 0xe8000000 0x08000000
@@ -80,6 +101,14 @@
ranges = <0x00000000 0xf 0x00000000 0x01072000>;
};
+ bportals: bman-portals@ff4000000 {
+ ranges = <0x0 0xf 0xf4000000 0x2000000>;
+ };
+
+ qportals: qman-portals@ff6000000 {
+ ranges = <0x0 0xf 0xf6000000 0x2000000>;
+ };
+
soc: soc@ffe000000 {
ranges = <0x00000000 0xf 0xfe000000 0x1000000>;
reg = <0xf 0xfe000000 0 0x00001000>;
diff --git a/arch/powerpc/boot/dts/fsl/t1024rdb.dts b/arch/powerpc/boot/dts/fsl/t1024rdb.dts
index 302cdd2..c7f4f62 100644
--- a/arch/powerpc/boot/dts/fsl/t1024rdb.dts
+++ b/arch/powerpc/boot/dts/fsl/t1024rdb.dts
@@ -41,6 +41,27 @@
#size-cells = <2>;
interrupt-parent = <&mpic>;
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ bman_fbpr: bman-fbpr {
+ size = <0 0x1000000>;
+ alignment = <0 0x1000000>;
+ };
+
+ qman_fqd: qman-fqd {
+ size = <0 0x400000>;
+ alignment = <0 0x400000>;
+ };
+
+ qman_pfdr: qman-pfdr {
+ size = <0 0x2000000>;
+ alignment = <0 0x2000000>;
+ };
+ };
+
ifc: localbus@ffe124000 {
reg = <0xf 0xfe124000 0 0x2000>;
ranges = <0 0 0xf 0xe8000000 0x08000000
@@ -82,6 +103,14 @@
ranges = <0x00000000 0xf 0x00000000 0x01072000>;
};
+ bportals: bman-portals@ff4000000 {
+ ranges = <0x0 0xf 0xf4000000 0x2000000>;
+ };
+
+ qportals: qman-portals@ff6000000 {
+ ranges = <0x0 0xf 0xf6000000 0x2000000>;
+ };
+
soc: soc@ffe000000 {
ranges = <0x00000000 0xf 0xfe000000 0x1000000>;
reg = <0xf 0xfe000000 0 0x00001000>;
--
2.1.0
^ permalink raw reply related
* [PATCH v3 1/4] powerpc/fsl/dts: add QMan and BMan nodes on t1023
From: Madalin Bucur @ 2016-12-07 15:14 UTC (permalink / raw)
To: devicetree; +Cc: oss, linuxppc-dev
Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com>
---
arch/powerpc/boot/dts/fsl/t1023rdb.dts | 29 ++++++++
arch/powerpc/boot/dts/fsl/t1023si-post.dtsi | 103 ++++++++++++++++++++++++++++
2 files changed, 132 insertions(+)
diff --git a/arch/powerpc/boot/dts/fsl/t1023rdb.dts b/arch/powerpc/boot/dts/fsl/t1023rdb.dts
index 2975762..5ba6fbf 100644
--- a/arch/powerpc/boot/dts/fsl/t1023rdb.dts
+++ b/arch/powerpc/boot/dts/fsl/t1023rdb.dts
@@ -41,6 +41,27 @@
#size-cells = <2>;
interrupt-parent = <&mpic>;
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ bman_fbpr: bman-fbpr {
+ size = <0 0x1000000>;
+ alignment = <0 0x1000000>;
+ };
+
+ qman_fqd: qman-fqd {
+ size = <0 0x400000>;
+ alignment = <0 0x400000>;
+ };
+
+ qman_pfdr: qman-pfdr {
+ size = <0 0x2000000>;
+ alignment = <0 0x2000000>;
+ };
+ };
+
ifc: localbus@ffe124000 {
reg = <0xf 0xfe124000 0 0x2000>;
ranges = <0 0 0xf 0xe8000000 0x08000000
@@ -72,6 +93,14 @@
ranges = <0x00000000 0xf 0x00000000 0x01072000>;
};
+ bportals: bman-portals@ff4000000 {
+ ranges = <0x0 0xf 0xf4000000 0x2000000>;
+ };
+
+ qportals: qman-portals@ff6000000 {
+ ranges = <0x0 0xf 0xf6000000 0x2000000>;
+ };
+
soc: soc@ffe000000 {
ranges = <0x00000000 0xf 0xfe000000 0x1000000>;
reg = <0xf 0xfe000000 0 0x00001000>;
diff --git a/arch/powerpc/boot/dts/fsl/t1023si-post.dtsi b/arch/powerpc/boot/dts/fsl/t1023si-post.dtsi
index 6e0b489..da2894c 100644
--- a/arch/powerpc/boot/dts/fsl/t1023si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/t1023si-post.dtsi
@@ -34,6 +34,21 @@
#include <dt-bindings/thermal/thermal.h>
+&bman_fbpr {
+ compatible = "fsl,bman-fbpr";
+ alloc-ranges = <0 0 0x10000 0>;
+};
+
+&qman_fqd {
+ compatible = "fsl,qman-fqd";
+ alloc-ranges = <0 0 0x10000 0>;
+};
+
+&qman_pfdr {
+ compatible = "fsl,qman-pfdr";
+ alloc-ranges = <0 0 0x10000 0>;
+};
+
&ifc {
#address-cells = <2>;
#size-cells = <1>;
@@ -180,6 +195,92 @@
};
};
+&bportals {
+ #address-cells = <0x1>;
+ #size-cells = <0x1>;
+ compatible = "simple-bus";
+
+ bman-portal@0 {
+ cell-index = <0x0>;
+ compatible = "fsl,bman-portal";
+ reg = <0x0 0x4000>, <0x1000000 0x1000>;
+ interrupts = <105 2 0 0>;
+ };
+ bman-portal@4000 {
+ cell-index = <0x1>;
+ compatible = "fsl,bman-portal";
+ reg = <0x4000 0x4000>, <0x1001000 0x1000>;
+ interrupts = <107 2 0 0>;
+ };
+ bman-portal@8000 {
+ cell-index = <2>;
+ compatible = "fsl,bman-portal";
+ reg = <0x8000 0x4000>, <0x1002000 0x1000>;
+ interrupts = <109 2 0 0>;
+ };
+ bman-portal@c000 {
+ cell-index = <0x3>;
+ compatible = "fsl,bman-portal";
+ reg = <0xc000 0x4000>, <0x1003000 0x1000>;
+ interrupts = <111 2 0 0>;
+ };
+ bman-portal@10000 {
+ cell-index = <0x4>;
+ compatible = "fsl,bman-portal";
+ reg = <0x10000 0x4000>, <0x1004000 0x1000>;
+ interrupts = <113 2 0 0>;
+ };
+ bman-portal@14000 {
+ cell-index = <0x5>;
+ compatible = "fsl,bman-portal";
+ reg = <0x14000 0x4000>, <0x1005000 0x1000>;
+ interrupts = <115 2 0 0>;
+ };
+};
+
+&qportals {
+ #address-cells = <0x1>;
+ #size-cells = <0x1>;
+ compatible = "simple-bus";
+
+ qportal0: qman-portal@0 {
+ compatible = "fsl,qman-portal";
+ reg = <0x0 0x4000>, <0x1000000 0x1000>;
+ interrupts = <104 0x2 0 0>;
+ cell-index = <0x0>;
+ };
+ qportal1: qman-portal@4000 {
+ compatible = "fsl,qman-portal";
+ reg = <0x4000 0x4000>, <0x1001000 0x1000>;
+ interrupts = <106 0x2 0 0>;
+ cell-index = <0x1>;
+ };
+ qportal2: qman-portal@8000 {
+ compatible = "fsl,qman-portal";
+ reg = <0x8000 0x4000>, <0x1002000 0x1000>;
+ interrupts = <108 0x2 0 0>;
+ cell-index = <0x2>;
+ };
+ qportal3: qman-portal@c000 {
+ compatible = "fsl,qman-portal";
+ reg = <0xc000 0x4000>, <0x1003000 0x1000>;
+ interrupts = <110 0x2 0 0>;
+ cell-index = <0x3>;
+ };
+ qportal4: qman-portal@10000 {
+ compatible = "fsl,qman-portal";
+ reg = <0x10000 0x4000>, <0x1004000 0x1000>;
+ interrupts = <112 0x2 0 0>;
+ cell-index = <0x4>;
+ };
+ qportal5: qman-portal@14000 {
+ compatible = "fsl,qman-portal";
+ reg = <0x14000 0x4000>, <0x1005000 0x1000>;
+ interrupts = <114 0x2 0 0>;
+ cell-index = <0x5>;
+ };
+};
+
&soc {
#address-cells = <1>;
#size-cells = <1>;
@@ -413,6 +514,8 @@
};
/include/ "qoriq-sec5.0-0.dtsi"
+/include/ "qoriq-qman3.dtsi"
+/include/ "qoriq-bman1.dtsi"
/include/ "qoriq-fman3l-0.dtsi"
/include/ "qoriq-fman3-0-10g-0-best-effort.dtsi"
--
2.1.0
^ permalink raw reply related
* Re: [PATCH v3 4/6] mfd: dt: Add bindings for the Aspeed LPC Host Controller (LHC)
From: Linus Walleij @ 2016-12-07 15:12 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Lee Jones, Rob Herring, Mark Rutland, Corey Minyard,
Cédric Le Goater, Joel Stanley,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20161206025321.1792-5-andrew-zrmu5oMJ5Fs@public.gmane.org>
On Tue, Dec 6, 2016 at 3:53 AM, Andrew Jeffery <andrew-zrmu5oMJ5Fs@public.gmane.org> wrote:
> The LPC bus pinmux configuration on fifth generation Aspeed SoCs depends
> on bits in both the System Control Unit and the LPC Host Controller.
>
> The Aspeed LPC Host Controller is described as a child node of the
> LPC host-range syscon device for arbitration of access by the host
> controller and pinmux drivers.
>
> Signed-off-by: Andrew Jeffery <andrew-zrmu5oMJ5Fs@public.gmane.org>
Reviewed-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RESEND PATCH v2 4/7] drm/vc4: Add support for the VEC (Video Encoder) IP
From: Boris Brezillon @ 2016-12-07 15:12 UTC (permalink / raw)
To: Florian Fainelli
Cc: Mark Rutland, devicetree, Ian Campbell, Pawel Moll, Scott Branden,
Stephen Warren, Ray Jui, Lee Jones, dri-devel, Rob Herring,
bcm-kernel-feedback-list, linux-rpi-kernel, Kumar Gala,
linux-arm-kernel
In-Reply-To: <c1b904db-be3d-1e83-37bc-1f750ecfe224@gmail.com>
On Mon, 5 Dec 2016 17:50:13 -0800
Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 12/02/2016 05:48 AM, Boris Brezillon wrote:
> > The VEC IP is a TV DAC, providing support for PAL and NTSC standards.
> >
> > Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> > ---
>
> > diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c
> > new file mode 100644
> > index 000000000000..2d4256fcc6f2
> > --- /dev/null
> > +++ b/drivers/gpu/drm/vc4/vc4_vec.c
> > @@ -0,0 +1,657 @@
> > +/*
> > + * Copyright (C) 2016 Broadcom Limited
>
> The standard copyright template post acquisition is just Broadcom, not
> Broadcom Limited, nor Broadcom corporation. Can you audit your entire
> submission and fix this up accordingly?
This is the only patch adding a copyright header.
Eric, can you fix that when applying the series or should I resend a
new version?
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v3 3/6] mfd: dt: Add Aspeed Low Pin Count Controller bindings
From: Linus Walleij @ 2016-12-07 15:11 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Lee Jones, Rob Herring, Mark Rutland, Corey Minyard,
Cédric Le Goater, Joel Stanley, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20161206025321.1792-4-andrew@aj.id.au>
On Tue, Dec 6, 2016 at 3:53 AM, Andrew Jeffery <andrew@aj.id.au> wrote:
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v3 1/6] mfd: dt: Fix "indicates" typo in mfd bindings document
From: Linus Walleij @ 2016-12-07 15:08 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Lee Jones, Rob Herring, Mark Rutland, Corey Minyard,
Cédric Le Goater, Joel Stanley,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20161206025321.1792-2-andrew-zrmu5oMJ5Fs@public.gmane.org>
On Tue, Dec 6, 2016 at 3:53 AM, Andrew Jeffery <andrew-zrmu5oMJ5Fs@public.gmane.org> wrote:
> Signed-off-by: Andrew Jeffery <andrew-zrmu5oMJ5Fs@public.gmane.org>
My speling mistak.
Acked-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC PATCH v3 2/2] drm/panel: Add support for Chunghwa CLAA070WP03XG panel
From: Daniel Vetter @ 2016-12-07 14:55 UTC (permalink / raw)
To: Ayaka
Cc: Thierry Reding, devicetree, linux-samsung-soc, linux, krzk,
linux-kernel, kgene, dri-devel, linux-arm-kernel
In-Reply-To: <2C9FE0C5-F521-48CD-B274-66128312CA75@soulik.info>
On Wed, Dec 07, 2016 at 08:57:23AM +0800, Ayaka wrote:
>
>
> 從我的 iPad 傳送
>
> > Thierry Reding <thierry.reding@gmail.com> 於 2016年12月6日 下午11:46 寫道：
> >
> >> On Tue, Sep 20, 2016 at 03:02:51AM +0800, Randy Li wrote:
> >> The Chunghwa CLAA070WP03XG is a 7" 1280x800 panel, which can be
> >> supported by the simple panel driver.
> >>
> >> Signed-off-by: Randy Li <ayaka@soulik.info>
> >> ---
> >> .../display/panel/chunghwa,claa070wp03xg.txt | 7 ++++++
> >> drivers/gpu/drm/panel/panel-simple.c | 27 ++++++++++++++++++++++
> >> 2 files changed, 34 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/display/panel/chunghwa,claa070wp03xg.txt
> >
> > Applied, thanks.
> Wait, it is RFC, not pass the test.
Well 2 months of silence, it's reasonable to assume that this works for
you ... I guess you need to supply a fixup patch asap ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ 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