* Re: [PATCH 3/8] ARM: dts: armada-388-clearfog: Utilize new DSA binding
From: Neil Armstrong @ 2017-01-02 8:59 UTC (permalink / raw)
To: Florian Fainelli, linux-arm-kernel
Cc: Mark Rutland, Andrew Lunn, Jason Cooper, vivien.didelot,
Russell King, open list,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Rob Herring, Gregory Clement, Sebastian Hesselbarth
In-Reply-To: <20170102022249.10657-4-f.fainelli@gmail.com>
Hi Florian,
On 01/02/2017 03:22 AM, Florian Fainelli wrote:
> Utilize the new DSA binding, introduced with commit 8c5ad1d6179d ("net:
> dsa: Document new binding"). The legacy binding node is kept included, but is
> marked disabled.
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> arch/arm/boot/dts/armada-388-clearfog.dts | 65 +++++++++++++++++++++++++++++++
> 1 file changed, 65 insertions(+)
>
> diff --git a/arch/arm/boot/dts/armada-388-clearfog.dts b/arch/arm/boot/dts/armada-388-clearfog.dts
> index 71ce201c903e..35207aa1f4ec 100644
> --- a/arch/arm/boot/dts/armada-388-clearfog.dts
> +++ b/arch/arm/boot/dts/armada-388-clearfog.dts
> @@ -351,6 +351,8 @@
> };
>
> dsa@0 {
> + status = "okay";
I think you wanted "disabled" here !
> +
> compatible = "marvell,dsa";
> dsa,ethernet = <ð1>;
> dsa,mii-bus = <&mdio>;
> @@ -444,3 +446,66 @@
> status = "disabled";
> };
> };
[...]
Neil
^ permalink raw reply
* Re: [PATCH v6 2/9] misc: minimal mux subsystem and gpio-based mux controller
From: Peter Rosin @ 2017-01-02 9:14 UTC (permalink / raw)
To: Jonathan Cameron, linux-kernel
Cc: Wolfram Sang, Rob Herring, Mark Rutland, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler, Jonathan Corbet,
Arnd Bergmann, Greg Kroah-Hartman, linux-i2c, devicetree,
linux-iio, linux-doc
In-Reply-To: <8df0d60d-cc95-b0ce-f149-0e123af5046b@kernel.org>
On 2016-12-31 17:19, Jonathan Cameron wrote:
> On 30/11/16 08:16, Peter Rosin wrote:
>> Add a new minimalistic subsystem that handles multiplexer controllers.
>> When multiplexers are used in various places in the kernel, and the
>> same multiplexer controller can be used for several independent things,
>> there should be one place to implement support for said multiplexer
>> controller.
>>
>> A single multiplexer controller can also be used to control several
>> parallel multiplexers, that are in turn used by different subsystems
>> in the kernel, leading to a need to coordinate multiplexer accesses.
>> The multiplexer subsystem handles this coordination.
>>
>> This new mux controller subsystem initially comes with a single backend
>> driver that controls gpio based multiplexers. Even though not needed by
>> this initial driver, the mux controller subsystem is prepared to handle
>> chips with multiple (independent) mux controllers.
>>
>> Signed-off-by: Peter Rosin <peda@axentia.se>
> Few trivial bits inline + question of whether misc is the right location..
> It's small, but not totally trivial as subsystems go, so perhaps it needs it's
> own directory.
In [9/9] you come to the conclusion that muxes should have their own
directory, but do you think it should be
drivers/mux/*
or
drivers/misc/mux/*
?
>> ---
>> Documentation/driver-model/devres.txt | 6 +-
>> MAINTAINERS | 2 +
>> drivers/misc/Kconfig | 30 ++++
>> drivers/misc/Makefile | 2 +
>> drivers/misc/mux-core.c | 311 ++++++++++++++++++++++++++++++++++
>> drivers/misc/mux-gpio.c | 138 +++++++++++++++
>> include/linux/mux.h | 197 +++++++++++++++++++++
>> 7 files changed, 685 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/misc/mux-core.c
>> create mode 100644 drivers/misc/mux-gpio.c
>> create mode 100644 include/linux/mux.h
>>
>> diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt
>> index ca9d1eb46bc0..d64ede85b61b 100644
>> --- a/Documentation/driver-model/devres.txt
>> +++ b/Documentation/driver-model/devres.txt
>> @@ -330,7 +330,11 @@ MEM
>> devm_kzalloc()
>>
>> MFD
>> - devm_mfd_add_devices()
> Technically should be in a separate cleanup patch...
>> + devm_mfd_add_devices()
>> +
>> +MUX
>> + devm_mux_control_get()
>> + devm_mux_control_put()
>>
>> PER-CPU MEM
>> devm_alloc_percpu()
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 3d4d0efc2b64..dc7498682752 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -8407,6 +8407,8 @@ MULTIPLEXER SUBSYSTEM
>> M: Peter Rosin <peda@axentia.se>
>> S: Maintained
>> F: Documentation/devicetree/bindings/misc/mux-*
>> +F: include/linux/mux.h
>> +F: drivers/misc/mux-*
>>
>> MULTISOUND SOUND DRIVER
>> M: Andrew Veliath <andrewtv@usa.net>
>> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
>> index 64971baf11fa..2ce675e410c5 100644
>> --- a/drivers/misc/Kconfig
>> +++ b/drivers/misc/Kconfig
>> @@ -766,6 +766,36 @@ config PANEL_BOOT_MESSAGE
>> An empty message will only clear the display at driver init time. Any other
>> printf()-formatted message is valid with newline and escape codes.
>>
>> +menuconfig MULTIPLEXER
>> + bool "Multiplexer subsystem"
>> + help
>> + Multiplexer controller subsystem. Multiplexers are used in a
>> + variety of settings, and this subsystem abstracts their use
>> + so that the rest of the kernel sees a common interface. When
>> + multiple parallel multiplexers are controlled by one single
>> + multiplexer controller, this subsystem also coordinates the
>> + multiplexer accesses.
>> +
>> + If unsure, say no.
>> +
> Fun question of the day. Is misc the place to put this or should it
> have it's own directory. I'd go for own directory...
I thought it too small for its own dir and that it could always be
moved later. But I don't really care...
> On the plus side, whilst it's in misc you get to pester Greg and Arnd
> for review.
I know :-]
>> +if MULTIPLEXER
>> +
>> +config MUX_GPIO
>> + tristate "GPIO-controlled Multiplexer"
>> + depends on OF && GPIOLIB
>> + help
>> + GPIO-controlled Multiplexer controller.
>> +
>> + The driver builds a single multiplexer controller using a number
>> + of gpio pins. For N pins, there will be 2^N possible multiplexer
>> + states. The GPIO pins can be connected (by the hardware) to several
*snip*
>> +
>> +void mux_chip_free(struct mux_chip *mux_chip)
>> +{
>> + if (!mux_chip)
>> + return;
> I'd drop a blank line in here. Slightly nicer to read.
Right.
>> + put_device(&mux_chip->dev);
>> +}
>> +EXPORT_SYMBOL_GPL(mux_chip_free);
*snip*
>> +
>> +static int mux_gpio_probe(struct platform_device *pdev)
>> +{
>> + struct device *dev = &pdev->dev;
>> + struct device_node *np = pdev->dev.of_node;
>> + struct mux_chip *mux_chip;
>> + struct mux_gpio *mux_gpio;
>> + int pins;
>> + u32 idle_state;
>> + int ret;
>> +
>> + if (!np)
>> + return -ENODEV;
>> +
>> + pins = gpiod_count(dev, "mux");
>> + if (pins < 0)
>> + return pins;
>> +
>> + mux_chip = mux_chip_alloc(dev, 1, sizeof(*mux_gpio) +
>> + pins * sizeof(*mux_gpio->val));
>> + if (!mux_chip)
>> + return -ENOMEM;
> Rather feels like mux_chip_alloc is a good candidate for a managed
> allocator. Might be worth doing the register as well then the remove
> below would go away. I guess perhaps not that worthwhile as not many
> mux types are likely to ever exist...
To me it seemed like too much extra support code for just two drivers.
And it can always be added later if/when more mux drivers show up...
>> +
>> + mux_gpio = mux_chip_priv(mux_chip);
>> + mux_gpio->val = (int *)(mux_gpio + 1);
*snip*
Cheers,
peda
^ permalink raw reply
* Re: [PATCH v6 2/9] misc: minimal mux subsystem and gpio-based mux controller
From: Jonathan Cameron @ 2017-01-02 9:20 UTC (permalink / raw)
To: Peter Rosin, Jonathan Cameron,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Wolfram Sang, Rob Herring, Mark Rutland, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler, Jonathan Corbet,
Arnd Bergmann, Greg Kroah-Hartman,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <7080f03c-0ee3-13b2-b242-21f80052e479-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
On 2 January 2017 09:14:34 GMT+00:00, Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org> wrote:
>On 2016-12-31 17:19, Jonathan Cameron wrote:
>> On 30/11/16 08:16, Peter Rosin wrote:
>>> Add a new minimalistic subsystem that handles multiplexer
>controllers.
>>> When multiplexers are used in various places in the kernel, and the
>>> same multiplexer controller can be used for several independent
>things,
>>> there should be one place to implement support for said multiplexer
>>> controller.
>>>
>>> A single multiplexer controller can also be used to control several
>>> parallel multiplexers, that are in turn used by different subsystems
>>> in the kernel, leading to a need to coordinate multiplexer accesses.
>>> The multiplexer subsystem handles this coordination.
>>>
>>> This new mux controller subsystem initially comes with a single
>backend
>>> driver that controls gpio based multiplexers. Even though not needed
>by
>>> this initial driver, the mux controller subsystem is prepared to
>handle
>>> chips with multiple (independent) mux controllers.
>>>
>>> Signed-off-by: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
>> Few trivial bits inline + question of whether misc is the right
>location..
>> It's small, but not totally trivial as subsystems go, so perhaps it
>needs it's
>> own directory.
>
>In [9/9] you come to the conclusion that muxes should have their own
>directory, but do you think it should be
> drivers/mux/*
Probably this one...
>or
> drivers/misc/mux/*
>?
>
>>> ---
>>> Documentation/driver-model/devres.txt | 6 +-
>>> MAINTAINERS | 2 +
>>> drivers/misc/Kconfig | 30 ++++
>>> drivers/misc/Makefile | 2 +
>>> drivers/misc/mux-core.c | 311
>++++++++++++++++++++++++++++++++++
>>> drivers/misc/mux-gpio.c | 138 +++++++++++++++
>>> include/linux/mux.h | 197 +++++++++++++++++++++
>>> 7 files changed, 685 insertions(+), 1 deletion(-)
>>> create mode 100644 drivers/misc/mux-core.c
>>> create mode 100644 drivers/misc/mux-gpio.c
>>> create mode 100644 include/linux/mux.h
>>>
>>> diff --git a/Documentation/driver-model/devres.txt
>b/Documentation/driver-model/devres.txt
>>> index ca9d1eb46bc0..d64ede85b61b 100644
>>> --- a/Documentation/driver-model/devres.txt
>>> +++ b/Documentation/driver-model/devres.txt
>>> @@ -330,7 +330,11 @@ MEM
>>> devm_kzalloc()
>>>
>>> MFD
>>> - devm_mfd_add_devices()
>> Technically should be in a separate cleanup patch...
>>> + devm_mfd_add_devices()
>>> +
>>> +MUX
>>> + devm_mux_control_get()
>>> + devm_mux_control_put()
>>>
>>> PER-CPU MEM
>>> devm_alloc_percpu()
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index 3d4d0efc2b64..dc7498682752 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -8407,6 +8407,8 @@ MULTIPLEXER SUBSYSTEM
>>> M: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
>>> S: Maintained
>>> F: Documentation/devicetree/bindings/misc/mux-*
>>> +F: include/linux/mux.h
>>> +F: drivers/misc/mux-*
>>>
>>> MULTISOUND SOUND DRIVER
>>> M: Andrew Veliath <andrewtv-Jdbf3xiKgS8@public.gmane.org>
>>> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
>>> index 64971baf11fa..2ce675e410c5 100644
>>> --- a/drivers/misc/Kconfig
>>> +++ b/drivers/misc/Kconfig
>>> @@ -766,6 +766,36 @@ config PANEL_BOOT_MESSAGE
>>> An empty message will only clear the display at driver init
>time. Any other
>>> printf()-formatted message is valid with newline and escape
>codes.
>>>
>>> +menuconfig MULTIPLEXER
>>> + bool "Multiplexer subsystem"
>>> + help
>>> + Multiplexer controller subsystem. Multiplexers are used in a
>>> + variety of settings, and this subsystem abstracts their use
>>> + so that the rest of the kernel sees a common interface. When
>>> + multiple parallel multiplexers are controlled by one single
>>> + multiplexer controller, this subsystem also coordinates the
>>> + multiplexer accesses.
>>> +
>>> + If unsure, say no.
>>> +
>> Fun question of the day. Is misc the place to put this or should it
>> have it's own directory. I'd go for own directory...
>
>I thought it too small for its own dir and that it could always be
>moved later. But I don't really care...
>
>> On the plus side, whilst it's in misc you get to pester Greg and Arnd
>> for review.
>
>I know :-]
>
>>> +if MULTIPLEXER
>>> +
>>> +config MUX_GPIO
>>> + tristate "GPIO-controlled Multiplexer"
>>> + depends on OF && GPIOLIB
>>> + help
>>> + GPIO-controlled Multiplexer controller.
>>> +
>>> + The driver builds a single multiplexer controller using a number
>>> + of gpio pins. For N pins, there will be 2^N possible multiplexer
>>> + states. The GPIO pins can be connected (by the hardware) to
>several
>
>*snip*
>
>>> +
>>> +void mux_chip_free(struct mux_chip *mux_chip)
>>> +{
>>> + if (!mux_chip)
>>> + return;
>> I'd drop a blank line in here. Slightly nicer to read.
>
>Right.
>
>>> + put_device(&mux_chip->dev);
>>> +}
>>> +EXPORT_SYMBOL_GPL(mux_chip_free);
>
>*snip*
>
>>> +
>>> +static int mux_gpio_probe(struct platform_device *pdev)
>>> +{
>>> + struct device *dev = &pdev->dev;
>>> + struct device_node *np = pdev->dev.of_node;
>>> + struct mux_chip *mux_chip;
>>> + struct mux_gpio *mux_gpio;
>>> + int pins;
>>> + u32 idle_state;
>>> + int ret;
>>> +
>>> + if (!np)
>>> + return -ENODEV;
>>> +
>>> + pins = gpiod_count(dev, "mux");
>>> + if (pins < 0)
>>> + return pins;
>>> +
>>> + mux_chip = mux_chip_alloc(dev, 1, sizeof(*mux_gpio) +
>>> + pins * sizeof(*mux_gpio->val));
>>> + if (!mux_chip)
>>> + return -ENOMEM;
>> Rather feels like mux_chip_alloc is a good candidate for a managed
>> allocator. Might be worth doing the register as well then the remove
>> below would go away. I guess perhaps not that worthwhile as not many
>> mux types are likely to ever exist...
>
>To me it seemed like too much extra support code for just two drivers.
>And it can always be added later if/when more mux drivers show up...
There will be others :) sure do it later.
>
>>> +
>>> + mux_gpio = mux_chip_priv(mux_chip);
>>> + mux_gpio->val = (int *)(mux_gpio + 1);
>
>*snip*
>
>Cheers,
>peda
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
^ permalink raw reply
* Re: [PATCH 1/2] ARM: dts: imx6dl: Add Engicam i.CoreM6 DualLite/Solo RQS initial support
From: Shawn Guo @ 2017-01-02 9:23 UTC (permalink / raw)
To: Jagan Teki
Cc: linux-arm-kernel, devicetree, linux-kernel, Matteo Lisi,
Michael Trimarchi, Jagan Teki
In-Reply-To: <1482508935-9414-1-git-send-email-jagan@openedev.com>
On Fri, Dec 23, 2016 at 05:02:14PM +0100, Jagan Teki wrote:
> From: Jagan Teki <jagan@amarulasolutions.com>
>
> i.CoreM6 DualLite/Solo modules are system on module solutions manufactured
> by Engicam with following characteristics:
> CPU NXP i.MX6 DL, 800MHz
> RAM 1GB, 32, 64 bit, DDR3-800/1066
> NAND SLC,512MB
> Power supply Single 5V
> MAX LCD RES FULLHD
>
> and more info at
> http://www.engicam.com/en/products/embedded/som/standard/i-core-rqs-m6s-dl-d-q
>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Matteo Lisi <matteo.lisi@engicam.com>
> Cc: Michael Trimarchi <michael@amarulasolutions.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/imx6dl-icore-rqs.dts | 51 ++++++++++++++++++++++++++++++++++
> 2 files changed, 52 insertions(+)
> create mode 100644 arch/arm/boot/dts/imx6dl-icore-rqs.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index cccdbcb..51f8dae 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -349,6 +349,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
> imx6dl-gw553x.dtb \
> imx6dl-hummingboard.dtb \
> imx6dl-icore.dtb \
> + imx6dl-icore-rqs.dtb \
> imx6dl-nit6xlite.dtb \
> imx6dl-nitrogen6x.dtb \
> imx6dl-phytec-pbab01.dtb \
> diff --git a/arch/arm/boot/dts/imx6dl-icore-rqs.dts b/arch/arm/boot/dts/imx6dl-icore-rqs.dts
> new file mode 100644
> index 0000000..5c19927
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6dl-icore-rqs.dts
> @@ -0,0 +1,51 @@
> +/*
> + * Copyright (C) 2016 Amarula Solutions B.V.
> + * Copyright (C) 2016 Engicam S.r.l.
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + *
> + * This file is distributed in the hope that it will be useful
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
Please take a look at the following patch.
https://patchwork.kernel.org/patch/9475057/
Shawn
> +
> +/dts-v1/;
> +
> +#include "imx6q.dtsi"
> +#include "imx6qdl-icore-rqs.dtsi"
> +
> +/ {
> + model = "Engicam i.CoreM6 DualLite/Solo RQS Starter Kit";
> + compatible = "engicam,imx6-icore-rqs", "fsl,imx6dl";
> +};
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH 0/9] dmaengine: stm32-dma: Bug fixes and improvements series
From: M'boumba Cedric Madianga @ 2017-01-02 9:26 UTC (permalink / raw)
To: Vinod Koul
Cc: Rob Herring, Mark Rutland, Maxime Coquelin, Alexandre Torgue,
dan.j.williams, dmaengine, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20170102041433.GM3573@localhost>
Hi Vinod,
> So you should order fixes first and then new additions.
> Fixes go in for current release whereas the rest for next one.
Ok thanks for the info.
> I have applied two to fixes and rest to updated, patch 5 didn't apply, please
> resend that one.
I have tried to apply patch 5 on top of slave-dma/fixes branch but I
don't have any issue.
So, I am going to resend this patch in order to be sure that there is no diff.
Best regards,
Cedric
^ permalink raw reply
* [PATCH RESEND] dmaengine: stm32-dma: Rework starting transfer management
From: M'boumba Cedric Madianga @ 2017-01-02 9:33 UTC (permalink / raw)
To: vinod.koul, robh+dt, mark.rutland, mcoquelin.stm32,
alexandre.torgue, dan.j.williams, dmaengine, devicetree,
linux-arm-kernel, linux-kernel
Cc: M'boumba Cedric Madianga
This patch reworks the way to manage transfer starting.
Now, starting DMA is only allowed when the channel is not busy.
Then, stm32_dma_start_transfer is declared as void.
At least, after each transfer completion, we start the next transfer if a
new descriptor as been queued in the issued list during an ongoing
transfer.
Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com>
Reviewed-by: Ludovic BARRE <ludovic.barre@st.com>
---
drivers/dma/stm32-dma.c | 20 +++++++++-----------
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/dma/stm32-dma.c b/drivers/dma/stm32-dma.c
index 3056ce7..adb846c 100644
--- a/drivers/dma/stm32-dma.c
+++ b/drivers/dma/stm32-dma.c
@@ -421,7 +421,7 @@ static void stm32_dma_dump_reg(struct stm32_dma_chan *chan)
dev_dbg(chan2dev(chan), "SFCR: 0x%08x\n", sfcr);
}
-static int stm32_dma_start_transfer(struct stm32_dma_chan *chan)
+static void stm32_dma_start_transfer(struct stm32_dma_chan *chan)
{
struct stm32_dma_device *dmadev = stm32_dma_get_dev(chan);
struct virt_dma_desc *vdesc;
@@ -432,12 +432,12 @@ static int stm32_dma_start_transfer(struct stm32_dma_chan *chan)
ret = stm32_dma_disable_chan(chan);
if (ret < 0)
- return ret;
+ return;
if (!chan->desc) {
vdesc = vchan_next_desc(&chan->vchan);
if (!vdesc)
- return -EPERM;
+ return;
chan->desc = to_stm32_dma_desc(vdesc);
chan->next_sg = 0;
@@ -471,7 +471,7 @@ static int stm32_dma_start_transfer(struct stm32_dma_chan *chan)
chan->busy = true;
- return 0;
+ dev_dbg(chan2dev(chan), "vchan %p: started\n", &chan->vchan);
}
static void stm32_dma_configure_next_sg(struct stm32_dma_chan *chan)
@@ -552,15 +552,13 @@ static void stm32_dma_issue_pending(struct dma_chan *c)
{
struct stm32_dma_chan *chan = to_stm32_dma_chan(c);
unsigned long flags;
- int ret;
spin_lock_irqsave(&chan->vchan.lock, flags);
- if (!chan->busy) {
- if (vchan_issue_pending(&chan->vchan) && !chan->desc) {
- ret = stm32_dma_start_transfer(chan);
- if ((!ret) && (chan->desc->cyclic))
- stm32_dma_configure_next_sg(chan);
- }
+ if (vchan_issue_pending(&chan->vchan) && !chan->desc && !chan->busy) {
+ dev_dbg(chan2dev(chan), "vchan %p: issued\n", &chan->vchan);
+ stm32_dma_start_transfer(chan);
+ if (chan->desc->cyclic)
+ stm32_dma_configure_next_sg(chan);
}
spin_unlock_irqrestore(&chan->vchan.lock, flags);
}
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 0/4] PCI: exynos: use the PHY generic framework
From: Jaehoon Chung @ 2017-01-02 9:45 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-pci, devicetree, linux-kernel, linux-samsung-soc, bhelgaas,
robh+dt, mark.rutland, kgene, kishon, jingoohan1, vivek.gautam,
pankaj.dubey, alim.akhtar, cpgs
In-Reply-To: <20161230155613.jpwzytnh4osz76c6@kozik-lap>
On 12/31/2016 12:56 AM, Krzysztof Kozlowski wrote:
> On Wed, Dec 28, 2016 at 07:34:50PM +0900, Jaehoon Chung wrote:
>> This patch is for using PHY generic framework.
>> When Exynos5440 had upstreamed, there was no PHY subsytem.
>> Now the using PHY framework is mandantory.
>> In future, Exynos variant should be supported in pci-exynos.c
>>
>> Theses pathces based on the below patches
>>
>
> Aren't you breaking DTB ABI here? If yes, then I don't mind but please
> put it in the commit message. Also order the patches in a way
> preserving bisectability.
Will resend the patch v2.
Best Regards,
Jaehoon Chung
>
> Best regards,
> Krzysztof
>
>> - Jaehoon's patches
>> http://patchwork.ozlabs.org/patch/706998/
>> http://patchwork.ozlabs.org/patch/706997/
>> http://patchwork.ozlabs.org/patch/706995/
>> http://patchwork.ozlabs.org/patch/706994/
>>
>> - Srinivas's patch
>> http://patchwork.ozlabs.org/patch/703530/
>>
>> - Pankaj's patch
>> http://patchwork.ozlabs.org/patch/708414/
>>
>> Jaehoon Chung (4):
>> phy: exynos-pcie: Add support for Exynos PCIe phy
>> Documetation: samsung-phy: add the exynos-pcie-phy binding
>> Documetation: binding: modify the exynos5440 pcie binding
>> ARM: dts: exynos5440: support the phy-pcie node for pcie
>>
>> .../bindings/pci/samsung,exynos5440-pcie.txt | 29 ++-
>> .../devicetree/bindings/phy/samsung-phy.txt | 23 ++
>> arch/arm/boot/dts/exynos5440.dtsi | 44 +++-
>> drivers/pci/host/pci-exynos.c | 198 ++------------
>> drivers/phy/Kconfig | 9 +
>> drivers/phy/Makefile | 1 +
>> drivers/phy/phy-exynos-pcie.c | 289 +++++++++++++++++++++
>> 7 files changed, 395 insertions(+), 198 deletions(-)
>> create mode 100644 drivers/phy/phy-exynos-pcie.c
>>
>> --
>> 2.10.2
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" 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
* Re: [PATCH] iio: adc: Add Renesas GyroADC driver
From: Geert Uytterhoeven @ 2017-01-02 10:01 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Geert Uytterhoeven, Simon Horman
In-Reply-To: <20161230191800.2532-1-marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Marek,
On Fri, Dec 30, 2016 at 8:18 PM, Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Add IIO driver for the Renesas RCar GyroADC block. This block is a
> simple 4/8-channel ADC which samples 12/15/24 bits of data every
> cycle from all channels.
Thanks for your patch!
> Signed-off-by: Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
> Cc: Simon Horman <horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org>
> ---
> .../bindings/iio/adc/renesas,gyroadc.txt | 38 +++
> MAINTAINERS | 6 +
> drivers/iio/adc/Kconfig | 10 +
> drivers/iio/adc/Makefile | 1 +
> drivers/iio/adc/rcar_gyro_adc.c | 379 +++++++++++++++++++++
> 5 files changed, 434 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/renesas,gyroadc.txt
> create mode 100644 drivers/iio/adc/rcar_gyro_adc.c
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/renesas,gyroadc.txt b/Documentation/devicetree/bindings/iio/adc/renesas,gyroadc.txt
> new file mode 100644
> index 0000000..3fd5f57
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/renesas,gyroadc.txt
> @@ -0,0 +1,38 @@
> +* Renesas RCar GyroADC device driver
> +
> +Required properties:
> +- compatible: Should be "renesas,rcar-gyroadc" for regular GyroADC or
> + "renesas,rcar-gyroadc-r8a7792" for GyroADC without interrupt
Please use "renesas,r8a7792-gyroadc" to match existing practices.
Unfortunately we cannot just look at the presence of an "interrupts" property
to distinguish between the two variants, as the interrupt is handled
by a different
block (Speed Pulse IF).
Do you have a (future) use for the interrupt? If yes, we will need a phandle
link to the Speed Pulse IF device node later...
BTW, it's a good idea to always cater for SoC-specific differences that may
be discovered later by adding SoC-specific compatible values.
BTW, the same hardware block seems to be present in R-Car Gen1 and
R-Car Gen3 SoCs.
> + block found in R8A7792.
> +- renesas,gyroadc-vref: Array of reference voltage values for each input to
> + the GyroADC, in uV. Array must have 4 elemenets for
> + mode 1 and 8 elements for mode 2 and 3.
Should this be an array of phandles to regulators instead?
> --- /dev/null
> +++ b/drivers/iio/adc/rcar_gyro_adc.c
> @@ -0,0 +1,379 @@
> +/*
> + * Renesas RCar GyroADC driver
R-Car
> + *
> + * Copyright 2016 Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
MODULE_LICENSE() says GPL V2 only?
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/interrupt.h>
Do you need this include? There's no interrupt support.
> +#include <linux/delay.h>
> +#include <linux/kernel.h>
> +#include <linux/slab.h>
> +#include <linux/io.h>
> +#include <linux/clk.h>
> +#include <linux/of.h>
> +#include <linux/of_irq.h>
> +#include <linux/regulator/consumer.h>
Do you need this include?
Ah, you were already anticipating the array of phandles to regulators ;-)
> +struct rcar_gyroadc {
> + struct device *dev;
> + void __iomem *regs;
> + struct clk *fclk;
> + struct clk *clk;
iclk?
> +static void rcar_gyroadc_hw_init(struct rcar_gyroadc *priv)
> +{
> + unsigned long clk_mhz = clk_get_rate(priv->clk) / 1000000;
> +
> + /* Stop the GyroADC. */
> + writel(0, priv->regs + RCAR_GYROADC_START_STOP);
> +
> + /* Disable IRQ, except on V2H. */
> + if (priv->model != RCAR_GYROADC_MODEL_R8A7792)
> + writel(0, priv->regs + RCAR_GYROADC_INTENR);
> +
> + /* Set mode and timing. */
> + writel(priv->mode, priv->regs + RCAR_GYROADC_MODE_SELECT);
> +
> + if (priv->mode == RCAR_GYROADC_MODE_SELECT_1_MB88101A)
> + writel(clk_mhz * 10, priv->regs + RCAR_GYROADC_CLOCK_LENGTH);
> + else if (priv->mode == RCAR_GYROADC_MODE_SELECT_2_ADCS7476)
> + writel(clk_mhz * 5, priv->regs + RCAR_GYROADC_CLOCK_LENGTH);
> + else if (priv->mode == RCAR_GYROADC_MODE_SELECT_3_MAX1162)
> + writel(clk_mhz * 5, priv->regs + RCAR_GYROADC_CLOCK_LENGTH);
> + writel(clk_mhz * 1250, priv->regs + RCAR_GYROADC_1_25MS_LENGTH);
> +
> + /*
> + * We can possibly turn the sampling on/off on-demand to reduce power
And the module clock, using runtime PM (see below).
> + * consumption, but for the sake of quick availability of samples, we
> + * don't do it now.
> + */
> + writel(RCAR_GYROADC_START_STOP_START,
> + priv->regs + RCAR_GYROADC_START_STOP);
> +
> + /* Wait for the first conversion to complete. */
> + udelay(1250);
> +}
> +static const struct of_device_id rcar_gyroadc_match[] = {
> + {
> + /* RCar Gen2 compatible GyroADC */
R-Car
> + .compatible = "renesas,rcar-gyroadc",
> + .data = (void *)RCAR_GYROADC_MODEL_DEFAULT,
> + }, {
> + /* RCar V2H specialty without interrupt registers. */
R-Car
> + .compatible = "renesas,rcar-gyroadc-r8a7792",
> + .data = (void *)RCAR_GYROADC_MODEL_R8A7792,
> + }, {
> + /* sentinel */
> + }
> +};
> +static int rcar_gyroadc_probe(struct platform_device *pdev)
> +{
> + priv->fclk = devm_clk_get(dev, "fck");
The module clock isn't used directly by this driver (you don't need
e.g. its rate),
so you can leave out all handling related to this clock iff you enable
runtime PM:
pm_runtime_enable(dev);
pm_runtime_get_sync(dev);
Then runtime PM will take care of enabling the module clock, as the
GyroADC block is part of the CPG/MSSR clock domain.
Doing that also means the driver keeps on working in future SoCs where
the GyroADC block may be located in a power area.
> + if (IS_ERR(priv->fclk)) {
> + ret = PTR_ERR(priv->fclk);
> + dev_err(dev, "Failed to get FCK clock (ret=%i)\n", ret);
Do you need this error message? It will add to the noise in case of
deferred probing.
Please either remove it, or make it depend on != -EPROBE_DEFER.
> + return ret;
> + }
> +
> + priv->clk = devm_clk_get(dev, "if");
> + if (IS_ERR(priv->clk)) {
> + ret = PTR_ERR(priv->clk);
> + dev_err(dev, "Failed to get IF clock (ret=%i)\n", ret);
Likewise.
> + return ret;
> + }
> +
> + ret = of_property_read_u32(pdev->dev.of_node, "renesas,gyroadc-mode",
> + &mode);
> + if (ret || (mode < 1) || (mode > 3)) {
> + dev_err(dev, "Failed to get GyroADC mode (ret=%i)\n", ret);
Note that this will print "ret=0" (no error?) if an invalid mode was specified.
> + return ret;
> + }
> +
> + if (mode == 1)
> + priv->mode = RCAR_GYROADC_MODE_SELECT_1_MB88101A;
> + else if (mode == 2)
> + priv->mode = RCAR_GYROADC_MODE_SELECT_2_ADCS7476;
> + else if (mode == 3)
> + priv->mode = RCAR_GYROADC_MODE_SELECT_3_MAX1162;
switch()? And print the invalid mode message here?
> +
> + of_property_read_u32_array(pdev->dev.of_node, "renesas,gyroadc-vref",
> + priv->vref_uv, (mode == 1) ? 4 : 8);
This call may fail.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH V2 1/2] PM / Domains: Introduce domain-performance-states binding
From: Viresh Kumar @ 2017-01-02 10:05 UTC (permalink / raw)
To: Rob Herring
Cc: Rafael Wysocki, linaro-kernel-cunTk1MwBs8s++Sfvej+rw,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Stephen Boyd, Nishanth Menon,
Vincent Guittot, Mark Rutland, Kevin Hilman, Ulf Hansson,
Lina Iyer, devicetree-u79uwXL29TY76Z2rM5mHXA, Nayak Rajendra
In-Reply-To: <20161222183453.xlkfrb2f4stcfr32@rob-hp-laptop>
On 22-12-16, 12:34, Rob Herring wrote:
> > +Optional properties:
> > +- domain-performance-state: A phandle of a Performance state node.
> > +
> > +Example:
> > +
> > + parent: power-controller@12340000 {
> > + compatible = "foo,power-controller";
> > + reg = <0x12340000 0x1000>;
> > + #power-domain-cells = <0>;
> > + domain-performance-states = <&domain_perf_states>;
> > + };
> > +
> > + domain_perf_states: performance_states {
>
> If you want to have performance states for a domain in DT, then you need
> to actually have a node for the domain in DT. Then this should be a
> child of the domain. I wouldn't think non-CPU domain performance states
> will be common across domains.
So you suggest something like this then ?
+ parent: power-controller@12340000 {
+ compatible = "foo,power-controller";
+ reg = <0x12340000 0x1000>;
+ #power-domain-cells = <0>;
+
+ performance_states {
+ compatible = "domain-performance-state";
+ domain_perf_state1: pstate@1 {
+ performance-level = <1>;
+ domain-microvolt = <970000 975000 985000>;
+ };
+ domain_perf_state2: pstate@2 {
+ performance-level = <2>;
+ domain-microvolt = <1000000 1075000 1085000>;
+ };
+ domain_perf_state3: pstate@3 {
+ performance-level = <3>;
+ domain-microvolt = <1100000 1175000 1185000>;
+ };
+ }
+ };
+
>
> > + compatible = "domain-performance-state";
> > + domain_perf_state1: pstate@1 {
>
> A unit address should have a reg property.
There is no register address here. Similar problem as the OPP table
where we ended up using the frequency. What should we do here ?
> > + performance-level = <1>;
> > + domain-microvolt = <970000 975000 985000>;
> > + };
> > + domain_perf_state2: pstate@2 {
> > + performance-level = <2>;
> > + domain-microvolt = <1000000 1075000 1085000>;
> > + };
> > + domain_perf_state3: pstate@3 {
> > + performance-level = <3>;
> > + domain-microvolt = <1100000 1175000 1185000>;
> > + };
> > + }
> > +
> > + leaky-device@12350000 {
> > + compatible = "foo,i-leak-current";
> > + reg = <0x12350000 0x1000>;
> > + power-domains = <&power 0>;
> > + domain-performance-state = <&domain_perf_state2>;
>
> domain-performance-state and domain-performance-states are too similar
> in name. The property here should probably reflect the mode needed and
> perhaps specific to the device.
Its the state of its power domain which is required for the
functioning of the device.
> I assume a device will need multiple states/modes.
Such devices are handled by the 2nd patch, which uses OPP table for
this. The above example is for simple devices, which have a fixed
requirement.
> Also, since you refer to the performance state node directly, I'm not
> sure why you need the performance-level property.
That value will be used by the genpd core to pass on to the platform
specific code which will take care of updating the domain state. For
example in case of Qcom, it is a separate M3 core which accepts these
values.
--
viresh
--
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: da850-lcdk: add gpio-keys
From: Sekhar Nori @ 2017-01-02 10:38 UTC (permalink / raw)
To: Bartosz Golaszewski, Kevin Hilman, Michael Turquette, Rob Herring,
Frank Rowand, Mark Rutland, Russell King
Cc: arm-soc, linux-devicetree, LKML
In-Reply-To: <1482141234-11546-1-git-send-email-bgolaszewski@baylibre.com>
On Monday 19 December 2016 03:23 PM, Bartosz Golaszewski wrote:
> Add a gpio-keys node for two user buttons present on the board.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Applied to v4.11/dt
Thanks,
Sekhar
^ permalink raw reply
* Re: [PATCH V2 0/2] PM / Domains / OPP: Introduce domain-performance-state binding
From: Viresh Kumar @ 2017-01-02 10:44 UTC (permalink / raw)
To: Rob Herring
Cc: Rafael Wysocki, linaro-kernel, linux-pm, linux-kernel,
Stephen Boyd, Nishanth Menon, Vincent Guittot, Mark Rutland,
Kevin Hilman, Ulf Hansson, Lina Iyer, devicetree, Nayak Rajendra
In-Reply-To: <20161222181422.2cpmdfzeyxdi6vpa@rob-hp-laptop>
On 22-12-16, 12:14, Rob Herring wrote:
> On Mon, Dec 12, 2016 at 04:26:17PM +0530, Viresh Kumar wrote:
> > Hello,
> >
> > Some platforms have the capability to configure the performance state of
> > their Power Domains. The performance levels are represented by positive
> > integer values, a lower value represents lower performance state.
> >
> > We had some discussions about it in the past on the PM list [1], which is
> > followed by discussions during the LPC. The outcome of all that was that we
> > should extend Power Domain framework to support active state power management
> > as well.
> >
> > The power-domains until now were only concentrating on the idle state
> > management of the device and this needs to change in order to reuse the
> > infrastructure of power domains for active state management.
>
> From a h/w perspective, are idle states really different from
> performance states?
Its a tricky question TBH :)
The device is almost powered off during the idle states, while
performance states here are the functioning of the device. I haven't
answered your question well, perhaps I need a more direct question :)
> > To get a complete picture of the proposed plan, following is what we
> > need to do:
> > - Create DT bindings to get domain performance state information for the
> > platforms.
>
> I would do this last so you can evolve things if you're not certain
> about what the bindings should look like. You can always start with
> things in the kernel and add to DT later.
I didn't knew that and it looks like a very good option. I am not sure
if I would like to do that for this series though. Maybe lets discuss
the bindings a bit more and if we aren't able to find a common ground,
I can try code first.
> While in theory we should be able to just "describe the h/w" in DT and
Right.
> develop the Linux side independently, this feels too much like the
> bindings are just evolving with Linux needs.
:)
--
viresh
^ permalink raw reply
* Re: [PATCH v6 9/9] misc: mux-adg792a: add mux controller driver for ADG792A/G
From: Peter Rosin @ 2017-01-02 11:00 UTC (permalink / raw)
To: Jonathan Cameron, linux-kernel
Cc: Wolfram Sang, Rob Herring, Mark Rutland, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler, Jonathan Corbet,
Arnd Bergmann, Greg Kroah-Hartman, linux-i2c, devicetree,
linux-iio, linux-doc
In-Reply-To: <fb8a7864-a6cf-351f-b9c5-a5036c30474e@kernel.org>
On 2017-01-01 12:24, Jonathan Cameron wrote:
> On 30/11/16 08:17, Peter Rosin wrote:
>> Analog Devices ADG792A/G is a triple 4:1 mux.
>>
>> Signed-off-by: Peter Rosin <peda@axentia.se>
> Looks pretty good. Some minor suggestions inline.
>
> This convinced me of two things:
> 1. Need a separate subsystem directory for muxes - having them under misc
> is going to lead to long term mess.
> 2. Devm alloc and registration functions will make the drivers all simpler.
Ok, I'm making the move to drivers/mux/* for v7 and adding more devm_*
functions.
> Also, browsing through ADIs list of muxes and switches it's clear that
> one classic case will be where an i2c octal or similar switch is used with
> outputs wired together in weird combinations to act as a mux. Going to
> be 'fun' describing that.
>
> There are also potentially cross point switches to be described ;)
> (I had to look up what one of those was ;)
>
> Crosspoints aren't implausible as front ends for ADCs as you might
> want to be able rapidly sample any 2 of say 16 channels coming from
> for example a max14661. We'd have to figure out how to add buffered
> capture support with sensible restrictions to the iio-mux driver
> to do that - realistically I think we would just not allow buffered
> capture with the mux having to switch. Without hardware support
> (i.e. an ADC with external mux control) it would be too slow.
>
> Always good to bury some idle thoughts deep in the review of a random
> driver ;) I'll never be able to remember where they were let alone
> anyone else.
But that's switches, and this is muxes. Switches are way more flexible,
so it's only natural that they are on a completely different level when
it comes to trying a generic description of them... Intentionally not
going there :-)
>> ---
>> drivers/misc/Kconfig | 12 ++++
>> drivers/misc/Makefile | 1 +
>> drivers/misc/mux-adg792a.c | 154 +++++++++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 167 insertions(+)
>> create mode 100644 drivers/misc/mux-adg792a.c
>>
>> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
>> index 2ce675e410c5..45567a444bbf 100644
>> --- a/drivers/misc/Kconfig
>> +++ b/drivers/misc/Kconfig
>> @@ -780,6 +780,18 @@ menuconfig MULTIPLEXER
>>
>> if MULTIPLEXER
>>
>> +config MUX_ADG792A
>> + tristate "Analog Devices ADG792A/ADG792G Multiplexers"
>> + depends on I2C
>> + help
>> + ADG792A and ADG792G Wide Bandwidth Triple 4:1 Multiplexers
>> +
>> + The driver supports both operating the three multiplexers in
>> + parellel and operating them independently.
> parallel
>> +
>> + To compile the driver as a module, choose M here: the module will
>> + be called mux-adg792a.
>> +
>> config MUX_GPIO
>> tristate "GPIO-controlled Multiplexer"
>> depends on OF && GPIOLIB
>> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
>> index 0befa2bba762..10ab8d34c9e5 100644
>> --- a/drivers/misc/Makefile
>> +++ b/drivers/misc/Makefile
>> @@ -54,6 +54,7 @@ obj-$(CONFIG_VEXPRESS_SYSCFG) += vexpress-syscfg.o
>> obj-$(CONFIG_CXL_BASE) += cxl/
>> obj-$(CONFIG_PANEL) += panel.o
>> obj-$(CONFIG_MULTIPLEXER) += mux-core.o
>> +obj-$(CONFIG_MUX_ADG792A) += mux-adg792a.o
>> obj-$(CONFIG_MUX_GPIO) += mux-gpio.o
>>
>> lkdtm-$(CONFIG_LKDTM) += lkdtm_core.o
>> diff --git a/drivers/misc/mux-adg792a.c b/drivers/misc/mux-adg792a.c
>> new file mode 100644
>> index 000000000000..7d309a78af65
>> --- /dev/null
>> +++ b/drivers/misc/mux-adg792a.c
>> @@ -0,0 +1,154 @@
>> +/*
>> + * Multiplexer driver for Analog Devices ADG792A/G Triple 4:1 mux
>> + *
>> + * Copyright (C) 2016 Axentia Technologies AB
>> + *
>> + * Author: Peter Rosin <peda@axentia.se>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#include <linux/err.h>
>> +#include <linux/i2c.h>
>> +#include <linux/module.h>
>> +#include <linux/mux.h>
>> +
>> +#define ADG792A_LDSW BIT(0)
>> +#define ADG792A_RESET BIT(1)
>> +#define ADG792A_DISABLE(mux) (0x50 | (mux))
>> +#define ADG792A_DISABLE_ALL (0x5f)
>> +#define ADG792A_MUX(mux, state) (0xc0 | (((mux) + 1) << 2) | (state))
>> +#define ADG792A_MUX_ALL(state) (0xc0 | (state))
>> +
>> +#define ADG792A_DISABLE_STATE (4)
>> +#define ADG792A_KEEP_STATE (5)
>> +
>> +static int adg792a_set(struct mux_control *mux, int state)
>> +{
>> + struct i2c_client *i2c = to_i2c_client(mux->chip->dev.parent);
>> + u8 cmd;
>> +
>> + if (mux->chip->controllers == 1) {
>> + /* parallel mux controller operation */
>> + if (state == ADG792A_DISABLE_STATE)
>> + cmd = ADG792A_DISABLE_ALL;
>> + else
>> + cmd = ADG792A_MUX_ALL(state);
>> + } else {
>> + unsigned int controller = mux_control_get_index(mux);
>> +
>> + if (state == ADG792A_DISABLE_STATE)
>> + cmd = ADG792A_DISABLE(controller);
>> + else
>> + cmd = ADG792A_MUX(controller, state);
>> + }
>> +
>> + return i2c_smbus_write_byte_data(i2c, cmd, ADG792A_LDSW);
>> +}
>> +
>> +static const struct mux_control_ops adg792a_ops = {
>> + .set = adg792a_set,
>> +};
>> +
>> +static int adg792a_probe(struct i2c_client *i2c,
>> + const struct i2c_device_id *id)
>> +{
>> + struct device *dev = &i2c->dev;
>> + struct mux_chip *mux_chip;
>> + bool parallel;
>> + int ret;
>> + int i;
>> +
>> + parallel = of_property_read_bool(i2c->dev.of_node, "adi,parallel");
>> +
>> + mux_chip = mux_chip_alloc(dev, parallel ? 1 : 3, 0);
> This makes me wonder if we can have a more generic binding.
> mux-poles = 3 vs mux-poles = 1?
The adg729 in theory allows to create one double pole mux and one single
pole mux (three variations, depending on which mux is single pole).
However, I did not put all that much effort into this driver. It is
mainly a proof of concept, as mentioned in the cover letter, to "prove"
that the proposed mux bindings are valid and that it is right to
have separate mux nodes in devicetree. I'm not even sure it should
be going upstream as it has seen zero testing. (But hey, it builds, what
can be wrong?)
>> + if (!mux_chip)
>> + return -ENOMEM;
>> +
>> + mux_chip->ops = &adg792a_ops;
>> + dev_set_drvdata(dev, mux_chip);
>> +
>> + ret = i2c_smbus_write_byte_data(i2c, ADG792A_DISABLE_ALL,
>> + ADG792A_RESET | ADG792A_LDSW);
>> + if (ret < 0)
>> + goto free_mux_chip;
>> +
>> + for (i = 0; i < mux_chip->controllers; ++i) {
>> + struct mux_control *mux = &mux_chip->mux[i];
>> + u32 idle_state;
>> +
>> + mux->states = 4;
>> +
>> + ret = of_property_read_u32_index(i2c->dev.of_node,
>> + "adi,idle-state", i,
>> + &idle_state);
>> + if (ret >= 0) {
>> + if (idle_state > ADG792A_KEEP_STATE) {
>> + dev_err(dev, "invalid idle-state %u\n",
>> + idle_state);
>> + ret = -EINVAL;
>> + goto free_mux_chip;
>> + }
>> + if (idle_state != ADG792A_KEEP_STATE)
>> + mux->idle_state = idle_state;
>> + }
>> + }
>> +
>> + ret = mux_chip_register(mux_chip);
>> + if (ret < 0) {
>> + dev_err(dev, "failed to register mux-chip\n");
>> + goto free_mux_chip;
>> + }
>> +
>> + if (parallel)
>> + dev_info(dev, "1 triple 4-way mux-controller registered\n");
> I'd use the relay / switch standard description for this so
> 'triple pole, quadruple throw mux registered'.
>> + else
>> + dev_info(dev, "3 4-way mux-controllers registered\n");
> '3x single pole, quadruple throw muxes registered'.
Ok, fine by me.
>> +
>> + return 0;
>> +
>> +free_mux_chip:
>> + mux_chip_free(mux_chip);
>> + return ret;
>> +}
>> +
>> +static int adg792a_remove(struct i2c_client *i2c)
>> +{
>> + struct mux_chip *mux_chip = dev_get_drvdata(&i2c->dev);
>> +
> Definitely looking like it's worth managed versions of mux_chip_register and
> mux_chip_alloc given this is another case where they would let us get rid
> of the remove function entirely.
>> + mux_chip_unregister(mux_chip);
>> + mux_chip_free(mux_chip);
>> +
>> + return 0;
>> +}
>> +
>> +static const struct i2c_device_id adg792a_id[] = {
>> + { .name = "adg792a", },
>> + { .name = "adg792g", },
>> + { }
>> +};
>> +MODULE_DEVICE_TABLE(i2c, adg792a_id);
>> +
>> +static const struct of_device_id adg792a_of_match[] = {
>> + { .compatible = "adi,adg792a", },
>> + { .compatible = "adi,adg792g", },
>> + { }
>> +};
>> +MODULE_DEVICE_TABLE(of, adg792a_of_match);
>> +
>> +static struct i2c_driver adg792a_driver = {
>> + .driver = {
>> + .name = "adg792a",
>> + .of_match_table = of_match_ptr(adg792a_of_match),
>> + },
>> + .probe = adg792a_probe,
>> + .remove = adg792a_remove,
>> + .id_table = adg792a_id,
>> +};
>> +module_i2c_driver(adg792a_driver);
>> +
>> +MODULE_DESCRIPTION("Analog Devices ADG792A/G Triple 4:1 mux driver");
>> +MODULE_AUTHOR("Peter Rosin <peda@axentia.se");
>> +MODULE_LICENSE("GPL v2");
>>
>
^ permalink raw reply
* Re: [PATCH v7 1/5] ARM: dts: da850: rename the display node label
From: Sekhar Nori @ 2017-01-02 11:04 UTC (permalink / raw)
To: Tomi Valkeinen, Bartosz Golaszewski, Jyri Sarha, David Airlie,
Kevin Hilman, Michael Turquette, Rob Herring, Frank Rowand,
Mark Rutland, Laurent Pinchart, Peter Ujfalusi, Russell King,
Maxime Ripard
Cc: LKML, arm-soc, linux-drm, linux-devicetree
In-Reply-To: <750eaa32-ca29-b140-eec6-cec4350cf304-l0cyMroinI0@public.gmane.org>
On Wednesday 14 December 2016 03:27 PM, Tomi Valkeinen wrote:
> On 13/12/16 12:09, Bartosz Golaszewski wrote:
>> The tilcdc node name is 'display' as per the ePAPR 1.1 recommendation.
>> The label is also 'display', but change it to 'lcdc' to make it clear
>> what the underlying hardware is.
>>
>> Signed-off-by: Bartosz Golaszewski <bgolaszewski-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>> ---
>> arch/arm/boot/dts/da850.dtsi | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>> index 104155d..6b0ef3d 100644
>> --- a/arch/arm/boot/dts/da850.dtsi
>> +++ b/arch/arm/boot/dts/da850.dtsi
>> @@ -458,7 +458,7 @@
>> dma-names = "tx", "rx";
>> };
>>
>> - display: display@213000 {
>> + lcdc: display@213000 {
>> compatible = "ti,da850-tilcdc";
>> reg = <0x213000 0x1000>;
>> interrupts = <52>;
>>
>
> Reviewed-by: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Applied with Tomi's reviewed-by.
Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v7 3/5] drm: bridge: add support for TI ths8135
From: Sekhar Nori @ 2017-01-02 11:08 UTC (permalink / raw)
To: Archit Taneja, Bartosz Golaszewski, Jyri Sarha, Tomi Valkeinen,
David Airlie, Kevin Hilman, Michael Turquette, Rob Herring,
Frank Rowand, Mark Rutland, Laurent Pinchart, Peter Ujfalusi,
Russell King, Maxime Ripard
Cc: LKML, arm-soc, linux-drm, linux-devicetree
In-Reply-To: <dbb47a8f-07be-19d6-e77b-f5c06fd39c61@codeaurora.org>
Hi Archit,
On Wednesday 14 December 2016 10:35 AM, Archit Taneja wrote:
>
>
> On 12/13/2016 03:39 PM, Bartosz Golaszewski wrote:
>> THS8135 is a configurable video DAC, but no configuration is actually
>> necessary to make it work.
>>
>> For now use the dumb-vga-dac driver to support it.
>
> Queued to drm-misc-next
This patch and 2/5 are not in v4.10 kernel. Did you mean to queue them
to v4.10?
Thanks,
Sekhar
^ permalink raw reply
* Re: [PATCH v7 4/5] ARM: dts: da850-lcdk: add the vga-bridge node
From: Sekhar Nori @ 2017-01-02 11:16 UTC (permalink / raw)
To: Tomi Valkeinen, Bartosz Golaszewski, Jyri Sarha, David Airlie,
Kevin Hilman, Michael Turquette, Rob Herring, Frank Rowand,
Mark Rutland, Laurent Pinchart, Peter Ujfalusi, Russell King,
Maxime Ripard
Cc: LKML, arm-soc, linux-drm, linux-devicetree
In-Reply-To: <0ad07b84-7f5a-6467-e310-52c3efc66d3d-l0cyMroinI0@public.gmane.org>
On Wednesday 14 December 2016 03:24 PM, Tomi Valkeinen wrote:
> On 13/12/16 12:09, Bartosz Golaszewski wrote:
>> Add the vga-bridge node to the board DT together with corresponding
>> ports and vga connector. This allows to retrieve the edid info from
>> the display automatically.
>>
>> Signed-off-by: Bartosz Golaszewski <bgolaszewski-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>> Reviewed-by: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
>> ---
>> arch/arm/boot/dts/da850-lcdk.dts | 51 ++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 51 insertions(+)
>
> Reviewed-by: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Applied to v4.11/dt with Tomi's reviewed-by.
Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH V7 3/4] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge
From: Peter Senna Tschudin @ 2017-01-02 11:26 UTC (permalink / raw)
To: Peter Senna Tschudin
Cc: kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
enric.balletbo-ZGY8ohtN/8qB+jHODAdFcQ,
mchehab-JPH+aEBZ4P+UEJcrhfAQsw, tiwai-IBi9RG/b67k,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b, Rob Herring,
javier-0uQlZySMnqxg9hUCZPvPmw, devicetree-u79uwXL29TY76Z2rM5mHXA,
martin.donnelly-JJi787mZWgc, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
eballetbo-Re5JQEeQqe8AvxtiuMwx3w, pawel.moll-5wv7dgnIgG8,
airlied-cv59FeDIM0c, treding-DDmLM1+adcrQT0dZR+AlfA,
heiko-4mtYJXux2i+zQB+pC5nmwQ,
thierry.reding-Re5JQEeQqe8AvxtiuMwx3w, daniel.vetter-/w4YWyX8dFk,
linux-0h96xk9xTtrk1uMJSBkQmQ, Fabio Estevam, jslaby-AlSwsSmVLrQ,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
martyn.welch-ZGY8ohtN/8pPYcu2f3hruQ,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
galak-sgV2jX0FEOL9JmXXK+q4OQ, peter.senna-Re5JQEeQqe8AvxtiuMwx3w,
architt-sgV2jX0FEOL9JmXXK+q4OQ, ykk-TNX95d0MmH7DzftRWevZcw
In-Reply-To: <4232c88a99f44a24287d04d74b891e2eb139864c.1483301745.git.peter.senna-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>
On 01 January, 2017 21:24 CET, Peter Senna Tschudin <peter.senna-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org> wrote:
[ ... ]
> +static void ge_b850v3_lvds_dp_detach(struct drm_bridge *bridge)
> +{
> + struct ge_b850v3_lvds_dp *ptn_bridge
> + = bridge_to_ge_b850v3_lvds_dp(bridge);
> + struct i2c_client *ge_b850v3_lvds_dp_i2c
> + = ptn_bridge->ge_b850v3_lvds_dp_i2c;
> +
> + /* Disable interrupts */
> + i2c_smbus_write_word_data(ge_b850v3_lvds_dp_i2c,
> + STDP4028_DPTX_IRQ_EN_REG, ~STDP4028_DPTX_IRQ_CONFIG);
~STDP4028_DPTX_IRQ_CONFIG? Argh! Will fix this and resend after reviews...
[ ... ]
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v7 5/5] ARM: dts: da850: specify the maximum pixel clock rate for tilcdc
From: Sekhar Nori @ 2017-01-02 11:29 UTC (permalink / raw)
To: Bartosz Golaszewski, Jyri Sarha, Tomi Valkeinen, David Airlie,
Kevin Hilman, Michael Turquette, Rob Herring, Frank Rowand,
Mark Rutland, Laurent Pinchart, Peter Ujfalusi, Russell King,
Maxime Ripard
Cc: LKML, arm-soc, linux-drm, linux-devicetree
In-Reply-To: <1481623759-12786-6-git-send-email-bgolaszewski@baylibre.com>
On Tuesday 13 December 2016 03:39 PM, Bartosz Golaszewski wrote:
> At maximum CPU frequency of 300 MHz the maximum pixel clock frequency
> is 37.5 MHz[1]. We must filter out any mode for which the calculated
> pixel clock rate would exceed this value.
>
> Specify the max-pixelclock property for the display node for
> da850-lcdk.
>
> [1] http://processors.wiki.ti.com/index.php/OMAP-L1x/C674x/AM1x_LCD_Controller_(LCDC)_Throughput_and_Optimization_Techniques
This wiki page is not really a TI datasheet and can change without
notice. I changed this to refer to
http://www.ti.com/lit/ds/symlink/am1808.pdf (SPRS653E, revised March
2014), table 6-110.
Applied to v4.11/dt
Thanks,
Sekhar
^ permalink raw reply
* Re: [PATCH v3 0/2] Add support for the S6E3HA2 panel on TM2 board
From: Andrzej Hajda @ 2017-01-02 12:06 UTC (permalink / raw)
To: Hoegeun Kwon, robh, thierry.reding, airlied, kgene, krzk
Cc: dri-devel, linux-kernel, devicetree, linux-samsung-soc, inki.dae,
cw00.choi, jh80.chung
In-Reply-To: <1483081108-32055-1-git-send-email-hoegeun.kwon@samsung.com>
On 30.12.2016 07:58, Hoegeun Kwon wrote:
> Purpose of this patch is add support for S6E3HA2 AMOLED panel on
> the TM2 board. The first patch adds support for S6E3HA2 panel
> device tree document and driver, the second patch add support for
> S6E3HA2 panel device tree.
>
> Changes for V3:
>
> - In the DT binding document, made it clearly that the panel is a
> child node of dsi.
> - Fix reset-gpio active from high to low.
> - Is the OF graph saying related to [1]?
Yes, video-interfaces described in [1] are OF graphs described in [2]
with additional properties specific for video pipelines.
[2]: Documentation/devicetree/bindings/graph.txt
> Althogh the panel is a child of dsi, I think OF graph necessary.
> because if a remote-endpoint is not specified, the dsi also
> panel is not probed.
OK, I see the issue: dsi driver requires presence of DSI_PORT_OUT
endpoint, because it needs to read MIPI-DSI burst and esc clock
frequencies from these nodes, however it does not use it to get panel
node, panel node is get by .attach callback. Probably these clock
frequencies should be passed via struct mipi_dsi_device.
So as for now I think it would be simpler to leave OF graph, as it is
already used this way in other drivers.
> - The display-timings has been fixed to be provided by the device
> driver. however, I think display-timings is necessary in dts.
> because if dts does not have display-timings, dsi will not load.
After examining drivers it looks like these timings, beside panel, are
read by MIC driver, and this is wrong. MIC driver shouldn't peek into
other driver's nodes, it can use DRM callbacks (mode_fixup, mode_set) to
get necessary information. And more importantly display-timings in
panels are not accepted by panels maintainer AFAIK, see [1] for rationale.
[1]:
https://sietch-tagr.blogspot.de/2016/04/display-panels-are-not-special.html
Regards
Andrzej
>
> [1]: Documentation/devicetree/bindings/media/video-interfaces.txt
>
> Hoegeun Kwon (1):
> drm/panel: Add support for S6E3HA2 panel driver on TM2 board
>
> Hyungwon Hwang (1):
> arm64: dts: exynos: Add support for S6E3HA2 panel device on TM2 board
>
> .../bindings/display/panel/samsung,s6e3ha2.txt | 58 ++
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 31 +
> drivers/gpu/drm/panel/Kconfig | 6 +
> drivers/gpu/drm/panel/Makefile | 1 +
> drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 741 +++++++++++++++++++++
> 5 files changed, 837 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
> create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
>
^ permalink raw reply
* Re: [PATCH] DTS: MCCMON6: IMX: Provide support for iMX6Q based Liebherr mccmon6 board
From: Vladimir Zapolskiy @ 2017-01-02 12:20 UTC (permalink / raw)
To: Lukasz Majewski, Rob Herring, Mark Rutland, Russell King,
Shawn Guo, Fabio Estevam, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Sascha Hauer, Zerlauth Karl (LWN)
In-Reply-To: <1482794396-16153-1-git-send-email-l.majewski-AM3owJQeAb5mR6Xm/wNWPw@public.gmane.org>
Hello Lukasz,
On 12/27/2016 01:19 AM, Lukasz Majewski wrote:
> Signed-off-by: Lukasz Majewski <l.majewski-AM3owJQeAb5mR6Xm/wNWPw@public.gmane.org>
please add a commit message with a short description of the change.
Also change subject line to "ARM: dts: imx6q: Add mccmon6 board support".
> ---
> MCCMON6 board support depends on following patches:
>
> 1. "video: backlight: pwm_bl: Initialize fb_bl_on[x] and use_count during pwm_backlight_probe()"
> http://patchwork.ozlabs.org/patch/708844/
>
> 2. "pwm: imx: Provide atomic operation for IMX PWM driver"
> http://patchwork.ozlabs.org/patch/708847/ - http://patchwork.ozlabs.org/patch/708843/
>
>
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/imx6q-mccmon6.dts | 469 ++++++++++++++++++++++++++++++++++++
> 2 files changed, 470 insertions(+)
> create mode 100644 arch/arm/boot/dts/imx6q-mccmon6.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index c558ba7..7ce1080 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -382,6 +382,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
> imx6q-h100.dtb \
> imx6q-hummingboard.dtb \
> imx6q-icore-rqs.dtb \
> + imx6q-mccmon6.dtb \
> imx6q-marsboard.dtb \
Please add a new line preserving alphabetical order.
> imx6q-nitrogen6x.dtb \
> imx6q-nitrogen6_max.dtb \
> diff --git a/arch/arm/boot/dts/imx6q-mccmon6.dts b/arch/arm/boot/dts/imx6q-mccmon6.dts
> new file mode 100644
> index 0000000..7445d01
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6q-mccmon6.dts
> @@ -0,0 +1,469 @@
> +/*
> + * Copyright 2016
Copyright holder is missing.
> + *
> + * Author: Lukasz Majewski <l.majewski-AM3owJQeAb5mR6Xm/wNWPw@public.gmane.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + */
Please add an empty line here to improve readability.
> +/dts-v1/;
Please add an empty line here to improve readability.
> +#include "imx6q.dtsi"
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/pwm/pwm.h>
> +
> +/ {
> + model = "Monitor6 i.MX6 Quad Board";
Missing hardware vendor name.
> + compatible = "mccmon6", "fsl,imx6q";
Missing hardware vendor prefix before "mccmon6".
> +
> + memory {
> + reg = <0x10000000 0x80000000>;
> + };
> +
> + ethernet0 {
> + status = "okay";
> + };
It looks like a useless device node, you have a description of &fec already.
> +
> + backlight_lvds: backlight {
> + compatible = "pwm-backlight";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_display>;
I would recommend to rename "pinctrl_display" to "pinctrl_backlight".
> + pwms = <&pwm2 0 5000000 PWM_POLARITY_INVERTED>;
This should work when extension to the i.MX PWM driver is merged.
> + brightness-levels = < 0 1 2 3 4 5 6 7 8 9
> + 10 11 12 13 14 15 16 17 18 19
> + 20 21 22 23 24 25 26 27 28 29
> + 30 31 32 33 34 35 36 37 38 39
> + 40 41 42 43 44 45 46 47 48 49
> + 50 51 52 53 54 55 56 57 58 59
> + 60 61 62 63 64 65 66 67 68 69
> + 70 71 72 73 74 75 76 77 78 79
> + 80 81 82 83 84 85 86 87 88 89
> + 90 91 92 93 94 95 96 97 98 99
> + 100 101 102 103 104 105 106 107 108 109
> + 110 111 112 113 114 115 116 117 118 119
> + 120 121 122 123 124 125 126 127 128 129
> + 130 131 132 133 134 135 136 137 138 139
> + 140 141 142 143 144 145 146 147 148 149
> + 150 151 152 153 154 155 156 157 158 159
> + 160 161 162 163 164 165 166 167 168 169
> + 170 171 172 173 174 175 176 177 178 179
> + 180 181 182 183 184 185 186 187 188 189
> + 190 191 192 193 194 195 196 197 198 199
> + 200 201 202 203 204 205 206 207 208 209
> + 210 211 212 213 214 215 216 217 218 219
> + 220 221 222 223 224 225 226 227 228 229
> + 230 231 232 233 234 235 236 237 238 239
> + 240 241 242 243 244 245 246 247 248 249
> + 250 251 252 253 254 255>;
I'm not sure that actually need such a long list of brightness levels.
> + default-brightness-level = <50>;
> + enable-gpios = <&gpio1 2 GPIO_ACTIVE_LOW>;
> + };
> +
> + reg_lvds: regulator-lvds {
> + compatible = "regulator-fixed";
> + regulator-name = "lvds_ppen";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-boot-on;
> + gpio = <&gpio1 19 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> + panel-lvds0 {
> + compatible = "innolux,g121x1-l03";
> + backlight = <&backlight_lvds>;
> + power-supply = <®_lvds>;
> +
> + port {
> + panel_in_lvds0: endpoint {
> + remote-endpoint = <&lvds0_out>;
> + };
> + };
> + };
> +};
> +
> +&i2c1 {
> + clock-frequency = <100000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_i2c1>;
> + status = "okay";
> +};
> +
> +&i2c2 {
> + clock-frequency = <100000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_i2c2>;
> + status = "okay";
> +
> + pmic: pfuze100@08 {
> + compatible = "fsl,pfuze100";
> + reg = <0x08>;
> +
> + regulators {
> + sw1a_reg: sw1ab {
> + regulator-min-microvolt = <300000>;
> + regulator-max-microvolt = <1875000>;
> + regulator-boot-on;
> + regulator-always-on;
> + regulator-ramp-delay = <6250>;
> + };
> +
> + sw1c_reg: sw1c {
> + regulator-min-microvolt = <300000>;
> + regulator-max-microvolt = <1875000>;
> + regulator-boot-on;
> + regulator-always-on;
> + regulator-ramp-delay = <6250>;
> + };
> +
> + sw2_reg: sw2 {
> + regulator-min-microvolt = <800000>;
> + regulator-max-microvolt = <3950000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + sw3a_reg: sw3a {
> + regulator-min-microvolt = <400000>;
> + regulator-max-microvolt = <1975000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + sw3b_reg: sw3b {
> + regulator-min-microvolt = <400000>;
> + regulator-max-microvolt = <1975000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + sw4_reg: sw4 {
> + regulator-min-microvolt = <800000>;
> + regulator-max-microvolt = <3300000>;
> + };
> +
> + swbst_reg: swbst {
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5150000>;
> + };
> +
> + snvs_reg: vsnvs {
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <3000000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + vref_reg: vrefddr {
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + vgen1_reg: vgen1 {
> + regulator-min-microvolt = <800000>;
> + regulator-max-microvolt = <1550000>;
> + };
> +
> + vgen2_reg: vgen2 {
> + regulator-min-microvolt = <800000>;
> + regulator-max-microvolt = <1550000>;
> + };
> +
> + vgen3_reg: vgen3 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + };
> +
> + vgen4_reg: vgen4 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + };
> +
> + vgen5_reg: vgen5 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + };
> +
> + vgen6_reg: vgen6 {
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + };
> + };
> + };
> +};
> +
> +&iomuxc {
> + pinctrl-names = "default";
> +
> + imx6q-mccmon6 {
> +
Please drop the empty line above.
> + pinctrl_enet: enetgrp {
> + fsl,pins = <
> + MX6QDL_PAD_ENET_MDIO__ENET_MDIO 0x1b0b0
> + MX6QDL_PAD_ENET_MDC__ENET_MDC 0x1b0b0
> + MX6QDL_PAD_RGMII_TXC__RGMII_TXC 0x1b0b0
> + MX6QDL_PAD_RGMII_TD0__RGMII_TD0 0x1b0b0
> + MX6QDL_PAD_RGMII_TD1__RGMII_TD1 0x1b0b0
> + MX6QDL_PAD_RGMII_TD2__RGMII_TD2 0x1b0b0
> + MX6QDL_PAD_RGMII_TD3__RGMII_TD3 0x1b0b0
> + MX6QDL_PAD_RGMII_TX_CTL__RGMII_TX_CTL 0x1b0b0
> + MX6QDL_PAD_ENET_REF_CLK__ENET_TX_CLK 0x1b0b0
> + MX6QDL_PAD_RGMII_RXC__RGMII_RXC 0x1b0b0
> + MX6QDL_PAD_RGMII_RD0__RGMII_RD0 0x1b0b0
> + MX6QDL_PAD_RGMII_RD1__RGMII_RD1 0x1b0b0
> + MX6QDL_PAD_RGMII_RD2__RGMII_RD2 0x1b0b0
> + MX6QDL_PAD_RGMII_RD3__RGMII_RD3 0x1b0b0
> + MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL 0x1b0b0
> + MX6QDL_PAD_GPIO_16__ENET_REF_CLK 0x4001b0a8
> + MX6QDL_PAD_GPIO_6__ENET_IRQ 0x000b1
> + >;
> + };
> +
> + pinctrl_i2c1: i2c1grp {
> + fsl,pins = <
> + MX6QDL_PAD_CSI0_DAT9__I2C1_SCL 0x4001b8b1
> + MX6QDL_PAD_CSI0_DAT8__I2C1_SDA 0x4001b8b1
> + >;
> + };
> +
> + pinctrl_i2c2: i2c2grp {
> + fsl,pins = <
> + MX6QDL_PAD_KEY_COL3__I2C2_SCL 0x4001b8b1
> + MX6QDL_PAD_KEY_ROW3__I2C2_SDA 0x4001b8b1
> + >;
> + };
> +
> + pinctrl_uart1: uart1grp {
> + fsl,pins = <
> + MX6QDL_PAD_CSI0_DAT10__UART1_TX_DATA 0x1b0b1
> + MX6QDL_PAD_CSI0_DAT11__UART1_RX_DATA 0x1b0b1
> + >;
> + };
> +
> + pinctrl_usdhc2: usdhc2grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD2_CMD__SD2_CMD 0x17059
> + MX6QDL_PAD_SD2_CLK__SD2_CLK 0x10059
> + MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x17059
> + MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x17059
> + MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x17059
> + MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x17059
> + >;
> + };
> +
> + pinctrl_usdhc3: usdhc3grp {
> + fsl,pins = <
> + MX6QDL_PAD_SD3_CMD__SD3_CMD 0x17059
> + MX6QDL_PAD_SD3_CLK__SD3_CLK 0x10059
> + MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x17059
> + MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x17059
> + MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x17059
> + MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x17059
> + MX6QDL_PAD_SD3_DAT4__SD3_DATA4 0x17059
> + MX6QDL_PAD_SD3_DAT5__SD3_DATA5 0x17059
> + MX6QDL_PAD_SD3_DAT6__SD3_DATA6 0x17059
> + MX6QDL_PAD_SD3_DAT7__SD3_DATA7 0x17059
> + MX6QDL_PAD_SD3_RST__SD3_RESET 0x17059
> + >;
> + };
> +
> + pinctrl_weim_cs0: weimcs0grp {
> + fsl,pins = <
> + MX6QDL_PAD_EIM_CS0__EIM_CS0_B 0xb0b1
> + >;
> + };
> +
> + pinctrl_weim_nor: weimnorgrp {
> + fsl,pins = <
> + MX6QDL_PAD_EIM_OE__EIM_OE_B 0xb0b1
> + MX6QDL_PAD_EIM_RW__EIM_RW 0xb0b1
> + MX6QDL_PAD_EIM_WAIT__EIM_WAIT_B 0xb060
> + MX6QDL_PAD_EIM_D16__EIM_DATA16 0x1b0b0
> + MX6QDL_PAD_EIM_D17__EIM_DATA17 0x1b0b0
> + MX6QDL_PAD_EIM_D18__EIM_DATA18 0x1b0b0
> + MX6QDL_PAD_EIM_D19__EIM_DATA19 0x1b0b0
> + MX6QDL_PAD_EIM_D20__EIM_DATA20 0x1b0b0
> + MX6QDL_PAD_EIM_D21__EIM_DATA21 0x1b0b0
> + MX6QDL_PAD_EIM_D22__EIM_DATA22 0x1b0b0
> + MX6QDL_PAD_EIM_D23__EIM_DATA23 0x1b0b0
> + MX6QDL_PAD_EIM_D24__EIM_DATA24 0x1b0b0
> + MX6QDL_PAD_EIM_D25__EIM_DATA25 0x1b0b0
> + MX6QDL_PAD_EIM_D26__EIM_DATA26 0x1b0b0
> + MX6QDL_PAD_EIM_D27__EIM_DATA27 0x1b0b0
> + MX6QDL_PAD_EIM_D28__EIM_DATA28 0x1b0b0
> + MX6QDL_PAD_EIM_D29__EIM_DATA29 0x1b0b0
> + MX6QDL_PAD_EIM_D30__EIM_DATA30 0x1b0b0
> + MX6QDL_PAD_EIM_D31__EIM_DATA31 0x1b0b0
> + MX6QDL_PAD_EIM_A23__EIM_ADDR23 0xb0b1
> + MX6QDL_PAD_EIM_A22__EIM_ADDR22 0xb0b1
> + MX6QDL_PAD_EIM_A21__EIM_ADDR21 0xb0b1
> + MX6QDL_PAD_EIM_A20__EIM_ADDR20 0xb0b1
> + MX6QDL_PAD_EIM_A19__EIM_ADDR19 0xb0b1
> + MX6QDL_PAD_EIM_A18__EIM_ADDR18 0xb0b1
> + MX6QDL_PAD_EIM_A17__EIM_ADDR17 0xb0b1
> + MX6QDL_PAD_EIM_A16__EIM_ADDR16 0xb0b1
> + MX6QDL_PAD_EIM_DA15__EIM_AD15 0xb0b1
> + MX6QDL_PAD_EIM_DA14__EIM_AD14 0xb0b1
> + MX6QDL_PAD_EIM_DA13__EIM_AD13 0xb0b1
> + MX6QDL_PAD_EIM_DA12__EIM_AD12 0xb0b1
> + MX6QDL_PAD_EIM_DA11__EIM_AD11 0xb0b1
> + MX6QDL_PAD_EIM_DA10__EIM_AD10 0xb0b1
> + MX6QDL_PAD_EIM_DA9__EIM_AD09 0xb0b1
> + MX6QDL_PAD_EIM_DA8__EIM_AD08 0xb0b1
> + MX6QDL_PAD_EIM_DA7__EIM_AD07 0xb0b1
> + MX6QDL_PAD_EIM_DA6__EIM_AD06 0xb0b1
> + MX6QDL_PAD_EIM_DA5__EIM_AD05 0xb0b1
> + MX6QDL_PAD_EIM_DA4__EIM_AD04 0xb0b1
> + MX6QDL_PAD_EIM_DA3__EIM_AD03 0xb0b1
> + MX6QDL_PAD_EIM_DA2__EIM_AD02 0xb0b1
> + MX6QDL_PAD_EIM_DA1__EIM_AD01 0xb0b1
> + MX6QDL_PAD_EIM_DA0__EIM_AD00 0xb0b1
> + >;
> + };
> +
> + pinctrl_ecspi3: ecspi3grp {
> + fsl,pins = <
> + MX6QDL_PAD_DISP0_DAT2__ECSPI3_MISO 0x100b1
> + MX6QDL_PAD_DISP0_DAT1__ECSPI3_MOSI 0x100b1
> + MX6QDL_PAD_DISP0_DAT0__ECSPI3_SCLK 0x100b1
> + >;
> + };
> +
> + pinctrl_ecspi3_cs: ecspi3cs {
> + fsl,pins = <
> + MX6QDL_PAD_DISP0_DAT3__GPIO4_IO24 0x80000000
> + >;
> + };
> + pinctrl_ecspi3_flwp: ecspi3flwp {
> + fsl,pins = <
> + MX6QDL_PAD_DISP0_DAT6__GPIO4_IO27 0x80000000
> + >;
> + };
> +
> + pinctrl_uart4: uart4grp {
> + fsl,pins = <
> + MX6QDL_PAD_KEY_COL0__UART4_TX_DATA 0x1b0b1
> + MX6QDL_PAD_KEY_ROW0__UART4_RX_DATA 0x1b0b1
> + MX6QDL_PAD_CSI0_DAT16__UART4_RTS_B 0x1b0b1
> + MX6QDL_PAD_CSI0_DAT17__UART4_CTS_B 0x1b0b1
> + >;
> + };
> +
> + pinctrl_display: dispgrp {
> + fsl,pins = <
> + /* BLEN_OUT */
> + MX6QDL_PAD_GPIO_2__GPIO1_IO02 0x1b0b0
> + /* LVDS_PPEN_OUT */
> + MX6QDL_PAD_SD1_DAT2__GPIO1_IO19 0x1b0b0
This GPIO should be moved to a pinctrl group of regulator-lvds device node.
> + >;
> + };
> +
> + pinctrl_pwm2: pwm2grp {
> + fsl,pins = <
> + MX6QDL_PAD_GPIO_1__PWM2_OUT 0x1b0b1
> + >;
> + };
Please sort out all pinctrl_* nodes alphabetically.
> + };
> +};
> +
> +&fec {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_enet>;
> + phy-mode = "rgmii";
> + phy-reset-gpios = <&gpio1 27 0>;
GPIO1_27 has no pad configuration in pinctrl_enet.
> + interrupts-extended = <&gpio1 6 IRQ_TYPE_LEVEL_HIGH>,
> + <&intc 0 119 IRQ_TYPE_LEVEL_HIGH>;
> + status = "okay";
> +};
> +
> +&uart1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart1>;
Should you add "uart-has-rtscts" property?
> + status = "okay";
> +};
> +
> +&usdhc2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usdhc2>;
> + cd-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>;
bus-width = <4>;
You should consider to add the GPIO1_4 into pinctrl_usdhc2 group.
> + status = "okay";
> +};
> +
> +&usdhc3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usdhc3>;
> + bus-width = <8>;
> + status = "okay";
No "cd-gpios" property, should you add "non-removable" property then?
> +};
> +
> +&weim {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_weim_nor &pinctrl_weim_cs0>;
> + #address-cells = <2>;
> + #size-cells = <1>;
> + ranges = <0 0 0x08000000 0x08000000>;
> + status = "okay";
> +
> + nor@0,0 {
> + compatible = "cfi-flash";
> + reg = <0 0 0x02000000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + bank-width = <2>;
> + use-advanced-sector-protection;
> + fsl,weim-cs-timing = <0x00620081 0x00000001 0x1c022000
> + 0x0000c000 0x1404a38e 0x00000000>;
> + };
> +};
> +
> +&ecspi3 {
> + fsl,spi-num-chipselects = <1>;
This property is obsoleted, please remove it.
> + cs-gpios = <&gpio4 24 0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_ecspi3 &pinctrl_ecspi3_cs &pinctrl_ecspi3_flwp>;
> + status = "okay";
> +
> + flash: s25sl032p@0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "spansion,s25sl032p", "jedec,spi-nor";
> + spi-max-frequency = <40000000>;
> + reg = <0>;
> + };
> +};
> +
> +&uart4 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_uart4>;
> + status = "okay";
Should you add "uart-has-rtscts" property?
> +};
> +
> +&ldb {
> + status = "okay";
> +
> + lvds0: lvds-channel@0 {
> + fsl,data-mapping = "spwg";
> + fsl,data-width = <24>;
> + status = "okay";
> +
> + port@4 {
> + reg = <4>;
> +
> + lvds0_out: endpoint {
> + remote-endpoint = <&panel_in_lvds0>;
> + };
> + };
> + };
> +};
> +
> +&pwm2 {
> + #pwm-cells = <3>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_pwm2>;
> + status = "okay";
> +};
>
Please sort out all device nodes but &iomuxc alphabetically:
* iomuxc
* ecspi3
* fec
* i2c1
* i2c2
* ldb
* pwm2
* uart1
* uart4
* usdhc2
* usdhc3
* weim
--
With best wishes,
Vladimir
--
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 v3 0/7] Add support for Video Data Order Adapter
From: Michael Tretter @ 2017-01-02 13:23 UTC (permalink / raw)
To: linux-media-u79uwXL29TY76Z2rM5mHXA
Cc: Philipp Zabel, devicetree-u79uwXL29TY76Z2rM5mHXA, Hans Verkuil,
Mauro Carvalho Chehab, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
Michael Tretter
Hello,
This is v3 of a patch series that adds support for the Video Data Order
Adapter (VDOA) that can be found on Freescale i.MX6. It converts the
macroblock tiled format produced by the CODA 960 video decoder to a
raster-ordered format for scanout.
Changes since v2:
- Patch 1/7: Update commit message to include binding change; fix
spelling/style in binding documentation
Changes since v1:
- Dropped patch 8/9 of v1
- Patch 1/7: Add devicetree binding documentation for fsl-vdoa
- Patch 6/7: I merged patch 5/9 and patch 8/9 of v1 into a single patch
- Patch 6/7: Use dt compatible instead of a phandle to find VDOA device
- Patch 6/7: Always check VDOA availability even if disabled via module
parameter and do not print a message if VDOA cannot be found
- Patch 6/7: Do not change the CODA context in coda_try_fmt()
- Patch 6/7: Allocate an additional internal frame if the VDOA is in use
Michael Tretter (3):
[media] coda: fix frame index to returned error
[media] coda: use VDOA for un-tiling custom macroblock format
[media] coda: support YUYV output if VDOA is used
Philipp Zabel (4):
[media] dt-bindings: Add a binding for Video Data Order Adapter
[media] coda: add i.MX6 VDOA driver
[media] coda: correctly set capture compose rectangle
[media] coda: add debug output about tiling
.../devicetree/bindings/media/fsl-vdoa.txt | 21 ++
arch/arm/boot/dts/imx6qdl.dtsi | 2 +
drivers/media/platform/Kconfig | 3 +
drivers/media/platform/coda/Makefile | 1 +
drivers/media/platform/coda/coda-bit.c | 93 ++++--
drivers/media/platform/coda/coda-common.c | 175 ++++++++++-
drivers/media/platform/coda/coda.h | 3 +
drivers/media/platform/coda/imx-vdoa.c | 335 +++++++++++++++++++++
drivers/media/platform/coda/imx-vdoa.h | 58 ++++
9 files changed, 649 insertions(+), 42 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/fsl-vdoa.txt
create mode 100644 drivers/media/platform/coda/imx-vdoa.c
create mode 100644 drivers/media/platform/coda/imx-vdoa.h
--
2.11.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
* [PATCH v3 1/7] [media] dt-bindings: Add a binding for Video Data Order Adapter
From: Michael Tretter @ 2017-01-02 13:23 UTC (permalink / raw)
To: linux-media
Cc: Philipp Zabel, devicetree, Hans Verkuil, Mauro Carvalho Chehab,
kernel, Philipp Zabel, Michael Tretter
In-Reply-To: <20170102132352.23669-1-m.tretter@pengutronix.de>
From: Philipp Zabel <philipp.zabel@gmail.com>
Add a DT binding documentation for the Video Data Order Adapter (VDOA)
of the Freescale i.MX6 SoC.
Also, add the compatible property and correct clock to the device tree
to match the documentation.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
---
.../devicetree/bindings/media/fsl-vdoa.txt | 21 +++++++++++++++++++++
arch/arm/boot/dts/imx6qdl.dtsi | 2 ++
2 files changed, 23 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/fsl-vdoa.txt
diff --git a/Documentation/devicetree/bindings/media/fsl-vdoa.txt b/Documentation/devicetree/bindings/media/fsl-vdoa.txt
new file mode 100644
index 000000000000..6c5628530bb7
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/fsl-vdoa.txt
@@ -0,0 +1,21 @@
+Freescale Video Data Order Adapter
+==================================
+
+The Video Data Order Adapter (VDOA) is present on the i.MX6q. Its sole purpose
+is to reorder video data from the macroblock tiled order produced by the CODA
+960 VPU to the conventional raster-scan order for scanout.
+
+Required properties:
+- compatible: must be "fsl,imx6q-vdoa"
+- reg: the register base and size for the device registers
+- interrupts: the VDOA interrupt
+- clocks: the vdoa clock
+
+Example:
+
+vdoa@21e4000 {
+ compatible = "fsl,imx6q-vdoa";
+ reg = <0x021e4000 0x4000>;
+ interrupts = <0 18 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX6QDL_CLK_VDOA>;
+};
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 53e6e63cbb02..61569c86d28e 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1157,8 +1157,10 @@
};
vdoa@021e4000 {
+ compatible = "fsl,imx6q-vdoa";
reg = <0x021e4000 0x4000>;
interrupts = <0 18 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clks IMX6QDL_CLK_VDOA>;
};
uart2: serial@021e8000 {
--
2.11.0
^ permalink raw reply related
* [PATCH v3 2/7] [media] coda: add i.MX6 VDOA driver
From: Michael Tretter @ 2017-01-02 13:23 UTC (permalink / raw)
To: linux-media
Cc: Philipp Zabel, devicetree, Hans Verkuil, Mauro Carvalho Chehab,
kernel, Philipp Zabel, Michael Tretter
In-Reply-To: <20170102132352.23669-1-m.tretter@pengutronix.de>
From: Philipp Zabel <philipp.zabel@gmail.com>
The i.MX6 Video Data Order Adapter's (VDOA) sole purpose is to convert
from a custom macroblock tiled format produced by the CODA960 decoder
into linear formats that can be used for scanout.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
---
drivers/media/platform/Kconfig | 3 +
drivers/media/platform/coda/Makefile | 1 +
drivers/media/platform/coda/imx-vdoa.c | 335 +++++++++++++++++++++++++++++++++
drivers/media/platform/coda/imx-vdoa.h | 58 ++++++
4 files changed, 397 insertions(+)
create mode 100644 drivers/media/platform/coda/imx-vdoa.c
create mode 100644 drivers/media/platform/coda/imx-vdoa.h
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index d944421e392d..595652613db9 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -162,6 +162,9 @@ config VIDEO_CODA
Coda is a range of video codec IPs that supports
H.264, MPEG-4, and other video formats.
+config VIDEO_IMX_VDOA
+ def_tristate VIDEO_CODA if SOC_IMX6Q || COMPILE_TEST
+
config VIDEO_MEDIATEK_VPU
tristate "Mediatek Video Processor Unit"
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
diff --git a/drivers/media/platform/coda/Makefile b/drivers/media/platform/coda/Makefile
index 9342ac57b230..858284328af9 100644
--- a/drivers/media/platform/coda/Makefile
+++ b/drivers/media/platform/coda/Makefile
@@ -3,3 +3,4 @@ ccflags-y += -I$(src)
coda-objs := coda-common.o coda-bit.o coda-gdi.o coda-h264.o coda-jpeg.o
obj-$(CONFIG_VIDEO_CODA) += coda.o
+obj-$(CONFIG_VIDEO_IMX_VDOA) += imx-vdoa.o
diff --git a/drivers/media/platform/coda/imx-vdoa.c b/drivers/media/platform/coda/imx-vdoa.c
new file mode 100644
index 000000000000..36ceffbf08de
--- /dev/null
+++ b/drivers/media/platform/coda/imx-vdoa.c
@@ -0,0 +1,335 @@
+/*
+ * i.MX6 Video Data Order Adapter (VDOA)
+ *
+ * Copyright (C) 2014 Philipp Zabel
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk.h>
+#include <linux/device.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/dma-mapping.h>
+#include <linux/platform_device.h>
+#include <linux/videodev2.h>
+#include <linux/slab.h>
+
+#include "imx-vdoa.h"
+
+#define VDOA_NAME "imx-vdoa"
+
+#define VDOAC 0x00
+#define VDOASRR 0x04
+#define VDOAIE 0x08
+#define VDOAIST 0x0c
+#define VDOAFP 0x10
+#define VDOAIEBA00 0x14
+#define VDOAIEBA01 0x18
+#define VDOAIEBA02 0x1c
+#define VDOAIEBA10 0x20
+#define VDOAIEBA11 0x24
+#define VDOAIEBA12 0x28
+#define VDOASL 0x2c
+#define VDOAIUBO 0x30
+#define VDOAVEBA0 0x34
+#define VDOAVEBA1 0x38
+#define VDOAVEBA2 0x3c
+#define VDOAVUBO 0x40
+#define VDOASR 0x44
+
+#define VDOAC_ISEL BIT(6)
+#define VDOAC_PFS BIT(5)
+#define VDOAC_SO BIT(4)
+#define VDOAC_SYNC BIT(3)
+#define VDOAC_NF BIT(2)
+#define VDOAC_BNDM_MASK 0x3
+#define VDOAC_BAND_HEIGHT_8 0x0
+#define VDOAC_BAND_HEIGHT_16 0x1
+#define VDOAC_BAND_HEIGHT_32 0x2
+
+#define VDOASRR_START BIT(1)
+#define VDOASRR_SWRST BIT(0)
+
+#define VDOAIE_EITERR BIT(1)
+#define VDOAIE_EIEOT BIT(0)
+
+#define VDOAIST_TERR BIT(1)
+#define VDOAIST_EOT BIT(0)
+
+#define VDOAFP_FH_MASK (0x1fff << 16)
+#define VDOAFP_FW_MASK (0x3fff)
+
+#define VDOASL_VSLY_MASK (0x3fff << 16)
+#define VDOASL_ISLY_MASK (0x7fff)
+
+#define VDOASR_ERRW BIT(4)
+#define VDOASR_EOB BIT(3)
+#define VDOASR_CURRENT_FRAME (0x3 << 1)
+#define VDOASR_CURRENT_BUFFER BIT(1)
+
+enum {
+ V4L2_M2M_SRC = 0,
+ V4L2_M2M_DST = 1,
+};
+
+struct vdoa_data {
+ struct vdoa_ctx *curr_ctx;
+ struct device *dev;
+ struct clk *vdoa_clk;
+ void __iomem *regs;
+ int irq;
+};
+
+struct vdoa_q_data {
+ unsigned int width;
+ unsigned int height;
+ unsigned int bytesperline;
+ unsigned int sizeimage;
+ u32 pixelformat;
+};
+
+struct vdoa_ctx {
+ struct vdoa_data *vdoa;
+ struct completion completion;
+ struct vdoa_q_data q_data[2];
+};
+
+static irqreturn_t vdoa_irq_handler(int irq, void *data)
+{
+ struct vdoa_data *vdoa = data;
+ struct vdoa_ctx *curr_ctx;
+ u32 val;
+
+ /* Disable interrupts */
+ writel(0, vdoa->regs + VDOAIE);
+
+ curr_ctx = vdoa->curr_ctx;
+ if (!curr_ctx) {
+ dev_dbg(vdoa->dev,
+ "Instance released before the end of transaction\n");
+ return IRQ_HANDLED;
+ }
+
+ val = readl(vdoa->regs + VDOAIST);
+ writel(val, vdoa->regs + VDOAIST);
+ if (val & VDOAIST_TERR) {
+ val = readl(vdoa->regs + VDOASR) & VDOASR_ERRW;
+ dev_err(vdoa->dev, "AXI %s error\n", val ? "write" : "read");
+ } else if (!(val & VDOAIST_EOT)) {
+ dev_warn(vdoa->dev, "Spurious interrupt\n");
+ }
+ complete(&curr_ctx->completion);
+
+ return IRQ_HANDLED;
+}
+
+void vdoa_device_run(struct vdoa_ctx *ctx, dma_addr_t dst, dma_addr_t src)
+{
+ struct vdoa_q_data *src_q_data, *dst_q_data;
+ struct vdoa_data *vdoa = ctx->vdoa;
+ u32 val;
+
+ vdoa->curr_ctx = ctx;
+
+ src_q_data = &ctx->q_data[V4L2_M2M_SRC];
+ dst_q_data = &ctx->q_data[V4L2_M2M_DST];
+
+ /* Progressive, no sync, 1 frame per run */
+ if (dst_q_data->pixelformat == V4L2_PIX_FMT_YUYV)
+ val = VDOAC_PFS;
+ else
+ val = 0;
+ writel(val, vdoa->regs + VDOAC);
+
+ writel(dst_q_data->height << 16 | dst_q_data->width,
+ vdoa->regs + VDOAFP);
+
+ val = dst;
+ writel(val, vdoa->regs + VDOAIEBA00);
+
+ writel(src_q_data->bytesperline << 16 | dst_q_data->bytesperline,
+ vdoa->regs + VDOASL);
+
+ if (dst_q_data->pixelformat == V4L2_PIX_FMT_NV12 ||
+ dst_q_data->pixelformat == V4L2_PIX_FMT_NV21)
+ val = dst_q_data->bytesperline * dst_q_data->height;
+ else
+ val = 0;
+ writel(val, vdoa->regs + VDOAIUBO);
+
+ val = src;
+ writel(val, vdoa->regs + VDOAVEBA0);
+ val = src_q_data->bytesperline * src_q_data->height;
+ writel(val, vdoa->regs + VDOAVUBO);
+
+ /* Enable interrupts and start transfer */
+ writel(VDOAIE_EITERR | VDOAIE_EIEOT, vdoa->regs + VDOAIE);
+ writel(VDOASRR_START, vdoa->regs + VDOASRR);
+}
+EXPORT_SYMBOL(vdoa_device_run);
+
+int vdoa_wait_for_completion(struct vdoa_ctx *ctx)
+{
+ struct vdoa_data *vdoa = ctx->vdoa;
+
+ if (!wait_for_completion_timeout(&ctx->completion,
+ msecs_to_jiffies(300))) {
+ dev_err(vdoa->dev,
+ "Timeout waiting for transfer result\n");
+ return -ETIMEDOUT;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(vdoa_wait_for_completion);
+
+struct vdoa_ctx *vdoa_context_create(struct vdoa_data *vdoa)
+{
+ struct vdoa_ctx *ctx;
+ int err;
+
+ ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
+ if (!ctx)
+ return NULL;
+
+ err = clk_prepare_enable(vdoa->vdoa_clk);
+ if (err) {
+ kfree(ctx);
+ return NULL;
+ }
+
+ init_completion(&ctx->completion);
+ ctx->vdoa = vdoa;
+
+ return ctx;
+}
+EXPORT_SYMBOL(vdoa_context_create);
+
+void vdoa_context_destroy(struct vdoa_ctx *ctx)
+{
+ struct vdoa_data *vdoa = ctx->vdoa;
+
+ clk_disable_unprepare(vdoa->vdoa_clk);
+ kfree(ctx);
+}
+EXPORT_SYMBOL(vdoa_context_destroy);
+
+int vdoa_context_configure(struct vdoa_ctx *ctx,
+ unsigned int width, unsigned int height,
+ u32 pixelformat)
+{
+ struct vdoa_q_data *src_q_data;
+ struct vdoa_q_data *dst_q_data;
+
+ if (width < 16 || width > 8192 || width % 16 != 0 ||
+ height < 16 || height > 4096 || height % 16 != 0)
+ return -EINVAL;
+
+ if (pixelformat != V4L2_PIX_FMT_YUYV &&
+ pixelformat != V4L2_PIX_FMT_NV12)
+ return -EINVAL;
+
+ /* If no context is passed, only check if the format is valid */
+ if (!ctx)
+ return 0;
+
+ src_q_data = &ctx->q_data[V4L2_M2M_SRC];
+ dst_q_data = &ctx->q_data[V4L2_M2M_DST];
+
+ src_q_data->width = width;
+ src_q_data->height = height;
+ src_q_data->bytesperline = width;
+ src_q_data->sizeimage = src_q_data->bytesperline * height * 3 / 2;
+
+ dst_q_data->width = width;
+ dst_q_data->height = height;
+ dst_q_data->pixelformat = pixelformat;
+ switch (pixelformat) {
+ case V4L2_PIX_FMT_YUYV:
+ dst_q_data->bytesperline = width * 2;
+ dst_q_data->sizeimage = dst_q_data->bytesperline * height;
+ break;
+ case V4L2_PIX_FMT_NV12:
+ default:
+ dst_q_data->bytesperline = width;
+ dst_q_data->sizeimage =
+ dst_q_data->bytesperline * height * 3 / 2;
+ break;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(vdoa_context_configure);
+
+static int vdoa_probe(struct platform_device *pdev)
+{
+ struct vdoa_data *vdoa;
+ struct resource *res;
+
+ dma_set_coherent_mask(&pdev->dev, DMA_BIT_MASK(32));
+
+ vdoa = devm_kzalloc(&pdev->dev, sizeof(*vdoa), GFP_KERNEL);
+ if (!vdoa)
+ return -ENOMEM;
+
+ vdoa->dev = &pdev->dev;
+
+ vdoa->vdoa_clk = devm_clk_get(vdoa->dev, NULL);
+ if (IS_ERR(vdoa->vdoa_clk)) {
+ dev_err(vdoa->dev, "Failed to get clock\n");
+ return PTR_ERR(vdoa->vdoa_clk);
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ vdoa->regs = devm_ioremap_resource(vdoa->dev, res);
+ if (IS_ERR(vdoa->regs))
+ return PTR_ERR(vdoa->regs);
+
+ res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ vdoa->irq = devm_request_threaded_irq(&pdev->dev, res->start, NULL,
+ vdoa_irq_handler, IRQF_ONESHOT,
+ "vdoa", vdoa);
+ if (vdoa->irq < 0) {
+ dev_err(vdoa->dev, "Failed to get irq\n");
+ return vdoa->irq;
+ }
+
+ platform_set_drvdata(pdev, vdoa);
+
+ return 0;
+}
+
+static int vdoa_remove(struct platform_device *pdev)
+{
+ return 0;
+}
+
+static struct of_device_id vdoa_dt_ids[] = {
+ { .compatible = "fsl,imx6q-vdoa" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, vdoa_dt_ids);
+
+static struct platform_driver vdoa_driver = {
+ .probe = vdoa_probe,
+ .remove = vdoa_remove,
+ .driver = {
+ .name = VDOA_NAME,
+ .of_match_table = vdoa_dt_ids,
+ },
+};
+
+module_platform_driver(vdoa_driver);
+
+MODULE_DESCRIPTION("Video Data Order Adapter");
+MODULE_AUTHOR("Philipp Zabel <philipp.zabel@gmail.com>");
+MODULE_ALIAS("platform:imx-vdoa");
+MODULE_LICENSE("GPL");
diff --git a/drivers/media/platform/coda/imx-vdoa.h b/drivers/media/platform/coda/imx-vdoa.h
new file mode 100644
index 000000000000..967576b2a06a
--- /dev/null
+++ b/drivers/media/platform/coda/imx-vdoa.h
@@ -0,0 +1,58 @@
+/*
+ * Copyright (C) 2016 Pengutronix
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef IMX_VDOA_H
+#define IMX_VDOA_H
+
+struct vdoa_data;
+struct vdoa_ctx;
+
+#if (defined CONFIG_VIDEO_IMX_VDOA || defined CONFIG_VIDEO_IMX_VDOA_MODULE)
+
+struct vdoa_ctx *vdoa_context_create(struct vdoa_data *vdoa);
+int vdoa_context_configure(struct vdoa_ctx *ctx,
+ unsigned int width, unsigned int height,
+ u32 pixelformat);
+void vdoa_context_destroy(struct vdoa_ctx *ctx);
+
+void vdoa_device_run(struct vdoa_ctx *ctx, dma_addr_t dst, dma_addr_t src);
+int vdoa_wait_for_completion(struct vdoa_ctx *ctx);
+
+#else
+
+static inline struct vdoa_ctx *vdoa_context_create(struct vdoa_data *vdoa)
+{
+ return NULL;
+}
+
+static inline int vdoa_context_configure(struct vdoa_ctx *ctx,
+ unsigned int width,
+ unsigned int height,
+ u32 pixelformat)
+{
+ return 0;
+}
+
+static inline void vdoa_context_destroy(struct vdoa_ctx *ctx) { };
+
+static inline void vdoa_device_run(struct vdoa_ctx *ctx,
+ dma_addr_t dst, dma_addr_t src) { };
+
+static inline int vdoa_wait_for_completion(struct vdoa_ctx *ctx)
+{
+ return 0;
+};
+
+#endif
+
+#endif /* IMX_VDOA_H */
--
2.11.0
^ permalink raw reply related
* [PATCH v3 3/7] [media] coda: correctly set capture compose rectangle
From: Michael Tretter @ 2017-01-02 13:23 UTC (permalink / raw)
To: linux-media-u79uwXL29TY76Z2rM5mHXA
Cc: Philipp Zabel, devicetree-u79uwXL29TY76Z2rM5mHXA, Hans Verkuil,
Mauro Carvalho Chehab, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
Michael Tretter
In-Reply-To: <20170102132352.23669-1-m.tretter-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
From: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Correctly store the rectangle of valid video data in the destination
q_data before rounding up to macroblock size. This fixes the output
of VIDIOC_G_SELECTION for the capture side compose rectangle.
Signed-off-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Signed-off-by: Michael Tretter <m.tretter-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
---
drivers/media/platform/coda/coda-common.c | 37 ++++++++++++++++++++++++-------
1 file changed, 29 insertions(+), 8 deletions(-)
diff --git a/drivers/media/platform/coda/coda-common.c b/drivers/media/platform/coda/coda-common.c
index 9e6bdafa16f5..fa3ed74af116 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -566,7 +566,8 @@ static int coda_try_fmt_vid_out(struct file *file, void *priv,
return coda_try_fmt(ctx, codec, f);
}
-static int coda_s_fmt(struct coda_ctx *ctx, struct v4l2_format *f)
+static int coda_s_fmt(struct coda_ctx *ctx, struct v4l2_format *f,
+ struct v4l2_rect *r)
{
struct coda_q_data *q_data;
struct vb2_queue *vq;
@@ -589,10 +590,14 @@ static int coda_s_fmt(struct coda_ctx *ctx, struct v4l2_format *f)
q_data->height = f->fmt.pix.height;
q_data->bytesperline = f->fmt.pix.bytesperline;
q_data->sizeimage = f->fmt.pix.sizeimage;
- q_data->rect.left = 0;
- q_data->rect.top = 0;
- q_data->rect.width = f->fmt.pix.width;
- q_data->rect.height = f->fmt.pix.height;
+ if (r) {
+ q_data->rect = *r;
+ } else {
+ q_data->rect.left = 0;
+ q_data->rect.top = 0;
+ q_data->rect.width = f->fmt.pix.width;
+ q_data->rect.height = f->fmt.pix.height;
+ }
switch (f->fmt.pix.pixelformat) {
case V4L2_PIX_FMT_NV12:
@@ -621,27 +626,37 @@ static int coda_s_fmt_vid_cap(struct file *file, void *priv,
struct v4l2_format *f)
{
struct coda_ctx *ctx = fh_to_ctx(priv);
+ struct coda_q_data *q_data_src;
+ struct v4l2_rect r;
int ret;
ret = coda_try_fmt_vid_cap(file, priv, f);
if (ret)
return ret;
- return coda_s_fmt(ctx, f);
+ q_data_src = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
+ r.left = 0;
+ r.top = 0;
+ r.width = q_data_src->width;
+ r.height = q_data_src->height;
+
+ return coda_s_fmt(ctx, f, &r);
}
static int coda_s_fmt_vid_out(struct file *file, void *priv,
struct v4l2_format *f)
{
struct coda_ctx *ctx = fh_to_ctx(priv);
+ struct coda_q_data *q_data_src;
struct v4l2_format f_cap;
+ struct v4l2_rect r;
int ret;
ret = coda_try_fmt_vid_out(file, priv, f);
if (ret)
return ret;
- ret = coda_s_fmt(ctx, f);
+ ret = coda_s_fmt(ctx, f, NULL);
if (ret)
return ret;
@@ -657,7 +672,13 @@ static int coda_s_fmt_vid_out(struct file *file, void *priv,
if (ret)
return ret;
- return coda_s_fmt(ctx, &f_cap);
+ q_data_src = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
+ r.left = 0;
+ r.top = 0;
+ r.width = q_data_src->width;
+ r.height = q_data_src->height;
+
+ return coda_s_fmt(ctx, &f_cap, &r);
}
static int coda_reqbufs(struct file *file, void *priv,
--
2.11.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 4/7] [media] coda: add debug output about tiling
From: Michael Tretter @ 2017-01-02 13:23 UTC (permalink / raw)
To: linux-media-u79uwXL29TY76Z2rM5mHXA
Cc: Philipp Zabel, devicetree-u79uwXL29TY76Z2rM5mHXA, Hans Verkuil,
Mauro Carvalho Chehab, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
Michael Tretter
In-Reply-To: <20170102132352.23669-1-m.tretter-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
From: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
In order to make the VDOA work correctly, the CODA must produce frames
in tiled format. Print this information in the debug output.
Also print the color format in fourcc instead of the numeric value.
Signed-off-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Signed-off-by: Michael Tretter <m.tretter-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
---
drivers/media/platform/coda/coda-common.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/coda/coda-common.c b/drivers/media/platform/coda/coda-common.c
index fa3ed74af116..b23fe0f0fb56 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -616,8 +616,10 @@ static int coda_s_fmt(struct coda_ctx *ctx, struct v4l2_format *f,
}
v4l2_dbg(1, coda_debug, &ctx->dev->v4l2_dev,
- "Setting format for type %d, wxh: %dx%d, fmt: %d\n",
- f->type, q_data->width, q_data->height, q_data->fourcc);
+ "Setting format for type %d, wxh: %dx%d, fmt: %4.4s %c\n",
+ f->type, q_data->width, q_data->height,
+ (char *)&q_data->fourcc,
+ (ctx->tiled_map_type == GDI_LINEAR_FRAME_MAP) ? 'L' : 'T');
return 0;
}
--
2.11.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 5/7] [media] coda: fix frame index to returned error
From: Michael Tretter @ 2017-01-02 13:23 UTC (permalink / raw)
To: linux-media-u79uwXL29TY76Z2rM5mHXA
Cc: Philipp Zabel, devicetree-u79uwXL29TY76Z2rM5mHXA, Hans Verkuil,
Mauro Carvalho Chehab, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
Michael Tretter
In-Reply-To: <20170102132352.23669-1-m.tretter-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
display_idx refers to the frame that will be returned in the next round.
The currently processed frame is ctx->display_idx and errors should be
reported for this frame.
Signed-off-by: Michael Tretter <m.tretter-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Acked-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
---
drivers/media/platform/coda/coda-bit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/coda/coda-bit.c b/drivers/media/platform/coda/coda-bit.c
index b6625047250d..309eb4eb5ad1 100644
--- a/drivers/media/platform/coda/coda-bit.c
+++ b/drivers/media/platform/coda/coda-bit.c
@@ -2057,7 +2057,7 @@ static void coda_finish_decode(struct coda_ctx *ctx)
}
vb2_set_plane_payload(&dst_buf->vb2_buf, 0, payload);
- coda_m2m_buf_done(ctx, dst_buf, ctx->frame_errors[display_idx] ?
+ coda_m2m_buf_done(ctx, dst_buf, ctx->frame_errors[ctx->display_idx] ?
VB2_BUF_STATE_ERROR : VB2_BUF_STATE_DONE);
v4l2_dbg(1, coda_debug, &dev->v4l2_dev,
--
2.11.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
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