* Re: [PATCH v4 9/9] ARM: dts: stm32f4: Include auxiliary stm32fx clock definition
From: Alexandre Torgue @ 2017-01-10 10:59 UTC (permalink / raw)
To: Gabriel FERNANDEZ, Rob Herring, Mark Rutland, Russell King,
Maxime Coquelin, Michael Turquette, Stephen Boyd, Nicolas Pitre,
Arnd Bergmann, daniel.thompson@linaro.org,
andrea.merello@gmail.com, radoslaw.pietrzyk@gmail.com
Cc: devicetree@vger.kernel.org, Amelie DELAUNAY, kernel@stlinux.com,
Olivier BIDEAU, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org,
Ludovic BARRE
In-Reply-To: <1481638820-29324-10-git-send-email-gabriel.fernandez@st.com>
hi
On 12/13/2016 03:20 PM, Gabriel FERNANDEZ wrote:
> From: Gabriel Fernandez <gabriel.fernandez@st.com>
>
> This patch include auxiliary clock definition (clocks which are not derived
> from system clock.
>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> ---
> arch/arm/boot/dts/stm32f429.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
> index 7c7dfbd..041e3fc 100644
> --- a/arch/arm/boot/dts/stm32f429.dtsi
> +++ b/arch/arm/boot/dts/stm32f429.dtsi
> @@ -48,6 +48,7 @@
> #include "skeleton.dtsi"
> #include "armv7-m.dtsi"
> #include <dt-bindings/pinctrl/stm32f429-pinfunc.h>
> +#include <dt-bindings/clock/stm32fx-clock.h>
>
> / {
> clocks {
>
Applied on stm32-dt-for-v4.11
Thanks
^ permalink raw reply
* Re: [PATCH v2 2/2] media: rc: add driver for IR remote receiver on MT7623 SoC
From: Sean Young @ 2017-01-10 11:09 UTC (permalink / raw)
To: sean.wang-NuS5LvNUpcJWk0Htik3J/w
Cc: mchehab-JPH+aEBZ4P+UEJcrhfAQsw, hdegoede-H+wXaHxf7aLQT0dZR+AlfA,
hkallweit1-Re5JQEeQqe8AvxtiuMwx3w, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w,
andi.shyti-Sze3O3UU22JBDgjK7y7TUQ,
hverkuil-qWit8jRvyhVmR6Xm/wNWPw,
ivo.g.dimitrov.75-Re5JQEeQqe8AvxtiuMwx3w,
linux-media-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
keyhaede-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1484039631-25120-3-git-send-email-sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Hi Sean
Some more review comments.
On Tue, Jan 10, 2017 at 05:13:51PM +0800, sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org wrote:
> From: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
>
> This patch adds driver for IR controller on MT7623 SoC.
> and should also work on similar Mediatek SoC. Currently
> testing successfully on NEC and SONY remote controller
> only but it should work on others (lirc, rc-5 and rc-6).
>
> Signed-off-by: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> Reviewed-by: Sean Young <sean-hENCXIMQXOg@public.gmane.org>
> ---
> drivers/media/rc/Kconfig | 11 ++
> drivers/media/rc/Makefile | 1 +
> drivers/media/rc/mtk-cir.c | 326 +++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 338 insertions(+)
> create mode 100644 drivers/media/rc/mtk-cir.c
>
> diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
> index 629e8ca..9228479 100644
> --- a/drivers/media/rc/Kconfig
> +++ b/drivers/media/rc/Kconfig
> @@ -235,6 +235,17 @@ config IR_MESON
> To compile this driver as a module, choose M here: the
> module will be called meson-ir.
>
> +config IR_MTK
> + tristate "Mediatek IR remote receiver"
> + depends on RC_CORE
> + depends on ARCH_MEDIATEK || COMPILE_TEST
> + ---help---
> + Say Y if you want to use the IR remote receiver available
> + on Mediatek SoCs.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called mtk-cir.
> +
> config IR_NUVOTON
> tristate "Nuvoton w836x7hg Consumer Infrared Transceiver"
> depends on PNP
> diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
> index 3a984ee..a78570b 100644
> --- a/drivers/media/rc/Makefile
> +++ b/drivers/media/rc/Makefile
> @@ -38,3 +38,4 @@ obj-$(CONFIG_RC_ST) += st_rc.o
> obj-$(CONFIG_IR_SUNXI) += sunxi-cir.o
> obj-$(CONFIG_IR_IMG) += img-ir/
> obj-$(CONFIG_IR_SERIAL) += serial_ir.o
> +obj-$(CONFIG_IR_MTK) += mtk-cir.o
> diff --git a/drivers/media/rc/mtk-cir.c b/drivers/media/rc/mtk-cir.c
> new file mode 100644
> index 0000000..f752f63
> --- /dev/null
> +++ b/drivers/media/rc/mtk-cir.c
> @@ -0,0 +1,326 @@
> +/*
> + * Driver for Mediatek IR Receiver Controller
> + *
> + * Copyright (C) 2017 Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@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.
> + *
> + * 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/interrupt.h>
> +#include <linux/module.h>
> +#include <linux/of_platform.h>
> +#include <linux/reset.h>
> +#include <media/rc-core.h>
> +
> +#define MTK_IR_DEV KBUILD_MODNAME
You could remove this #define and just use KBUILD_MODNAME
> +
> +/* Register to enable PWM and IR */
> +#define MTK_CONFIG_HIGH_REG 0x0c
> +/* Enable IR pulse width detection */
> +#define MTK_PWM_EN BIT(13)
> +/* Enable IR hardware function */
> +#define MTK_IR_EN BIT(0)
> +
> +/* Register to setting sample period */
> +#define MTK_CONFIG_LOW_REG 0x10
> +/* Field to set sample period */
> +#define CHK_PERIOD DIV_ROUND_CLOSEST(MTK_IR_SAMPLE, \
> + MTK_IR_CLK_PERIOD)
> +#define MTK_CHK_PERIOD (((CHK_PERIOD) << 8) & (GENMASK(20, 8)))
> +#define MTK_CHK_PERIOD_MASK (GENMASK(20, 8))
> +
> +/* Register to clear state of state machine */
> +#define MTK_IRCLR_REG 0x20
> +/* Bit to restart IR receiving */
> +#define MTK_IRCLR BIT(0)
> +
> +/* Register containing pulse width data */
> +#define MTK_CHKDATA_REG(i) (0x88 + 4 * (i))
> +#define MTK_WIDTH_MASK (GENMASK(7, 0))
> +
> +/* Register to enable IR interrupt */
> +#define MTK_IRINT_EN_REG 0xcc
> +/* Bit to enable interrupt */
> +#define MTK_IRINT_EN BIT(0)
> +
> +/* Register to ack IR interrupt */
> +#define MTK_IRINT_CLR_REG 0xd0
> +/* Bit to clear interrupt status */
> +#define MTK_IRINT_CLR BIT(0)
> +
> +/* Maximum count of samples */
> +#define MTK_MAX_SAMPLES 0xff
> +/* Indicate the end of IR message */
> +#define MTK_IR_END(v, p) ((v) == MTK_MAX_SAMPLES && (p) == 0)
> +/* Number of registers to record the pulse width */
> +#define MTK_CHKDATA_SZ 17
> +/* Source clock frequency */
> +#define MTK_IR_BASE_CLK 273000000
> +/* Frequency after IR internal divider */
> +#define MTK_IR_CLK_FREQ (MTK_IR_BASE_CLK / 4)
> +/* Period for MTK_IR_CLK in ns*/
> +#define MTK_IR_CLK_PERIOD DIV_ROUND_CLOSEST(1000000000ul, \
> + MTK_IR_CLK_FREQ)
> +/* Sample period in ns */
> +#define MTK_IR_SAMPLE (MTK_IR_CLK_PERIOD * 0xc00)
> +
> +/* struct mtk_ir - This is the main datasructure for holding the state
> + * of the driver
> + * @dev: The device pointer
> + * @rc: The rc instrance
> + * @irq: The IRQ that we are using
> + * @base: The mapped register i/o base
> + * @clk: The clock that we are using
> + */
> +struct mtk_ir {
> + struct device *dev;
> + struct rc_dev *rc;
> + void __iomem *base;
> + int irq;
> + struct clk *clk;
> +};
> +
> +static void mtk_w32_mask(struct mtk_ir *ir, u32 val, u32 mask, unsigned int reg)
> +{
> + u32 tmp;
> +
> + tmp = __raw_readl(ir->base + reg);
> + tmp = (tmp & ~mask) | val;
> + __raw_writel(tmp, ir->base + reg);
> +}
> +
> +static void mtk_w32(struct mtk_ir *ir, u32 val, unsigned int reg)
> +{
> + __raw_writel(val, ir->base + reg);
> +}
> +
> +static u32 mtk_r32(struct mtk_ir *ir, unsigned int reg)
> +{
> + return __raw_readl(ir->base + reg);
> +}
> +
> +static inline void mtk_irq_disable(struct mtk_ir *ir, u32 mask)
> +{
> + u32 val;
> +
> + val = mtk_r32(ir, MTK_IRINT_EN_REG);
> + mtk_w32(ir, val & ~mask, MTK_IRINT_EN_REG);
> +}
> +
> +static inline void mtk_irq_enable(struct mtk_ir *ir, u32 mask)
> +{
> + u32 val;
> +
> + val = mtk_r32(ir, MTK_IRINT_EN_REG);
> + mtk_w32(ir, val | mask, MTK_IRINT_EN_REG);
> +}
> +
> +static irqreturn_t mtk_ir_irq(int irqno, void *dev_id)
> +{
> + struct mtk_ir *ir = dev_id;
> + u8 wid = 0;
> + u32 i, j, val;
> + DEFINE_IR_RAW_EVENT(rawir);
> +
> + mtk_irq_disable(ir, MTK_IRINT_EN);
The kernel guarantees that calls to the interrupt handler are serialised,
no need to disable the interrupt in the handler.
> +
> + /* Reset decoder state machine */
> + ir_raw_event_reset(ir->rc);
Not needed.
> +
> + /* First message must be pulse */
> + rawir.pulse = false;
pulse = true?
> +
> + /* Handle all pulse and space IR controller captures */
> + for (i = 0 ; i < MTK_CHKDATA_SZ ; i++) {
> + val = mtk_r32(ir, MTK_CHKDATA_REG(i));
> + dev_dbg(ir->dev, "@reg%d=0x%08x\n", i, val);
> +
> + for (j = 0 ; j < 4 ; j++) {
> + wid = (val & (MTK_WIDTH_MASK << j * 8)) >> j * 8;
> + rawir.pulse = !rawir.pulse;
> + rawir.duration = wid * (MTK_IR_SAMPLE + 1);
> + ir_raw_event_store_with_filter(ir->rc, &rawir);
> + }
In v1 you would break out of the loop if the ir message was shorter, but
now you are always passing on 68 pulses and spaces. Is that right?
> + }
> +
> + /* The maximum number of edges the IR controller can
> + * hold is MTK_CHKDATA_SZ * 4. So if received IR messages
> + * is over the limit, the last incomplete IR message would
> + * be appended trailing space and still would be sent into
> + * ir-rc-raw to decode. That helps it is possible that it
> + * has enough information to decode a scancode even if the
> + * trailing end of the message is missing.
> + */
> + if (!MTK_IR_END(wid, rawir.pulse)) {
> + rawir.pulse = false;
> + rawir.duration = MTK_MAX_SAMPLES * (MTK_IR_SAMPLE + 1);
> + ir_raw_event_store_with_filter(ir->rc, &rawir);
> + }
> +
> + ir_raw_event_handle(ir->rc);
> +
> + /* Restart controller for the next receive */
> + mtk_w32_mask(ir, 0x1, MTK_IRCLR, MTK_IRCLR_REG);
> +
> + /* Clear interrupt status */
> + mtk_w32_mask(ir, 0x1, MTK_IRINT_CLR, MTK_IRINT_CLR_REG);
> +
> + /* Enable interrupt */
> + mtk_irq_enable(ir, MTK_IRINT_EN);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int mtk_ir_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct device_node *dn = dev->of_node;
> + struct resource *res;
> + struct mtk_ir *ir;
> + u32 val;
> + int ret = 0;
> + const char *map_name;
> +
> + ir = devm_kzalloc(dev, sizeof(struct mtk_ir), GFP_KERNEL);
> + if (!ir)
> + return -ENOMEM;
> +
> + ir->dev = dev;
> +
> + if (!of_device_is_compatible(dn, "mediatek,mt7623-cir"))
> + return -ENODEV;
> +
> + ir->clk = devm_clk_get(dev, "clk");
> + if (IS_ERR(ir->clk)) {
> + dev_err(dev, "failed to get a ir clock.\n");
> + return PTR_ERR(ir->clk);
> + }
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + ir->base = devm_ioremap_resource(dev, res);
> + if (IS_ERR(ir->base)) {
> + dev_err(dev, "failed to map registers\n");
> + return PTR_ERR(ir->base);
> + }
> +
> + ir->rc = devm_rc_allocate_device(dev, RC_DRIVER_IR_RAW);
> + if (!ir->rc) {
> + dev_err(dev, "failed to allocate device\n");
> + return -ENOMEM;
> + }
> +
> + ir->rc->priv = ir;
> + ir->rc->input_name = MTK_IR_DEV;
> + ir->rc->input_phys = MTK_IR_DEV "/input0";
> + ir->rc->input_id.bustype = BUS_HOST;
> + ir->rc->input_id.vendor = 0x0001;
> + ir->rc->input_id.product = 0x0001;
> + ir->rc->input_id.version = 0x0001;
> + map_name = of_get_property(dn, "linux,rc-map-name", NULL);
> + ir->rc->map_name = map_name ?: RC_MAP_EMPTY;
> + ir->rc->dev.parent = dev;
> + ir->rc->driver_name = MTK_IR_DEV;
> + ir->rc->allowed_protocols = RC_BIT_ALL;
> + ir->rc->rx_resolution = MTK_IR_SAMPLE;
> + ir->rc->timeout = MTK_MAX_SAMPLES * (MTK_IR_SAMPLE + 1);
> +
> + ret = devm_rc_register_device(dev, ir->rc);
Here you do devm_rc_register_device()
> + if (ret) {
> + dev_err(dev, "failed to register rc device\n");
> + return ret;
> + }
> +
> + platform_set_drvdata(pdev, ir);
> +
> + ir->irq = platform_get_irq(pdev, 0);
> + if (ir->irq < 0) {
> + dev_err(dev, "no irq resource\n");
> + return -ENODEV;
> + }
> +
> + /* Enable interrupt after proper hardware
> + * setup and IRQ handler registration
> + */
> + if (clk_prepare_enable(ir->clk)) {
> + dev_err(dev, "try to enable ir_clk failed\n");
> + ret = -EINVAL;
> + goto exit_clkdisable_clk;
> + }
> +
> + mtk_irq_disable(ir, MTK_IRINT_EN);
> +
> + ret = devm_request_irq(dev, ir->irq, mtk_ir_irq, 0, MTK_IR_DEV, ir);
> + if (ret) {
> + dev_err(dev, "failed request irq\n");
> + goto exit_clkdisable_clk;
> + }
> +
> + /* Enable IR and PWM */
> + val = mtk_r32(ir, MTK_CONFIG_HIGH_REG);
> + val |= MTK_PWM_EN | MTK_IR_EN;
> + mtk_w32(ir, val, MTK_CONFIG_HIGH_REG);
> +
> + /* Setting sample period */
> + mtk_w32_mask(ir, MTK_CHK_PERIOD, MTK_CHK_PERIOD_MASK,
> + MTK_CONFIG_LOW_REG);
> +
> + mtk_irq_enable(ir, MTK_IRINT_EN);
> +
> + dev_info(dev, "Initialized MT7623 IR driver, sample period = %luus\n",
> + DIV_ROUND_CLOSEST(MTK_IR_SAMPLE, 1000));
> +
> + return 0;
> +
> +exit_clkdisable_clk:
> + clk_disable_unprepare(ir->clk);
> +
> + return ret;
> +}
> +
> +static int mtk_ir_remove(struct platform_device *pdev)
> +{
> + struct mtk_ir *ir = platform_get_drvdata(pdev);
> +
> + /* Avoid contention between remove handler and
> + * IRQ handler so that disabling IR interrupt and
> + * waiting for pending IRQ handler to complete
> + */
> + mtk_irq_disable(ir, MTK_IRINT_EN);
> + synchronize_irq(ir->irq);
> +
> + clk_disable_unprepare(ir->clk);
> +
> + rc_unregister_device(ir->rc);
Yet here you explicitly call rc_unregister_device(). Since it was registered
with the devm call, this call is not needed and will lead to double frees etc
> +
> + return 0;
> +}
> +
> +static const struct of_device_id mtk_ir_match[] = {
> + { .compatible = "mediatek,mt7623-cir" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, mtk_ir_match);
> +
> +static struct platform_driver mtk_ir_driver = {
> + .probe = mtk_ir_probe,
> + .remove = mtk_ir_remove,
> + .driver = {
> + .name = MTK_IR_DEV,
> + .of_match_table = mtk_ir_match,
> + },
> +};
> +
> +module_platform_driver(mtk_ir_driver);
> +
> +MODULE_DESCRIPTION("Mediatek IR Receiver Controller Driver");
> +MODULE_AUTHOR("Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>");
> +MODULE_LICENSE("GPL");
> --
> 2.7.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v29 9/9] Documentation: dt: chosen properties for arm64 kdump
From: Will Deacon @ 2017-01-10 11:10 UTC (permalink / raw)
To: AKASHI Takahiro
Cc: catalin.marinas-5wv7dgnIgG8, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, james.morse-5wv7dgnIgG8,
geoff-wEGCiKHe2LqWVfeAwA7xHQ,
bauerman-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
dyoung-H+wXaHxf7aLQT0dZR+AlfA,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161228043734.27535-1-takahiro.akashi-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Hi James, Akashi,
On Wed, Dec 28, 2016 at 01:37:34PM +0900, AKASHI Takahiro wrote:
> From: James Morse <james.morse-5wv7dgnIgG8@public.gmane.org>
>
> Add documentation for
> linux,crashkernel-base and crashkernel-size,
> linux,usable-memory-range
> linux,elfcorehdr
> used by arm64 kdump to decribe the kdump reserved area, and
> the elfcorehdr's location within it.
>
> Signed-off-by: James Morse <james.morse-5wv7dgnIgG8@public.gmane.org>
> [takahiro.akashi-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org: added "linux,crashkernel-base" and "-size" ]
> Signed-off-by: AKASHI Takahiro <takahiro.akashi-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> ---
> Documentation/devicetree/bindings/chosen.txt | 50 ++++++++++++++++++++++++++++
> 1 file changed, 50 insertions(+)
I need an ack from Rob or Mark before I can merge this.
Will
--
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 11/11] dmaengine: cppi41: Fix teardown warnings
From: Alexandre Bailon @ 2017-01-10 11:11 UTC (permalink / raw)
To: Sergei Shtylyov, vinod.koul-ral2JQCrhuEAvxtiuMwx3w
Cc: dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, nsekhar-l0cyMroinI0,
khilman-rdvid1DuHRBWk0Htik3J/w, ptitiano-rdvid1DuHRBWk0Htik3J/w,
tony-4v6yS6AI5VpBDgjK7y7TUQ, linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
b-liu-l0cyMroinI0
In-Reply-To: <72228045-8c2d-3ea4-3fbb-00477b47a80b-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
On 01/09/2017 07:46 PM, Sergei Shtylyov wrote:
> On 01/09/2017 07:06 PM, Alexandre Bailon wrote:
>
>> During the teardown of a RX channel, because there is only one
>> completion queue available for RX channel, descriptor of another
>> channel may be popped which will cause 2 warnings:
>> - the first one because we popped a wrong descriptor
>> (neither the channel's descriptor, neither the teardown descriptor).
>
> Neither ... nor.
>
>> - the second one happen during the teardown of another channel,
>> because we can't find the channel descriptor
>> (that is, the one that caused the first warning).
>> Use the teardown queue as completion queue during the teardown.
>
> Hm, what's a teardown queue? I don't remember this documented...
> memory fade is always possible tho... :-)
I guess your memory is right :-)
There is no teardown queue. Though, we have to "allocate" an unassigned
queue and populate it with free teardown descriptors.
And when we are doing the teardown, we can select the queue to use for
completion. In the driver, we have to configure both of them.
Best regards,
Alexandre
>
>> Note that fix doesn't fix all the teardown warnings:
>> I still get some when I run some corner case.
>>
>> Signed-off-by: Alexandre Bailon <abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> [...]
>
> MBR, Sergei
>
--
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 v5 1/2] ARM: dts: at91: add devicetree for the Axentia TSE-850
From: Peter Rosin @ 2017-01-10 11:21 UTC (permalink / raw)
To: Alexandre Belloni
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland,
Russell King, Nicolas Ferre, Jean-Christophe Plagniol-Villard,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170110104248.iscurq55d7n26gfd-m++hUPXGwpdeoWH0uzbU5w@public.gmane.org>
On 2017-01-10 11:42, Alexandre Belloni wrote:
> On 10/01/2017 at 10:52:56 +0100, Peter Rosin wrote :
>> On 2017-01-10 10:29, Alexandre Belloni wrote:
>>> Hi,
>>>
>>> This needs a commit message, please add one.
>>
>> There's not all that much to say, but ok, I'll add something.
>>
>
> It doesn't have to be long but it has to be present.
Does it really? There are quite a few examples to contradict that,
and checkpatch doesn't complain. That's no proof of course...
As I said, I'll add something.
>>> On 10/01/2017 at 09:08:51 +0100, Peter Rosin wrote :
>> There's also the benefit of the increased chances of me getting
>> notified of changes. I don't mind...
>>
>
> Do you expect changes coming from third parties? I'm fine with it
> anyway.
Ok, I'll remember this and blame you for everything :-)
>>>> +&main {
>>>> + clock-frequency = <12000000>;
>>>> +};
>>>> +
>>>
>>> I don't think this is needed
>>>
>>>
>>
>> "this"? The &main frequency, or all of them?
>>
>
> I meant just main
Ok, I'll test with that change and then resend. Thanks!
Cheers,
peda
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 1/2] ARM: dts: at91: add devicetree for the Axentia TSE-850
From: Alexandre Belloni @ 2017-01-10 11:32 UTC (permalink / raw)
To: Peter Rosin
Cc: linux-kernel, Rob Herring, Mark Rutland, Russell King,
Nicolas Ferre, Jean-Christophe Plagniol-Villard, linux-arm-kernel,
devicetree
In-Reply-To: <81d5b553-38db-5137-2eac-145cb2f76578@axentia.se>
On 10/01/2017 at 12:21:42 +0100, Peter Rosin wrote :
> On 2017-01-10 11:42, Alexandre Belloni wrote:
> > On 10/01/2017 at 10:52:56 +0100, Peter Rosin wrote :
> >> On 2017-01-10 10:29, Alexandre Belloni wrote:
> >>> Hi,
> >>>
> >>> This needs a commit message, please add one.
> >>
> >> There's not all that much to say, but ok, I'll add something.
> >>
> >
> > It doesn't have to be long but it has to be present.
>
> Does it really? There are quite a few examples to contradict that,
> and checkpatch doesn't complain. That's no proof of course...
>
> As I said, I'll add something.
>
There is public shaming for maintainers taking patches without a commit
message, that's enough for me to require a commit message ;)
https://lwn.net/Articles/560392/
> >>> On 10/01/2017 at 09:08:51 +0100, Peter Rosin wrote :
> >> There's also the benefit of the increased chances of me getting
> >> notified of changes. I don't mind...
> >>
> >
> > Do you expect changes coming from third parties? I'm fine with it
> > anyway.
>
> Ok, I'll remember this and blame you for everything :-)
>
Well, you can let it there, I was just not sure whether you were
expecting to see patches or just trying to make checkpatch happy. As
said, I'm fine with it.
> >>>> +&main {
> >>>> + clock-frequency = <12000000>;
> >>>> +};
> >>>> +
> >>>
> >>> I don't think this is needed
> >>>
> >>>
> >>
> >> "this"? The &main frequency, or all of them?
> >>
> >
> > I meant just main
>
> Ok, I'll test with that change and then resend. Thanks!
>
> Cheers,
> peda
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 1/2] of: base: add support to get the number of cache levels
From: Sudeep Holla @ 2017-01-10 11:41 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Sudeep Holla, Rob Herring, Catalin Marinas, Will Deacon,
devicetree, linux-kernel, Tan Xiaojun, Mark Rutland
It is useful to have helper function just to get the number of cache
levels for a given logical cpu. This patch adds the support for the
same.
It will be used on ARM64 platform where the device tree provides the
information for the additional non-architected/transparent/external
last level caches that are not integrated with the processors.
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
drivers/of/base.c | 22 ++++++++++++++++++++++
include/linux/of.h | 1 +
2 files changed, 23 insertions(+)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index d4bea3c797d6..f7a2b47b3c77 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2268,6 +2268,28 @@ struct device_node *of_find_next_cache_node(const struct device_node *np)
}
/**
+ * of_count_cache_levels - Find the total number of cache levels for the
+ * given logical cpu
+ *
+ * @cpu: cpu number(logical index) for which cache levels is being counted
+ *
+ * Returns the total number of cache levels for the given logical cpu
+ */
+int of_count_cache_levels(unsigned int cpu)
+{
+ int level = 0;
+ struct device_node *np = of_cpu_device_node_get(cpu);
+
+ while (np) {
+ level++;
+ of_node_put(np);
+ np = of_find_next_cache_node(np);
+ }
+
+ return level;
+}
+
+/**
* of_graph_parse_endpoint() - parse common endpoint node properties
* @node: pointer to endpoint device_node
* @endpoint: pointer to the OF endpoint data structure
diff --git a/include/linux/of.h b/include/linux/of.h
index d72f01009297..c8597ae71ff3 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -280,6 +280,7 @@ extern struct device_node *of_get_child_by_name(const struct device_node *node,
/* cache lookup */
extern struct device_node *of_find_next_cache_node(const struct device_node *);
+extern int of_count_cache_levels(unsigned int cpu);
extern struct device_node *of_find_node_with_property(
struct device_node *from, const char *prop_name);
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] arm64: cacheinfo: add support to override cache levels via device tree
From: Sudeep Holla @ 2017-01-10 11:41 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Sudeep Holla, Rob Herring, Catalin Marinas, Will Deacon,
devicetree, linux-kernel, Tan Xiaojun, Mark Rutland
In-Reply-To: <1484048479-19767-1-git-send-email-sudeep.holla@arm.com>
The cache hierarchy can be identified through Cache Level ID(CLIDR)
architected system register. However in some cases it will provide
only the number of cache levels that are integrated into the processor
itself. In other words, it can't provide any information about the
caches that are external and/or transparent.
Some platforms require to export the information about all such external
caches to the userspace applications via the sysfs interface.
This patch adds support to override the cache levels using device tree
to take such external non-architected caches into account.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
arch/arm64/kernel/cacheinfo.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/cacheinfo.c b/arch/arm64/kernel/cacheinfo.c
index 9617301f76b5..fe7738a8c5b1 100644
--- a/arch/arm64/kernel/cacheinfo.c
+++ b/arch/arm64/kernel/cacheinfo.c
@@ -84,7 +84,7 @@ static void ci_leaf_init(struct cacheinfo *this_leaf,
static int __init_cache_level(unsigned int cpu)
{
- unsigned int ctype, level, leaves;
+ unsigned int ctype, level, leaves, of_level;
struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
for (level = 1, leaves = 0; level <= MAX_CACHE_LEVEL; level++) {
@@ -97,6 +97,17 @@ static int __init_cache_level(unsigned int cpu)
leaves += (ctype == CACHE_TYPE_SEPARATE) ? 2 : 1;
}
+ of_level = of_count_cache_levels(cpu);
+ if (level < of_level) {
+ /*
+ * some external caches not specified in CLIDR_EL1
+ * the information may be available in the device tree
+ * only unified external caches are considered here
+ */
+ leaves += (of_level - level);
+ level = of_level;
+ }
+
this_cpu_ci->num_levels = level;
this_cpu_ci->num_leaves = leaves;
return 0;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 1/2] of: base: add support to get the number of cache levels
From: Sudeep Holla @ 2017-01-10 11:56 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Sudeep Holla, Rob Herring, Catalin Marinas, Will Deacon,
devicetree, linux-kernel, Tan Xiaojun, Mark Rutland
In-Reply-To: <1484048479-19767-1-git-send-email-sudeep.holla@arm.com>
On 10/01/17 11:41, Sudeep Holla wrote:
> It is useful to have helper function just to get the number of cache
> levels for a given logical cpu. This patch adds the support for the
> same.
>
> It will be used on ARM64 platform where the device tree provides the
> information for the additional non-architected/transparent/external
> last level caches that are not integrated with the processors.
>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> drivers/of/base.c | 22 ++++++++++++++++++++++
> include/linux/of.h | 1 +
> 2 files changed, 23 insertions(+)
>
I seem to have missed to generate patch after I fixed the build error.
I will send updated version of this patch.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH 1/2][UPDATE] of: base: add support to get the number of cache levels
From: Sudeep Holla @ 2017-01-10 12:00 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Sudeep Holla, Rob Herring, Catalin Marinas, Will Deacon,
devicetree, linux-kernel, Tan Xiaojun, Mark Rutland
In-Reply-To: <1484048479-19767-1-git-send-email-sudeep.holla@arm.com>
It is useful to have helper function just to get the number of cache
levels for a given logical cpu. This patch adds the support for the
same.
It will be used on ARM64 platform where the device tree provides the
information for the additional non-architected/transparent/external
last level caches that are not integrated with the processors.
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
drivers/of/base.c | 23 +++++++++++++++++++++++
include/linux/of.h | 1 +
2 files changed, 24 insertions(+)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index d4bea3c797d6..80e557eca858 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -25,6 +25,7 @@
#include <linux/cpu.h>
#include <linux/module.h>
#include <linux/of.h>
+#include <linux/of_device.h>
#include <linux/of_graph.h>
#include <linux/spinlock.h>
#include <linux/slab.h>
@@ -2268,6 +2269,28 @@ struct device_node *of_find_next_cache_node(const struct device_node *np)
}
/**
+ * of_count_cache_levels - Find the total number of cache levels for the
+ * given logical cpu
+ *
+ * @cpu: cpu number(logical index) for which cache levels is being counted
+ *
+ * Returns the total number of cache levels for the given logical cpu
+ */
+int of_count_cache_levels(unsigned int cpu)
+{
+ int level = 0;
+ struct device_node *np = of_cpu_device_node_get(cpu);
+
+ while (np) {
+ level++;
+ of_node_put(np);
+ np = of_find_next_cache_node(np);
+ }
+
+ return level;
+}
+
+/**
* of_graph_parse_endpoint() - parse common endpoint node properties
* @node: pointer to endpoint device_node
* @endpoint: pointer to the OF endpoint data structure
diff --git a/include/linux/of.h b/include/linux/of.h
index d72f01009297..c8597ae71ff3 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -280,6 +280,7 @@ extern struct device_node *of_get_child_by_name(const struct device_node *node,
/* cache lookup */
extern struct device_node *of_find_next_cache_node(const struct device_node *);
+extern int of_count_cache_levels(unsigned int cpu);
extern struct device_node *of_find_node_with_property(
struct device_node *from, const char *prop_name);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2 2/2] media: rc: add driver for IR remote receiver on MT7623 SoC
From: kbuild test robot @ 2017-01-10 12:07 UTC (permalink / raw)
Cc: kbuild-all, mchehab, hdegoede, hkallweit1, robh+dt, mark.rutland,
matthias.bgg, andi.shyti, hverkuil, sean, ivo.g.dimitrov.75,
linux-media, devicetree, linux-mediatek, linux-arm-kernel,
linux-kernel, keyhaede, Sean Wang
In-Reply-To: <1484039631-25120-3-git-send-email-sean.wang@mediatek.com>
[-- Attachment #1: Type: text/plain, Size: 2615 bytes --]
Hi Sean,
[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.10-rc3 next-20170110]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/sean-wang-mediatek-com/Documentation-devicetree-Add-document-bindings-for-mtk-cir/20170110-193357
base: git://linuxtv.org/media_tree.git master
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
include/linux/compiler.h:253:8: sparse: attribute 'no_sanitize_address': unknown attribute
drivers/media/rc/mtk-cir.c:215:41: sparse: too many arguments for function devm_rc_allocate_device
drivers/media/rc/mtk-cir.c: In function 'mtk_ir_probe':
>> drivers/media/rc/mtk-cir.c:215:11: error: too many arguments to function 'devm_rc_allocate_device'
ir->rc = devm_rc_allocate_device(dev, RC_DRIVER_IR_RAW);
^~~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/media/rc/mtk-cir.c:22:0:
include/media/rc-core.h:213:16: note: declared here
struct rc_dev *devm_rc_allocate_device(struct device *dev);
^~~~~~~~~~~~~~~~~~~~~~~
sparse warnings: (new ones prefixed by >>)
include/linux/compiler.h:253:8: sparse: attribute 'no_sanitize_address': unknown attribute
>> drivers/media/rc/mtk-cir.c:215:41: sparse: too many arguments for function devm_rc_allocate_device
drivers/media/rc/mtk-cir.c: In function 'mtk_ir_probe':
drivers/media/rc/mtk-cir.c:215:11: error: too many arguments to function 'devm_rc_allocate_device'
ir->rc = devm_rc_allocate_device(dev, RC_DRIVER_IR_RAW);
^~~~~~~~~~~~~~~~~~~~~~~
In file included from drivers/media/rc/mtk-cir.c:22:0:
include/media/rc-core.h:213:16: note: declared here
struct rc_dev *devm_rc_allocate_device(struct device *dev);
^~~~~~~~~~~~~~~~~~~~~~~
vim +/devm_rc_allocate_device +215 drivers/media/rc/mtk-cir.c
209 ir->base = devm_ioremap_resource(dev, res);
210 if (IS_ERR(ir->base)) {
211 dev_err(dev, "failed to map registers\n");
212 return PTR_ERR(ir->base);
213 }
214
> 215 ir->rc = devm_rc_allocate_device(dev, RC_DRIVER_IR_RAW);
216 if (!ir->rc) {
217 dev_err(dev, "failed to allocate device\n");
218 return -ENOMEM;
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 57747 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3] arm64: dts: exynos5433: add DECON_TV node
From: Andi Shyti @ 2017-01-10 12:37 UTC (permalink / raw)
To: Andrzej Hajda
Cc: linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA, Krzysztof Kozlowski,
Bartlomiej Zolnierkiewicz, Marek Szyprowski, Inki Dae,
Rob Herring, Mark Rutland, Javier Martinez Canillas,
devicetree-u79uwXL29TY76Z2rM5mHXA, Andi Shyti, Chanwoo Choi
In-Reply-To: <1483958437-6572-1-git-send-email-a.hajda-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Hi Andrzej,
On Mon, Jan 09, 2017 at 11:40:35AM +0100, Andrzej Hajda wrote:
> DECON_TV is 2nd display controller on Exynos5433, used in HDMI path
> or 2nd DSI path.
>
> Signed-off-by: Andrzej Hajda <a.hajda-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> Reviewed-by: Javier Martinez Canillas <javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
> ---
>
> Hi Krzysztof,
>
> These patches are based on latest patches separating tm2 and tm2e and
> touchscreen patches. I hope this is good base.
> Thanks all for quick response/review.
All the three patches look good to me and they all apply on
Krzysztof's branch and next branch.
If you want you can add my review tag on all of them.
Andi
--
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 v6 0/2] Support for Axentia TSE-850
From: Peter Rosin @ 2017-01-10 13:18 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Peter Rosin, Rob Herring, Mark Rutland, Russell King,
Nicolas Ferre, Alexandre Belloni,
Jean-Christophe Plagniol-Villard,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
Hi!
changes v5 -> v6
- drop the &main clock-frequency
- add some text to the commit messages
- make config additions modules
changes v4 -> v5
- comment from Rob about the memory node made me look closer and
the memory size is actually updated by the bootloader, and that
hid the fact that the entry was always faulty. This version
specifies the correct memory size from the start, which is 64MB.
- ack from Rob
changes v3 -> v4
- rename files arch/arm/boot/dts/axentia-* to .../at91-*
- remove bootargs from at91-tse850-3.dts
- depend on the atmel ssc to register as a sound dai by itself
- bump copyright years
changes v2 -> v3
- document the new compatible strings prefixed with "axentia,".
changes v1 -> v2
- squash the fixup into the correct patch, sorry for the noise.
After finally having all essintial drivers upstreamed I would
like to have the dts and the defconfig also upstreamed.
The atmel-ssc/sound-dai change depends on a change that has been
sitting in the ASoC tree since mid-december, and I have been waiting
for it to hit linux-next before sending this, but it seems to take
longer than I anticipated. So, since I do not want this to in
turn miss the next merge window because of that wait I therefore
request that this is taken now even though it doesn't really work
w/o the ASoC "topic/atmel" branch as of 2016-12-15 [1]. It of course
builds cleanly even w/o those ASoC changes. That effectively means
that noone besides me should notice the inconsistency (I currently
have all affected devices under my control).
Cheers,
peda
[1] http://git.kernel.org/cgit/linux/kernel/git/broonie/sound.git/log/?h=topic/atmel
Peter Rosin (2):
ARM: dts: at91: add devicetree for the Axentia TSE-850
ARM: sama5_defconfig: add support for the Axentia TSE-850 board
Documentation/devicetree/bindings/arm/axentia.txt | 19 ++
MAINTAINERS | 8 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/at91-linea.dtsi | 49 ++++
arch/arm/boot/dts/at91-tse850-3.dts | 274 ++++++++++++++++++++++
arch/arm/configs/sama5_defconfig | 7 +-
6 files changed, 357 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/arm/axentia.txt
create mode 100644 arch/arm/boot/dts/at91-linea.dtsi
create mode 100644 arch/arm/boot/dts/at91-tse850-3.dts
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v6 1/2] ARM: dts: at91: add devicetree for the Axentia TSE-850
From: Peter Rosin @ 2017-01-10 13:18 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Peter Rosin, Rob Herring, Mark Rutland, Russell King,
Nicolas Ferre, Alexandre Belloni,
Jean-Christophe Plagniol-Villard,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1484054314-6244-1-git-send-email-peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
The Axentia TSE-850 is a SAMA5D3-based device designed to generate
FM subcarrier signals.
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
---
Documentation/devicetree/bindings/arm/axentia.txt | 19 ++
MAINTAINERS | 8 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/at91-linea.dtsi | 49 ++++
arch/arm/boot/dts/at91-tse850-3.dts | 274 ++++++++++++++++++++++
5 files changed, 351 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/axentia.txt
create mode 100644 arch/arm/boot/dts/at91-linea.dtsi
create mode 100644 arch/arm/boot/dts/at91-tse850-3.dts
diff --git a/Documentation/devicetree/bindings/arm/axentia.txt b/Documentation/devicetree/bindings/arm/axentia.txt
new file mode 100644
index 000000000000..ea3fb96ae465
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/axentia.txt
@@ -0,0 +1,19 @@
+Device tree bindings for Axentia ARM devices
+============================================
+
+Linea CPU module
+----------------
+
+Required root node properties:
+compatible = "axentia,linea",
+ "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+and following the rules from atmel-at91.txt for a sama5d31 SoC.
+
+
+TSE-850 v3 board
+----------------
+
+Required root node properties:
+compatible = "axentia,tse850v3", "axentia,linea",
+ "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+and following the rules from above for the axentia,linea CPU module.
diff --git a/MAINTAINERS b/MAINTAINERS
index 97b78cc5aa51..5c2ea6e9cd7f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2346,6 +2346,14 @@ S: Maintained
F: Documentation/devicetree/bindings/sound/axentia,*
F: sound/soc/atmel/tse850-pcm5142.c
+AXENTIA ARM DEVICES
+M: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
+L: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org (moderated for non-subscribers)
+S: Maintained
+F: Documentation/devicetree/bindings/arm/axentia.txt
+F: arch/arm/boot/dts/at91-linea.dtsi
+F: arch/arm/boot/dts/at91-tse850-3.dts
+
AZ6007 DVB DRIVER
M: Mauro Carvalho Chehab <mchehab-JsYNTwtnfakRB7SZvlqPiA@public.gmane.org>
M: Mauro Carvalho Chehab <mchehab-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9a7375c388a8..7632849866de 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -48,6 +48,7 @@ dtb-$(CONFIG_SOC_SAM_V7) += \
at91-kizbox2.dtb \
at91-sama5d2_xplained.dtb \
at91-sama5d3_xplained.dtb \
+ at91-tse850-3.dtb \
sama5d31ek.dtb \
sama5d33ek.dtb \
sama5d34ek.dtb \
diff --git a/arch/arm/boot/dts/at91-linea.dtsi b/arch/arm/boot/dts/at91-linea.dtsi
new file mode 100644
index 000000000000..0721c8472509
--- /dev/null
+++ b/arch/arm/boot/dts/at91-linea.dtsi
@@ -0,0 +1,49 @@
+/*
+ * at91-linea.dtsi - Device Tree Include file for the Axentia Linea Module.
+ *
+ * Copyright (C) 2017 Axentia Technologies AB
+ *
+ * Author: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
+ *
+ * Licensed under GPLv2 or later.
+ */
+
+#include "sama5d31.dtsi"
+
+/ {
+ compatible = "axentia,linea",
+ "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+
+ memory {
+ reg = <0x20000000 0x4000000>;
+ };
+};
+
+&slow_xtal {
+ clock-frequency = <32768>;
+};
+
+&main_xtal {
+ clock-frequency = <12000000>;
+};
+
+&i2c0 {
+ status = "okay";
+
+ eeprom@51 {
+ compatible = "st,24c64";
+ reg = <0x51>;
+ pagesize = <32>;
+ };
+};
+
+&nand0 {
+ status = "okay";
+
+ nand-bus-width = <8>;
+ nand-ecc-mode = "hw";
+ atmel,has-pmecc;
+ atmel,pmecc-cap = <4>;
+ atmel,pmecc-sector-size = <512>;
+ nand-on-flash-bbt;
+};
diff --git a/arch/arm/boot/dts/at91-tse850-3.dts b/arch/arm/boot/dts/at91-tse850-3.dts
new file mode 100644
index 000000000000..669a2c6bdefc
--- /dev/null
+++ b/arch/arm/boot/dts/at91-tse850-3.dts
@@ -0,0 +1,274 @@
+/*
+ * at91-tse850-3.dts - Device Tree file for the Axentia TSE-850 3.0 board
+ *
+ * Copyright (C) 2017 Axentia Technologies AB
+ *
+ * Author: Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
+ *
+ * Licensed under GPLv2 or later.
+ */
+/dts-v1/;
+#include <dt-bindings/pwm/pwm.h>
+#include "at91-linea.dtsi"
+
+/ {
+ model = "Axentia TSE-850 3.0";
+ compatible = "axentia,tse850v3", "axentia,linea",
+ "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5";
+
+ ahb {
+ apb {
+ pinctrl@fffff200 {
+ tse850 {
+ pinctrl_usba_vbus: usba-vbus {
+ atmel,pins =
+ <AT91_PIOC 31
+ AT91_PERIPH_GPIO
+ AT91_PINCTRL_DEGLITCH>;
+ };
+ };
+ };
+
+ watchdog@fffffe40 {
+ status = "okay";
+ };
+ };
+ };
+
+ sck: oscillator {
+ compatible = "fixed-clock";
+
+ #clock-cells = <0>;
+ clock-frequency = <16000000>;
+ clock-output-names = "sck";
+ };
+
+ reg_3v3: regulator {
+ compatible = "regulator-fixed";
+
+ regulator-name = "3v3-supply";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ ana: reg-ana {
+ compatible = "pwm-regulator";
+
+ regulator-name = "ANA";
+
+ pwms = <&pwm0 2 1000 PWM_POLARITY_INVERTED>;
+ pwm-dutycycle-unit = <1000>;
+ pwm-dutycycle-range = <100 1000>;
+
+ regulator-min-microvolt = <2000000>;
+ regulator-max-microvolt = <20000000>;
+ regulator-ramp-delay = <1000>;
+ };
+
+ sound {
+ compatible = "axentia,tse850-pcm5142";
+
+ axentia,cpu-dai = <&ssc0>;
+ axentia,audio-codec = <&pcm5142>;
+
+ axentia,add-gpios = <&pioA 8 GPIO_ACTIVE_LOW>;
+ axentia,loop1-gpios = <&pioA 10 GPIO_ACTIVE_LOW>;
+ axentia,loop2-gpios = <&pioA 11 GPIO_ACTIVE_LOW>;
+
+ axentia,ana-supply = <&ana>;
+ };
+
+ dac: dpot-dac {
+ compatible = "dpot-dac";
+ vref-supply = <®_3v3>;
+ io-channels = <&dpot 0>;
+ io-channel-names = "dpot";
+ #io-channel-cells = <1>;
+ };
+
+ envelope-detector {
+ compatible = "axentia,tse850-envelope-detector";
+ io-channels = <&dac 0>;
+ io-channel-names = "dac";
+
+ interrupt-parent = <&pioA>;
+ interrupts = <3 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "comp";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ ch1-red {
+ label = "ch-1:red";
+ gpios = <&pioA 23 GPIO_ACTIVE_LOW>;
+ };
+ ch1-green {
+ label = "ch-1:green";
+ gpios = <&pioA 22 GPIO_ACTIVE_LOW>;
+ };
+ ch2-red {
+ label = "ch-2:red";
+ gpios = <&pioA 21 GPIO_ACTIVE_LOW>;
+ };
+ ch2-green {
+ label = "ch-2:green";
+ gpios = <&pioA 20 GPIO_ACTIVE_LOW>;
+ };
+ data-red {
+ label = "data:red";
+ gpios = <&pioA 19 GPIO_ACTIVE_LOW>;
+ };
+ data-green {
+ label = "data:green";
+ gpios = <&pioA 18 GPIO_ACTIVE_LOW>;
+ };
+ alarm-red {
+ label = "alarm:red";
+ gpios = <&pioA 17 GPIO_ACTIVE_LOW>;
+ };
+ alarm-green {
+ label = "alarm:green";
+ gpios = <&pioA 16 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
+
+&nand0 {
+ at91bootstrap@0 {
+ label = "at91bootstrap";
+ reg = <0x0 0x40000>;
+ };
+
+ barebox@40000 {
+ label = "bootloader";
+ reg = <0x40000 0x60000>;
+ };
+
+ bareboxenv@c0000 {
+ label = "bareboxenv";
+ reg = <0xc0000 0x40000>;
+ };
+
+ bareboxenv2@100000 {
+ label = "bareboxenv2";
+ reg = <0x100000 0x40000>;
+ };
+
+ oftree@180000 {
+ label = "oftree";
+ reg = <0x180000 0x20000>;
+ };
+
+ kernel@200000 {
+ label = "kernel";
+ reg = <0x200000 0x500000>;
+ };
+
+ rootfs@800000 {
+ label = "rootfs";
+ reg = <0x800000 0x0f800000>;
+ };
+
+ ovlfs@10000000 {
+ label = "ovlfs";
+ reg = <0x10000000 0x10000000>;
+ };
+};
+
+&ssc0 {
+ #sound-dai-cells = <0>;
+
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+
+ jc42@18 {
+ compatible = "nxp,se97b", "jedec,jc-42.4-temp";
+ reg = <0x18>;
+ };
+
+ dpot: mcp4651-104@28 {
+ compatible = "microchip,mcp4651-104";
+ reg = <0x28>;
+ #io-channel-cells = <1>;
+ };
+
+ pcm5142: pcm5142@4c {
+ compatible = "ti,pcm5142";
+
+ reg = <0x4c>;
+
+ AVDD-supply = <®_3v3>;
+ DVDD-supply = <®_3v3>;
+ CPVDD-supply = <®_3v3>;
+
+ clocks = <&sck>;
+
+ pll-in = <3>;
+ pll-out = <6>;
+ };
+
+ eeprom@50 {
+ compatible = "nxp,24c02";
+ reg = <0x50>;
+ pagesize = <16>;
+ };
+};
+
+&usart0 {
+ status = "okay";
+
+ atmel,use-dma-rx;
+};
+
+&pwm0 {
+ status = "okay";
+
+ pinctrl-0 = <&pinctrl_pwm0_pwml2_1>;
+ pinctrl-names = "default";
+};
+
+&macb1 {
+ status = "okay";
+
+ phy-mode = "rgmii";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ phy0: ethernet-phy@3 {
+ reg = <3>;
+
+ interrupt-parent = <&pioE>;
+ interrupts = <31 IRQ_TYPE_EDGE_FALLING>;
+ };
+};
+
+&usb0 {
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usba_vbus>;
+ atmel,vbus-gpio = <&pioC 31 GPIO_ACTIVE_HIGH>;
+};
+
+&usb1 {
+ status = "okay";
+
+ num-ports = <1>;
+ atmel,vbus-gpio = <&pioD 29 GPIO_ACTIVE_HIGH>;
+ atmel,oc-gpio = <&pioC 15 GPIO_ACTIVE_LOW>;
+};
+
+&usb2 {
+ status = "okay";
+};
+
+&dbgu {
+ status = "okay";
+
+ dmas = <0>, <0>; /* Do not use DMA for dbgu */
+};
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v6 2/2] ARM: sama5_defconfig: add support for the Axentia TSE-850 board
From: Peter Rosin @ 2017-01-10 13:18 UTC (permalink / raw)
To: linux-kernel
Cc: Peter Rosin, Rob Herring, Mark Rutland, Russell King,
Nicolas Ferre, Alexandre Belloni,
Jean-Christophe Plagniol-Villard, linux-arm-kernel, devicetree
In-Reply-To: <1484054314-6244-1-git-send-email-peda@axentia.se>
The Axentia TSE-850 is a SAMA5D3-based device designed to generate
FM subcarrier signals.
Signed-off-by: Peter Rosin <peda@axentia.se>
---
arch/arm/configs/sama5_defconfig | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/configs/sama5_defconfig b/arch/arm/configs/sama5_defconfig
index aca8625b6fc9..777c9e986425 100644
--- a/arch/arm/configs/sama5_defconfig
+++ b/arch/arm/configs/sama5_defconfig
@@ -131,7 +131,7 @@ CONFIG_GPIO_SYSFS=y
CONFIG_POWER_SUPPLY=y
CONFIG_BATTERY_ACT8945A=y
CONFIG_POWER_RESET=y
-# CONFIG_HWMON is not set
+CONFIG_SENSORS_JC42=m
CONFIG_WATCHDOG=y
CONFIG_AT91SAM9X_WATCHDOG=y
CONFIG_SAMA5D4_WATCHDOG=y
@@ -142,6 +142,7 @@ CONFIG_REGULATOR=y
CONFIG_REGULATOR_FIXED_VOLTAGE=y
CONFIG_REGULATOR_ACT8865=y
CONFIG_REGULATOR_ACT8945A=y
+CONFIG_REGULATOR_PWM=m
CONFIG_MEDIA_SUPPORT=y
CONFIG_MEDIA_CAMERA_SUPPORT=y
CONFIG_V4L_PLATFORM_DRIVERS=y
@@ -164,6 +165,7 @@ CONFIG_SND_ATMEL_SOC=y
CONFIG_SND_ATMEL_SOC_WM8904=y
# CONFIG_HID_GENERIC is not set
CONFIG_SND_ATMEL_SOC_PDMIC=y
+CONFIG_SND_ATMEL_SOC_TSE850_PCM5142=m
CONFIG_USB=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
CONFIG_USB_EHCI_HCD=y
@@ -199,6 +201,9 @@ CONFIG_AT_XDMAC=y
CONFIG_IIO=y
CONFIG_AT91_ADC=y
CONFIG_AT91_SAMA5D2_ADC=y
+CONFIG_ENVELOPE_DETECTOR=m
+CONFIG_DPOT_DAC=m
+CONFIG_MCP4531=m
CONFIG_PWM=y
CONFIG_PWM_ATMEL=y
CONFIG_PWM_ATMEL_HLCDC_PWM=y
--
2.1.4
^ permalink raw reply related
* Re: [PATCH v6 0/2] Support for Axentia TSE-850
From: Nicolas Ferre @ 2017-01-10 13:24 UTC (permalink / raw)
To: Peter Rosin, linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Rob Herring, Mark Rutland, Russell King, Alexandre Belloni,
Jean-Christophe Plagniol-Villard,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1484054314-6244-1-git-send-email-peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
Le 10/01/2017 à 14:18, Peter Rosin a écrit :
> Hi!
>
> changes v5 -> v6
> - drop the &main clock-frequency
> - add some text to the commit messages
> - make config additions modules
Acked-by: Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
for the whole series.
Thanks, best regards,
> changes v4 -> v5
> - comment from Rob about the memory node made me look closer and
> the memory size is actually updated by the bootloader, and that
> hid the fact that the entry was always faulty. This version
> specifies the correct memory size from the start, which is 64MB.
> - ack from Rob
>
> changes v3 -> v4
> - rename files arch/arm/boot/dts/axentia-* to .../at91-*
> - remove bootargs from at91-tse850-3.dts
> - depend on the atmel ssc to register as a sound dai by itself
> - bump copyright years
>
> changes v2 -> v3
> - document the new compatible strings prefixed with "axentia,".
>
> changes v1 -> v2
> - squash the fixup into the correct patch, sorry for the noise.
>
> After finally having all essintial drivers upstreamed I would
> like to have the dts and the defconfig also upstreamed.
>
> The atmel-ssc/sound-dai change depends on a change that has been
> sitting in the ASoC tree since mid-december, and I have been waiting
> for it to hit linux-next before sending this, but it seems to take
> longer than I anticipated. So, since I do not want this to in
> turn miss the next merge window because of that wait I therefore
> request that this is taken now even though it doesn't really work
> w/o the ASoC "topic/atmel" branch as of 2016-12-15 [1]. It of course
> builds cleanly even w/o those ASoC changes. That effectively means
> that noone besides me should notice the inconsistency (I currently
> have all affected devices under my control).
>
> Cheers,
> peda
>
> [1] http://git.kernel.org/cgit/linux/kernel/git/broonie/sound.git/log/?h=topic/atmel
>
> Peter Rosin (2):
> ARM: dts: at91: add devicetree for the Axentia TSE-850
> ARM: sama5_defconfig: add support for the Axentia TSE-850 board
>
> Documentation/devicetree/bindings/arm/axentia.txt | 19 ++
> MAINTAINERS | 8 +
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/at91-linea.dtsi | 49 ++++
> arch/arm/boot/dts/at91-tse850-3.dts | 274 ++++++++++++++++++++++
> arch/arm/configs/sama5_defconfig | 7 +-
> 6 files changed, 357 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/arm/axentia.txt
> create mode 100644 arch/arm/boot/dts/at91-linea.dtsi
> create mode 100644 arch/arm/boot/dts/at91-tse850-3.dts
>
--
Nicolas Ferre
--
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 0/3] arm64: dts: Fix DTC warnings for Exynos boards
From: Javier Martinez Canillas @ 2017-01-10 13:27 UTC (permalink / raw)
To: linux-kernel
Cc: Andi Shyti, Chanwoo Choi, Javier Martinez Canillas, devicetree,
Kukjin Kim, Catalin Marinas, linux-samsung-soc, Rob Herring,
Will Deacon, Mark Rutland, Krzysztof Kozlowski, linux-arm-kernel
Hello Krzysztof,
This trivial series contains fixes for DTC warnings caused by mismatches
between unit names and reg properties in device tree nodes.
The patches shouldn't cause a functional change but have been just build
tested. I compared the generated DTB though to make sure that only these
nodes changed.
Best regards,
Javier
Javier Martinez Canillas (3):
arm64: dts: Add missing unit name to Exynos7 SoC node
arm64: dts: Add missing unit name to Exynos5433 SoC node
arm64: dts: Remove unneeded unit names in Exynos5433 nodes
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 8 ++++----
arch/arm64/boot/dts/exynos/exynos7.dtsi | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 1/3] arm64: dts: Add missing unit name to Exynos7 SoC node
From: Javier Martinez Canillas @ 2017-01-10 13:27 UTC (permalink / raw)
To: linux-kernel
Cc: Andi Shyti, Chanwoo Choi, Javier Martinez Canillas, devicetree,
Kukjin Kim, Catalin Marinas, linux-samsung-soc, Rob Herring,
Will Deacon, Mark Rutland, Krzysztof Kozlowski, linux-arm-kernel
In-Reply-To: <1484054866-3988-1-git-send-email-javier@osg.samsung.com>
This patch fixes the following DTC warning about a mismatch
between a device node reg property and its unit name:
Node /soc has a reg or ranges property, but no unit name
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
arch/arm64/boot/dts/exynos/exynos7.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi b/arch/arm64/boot/dts/exynos/exynos7.dtsi
index 80aa60e38237..0d2fedc6ac2f 100644
--- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -69,7 +69,7 @@
method = "smc";
};
- soc: soc {
+ soc: soc@0 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] arm64: dts: Add missing unit name to Exynos5433 SoC node
From: Javier Martinez Canillas @ 2017-01-10 13:27 UTC (permalink / raw)
To: linux-kernel
Cc: Andi Shyti, Chanwoo Choi, Javier Martinez Canillas, devicetree,
Kukjin Kim, Catalin Marinas, linux-samsung-soc, Rob Herring,
Will Deacon, Mark Rutland, Krzysztof Kozlowski, linux-arm-kernel
In-Reply-To: <1484054866-3988-1-git-send-email-javier@osg.samsung.com>
This patch fixes the following DTC warning about a mismatch
between a device node reg property and its unit name:
Node /soc has a reg or ranges property, but no unit name
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 68f764e5851c..3695ddaf2e04 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -241,7 +241,7 @@
mask = <0x1>;
};
- soc: soc {
+ soc: soc@0 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
--
2.7.4
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: Remove unneeded unit names in Exynos5433 nodes
From: Javier Martinez Canillas @ 2017-01-10 13:27 UTC (permalink / raw)
To: linux-kernel
Cc: Andi Shyti, Chanwoo Choi, Javier Martinez Canillas, devicetree,
Kukjin Kim, Catalin Marinas, linux-samsung-soc, Rob Herring,
Will Deacon, Mark Rutland, Krzysztof Kozlowski, linux-arm-kernel
In-Reply-To: <1484054866-3988-1-git-send-email-javier@osg.samsung.com>
The "samsung,exynos5433-mipi-video-phy" and "samsung,exynos5250-dwusb3"
DT bindings don't specify a reg property for these nodes, so having a
unit name leads to the following DTC warnings:
Node /soc/video-phy@105c0710 has a unit name, but no reg property
Node /soc/usb@15400000 has a unit name, but no reg property
Node /soc/usb@15a00000 has a unit name, but no reg property
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index 3695ddaf2e04..17e5dafd392c 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
@@ -706,7 +706,7 @@
interrupts = <GIC_PPI 9 0xf04>;
};
- mipi_phy: video-phy@105c0710 {
+ mipi_phy: video-phy {
compatible = "samsung,exynos5433-mipi-video-phy";
#phy-cells = <1>;
samsung,pmu-syscon = <&pmu_system_controller>;
@@ -1285,7 +1285,7 @@
status = "disabled";
};
- usbdrd30: usb@15400000 {
+ usbdrd30: usb-0 {
compatible = "samsung,exynos5250-dwusb3";
clocks = <&cmu_fsys CLK_ACLK_USBDRD30>,
<&cmu_fsys CLK_SCLK_USBDRD30>;
@@ -1332,7 +1332,7 @@
status = "disabled";
};
- usbhost30: usb@15a00000 {
+ usbhost30: usb-1 {
compatible = "samsung,exynos5250-dwusb3";
clocks = <&cmu_fsys CLK_ACLK_USBHOST30>,
<&cmu_fsys CLK_SCLK_USBHOST30>;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 1/1] ARM: dts: add Armadeus Systems OPOS6UL and OPOS6ULDEV support
From: Sébastien Szymanski @ 2017-01-10 13:32 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, devicetree, Russell King, linux-kernel, Rob Herring,
Sascha Hauer, Fabio Estevam, Julien Boibessot, Shawn Guo
OPOS6UL is an i.MX6UL based SoM.
OPOS6ULDev is a carrier board for the OPOS6UL SoM.
For more details see:
http://www.opossom.com/english/products-processor_boards-opos6ul.html
http://www.opossom.com/english/products-development_boards-opos6ul_dev.html
Signed-off-by: Sébastien Szymanski <sebastien.szymanski@armadeus.com>
---
Changes since v1:
- use "and" instead of "AND" in the subject patch.
- use "uart-has-rtscts" instead of "fsl,uart-has-rtscts".
- use "backlight" instead of "lcd_backlight".
- use hyphen for node names.
- sort correctly pwm3 node and pwm3grp node.
- drop "fsl,spi-num-chipselects" property.
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6ul-opos6ul.dtsi | 192 +++++++++++++++
arch/arm/boot/dts/imx6ul-opos6uldev.dts | 412 ++++++++++++++++++++++++++++++++
3 files changed, 605 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6ul-opos6ul.dtsi
create mode 100644 arch/arm/boot/dts/imx6ul-opos6uldev.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7327250..f839c75 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -435,6 +435,7 @@ dtb-$(CONFIG_SOC_IMX6UL) += \
imx6ul-14x14-evk.dtb \
imx6ul-geam-kit.dtb \
imx6ul-liteboard.dtb \
+ imx6ul-opos6uldev.dtb \
imx6ul-pico-hobbit.dtb \
imx6ul-tx6ul-0010.dtb \
imx6ul-tx6ul-0011.dtb \
diff --git a/arch/arm/boot/dts/imx6ul-opos6ul.dtsi b/arch/arm/boot/dts/imx6ul-opos6ul.dtsi
new file mode 100644
index 0000000..51095df
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ul-opos6ul.dtsi
@@ -0,0 +1,192 @@
+/*
+ * Copyright 2017 Armadeus Systems <support@armadeus.com>
+ *
+ * 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 as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this file; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ *
+ * 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 "AS IS", 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.
+ */
+
+#include "imx6ul.dtsi"
+
+/ {
+ memory {
+ reg = <0x80000000 0>; /* will be filled by U-Boot */
+ };
+
+ reg_3v3: regulator-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ usdhc3_pwrseq: usdhc3-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&gpio2 9 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&fec1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet1>;
+ phy-mode = "rmii";
+ phy-reset-duration = <1>;
+ phy-reset-gpios = <&gpio4 2 GPIO_ACTIVE_LOW>;
+ phy-handle = <ðphy1>;
+ phy-supply = <®_3v3>;
+ status = "okay";
+
+ mdio: mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy1: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <16 IRQ_TYPE_LEVEL_LOW>;
+ status = "okay";
+ };
+ };
+};
+
+/* Bluetooth */
+&uart8 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart8>;
+ uart-has-rtscts;
+ status = "okay";
+};
+
+/* eMMC */
+&usdhc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ bus-width = <8>;
+ no-1-8-v;
+ non-removable;
+ status = "okay";
+};
+
+/* WiFi */
+&usdhc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc2>;
+ bus-width = <4>;
+ no-1-8-v;
+ non-removable;
+ mmc-pwrseq = <&usdhc3_pwrseq>;
+ status = "okay";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ brcmf: bcrmf@1 {
+ compatible = "brcm,bcm4329-fmac";
+ reg = <1>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-names = "host-wake";
+ };
+};
+
+&iomuxc {
+ pinctrl_enet1: enet1grp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO06__ENET1_MDIO 0x1b0b0
+ MX6UL_PAD_GPIO1_IO07__ENET1_MDC 0x1b0b0
+ MX6UL_PAD_ENET1_RX_ER__ENET1_RX_ER 0x130b0
+ MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN 0x130b0
+ MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01 0x130b0
+ MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00 0x130b0
+ MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00 0x1b0b0
+ MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01 0x1b0b0
+ MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN 0x1b0b0
+ /* INT# */
+ MX6UL_PAD_NAND_DQS__GPIO4_IO16 0x1b0b0
+ /* RST# */
+ MX6UL_PAD_NAND_DATA00__GPIO4_IO02 0x130b0
+ MX6UL_PAD_ENET1_TX_CLK__ENET1_REF_CLK1 0x4001b031
+ >;
+ };
+
+ pinctrl_uart8: uart8grp {
+ fsl,pins = <
+ MX6UL_PAD_ENET2_TX_EN__UART8_DCE_RX 0x1b0b0
+ MX6UL_PAD_ENET2_TX_DATA1__UART8_DCE_TX 0x1b0b0
+ MX6UL_PAD_ENET2_RX_ER__UART8_DCE_RTS 0x1b0b0
+ MX6UL_PAD_ENET2_TX_CLK__UART8_DCE_CTS 0x1b0b0
+ /* BT_REG_ON */
+ MX6UL_PAD_ENET2_RX_EN__GPIO2_IO10 0x130b0
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX6UL_PAD_SD1_CMD__USDHC1_CMD 0x17059
+ MX6UL_PAD_SD1_CLK__USDHC1_CLK 0x10059
+ MX6UL_PAD_SD1_DATA0__USDHC1_DATA0 0x17059
+ MX6UL_PAD_SD1_DATA1__USDHC1_DATA1 0x17059
+ MX6UL_PAD_SD1_DATA2__USDHC1_DATA2 0x17059
+ MX6UL_PAD_SD1_DATA3__USDHC1_DATA3 0x17059
+ MX6UL_PAD_NAND_READY_B__USDHC1_DATA4 0x17059
+ MX6UL_PAD_NAND_CE0_B__USDHC1_DATA5 0x17059
+ MX6UL_PAD_NAND_CE1_B__USDHC1_DATA6 0x17059
+ MX6UL_PAD_NAND_CLE__USDHC1_DATA7 0x17059
+ >;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX6UL_PAD_LCD_DATA18__USDHC2_CMD 0x1b0b0
+ MX6UL_PAD_LCD_DATA19__USDHC2_CLK 0x100b0
+ MX6UL_PAD_LCD_DATA20__USDHC2_DATA0 0x1b0b0
+ MX6UL_PAD_LCD_DATA21__USDHC2_DATA1 0x1b0b0
+ MX6UL_PAD_LCD_DATA22__USDHC2_DATA2 0x1b0b0
+ MX6UL_PAD_LCD_DATA23__USDHC2_DATA3 0x1b0b0
+ /* WL_REG_ON */
+ MX6UL_PAD_ENET2_RX_DATA1__GPIO2_IO09 0x130b0
+ /* WL_IRQ */
+ MX6UL_PAD_ENET2_RX_DATA0__GPIO2_IO08 0x1b0b0
+ >;
+ };
+};
diff --git a/arch/arm/boot/dts/imx6ul-opos6uldev.dts b/arch/arm/boot/dts/imx6ul-opos6uldev.dts
new file mode 100644
index 0000000..0e59ee5
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ul-opos6uldev.dts
@@ -0,0 +1,412 @@
+/*
+ * Copyright 2017 Armadeus Systems <support@armadeus.com>
+ *
+ * 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 as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public
+ * License along with this file; if not, write to the Free
+ * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
+ * MA 02110-1301 USA
+ *
+ * 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 "AS IS", 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.
+ */
+
+/dts-v1/;
+#include "imx6ul-opos6ul.dtsi"
+
+/ {
+ model = "Armadeus Systems OPOS6UL SoM on OPOS6ULDev board";
+ compatible = "armadeus,opos6uldev", "armadeus,opos6ul", "fsl,imx6ul";
+
+ chosen {
+ stdout-path = &uart1;
+ };
+
+ backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm3 0 191000>;
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <7>;
+ power-supply = <®_5v>;
+ status = "okay";
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_keys>;
+
+ user-button {
+ label = "User button";
+ gpios = <&gpio2 11 GPIO_ACTIVE_LOW>;
+ linux,code = <BTN_MISC>;
+ wakeup-source;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ user-led {
+ label = "User";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_led>;
+ gpios = <&gpio3 4 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+ };
+
+ onewire {
+ compatible = "w1-gpio";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_w1>;
+ gpios = <&gpio5 1 GPIO_ACTIVE_HIGH>;
+ };
+
+ reg_5v: regulator-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "5V";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
+
+ reg_usbotg1_vbus: regulator-usbotg1vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usbotg1vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbotg1_vbus>;
+ gpio = <&gpio1 5 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_usbotg2_vbus: regulator-usbotg2vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usbotg2vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbotg2_vbus>;
+ gpio = <&gpio5 9 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+};
+
+&adc1 {
+ vref-supply = <®_3v3>;
+ status = "okay";
+};
+
+&can1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan1>;
+ xceiver-supply = <®_5v>;
+ status = "okay";
+};
+
+&can2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan2>;
+ xceiver-supply = <®_5v>;
+ status = "okay";
+};
+
+&ecspi4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi4>;
+ cs-gpios = <&gpio4 9 GPIO_ACTIVE_LOW>, <&gpio4 3 GPIO_ACTIVE_LOW>;
+ status = "okay";
+
+ spidev0: spi@0 {
+ compatible = "spidev";
+ reg = <0>;
+ spi-max-frequency = <5000000>;
+ };
+
+ spidev1: spi@1 {
+ compatible = "spidev";
+ reg = <1>;
+ spi-max-frequency = <5000000>;
+ };
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ clock_frequency = <400000>;
+ status = "okay";
+};
+
+&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ clock_frequency = <400000>;
+ status = "okay";
+};
+
+&lcdif {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lcdif>;
+ display = <&display0>;
+ lcd-supply = <®_3v3>;
+ status = "okay";
+
+ display0: display0 {
+ bits-per-pixel = <32>;
+ bus-width = <18>;
+
+ display-timings {
+ timing0: timing0 {
+ clock-frequency = <33000033>;
+ hactive = <800>;
+ vactive = <480>;
+ hback-porch = <96>;
+ hfront-porch = <96>;
+ vback-porch = <20>;
+ vfront-porch = <21>;
+ hsync-len = <64>;
+ vsync-len = <4>;
+ de-active = <1>;
+ pixelclk-active = <0>;
+ };
+ };
+ };
+};
+
+&pwm3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm3>;
+ status = "okay";
+};
+
+&snvs_pwrkey {
+ status = "disabled";
+};
+
+&tsc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tsc>;
+ xnur-gpio = <&gpio1 3 GPIO_ACTIVE_LOW>;
+ measure-delay-time = <0xffff>;
+ pre-charge-time = <0xffff>;
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ status = "okay";
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+ status = "okay";
+};
+
+&usbotg1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbotg1_id>;
+ vbus-supply = <®_usbotg1_vbus>;
+ dr_mode = "otg";
+ disable-over-current;
+ status = "okay";
+};
+
+&usbotg2 {
+ vbus-supply = <®_usbotg2_vbus>;
+ dr_mode = "host";
+ disable-over-current;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpios>;
+
+ pinctrl_ecspi4: ecspi4grp {
+ fsl,pins = <
+ MX6UL_PAD_NAND_DATA04__ECSPI4_SCLK 0x1b0b0
+ MX6UL_PAD_NAND_DATA05__ECSPI4_MOSI 0x1b0b0
+ MX6UL_PAD_NAND_DATA06__ECSPI4_MISO 0x1b0b0
+ MX6UL_PAD_NAND_DATA01__GPIO4_IO03 0x1b0b0
+ MX6UL_PAD_NAND_DATA07__GPIO4_IO09 0x1b0b0
+ >;
+ };
+
+ pinctrl_flexcan1: flexcan1grp {
+ fsl,pins = <
+ MX6UL_PAD_UART3_CTS_B__FLEXCAN1_TX 0x0b0b0
+ MX6UL_PAD_UART3_RTS_B__FLEXCAN1_RX 0x0b0b0
+ >;
+ };
+
+ pinctrl_flexcan2: flexcan2grp {
+ fsl,pins = <
+ MX6UL_PAD_UART2_CTS_B__FLEXCAN2_TX 0x0b0b0
+ MX6UL_PAD_UART2_RTS_B__FLEXCAN2_RX 0x0b0b0
+ >;
+ };
+
+ pinctrl_gpios: gpiosgrp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO09__GPIO1_IO09 0x0b0b0
+ MX6UL_PAD_UART3_RX_DATA__GPIO1_IO25 0x0b0b0
+ MX6UL_PAD_UART3_TX_DATA__GPIO1_IO24 0x0b0b0
+ MX6UL_PAD_NAND_RE_B__GPIO4_IO00 0x0b0b0
+ MX6UL_PAD_GPIO1_IO08__GPIO1_IO08 0x0b0b0
+ MX6UL_PAD_UART1_CTS_B__GPIO1_IO18 0x0b0b0
+ MX6UL_PAD_UART1_RTS_B__GPIO1_IO19 0x0b0b0
+ MX6UL_PAD_NAND_WE_B__GPIO4_IO01 0x0b0b0
+ MX6UL_PAD_SNVS_TAMPER0__GPIO5_IO00 0x0b0b0
+ MX6UL_PAD_SNVS_TAMPER2__GPIO5_IO02 0x0b0b0
+ MX6UL_PAD_SNVS_TAMPER3__GPIO5_IO03 0x0b0b0
+ MX6UL_PAD_SNVS_TAMPER4__GPIO5_IO04 0x0b0b0
+ MX6UL_PAD_SNVS_TAMPER5__GPIO5_IO05 0x0b0b0
+ MX6UL_PAD_SNVS_TAMPER6__GPIO5_IO06 0x0b0b0
+ MX6UL_PAD_SNVS_TAMPER7__GPIO5_IO07 0x0b0b0
+ MX6UL_PAD_SNVS_TAMPER8__GPIO5_IO08 0x0b0b0
+ >;
+ };
+
+ pinctrl_gpio_keys: gpiokeysgrp {
+ fsl,pins = <
+ MX6UL_PAD_ENET2_TX_DATA0__GPIO2_IO11 0x0b0b0
+ >;
+ };
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ MX6UL_PAD_UART4_RX_DATA__I2C1_SDA 0x4001b8b0
+ MX6UL_PAD_UART4_TX_DATA__I2C1_SCL 0x4001b8b0
+ >;
+ };
+
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX6UL_PAD_UART5_RX_DATA__I2C2_SDA 0x4001b8b0
+ MX6UL_PAD_UART5_TX_DATA__I2C2_SCL 0x4001b8b0
+ >;
+ };
+
+ pinctrl_lcdif: lcdifgrp {
+ fsl,pins = <
+ MX6UL_PAD_LCD_CLK__LCDIF_CLK 0x100b1
+ MX6UL_PAD_LCD_ENABLE__LCDIF_ENABLE 0x100b1
+ MX6UL_PAD_LCD_HSYNC__LCDIF_HSYNC 0x100b1
+ MX6UL_PAD_LCD_VSYNC__LCDIF_VSYNC 0x100b1
+ MX6UL_PAD_LCD_DATA00__LCDIF_DATA00 0x100b1
+ MX6UL_PAD_LCD_DATA01__LCDIF_DATA01 0x100b1
+ MX6UL_PAD_LCD_DATA02__LCDIF_DATA02 0x100b1
+ MX6UL_PAD_LCD_DATA03__LCDIF_DATA03 0x100b1
+ MX6UL_PAD_LCD_DATA04__LCDIF_DATA04 0x100b1
+ MX6UL_PAD_LCD_DATA05__LCDIF_DATA05 0x100b1
+ MX6UL_PAD_LCD_DATA06__LCDIF_DATA06 0x100b1
+ MX6UL_PAD_LCD_DATA07__LCDIF_DATA07 0x100b1
+ MX6UL_PAD_LCD_DATA08__LCDIF_DATA08 0x100b1
+ MX6UL_PAD_LCD_DATA09__LCDIF_DATA09 0x100b1
+ MX6UL_PAD_LCD_DATA10__LCDIF_DATA10 0x100b1
+ MX6UL_PAD_LCD_DATA11__LCDIF_DATA11 0x100b1
+ MX6UL_PAD_LCD_DATA12__LCDIF_DATA12 0x100b1
+ MX6UL_PAD_LCD_DATA13__LCDIF_DATA13 0x100b1
+ MX6UL_PAD_LCD_DATA14__LCDIF_DATA14 0x100b1
+ MX6UL_PAD_LCD_DATA15__LCDIF_DATA15 0x100b1
+ MX6UL_PAD_LCD_DATA16__LCDIF_DATA16 0x100b1
+ MX6UL_PAD_LCD_DATA17__LCDIF_DATA17 0x100b1
+ >;
+ };
+
+ pinctrl_led: ledgrp {
+ fsl,pins = <
+ MX6UL_PAD_LCD_RESET__GPIO3_IO04 0x0b0b0
+ >;
+ };
+
+ pinctrl_pwm3: pwm3grp {
+ fsl,pins = <
+ MX6UL_PAD_NAND_ALE__PWM3_OUT 0x1b0b0
+ >;
+ };
+
+ pinctrl_tsc: tscgrp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO01__GPIO1_IO01 0xb0
+ MX6UL_PAD_GPIO1_IO02__GPIO1_IO02 0xb0
+ MX6UL_PAD_GPIO1_IO03__GPIO1_IO03 0xb0
+ MX6UL_PAD_GPIO1_IO04__GPIO1_IO04 0xb0
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX6UL_PAD_UART1_TX_DATA__UART1_DCE_TX 0x1b0b1
+ MX6UL_PAD_UART1_RX_DATA__UART1_DCE_RX 0x1b0b1
+ >;
+ };
+
+ pinctrl_uart2: uart2grp {
+ fsl,pins = <
+ MX6UL_PAD_UART2_TX_DATA__UART2_DCE_TX 0x1b0b1
+ MX6UL_PAD_UART2_RX_DATA__UART2_DCE_RX 0x1b0b1
+ >;
+ };
+
+ pinctrl_usbotg1_id: usbotg1idgrp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO00__ANATOP_OTG1_ID 0x1b0b0
+ >;
+ };
+
+ pinctrl_usbotg1_vbus: usbotg1vbusgrp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO05__GPIO1_IO05 0x1b0b0
+ >;
+ };
+
+ pinctrl_usbotg2_vbus: usbotg2vbusgrp {
+ fsl,pins = <
+ MX6UL_PAD_SNVS_TAMPER9__GPIO5_IO09 0x1b0b0
+ >;
+ };
+
+ pinctrl_w1: w1grp {
+ fsl,pins = <
+ MX6UL_PAD_SNVS_TAMPER1__GPIO5_IO01 0x0b0b0
+ >;
+ };
+};
--
2.7.3
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 3/3] arm64: dts: add BananaPi-M64 support
From: kbuild test robot @ 2017-01-10 13:37 UTC (permalink / raw)
To: Andre Przywara
Cc: kbuild-all-JC7UmRfGjtg, Maxime Ripard, Chen-Yu Tsai, Rob Herring,
Mark Rutland, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1484011353-21480-4-git-send-email-andre.przywara-5wv7dgnIgG8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1684 bytes --]
Hi Andre,
[auto build test ERROR on mripard/sunxi/for-next]
[also build test ERROR on next-20170110]
[cannot apply to robh/for-next v4.10-rc3]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Andre-Przywara/arm64-dts-A64-board-MMC-support/20170110-124554
base: https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git sunxi/for-next
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64
All errors (new ones prefixed by >>):
>> Error: arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts:80.1-6 Label or path mmc0 not found
>> Error: arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts:91.1-6 Label or path mmc1 not found
>> Error: arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts:100.1-6 Label or path mmc2 not found
FATAL ERROR: Syntax error parsing input tree
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 33694 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] ARM: dts: da850: Add the cppi41 dma node
From: Alexandre Bailon @ 2017-01-10 13:45 UTC (permalink / raw)
To: Sergei Shtylyov, nsekhar-l0cyMroinI0,
khilman-rdvid1DuHRBWk0Htik3J/w
Cc: vinod.koul-ral2JQCrhuEAvxtiuMwx3w,
dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, ptitiano-rdvid1DuHRBWk0Htik3J/w,
tony-4v6yS6AI5VpBDgjK7y7TUQ, linux-omap-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
b-liu-l0cyMroinI0, david-nq/r/kbU++upp/zk7JDF2g
In-Reply-To: <811adb6b-00e4-bbc4-d6f5-7bf3ba85ab63-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
On 01/09/2017 07:26 PM, Sergei Shtylyov wrote:
> Hello.
>
> On 01/09/2017 07:24 PM, Alexandre Bailon wrote:
>
>> This adds the device tree node for the cppi41 dma
>> used by the usb otg controller present in the da850 family of SoC's.
>>
>> Signed-off-by: Alexandre Bailon <abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>> ---
>> arch/arm/boot/dts/da850.dtsi | 16 ++++++++++++++++
>> 1 file changed, 16 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>> index 104155d..d6b406a 100644
>> --- a/arch/arm/boot/dts/da850.dtsi
>> +++ b/arch/arm/boot/dts/da850.dtsi
>> @@ -403,6 +403,22 @@
>> phy-names = "usb-phy";
>> status = "disabled";
>> };
>> + cppi41dma: dma-controller@201000 {
>> + compatible = "ti,da8xx-cppi41";
>> + reg = <0x200000 0x1000
>
> I don't remember any DA8xx glue regs having to do with the CPPI 4.1...
The CPPI 4.1 driver need it to manage the IRQ.
>
>> + 0x201000 0x1000
>> + 0x202000 0x1000
>> + 0x204000 0x4000>;
>> + reg-names = "glue", "controller",
>> + "scheduler", "queuemgr";
>> + interrupts = <58>;
>> + interrupt-names = "glue";
>> + #dma-cells = <2>;
>> + #dma-channels = <4>;
>> + #dma-requests = <256>;
>> + status = "disabled";
>
> Why disabled? It doesn't use any external pins...
Will fix it.
>
> [...]
>
> MBR, Sergei
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/2] media: rc: add driver for IR remote receiver on MT7623 SoC
From: Sean Wang @ 2017-01-10 13:59 UTC (permalink / raw)
To: Sean Young
Cc: mchehab, hdegoede, hkallweit1, robh+dt, mark.rutland,
matthias.bgg, andi.shyti, hverkuil, ivo.g.dimitrov.75,
linux-media, devicetree, linux-mediatek, linux-arm-kernel,
linux-kernel, keyhaede
In-Reply-To: <20170110110943.GA24889@gofer.mess.org>
On Tue, 2017-01-10 at 11:09 +0000, Sean Young wrote:
> > +#include <linux/clk.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/module.h>
> > +#include <linux/of_platform.h>
> > +#include <linux/reset.h>
> > +#include <media/rc-core.h>
> > +
> > +#define MTK_IR_DEV KBUILD_MODNAME
>
> You could remove this #define and just use KBUILD_MODNAME
I preferred to use MTK_IR_DEV internally that helps
renaming in the future if necessary.
>
> > +
> > +/* Register to enable PWM and IR */
> > +#define MTK_CONFIG_HIGH_REG 0x0c
> > +/* Enable IR pulse width detection */
> > +#define MTK_PWM_EN BIT(13)
> > +/* Enable IR hardware function */
> > +#define MTK_IR_EN BIT(0)
> > +
> > +/* Register to setting sample period */
> > +#define MTK_CONFIG_LOW_REG 0x10
> > +/* Field to set sample period */
> > +#define CHK_PERIOD DIV_ROUND_CLOSEST(MTK_IR_SAMPLE, \
> > + MTK_IR_CLK_PERIOD)
> > +#define MTK_CHK_PERIOD (((CHK_PERIOD) << 8) & (GENMASK(20, 8)))
> > +#define MTK_CHK_PERIOD_MASK (GENMASK(20, 8))
> > +
> > +/* Register to clear state of state machine */
> > +#define MTK_IRCLR_REG 0x20
> > +/* Bit to restart IR receiving */
> > +#define MTK_IRCLR BIT(0)
> > +
> > +/* Register containing pulse width data */
> > +#define MTK_CHKDATA_REG(i) (0x88 + 4 * (i))
> > +#define MTK_WIDTH_MASK (GENMASK(7, 0))
> > +
> > +/* Register to enable IR interrupt */
> > +#define MTK_IRINT_EN_REG 0xcc
> > +/* Bit to enable interrupt */
> > +#define MTK_IRINT_EN BIT(0)
> > +
> > +/* Register to ack IR interrupt */
> > +#define MTK_IRINT_CLR_REG 0xd0
> > +/* Bit to clear interrupt status */
> > +#define MTK_IRINT_CLR BIT(0)
> > +
> > +/* Maximum count of samples */
> > +#define MTK_MAX_SAMPLES 0xff
> > +/* Indicate the end of IR message */
> > +#define MTK_IR_END(v, p) ((v) == MTK_MAX_SAMPLES && (p) == 0)
> > +/* Number of registers to record the pulse width */
> > +#define MTK_CHKDATA_SZ 17
> > +/* Source clock frequency */
> > +#define MTK_IR_BASE_CLK 273000000
> > +/* Frequency after IR internal divider */
> > +#define MTK_IR_CLK_FREQ (MTK_IR_BASE_CLK / 4)
> > +static irqreturn_t mtk_ir_irq(int irqno, void *dev_id)
> > +{
> > + struct mtk_ir *ir = dev_id;
> > + u8 wid = 0;
> > + u32 i, j, val;
> > + DEFINE_IR_RAW_EVENT(rawir);
> > +
> > + mtk_irq_disable(ir, MTK_IRINT_EN);
>
> The kernel guarantees that calls to the interrupt handler are serialised,
> no need to disable the interrupt in the handler.
agreed. I will save the mtk irq disable/enable and retest again.
> > +
> > + /* Reset decoder state machine */
> > + ir_raw_event_reset(ir->rc);
>
> Not needed.
two reasons I added the line here
1)
I thought it is possible the decoder goes to the
middle state when getting the data not belonged
to the protocol. If so, that would cause the decoding
fails in the next time receiving the valid protocol data.
2)
the mtk hardware register always contains the start of
IR message. So force to sync the state between
HW and ir-core.
> > +
> > + /* First message must be pulse */
> > + rawir.pulse = false;
>
> pulse = true?
becasue of rawir.pulse = !rawir.pulse does as below
so the initial value is set as false.
> > +
> > + /* Handle all pulse and space IR controller captures */
> > + for (i = 0 ; i < MTK_CHKDATA_SZ ; i++) {
> > + val = mtk_r32(ir, MTK_CHKDATA_REG(i));
> > + dev_dbg(ir->dev, "@reg%d=0x%08x\n", i, val);
> > +
> > + for (j = 0 ; j < 4 ; j++) {
> > + wid = (val & (MTK_WIDTH_MASK << j * 8)) >> j * 8;
> > + rawir.pulse = !rawir.pulse;
> > + rawir.duration = wid * (MTK_IR_SAMPLE + 1);
> > + ir_raw_event_store_with_filter(ir->rc, &rawir);
> > + }
>
> In v1 you would break out of the loop if the ir message was shorter, but
> now you are always passing on 68 pulses and spaces. Is that right?
as I asked in the previous mail list as below i copied from it, so i
made some changes ...
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
> I had another question. I found multiple and same IR messages being
> received when using SONY remote controller. Should driver needs to
> report each message or only one of these to the upper layer ?
In general the driver shouldn't try to change any IR message, this
should be done in rc-core if necessary.
rc-core should handle this correctly. If the same key is received twice
within IR_KEYPRESS_TIMEOUT (250ms) then it not reported to the input
layer.
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
for example:
the 68 pulse/spaces might contains 2.x IR messages when I
pressed one key on SONY remote control.
the v1 proposed is passing only one IR message into ir-core ;
the v2 done is passing all IR messages even including the last
incomplete message into ir-core.
But I was still afraid the state machine can't go back to initial state
after receiving these incomplete data.
So the ir_raw_event_reset() call in the beginning of ISR seems becoming
more important.
> > + }
> > +
> > + /* The maximum number of edges the IR controller can
> > + * hold is MTK_CHKDATA_SZ * 4. So if received IR messages
> > + * is over the limit, the last incomplete IR message would
> > + * be appended trailing space and still would be sent into
> > + * ir-rc-raw to decode. That helps it is possible that it
> > + * has enough information to decode a scancode even if the
> > + * trailing end of the message is missing.
> > + */
> > + if (!MTK_IR_END(wid, rawir.pulse)) {
> > + rawir.pulse = false;
> > + rawir.duration = MTK_MAX_SAMPLES * (MTK_IR_SAMPLE + 1);
> > + ir_raw_event_store_with_filter(ir->rc, &rawir);
> > + }
> > +
> > + ir_raw_event_handle(ir->rc);
> > +
> > + /* Restart controller for the next receive */
> > + mtk_w32_mask(ir, 0x1, MTK_IRCLR, MTK_IRCLR_REG);
> > +
> > + /* Clear interrupt status */
> > + mtk_w32_mask(ir, 0x1, MTK_IRINT_CLR, MTK_IRINT_CLR_REG);
> > +
> > + /* Enable interrupt */
> > + mtk_irq_enable(ir, MTK_IRINT_EN);
> > +
> > + return IRQ_HANDLED;
> > +}
> > +
> > +static int mtk_ir_probe(struct platform_device *pdev)
> > +{
> > + struct device *dev = &pdev->dev;
> > + struct device_node *dn = dev->of_node;
> > + struct resource *res;
> > + struct mtk_ir *ir;
> > + u32 val;
> > + int ret = 0;
> > + const char *map_name;
> > +
> > + ir = devm_kzalloc(dev, sizeof(struct mtk_ir), GFP_KERNEL);
> > + if (!ir)
> > + return -ENOMEM;
> > +
> > + ir->dev = dev;
> > +
> > + if (!of_device_is_compatible(dn, "mediatek,mt7623-cir"))
> > + return -ENODEV;
> > +
> > + ir->clk = devm_clk_get(dev, "clk");
> > + if (IS_ERR(ir->clk)) {
> > + dev_err(dev, "failed to get a ir clock.\n");
> > + return PTR_ERR(ir->clk);
> > + }
> > +
> > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + ir->base = devm_ioremap_resource(dev, res);
> > + if (IS_ERR(ir->base)) {
> > + dev_err(dev, "failed to map registers\n");
> > + return PTR_ERR(ir->base);
> > + }
> > +
> > + ir->rc = devm_rc_allocate_device(dev, RC_DRIVER_IR_RAW);
> > + if (!ir->rc) {
> > + dev_err(dev, "failed to allocate device\n");
> > + return -ENOMEM;
> > + }
> > +
> > + ir->rc->priv = ir;
> > + ir->rc->input_name = MTK_IR_DEV;
> > + ir->rc->input_phys = MTK_IR_DEV "/input0";
> > + ir->rc->input_id.bustype = BUS_HOST;
> > + ir->rc->input_id.vendor = 0x0001;
> > + ir->rc->input_id.product = 0x0001;
> > + ir->rc->input_id.version = 0x0001;
> > + map_name = of_get_property(dn, "linux,rc-map-name", NULL);
> > + ir->rc->map_name = map_name ?: RC_MAP_EMPTY;
> > + ir->rc->dev.parent = dev;
> > + ir->rc->driver_name = MTK_IR_DEV;
> > + ir->rc->allowed_protocols = RC_BIT_ALL;
> > + ir->rc->rx_resolution = MTK_IR_SAMPLE;
> > + ir->rc->timeout = MTK_MAX_SAMPLES * (MTK_IR_SAMPLE + 1);
> > +
> > + ret = devm_rc_register_device(dev, ir->rc);
>
> Here you do devm_rc_register_device()
does it have problem ?
> > + if (ret) {
> > + dev_err(dev, "failed to register rc device\n");
> > + return ret;
> > + }
> > +
> > + platform_set_drvdata(pdev, ir);
> > +
> > + ir->irq = platform_get_irq(pdev, 0);
> > + if (ir->irq < 0) {
> > + dev_err(dev, "no irq resource\n");
> > + return -ENODEV;
> > + }
> > +
> > + /* Enable interrupt after proper hardware
> > + * setup and IRQ handler registration
> > + */
> > + if (clk_prepare_enable(ir->clk)) {
> > + dev_err(dev, "try to enable ir_clk failed\n");
> > + ret = -EINVAL;
> > + goto exit_clkdisable_clk;
> > + }
> > +
> > + mtk_irq_disable(ir, MTK_IRINT_EN);
> > +
> > + ret = devm_request_irq(dev, ir->irq, mtk_ir_irq, 0, MTK_IR_DEV, ir);
> > + if (ret) {
> > + dev_err(dev, "failed request irq\n");
> > + goto exit_clkdisable_clk;
> > + }
> > +
> > + /* Enable IR and PWM */
> > + val = mtk_r32(ir, MTK_CONFIG_HIGH_REG);
> > + val |= MTK_PWM_EN | MTK_IR_EN;
> > + mtk_w32(ir, val, MTK_CONFIG_HIGH_REG);
> > +
> > + /* Setting sample period */
> > + mtk_w32_mask(ir, MTK_CHK_PERIOD, MTK_CHK_PERIOD_MASK,
> > + MTK_CONFIG_LOW_REG);
> > +
> > + mtk_irq_enable(ir, MTK_IRINT_EN);
> > +
> > + dev_info(dev, "Initialized MT7623 IR driver, sample period = %luus\n",
> > + DIV_ROUND_CLOSEST(MTK_IR_SAMPLE, 1000));
> > +
> > + return 0;
> > +
> > +exit_clkdisable_clk:
> > + clk_disable_unprepare(ir->clk);
> > +
> > + return ret;
> > +}
> > +
> > +static int mtk_ir_remove(struct platform_device *pdev)
> > +{
> > + struct mtk_ir *ir = platform_get_drvdata(pdev);
> > +
> > + /* Avoid contention between remove handler and
> > + * IRQ handler so that disabling IR interrupt and
> > + * waiting for pending IRQ handler to complete
> > + */
> > + mtk_irq_disable(ir, MTK_IRINT_EN);
> > + synchronize_irq(ir->irq);
> > +
> > + clk_disable_unprepare(ir->clk);
> > +
> > + rc_unregister_device(ir->rc);
>
> Yet here you explicitly call rc_unregister_device(). Since it was registered
> with the devm call, this call is not needed and will lead to double frees etc
bug :( . I will fix it ..
> > +
> > + return 0;
> > +}
> > +
> > +static const struct of_device_id mtk_ir_match[] = {
> > + { .compatible = "mediatek,mt7623-cir" },
> > + {},
> > +};
> > +MODULE_DEVICE_TABLE(of, mtk_ir_match);
> > +
> > +static struct platform_driver mtk_ir_driver = {
> > + .probe = mtk_ir_probe,
> > + .remove = mtk_ir_remove,
> > + .driver = {
> > + .name = MTK_IR_DEV,
> > + .of_match_table = mtk_ir_match,
> > + },
> > +};
> > +
> > +module_platform_driver(mtk_ir_driver);
> > +
> > +MODULE_DESCRIPTION("Mediatek IR Receiver Controller Driver");
> > +MODULE_AUTHOR("Sean Wang <sean.wang@mediatek.com>");
> > +MODULE_LICENSE("GPL");
> > --
> > 2.7.4
> >
^ permalink raw reply
* Re: [PATCH 2/5] drivers: mmc: sunxi: limit A64 MMC2 to 8K DMA buffer
From: Maxime Ripard @ 2017-01-10 14:06 UTC (permalink / raw)
To: André Przywara
Cc: Rob Herring, Ulf Hansson, Chen-Yu Tsai, Hans De Goede,
Icenowy Zheng, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <87b26848-4f86-f2d2-3f82-db0937c572e2-5wv7dgnIgG8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2610 bytes --]
On Thu, Jan 05, 2017 at 11:33:28PM +0000, André Przywara wrote:
> On 05/01/17 17:57, Maxime Ripard wrote:
> > Hi Rob,
> >
> > On Wed, Jan 04, 2017 at 08:07:50AM -0600, Rob Herring wrote:
> >> On Mon, Jan 02, 2017 at 11:03:43PM +0000, Andre Przywara wrote:
> >>> From: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> >>>
> >>> Unlike the A64 user manual reports, the third MMC controller on the
> >>> A64 (and the only one capable of 8-bit HS400 eMMC transfers) has a
> >>> DMA buffer size limit of 8KB (much like the very old Allwinner SoCs).
> >>> This does not affect the other two controllers, so introduce a new
> >>> DT compatible string to let the driver use different settings for that
> >>> particular device. This will also help to enable the high-speed transfer
> >>> modes of that controller later.
> >>>
> >>> Signed-off-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> >>> Signed-off-by: Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org>
> >>> ---
> >>> Documentation/devicetree/bindings/mmc/sunxi-mmc.txt | 1 +
> >>> drivers/mmc/host/sunxi-mmc.c | 7 +++++++
> >>> 2 files changed, 8 insertions(+)
> >>
> >> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >
> > Some kind of a digression on this: we have three MMC controllers on
> > this SoC. Like this patch shows, the third one is clearly different,
> > and supports both more modes, a wider bus, and specific quirks. We
> > need a new compatible for this one, everything's perfect.
> >
> > However, the other two are mostly the same, but seems to need
> > different tuning parameters to get more performances out of the
> > controller (but this is unclear yet). How do we usually deal with
> > that?
>
> I guess you wanted to hear Rob's opinion ;-), but "get more performance"
> sounds like we add one (or more) properties to tune those values.
> If I get this right, it works with default values, but is sub-optimal?
That would be my understanding too, at least, it works in a decent way
without fiddling with those parameters.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox