* [PATCH] ARM: pxa: pxa_cplds: honor probe deferral
From: Robert Jarzmik @ 2016-09-26 7:21 UTC (permalink / raw)
To: linux-arm-kernel
The method to acquire the input interrupt was working in a platform data
based board, but was failing in a device-tree one when the gpio
controller was probed after pxa_cplds.
Use platform_get_irq() to benefit from the probe deferral
mechanism. Moreover, as seen in dm9000.c development, platform_get_irq()
doesn't honor the irq type IO resource (ie. edge rising for example),
and it must be passed again at irq request in a not device-tree build,
hence the irq_get_trigger_type() call.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
---
arch/arm/mach-pxa/pxa_cplds_irqs.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-pxa/pxa_cplds_irqs.c b/arch/arm/mach-pxa/pxa_cplds_irqs.c
index e362f865fcd2..941508585e34 100644
--- a/arch/arm/mach-pxa/pxa_cplds_irqs.c
+++ b/arch/arm/mach-pxa/pxa_cplds_irqs.c
@@ -120,13 +120,9 @@ static int cplds_probe(struct platform_device *pdev)
if (!fpga)
return -ENOMEM;
- res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
- if (res) {
- fpga->irq = (unsigned int)res->start;
- irqflags = res->flags;
- }
- if (!fpga->irq)
- return -ENODEV;
+ fpga->irq = platform_get_irq(pdev, 0);
+ if (fpga->irq <= 0)
+ return fpga->irq;
base_irq = platform_get_irq(pdev, 1);
if (base_irq < 0)
@@ -142,6 +138,7 @@ static int cplds_probe(struct platform_device *pdev)
writel(fpga->irq_mask, fpga->base + FPGA_IRQ_MASK_EN);
writel(0, fpga->base + FPGA_IRQ_SET_CLR);
+ irqflags = irq_get_trigger_type(fpga->irq);
ret = devm_request_irq(&pdev->dev, fpga->irq, cplds_irq_handler,
irqflags, dev_name(&pdev->dev), fpga);
if (ret == -ENOSYS)
--
2.1.4
^ permalink raw reply related
* [PATCH] usb: gadget: udc: atmel: fix endpoint name
From: Felipe Balbi @ 2016-09-26 7:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923150323.GB13744@kroah.com>
Hi,
Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
> On Fri, Sep 23, 2016 at 04:20:45PM +0200, Nicolas Ferre wrote:
>> Le 16/09/2016 ? 10:36, Nicolas Ferre a ?crit :
>> > Le 15/09/2016 ? 17:07, Alexandre Belloni a ?crit :
>> >> Since commit c32b5bcfa3c4 ("ARM: dts: at91: Fix USB endpoint nodes"),
>> >> atmel_usba_udc fails with:
>> >>
>> >> ------------[ cut here ]------------
>> >> WARNING: CPU: 0 PID: 0 at include/linux/usb/gadget.h:405
>> >> ecm_do_notify+0x188/0x1a0
>> >> Modules linked in:
>> >> CPU: 0 PID: 0 Comm: swapper Not tainted 4.7.0+ #15
>> >> Hardware name: Atmel SAMA5
>> >> [<c010ccfc>] (unwind_backtrace) from [<c010a7ec>] (show_stack+0x10/0x14)
>> >> [<c010a7ec>] (show_stack) from [<c0115c10>] (__warn+0xe4/0xfc)
>> >> [<c0115c10>] (__warn) from [<c0115cd8>] (warn_slowpath_null+0x20/0x28)
>> >> [<c0115cd8>] (warn_slowpath_null) from [<c04377ac>] (ecm_do_notify+0x188/0x1a0)
>> >> [<c04377ac>] (ecm_do_notify) from [<c04379a4>] (ecm_set_alt+0x74/0x1ac)
>> >> [<c04379a4>] (ecm_set_alt) from [<c042f74c>] (composite_setup+0xfc0/0x19f8)
>> >> [<c042f74c>] (composite_setup) from [<c04356e8>] (usba_udc_irq+0x8f4/0xd9c)
>> >> [<c04356e8>] (usba_udc_irq) from [<c013ec9c>] (handle_irq_event_percpu+0x9c/0x158)
>> >> [<c013ec9c>] (handle_irq_event_percpu) from [<c013ed80>] (handle_irq_event+0x28/0x3c)
>> >> [<c013ed80>] (handle_irq_event) from [<c01416d4>] (handle_fasteoi_irq+0xa0/0x168)
>> >> [<c01416d4>] (handle_fasteoi_irq) from [<c013e3f8>] (generic_handle_irq+0x24/0x34)
>> >> [<c013e3f8>] (generic_handle_irq) from [<c013e640>] (__handle_domain_irq+0x54/0xa8)
>> >> [<c013e640>] (__handle_domain_irq) from [<c010b214>] (__irq_svc+0x54/0x70)
>> >> [<c010b214>] (__irq_svc) from [<c0107eb0>] (arch_cpu_idle+0x38/0x3c)
>> >> [<c0107eb0>] (arch_cpu_idle) from [<c0137300>] (cpu_startup_entry+0x9c/0xdc)
>> >> [<c0137300>] (cpu_startup_entry) from [<c0900c40>] (start_kernel+0x354/0x360)
>> >> [<c0900c40>] (start_kernel) from [<20008078>] (0x20008078)
>> >> ---[ end trace e7cf9dcebf4815a6 ]---
>> >>
>> >> Fixes: c32b5bcfa3c4 ("ARM: dts: at91: Fix USB endpoint nodes")
>> >> Reported-by: Richard Genoud <richard.genoud@gmail.com>
>> >> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
>> >
>> > Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>> >
>> > Felipe, Greg,
>> > It is clearly a regression and material for 4.8-fixes. But I do know
>> > that we are very late in the process :-(
>> > Please do what you can to make it progress before 4.8-final but I'm
>> > truly aware of the challenge.
>>
>> Any chance that we can have it (aka ping)?
>
> It's Felipe's area, not mine :)
Sorry, I had missed this one. Greg, seems like this would be the only
pending fix. Do you want it in a pull request or would you prefer to
just pick it up as a patch? Works either way for me. In case you decide
to pick it up as a patch:
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
If you prefer to pick it up as a pull request, I already have the patch
in my 'fixes' branch, just need to tag it and send it to you.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160926/244552d8/attachment.sig>
^ permalink raw reply
* [PATCH v3 1/3] ipmi: add an Aspeed BT IPMI BMC driver
From: Cédric Le Goater @ 2016-09-26 6:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923183421.GA14864@rob-hp-laptop>
Hello,
On 09/23/2016 08:34 PM, Rob Herring wrote:
> On Tue, Sep 20, 2016 at 09:01:38AM +0200, C?dric Le Goater wrote:
>> From: Alistair Popple <alistair@popple.id.au>
>>
>> This patch adds a simple device driver to expose the iBT interface on
>> Aspeed SOCs (AST2400 and AST2500) as a character device. Such SOCs are
>> commonly used as BMCs (BaseBoard Management Controllers) and this
>> driver implements the BMC side of the BT interface.
>>
>> The BT (Block Transfer) interface is used to perform in-band IPMI
>> communication between a host and its BMC. Entire messages are buffered
>> before sending a notification to the other end, host or BMC, that
>> there is data to be read. Usually, the host emits requests and the BMC
>> responses but the specification provides a mean for the BMC to send
>> SMS Attention (BMC-to-Host attention or System Management Software
>> attention) messages.
>>
>> For this purpose, the driver introduces a specific ioctl on the
>> device: 'BT_BMC_IOCTL_SMS_ATN' that can be used by the system running
>> on the BMC to signal the host of such an event.
>>
>> The device name defaults to '/dev/ipmi-bt-host'
>>
>> Signed-off-by: Alistair Popple <alistair@popple.id.au>
>> Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
>> Signed-off-by: Joel Stanley <joel@jms.id.au>
>> [clg: - checkpatch fixes
>> - added a devicetree binding documentation
>> - replace 'bt_host' by 'bt_bmc' to reflect that the driver is
>> the BMC side of the IPMI BT interface
>> - renamed the device to 'ipmi-bt-host'
>> - introduced a temporary buffer to copy_{to,from}_user
>> - used platform_get_irq()
>> - moved the driver under drivers/char/ipmi/ but kept it as a misc
>> device
>> - changed the compatible cell to "aspeed,ast2400-bt-bmc"
>> ]
>> Signed-off-by: C?dric Le Goater <clg@kaod.org>
>> Acked-by: Arnd Bergmann <arnd@arndb.de>
>> [clg: - checkpatch --strict fixes
>> - removed the use of devm_iounmap, devm_kfree in cleanup paths
>> - introduced an atomic-t to limit opens to 1
>> - introduced a mutex to protect write/read operations]
>> Signed-off-by: C?dric Le Goater <clg@kaod.org>
>>
>> ---
>>
>> Changes since v2:
>>
>> - fixed checkpatch --strict issues
>> - cleanup'ed includes
>> - limit to one opener
>> - protect write/read operations with a mutex.
>> - removed the use of devm_iounmap, devm_kfree in cleanup paths
>>
>> Changes since v1:
>>
>> - replace 'bt_host' by 'bt_bmc' to reflect that the driver is
>> the BMC side of the IPMI BT interface
>> - renamed the device to 'ipmi-bt-host'
>> - introduced a temporary buffer to copy_{to,from}_user
>> - used platform_get_irq()
>> - moved the driver under drivers/char/ipmi/ but kept it as a misc
>> device
>> - changed the compatible cell to "aspeed,ast2400-bt-bmc"
>>
>> .../bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt | 23 +
>
> While similar, this is not the kernel directory structure. Just make
> this bindings/ipmi/
>
> With that,
>
> Acked-by: Rob Herring <robh@kernel.org>
OK. So I suppose we should be moving all IPMI documentation under
the same directory.
Corey,
If the move is okay for you, I can send the patch below.
Thanks,
C.
>From ca25f89b25209c260480cda5e5532d6bbe83ed43 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <clg@kaod.org>
Date: Mon, 26 Sep 2016 08:45:15 +0200
Subject: [PATCH] dt-bindings: ipmi: move all documentation under
bindings/ipmi/
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: C?dric Le Goater <clg@kaod.org>
---
.../devicetree/bindings/{char => }/ipmi/aspeed,ast2400-bt-bmc.txt | 0
Documentation/devicetree/bindings/{ipmi.txt => ipmi/ipmi-smic.txt} | 0
2 files changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/{char => }/ipmi/aspeed,ast2400-bt-bmc.txt (100%)
rename Documentation/devicetree/bindings/{ipmi.txt => ipmi/ipmi-smic.txt} (100%)
diff --git a/Documentation/devicetree/bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-bt-bmc.txt
similarity index 100%
rename from Documentation/devicetree/bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt
rename to Documentation/devicetree/bindings/ipmi/aspeed,ast2400-bt-bmc.txt
diff --git a/Documentation/devicetree/bindings/ipmi.txt b/Documentation/devicetree/bindings/ipmi/ipmi-smic.txt
similarity index 100%
rename from Documentation/devicetree/bindings/ipmi.txt
rename to Documentation/devicetree/bindings/ipmi/ipmi-smic.txt
--
2.7.4
^ permalink raw reply
* [PATCH -next] mmc: sdhci-of-arasan: Fix non static symbol warning
From: Adrian Hunter @ 2016-09-26 6:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474818243-19207-1-git-send-email-weiyj.lk@gmail.com>
On 25/09/16 18:44, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Fixes the following sparse warning:
>
> drivers/mmc/host/sdhci-of-arasan.c:253:6: warning:
> symbol 'sdhci_arasan_reset' was not declared. Should it be static?
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
> ---
> drivers/mmc/host/sdhci-of-arasan.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
> index da8e40a..e263671 100644
> --- a/drivers/mmc/host/sdhci-of-arasan.c
> +++ b/drivers/mmc/host/sdhci-of-arasan.c
> @@ -250,7 +250,7 @@ static void sdhci_arasan_hs400_enhanced_strobe(struct mmc_host *mmc,
> writel(vendor, host->ioaddr + SDHCI_ARASAN_VENDOR_REGISTER);
> }
>
> -void sdhci_arasan_reset(struct sdhci_host *host, u8 mask)
> +static void sdhci_arasan_reset(struct sdhci_host *host, u8 mask)
> {
> u8 ctrl;
> struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
>
>
>
>
^ permalink raw reply
* [PATCH v2 2/4] ARM: dts: imx31: move CCM device node to AIPS2 bus devices
From: Uwe Kleine-König @ 2016-09-26 6:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474848223-19728-3-git-send-email-vz@mleia.com>
Hello Vladimir,
On Mon, Sep 26, 2016 at 03:03:41AM +0300, Vladimir Zapolskiy wrote:
> i.MX31 Clock Control Module controller is found on AIPS2 bus, move it
> there from SPBA bus to avoid a conflict of device IO space mismatch.
>
> Fixes: ef0e4a606fb6 ("ARM: mx31: Replace clk_register_clkdev with clock DT lookup")
> Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Acked-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
out of interest: Which kind of machine do you work with? I assume this
isn't just a finger exercise with qemu?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [RFC PATCH 2/2] ARM: i.MX: dts: add fsl, imx25-wdt compatible to all relevant watchdog nodes
From: Uwe Kleine-König @ 2016-09-26 6:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474850361-20884-3-git-send-email-vz@mleia.com>
Hello Vladimir,
On Mon, Sep 26, 2016 at 03:39:21AM +0300, Vladimir Zapolskiy wrote:
> Watchdog device controller found on all modern SoCs from i.MX series
> and firstly introduced in i.MX25 is not one in one compatible with the
> watchdog controllers on i.MX21, i.MX27 and i.MX31, the latter
> controlles don't have WICR (and pretimeout notification support) and
> WMCR registers. To get benefit from the more advanced watchdog device
> and to avoid operations over non-existing registers on legacy SoCs add
> fsl,imx25-wdt compatible to descriptions of all i.MX25 compatible
> watchdog controllers.
>
> Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
> ---
> arch/arm/boot/dts/imx35.dtsi | 3 ++-
> arch/arm/boot/dts/imx50.dtsi | 3 ++-
> arch/arm/boot/dts/imx51.dtsi | 6 ++++--
> arch/arm/boot/dts/imx53.dtsi | 6 ++++--
> arch/arm/boot/dts/imx6qdl.dtsi | 6 ++++--
> arch/arm/boot/dts/imx6sl.dtsi | 6 ++++--
> arch/arm/boot/dts/imx6sx.dtsi | 9 ++++++---
> arch/arm/boot/dts/imx6ul.dtsi | 6 ++++--
> arch/arm/boot/dts/imx7s.dtsi | 12 ++++++++----
> arch/arm/boot/dts/ls1021a.dtsi | 2 +-
> arch/arm/boot/dts/vfxxx.dtsi | 3 ++-
> 11 files changed, 41 insertions(+), 21 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx35.dtsi b/arch/arm/boot/dts/imx35.dtsi
> index 490b7b4..8fd4482 100644
> --- a/arch/arm/boot/dts/imx35.dtsi
> +++ b/arch/arm/boot/dts/imx35.dtsi
> @@ -284,7 +284,8 @@
> };
>
> wdog: wdog at 53fdc000 {
> - compatible = "fsl,imx35-wdt", "fsl,imx21-wdt";
> + compatible = "fsl,imx35-wdt", "fsl,imx25-wdt",
> + "fsl,imx21-wdt";
When this is used on an old kernel that doesn't know about fsl,imx25-wdt
this picks up the imx21 driver logic. As this is wrong I think you
should drop imx21-wdt here. Can one of the dt-people comfirm?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v7 0/8] power: add power sequence library
From: Peter Chen @ 2016-09-26 6:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474342607-27512-1-git-send-email-peter.chen@nxp.com>
On Tue, Sep 20, 2016 at 11:36:39AM +0800, Peter Chen wrote:
> Hi all,
>
> This is a follow-up for my last power sequence framework patch set [1].
> According to Rob Herring and Ulf Hansson's comments[2]. The kinds of
> power sequence instances will be added at postcore_initcall, the match
> criteria is compatible string first, if the compatible string is not
> matched between dts and library, it will try to use generic power sequence.
>
> The host driver just needs to call of_pwrseq_on/of_pwrseq_off
> if only one power sequence instance is needed, for more power sequences
> are used, using of_pwrseq_on_list/of_pwrseq_off_list instead (eg, USB hub driver).
>
> In future, if there are special power sequence requirements, the special
> power sequence library can be created.
>
> This patch set is tested on i.mx6 sabresx evk using a dts change, I use
> two hot-plug devices to simulate this use case, the related binding
> change is updated at patch [1/6], The udoo board changes were tested
> using my last power sequence patch set.[3]
>
> Except for hard-wired MMC and USB devices, I find the USB ULPI PHY also
> need to power on itself before it can be found by ULPI bus.
>
> [1] http://www.spinics.net/lists/linux-usb/msg142755.html
> [2] http://www.spinics.net/lists/linux-usb/msg143106.html
> [3] http://www.spinics.net/lists/linux-usb/msg142815.html
>
> Changes for v7:
> - Create kinds of power sequence instance at postcore_initcall, and match
> the instance with node using compatible string, the beneit of this is
> the host driver doesn't need to consider which pwrseq instance needs
> to be used, and pwrseq core will match it, however, it eats some memories
> if less power sequence instances are used. [Patch 2/8]
> - Add pwrseq_compatible_sample.c to test match pwrseq using device_id. [Patch 2/8]
> - Fix the comments Vaibhav Hiremath adds for error path for clock and do not
> use device_node for parameters at pwrseq_on. [Patch 2/8]
> - Simplify the caller to use power sequence, follows Alan's commnets [Patch 4/8]
> - Tested three pwrseq instances together using both specific compatible string and
> generic libraries.
>
Hi Vaibhav, would you please test if this series can support your case,
you can add one instance like pwrseq_compatible_sample? If you are busy
now, but think this series can satisfy your requirement, please ack it.
I will delete pwrseq_compatible_sample, and only submit the generic one
at next revision, you can add it later, thanks.
Peter
> Changes for v6:
> - Add Matthias Kaehlcke's Reviewed-by and Tested-by. (patch [2/6])
> - Change chipidea core of_node assignment for coming user. (patch [5/6])
> - Applies Joshua Clayton's three dts changes for two boards,
> the USB device's reg has only #address-cells, but without #size-cells.
>
> Changes for v5:
> - Delete pwrseq_register/pwrseq_unregister, which is useless currently
> - Fix the linker error when the pwrseq user is compiled as module
>
> Changes for v4:
> - Create the patch on next-20160722
> - Fix the of_node is not NULL after chipidea driver is unbinded [Patch 5/6]
> - Using more friendly wait method for reset gpio [Patch 2/6]
> - Support multiple input clocks [Patch 2/6]
> - Add Rob Herring's ack for DT changes
> - Add Joshua Clayton's Tested-by
>
> Changes for v3:
> - Delete "power-sequence" property at binding-doc, and change related code
> at both library and user code.
> - Change binding-doc example node name with Rob's comments
> - of_get_named_gpio_flags only gets the gpio, but without setting gpio flags,
> add additional code request gpio with proper gpio flags
> - Add Philipp Zabel's Ack and MAINTAINER's entry
>
> Changes for v2:
> - Delete "pwrseq" prefix and clock-names for properties at dt binding
> - Should use structure not but its pointer for kzalloc
> - Since chipidea core has no of_node, let core's of_node equals glue
> layer's at core's probe
>
> Joshua Clayton (2):
> ARM: dts: imx6qdl: Enable usb node children with <reg>
> ARM: dts: imx6q-evi: Fix onboard hub reset line
>
> Peter Chen (6):
> binding-doc: power: pwrseq-generic: add binding doc for generic power
> sequence library
> power: add power sequence library
> binding-doc: usb: usb-device: add optional properties for power
> sequence
> usb: core: add power sequence handling for USB devices
> usb: chipidea: let chipidea core device of_node equal's glue layer
> device of_node
> ARM: dts: imx6qdl-udoo.dtsi: fix onboard USB HUB property
>
> .../bindings/power/pwrseq/pwrseq-generic.txt | 48 ++++++
> .../devicetree/bindings/usb/usb-device.txt | 10 +-
> MAINTAINERS | 9 +
> arch/arm/boot/dts/imx6q-evi.dts | 25 +--
> arch/arm/boot/dts/imx6qdl-udoo.dtsi | 26 ++-
> arch/arm/boot/dts/imx6qdl.dtsi | 6 +
> drivers/power/Kconfig | 1 +
> drivers/power/Makefile | 1 +
> drivers/power/pwrseq/Kconfig | 45 +++++
> drivers/power/pwrseq/Makefile | 3 +
> drivers/power/pwrseq/core.c | 190 +++++++++++++++++++++
> drivers/power/pwrseq/pwrseq_compatible_sample.c | 178 +++++++++++++++++++
> drivers/power/pwrseq/pwrseq_generic.c | 177 +++++++++++++++++++
> drivers/usb/chipidea/core.c | 27 ++-
> drivers/usb/core/hub.c | 41 ++++-
> drivers/usb/core/hub.h | 1 +
> include/linux/power/pwrseq.h | 73 ++++++++
> 17 files changed, 820 insertions(+), 41 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/power/pwrseq/pwrseq-generic.txt
> create mode 100644 drivers/power/pwrseq/Kconfig
> create mode 100644 drivers/power/pwrseq/Makefile
> create mode 100644 drivers/power/pwrseq/core.c
> create mode 100644 drivers/power/pwrseq/pwrseq_compatible_sample.c
> create mode 100644 drivers/power/pwrseq/pwrseq_generic.c
> create mode 100644 include/linux/power/pwrseq.h
>
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards,
Peter Chen
^ permalink raw reply
* [PATCH v2 3/4] clk: imx31: fix rewritten input argument of mx31_clocks_init()
From: Uwe Kleine-König @ 2016-09-26 6:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474848223-19728-4-git-send-email-vz@mleia.com>
Hello,
On Mon, Sep 26, 2016 at 03:03:42AM +0300, Vladimir Zapolskiy wrote:
> Function mx31_clocks_init() is called during clock intialization on
> legacy boards with reference clock frequency passed as its input
> argument, this can be verified by examination of the function
> declaration found in arch/arm/mach-imx/common.h and actual function
> users which include that header file.
>
> Inside CCF driver the function ignores its input argument, by chance
> the used value in the function body is the same as input arguments on
> side of all callers.
>
> Fixes: d9388c843237 ("clk: imx31: Do not call mxc_timer_init twice when booting with DT")
> Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Reviewed-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
Thanks
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v3] arm: dts: zynq: Add MicroZed board support
From: Michal Simek @ 2016-09-26 6:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474624113-22825-1-git-send-email-jagan@amarulasolutions.com>
On 23.9.2016 11:48, Jagan Teki wrote:
> From: Jagan Teki <jteki@openedev.com>
>
> Added basic dts support for MicroZed board.
>
> - UART
> - SDHCI
> - Ethernet
>
> Cc: Soren Brinkmann <soren.brinkmann@xilinx.com>
> Cc: Michal Simek <michal.simek@xilinx.com>
> Signed-off-by: Jagan Teki <jteki@openedev.com>
> ---
> Changes for v3:
> - Add Xilinx copyright
> Changes for v2:
> - Add SDHCI
> - Add Ethernet
>
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/zynq-microzed.dts | 96 +++++++++++++++++++++++++++++++++++++
> 2 files changed, 97 insertions(+)
> create mode 100644 arch/arm/boot/dts/zynq-microzed.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index faacd52..4d7b858 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -862,6 +862,7 @@ dtb-$(CONFIG_ARCH_VT8500) += \
> wm8750-apc8750.dtb \
> wm8850-w70v2.dtb
> dtb-$(CONFIG_ARCH_ZYNQ) += \
> + zynq-microzed.dtb \
> zynq-parallella.dtb \
> zynq-zc702.dtb \
> zynq-zc706.dtb \
> diff --git a/arch/arm/boot/dts/zynq-microzed.dts b/arch/arm/boot/dts/zynq-microzed.dts
> new file mode 100644
> index 0000000..b9376a4
> --- /dev/null
> +++ b/arch/arm/boot/dts/zynq-microzed.dts
> @@ -0,0 +1,96 @@
> +/*
> + * Copyright (C) 2011 - 2014 Xilinx
> + * Copyright (C) 2016 Jagan Teki <jteki@openedev.com>
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * 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.
> + */
> +/dts-v1/;
> +/include/ "zynq-7000.dtsi"
> +
> +/ {
> + model = "Zynq MicroZED Development Board";
> + compatible = "xlnx,zynq-microzed", "xlnx,zynq-7000";
> +
> + aliases {
> + ethernet0 = &gem0;
> + serial0 = &uart1;
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0x0 0x40000000>;
> + };
> +
> + chosen {
> + bootargs = "earlycon";
> + stdout-path = "serial0:115200n8";
> + };
> +
> + usb_phy0: phy0 {
> + compatible = "usb-nop-xceiv";
> + #phy-cells = <0>;
> + };
> +};
> +
> +&clkc {
> + ps-clk-frequency = <33333333>;
> +};
> +
> +&gem0 {
> + status = "okay";
> + phy-mode = "rgmii-id";
> + phy-handle = <ðernet_phy>;
> +
> + ethernet_phy: ethernet-phy at 0 {
> + reg = <0>;
> + };
> +};
> +
> +&sdhci0 {
> + status = "okay";
> +};
> +
> +&uart1 {
> + status = "okay";
> +};
> +
> +&usb0 {
> + status = "okay";
> + dr_mode = "host";
> + usb-phy = <&usb_phy0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_usb0_default>;
> +};
> +
> +&pinctrl0 {
> + pinctrl_usb0_default: usb0-default {
> + mux {
> + groups = "usb0_0_grp";
> + function = "usb0";
> + };
> +
> + conf {
> + groups = "usb0_0_grp";
> + slew-rate = <0>;
> + io-standard = <1>;
> + };
> +
> + conf-rx {
> + pins = "MIO29", "MIO31", "MIO36";
> + bias-high-impedance;
> + };
> +
> + conf-tx {
> + pins = "MIO28", "MIO30", "MIO32", "MIO33", "MIO34",
> + "MIO35", "MIO37", "MIO38", "MIO39";
> + bias-disable;
> + };
> + };
> +};
>
Applied.
Thanks,
Michal
^ permalink raw reply
* [PATCH] tty/serial: atmel: fix fractional baud rate computation
From: Uwe Kleine-König @ 2016-09-26 6:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921104414.16241-1-nicolas.ferre@atmel.com>
Hello,
On Wed, Sep 21, 2016 at 12:44:14PM +0200, Nicolas Ferre wrote:
> From: Alexey Starikovskiy <aystarik@gmail.com>
>
> The problem with previous code was it rounded values in wrong
> place and produced wrong baud rate in some cases.
>
> Signed-off-by: Alexey Starikovskiy <aystarik@gmail.com>
> [nicolas.ferre at atmel.com: port to newer kernel and add commit log]
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
I first thought this patch results in not always picking the optimal
divider in some cases. But given the right error function (i.e.
error(r) = abs(1/r_target - 1/r_actual) which minimizes the error in the
time domain and so guarantees the maximal count of matched samples) it
can be proved to result in the right values (assuming no overflow etc.).
As writing formulas in email is cumbersome, see the attachment for a
prove.
Reviewed-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: baudrate.pdf
Type: application/pdf
Size: 69704 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160926/02579e68/attachment-0001.pdf>
^ permalink raw reply
* [RFC PATCH 00/11] pci: support for configurable PCI endpoint
From: Kishon Vijay Abraham I @ 2016-09-26 6:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6722152.QTF992tLpW@wuerfel>
Hi Arnd,
On Thursday 22 September 2016 07:04 PM, Arnd Bergmann wrote:
> On Thursday, September 15, 2016 2:03:05 PM CEST Kishon Vijay Abraham I wrote:
>> On Wednesday 14 September 2016 06:55 PM, Arnd Bergmann wrote:
>>> On Wednesday, September 14, 2016 10:41:56 AM CEST Kishon Vijay Abraham I wrote:
>>> I've added the drivers/ntb maintainers to Cc, given that there is
>>> a certain degree of overlap between your work and the existing
>>> code, I think they should be part of the discussion.
>>>
>>>> Known Limitation:
>>>> *) Does not support multi-function devices
>>>
>>> If I understand it right, this was a problem for USB and adding
>>> it later made it somewhat inconsistent. Maybe we can at least
>>> try to come up with an idea of how multi-function devices
>>> could be handled even if we don't implement it until someone
>>> actually needs it.
>>
>> Actually IMO multi-function device in PCI should be much simpler than it is for
>> USB. In the case of USB, all the functions in a multi-function device will
>> share the same *usb configuration* . (USB device can have multiple
>> configuration but only one can be enabled at a time). A multi-function USB
>> device will still have a single vendor-id/product-id/class... So I think a
>> separate library (composite.c) in USB makes sense.
>
> Ok, makes sense.
>
>> But in the case of PCI, every function can be treated independently since all
>> the functions have it's own 4KB configuration space. Each function can be
>> configured independently. Each can have it's own vendor-id/product-id/class..
>> I'm not sure if we'll need a separate library for PCI like we have for USB.
>
> I think it depends on whether we want to add the software multi-function
> support you mention.
>
>> Now the restriction for not allowing multi-function device is because of the
>> following structure definition.
>>
>> struct pci_epc {
>> ..
>> struct pci_epf *epf;
>> ..
>> };
>>
>> EPC has a single reference to EPF and it is used *only* to notify the function
>> driver when the link is up. (If this can be changed to use notification
>> mechanism, multi-function devices can be supported here)
>>
>> One more place where this restriction arises is in designware driver
>>
>> struct dw_pcie_ep {
>> ..
>> u8 bar_to_atu[6];
>> ..
>> };
>>
>> We use single ATU window to configure a BAR (in BAR). If there are multiple
>> functions, then this should also be modified since each function has 6 BARs.
>>
>> This can be fixed without much effort unless some other issue props up.
>
> Ok.
>
>>>
>>> Is your hardware able to make the PCIe endpoint look like
>>> a device with multiple PCI functions, or would one have to
>>> do this in software inside of a single PCI function if we
>>> ever need it?
>>
>> The hardware I have doesn't support multiple PCI functions (like having a
>> separate configuration space for each function). It has a dedicated space for
>> configuration space supporting only one function. [Section 24.9.7.3.2
>> PCIe_SS_EP_CFG_DBICS Register Description in [1]].
>>
>> yeah, it has to be done in software (but that won't be multi-function device in
>> PCI terms).
>>
>> [1] -> http://www.ti.com/lit/ug/spruhz6g/spruhz6g.pdf
>
> Ok, so in theory there can be other hardware (and quite likely is)
> that supports multiple functions, and we can extend the framework
> to support them without major obstacles, but your hardware doesn't,
> so you kept it simple with one hardcoded function, right?
right, PCIe can have upto 8 functions. So the issues with the current framework
has to be fixed. I don't expect major obstacles with this as of now.
>
> Seems completely reasonable to me.
>
>>>> TODO:
>>>> *) access buffers in RC
>>>> *) raise MSI interrupts
>>>> *) Enable user space control for the RC side PCI driver
>>>
>>> The user space control would end up just being one of several
>>> gadget drivers, right? E.g. gadget drivers for standard hardware
>>> (8250 uart, ATA, NVMe, some ethernet) could be done as kernel
>>> drivers while a user space driver can be used for things that
>>> are more unusual and that don't need to interface to another
>>> part of the kernel?
>>
>> Actually I didn't mean that. It was more with respect to the host side PCI test
>> driver (drivers/misc/pci_endpoint_test.c). Right now it validates BAR, irq
>> itself. I wanted to change this so that the user controls which tests to run.
>> (Like for USB gadget zero tests, testusb.c invokes ioctls to perform various
>> tests). Similarly I want to have a userspace program invoke pci_endpoint_test
>> to perform various PCI tests.
>
> Ok, I see. So what I described above would be yet another function
> driver that can be implemented, but so far, you have not planned
> to do that because there was not need, right?
right. I felt pci_endpoint_test is the generic function that would be of
interest to all the vendors. Any new function can be added by taking
pci_endpoint_test as a reference.
The simple usecase I plan to work on after completing the framework is to have
a camera sensor in one board and display in another board (the boards connected
using PCIe) and the display showing the the camera capture.
>
>>>
>>>> *) Adapt all other users of designware to use the new design (only
>>>> dra7xx has been adapted)
>>>
>>> I don't fully understand this part. Does every designware based
>>> driver need modifications, or are the changes to the
>>> generic parts of the designware driver enough to make it
>>> work for the simpler platforms?
>>
>> I have changed the core designware driver structures (like previously the
>> platform drivers will only use pcie_port, but now I introduced struct dw_pcie
>> to support both host and endpoint). This will break (compilation failure) all
>> the designware based drivers (except dra7xx). All these drivers should be
>> adapted to the new change (even if they work only in host mode these has to be
>> adapted).
>
> Ah, so we have to do two separate modifications to each designware driver:
>
> a) make it work with your patch (mandatory)
> b) make it support endpoint mode (optional)
yes.
>
>>>> HOW TO:
>>>>
>>>> ON THE EP SIDE:
>>>> ***************
>>>>
>>>> /* EP function is configured using configfs */
>>>> # mount -t configfs none /sys/kernel/config
>>>>
>>>> /* PCI EP core layer creates "pci_ep" entry in configfs */
>>>> # cd /sys/kernel/config/pci_ep/
>>>>
>>>> /*
>>>> * This is the 1st step in creating an endpoint function. This
>>>> * creates the endpoint function device *instance*. The string
>>>> * before the .<num> suffix will identify the driver this
>>>> * EP function will bind to.
>>>> * Just pci_epf_test is also valid. The .<num> suffix is used
>>>> * if there are multiple PCI controllers and all of them wants
>>>> * to use the same function.
>>>> */
>>>> # mkdir pci_epf_test.0
>>>
>>> I haven't used USB gadgets, but I assume this is modeled around
>>> the same interface. If there are notable differences, please mention
>>> what they are. Otherwise the general concept seems rather nice to me.
>>
>> Yeah, both USB gadget and PCI endpoint use configfs interface but the semantics
>> are quite different.
>>
>> Every directory in *usb_gadget* corresponds to a gadget device, and the gadget
>> device has a functions sub-directory which has the USB functions. And these
>> directories have fields or attributes specific to USB.
>>
>> But in the case of PCI, every directory in *pci_ep* corresponds to a PCI
>> function and it has fields or attributes specific to PCI function.
>
> Ok, I see.
>
>> The main reason for using configfs for PCI endpoint is to give the users to
>> control "which function has to be bound to which controller". The same concept
>> is used for USB gadget as well but there it is "which gadget device has to be
>> bound to which controller".
>
> We should still find out whether it's important that you can have
> a single PCI function with a software multi-function support of some
> sort. We'd still be limited to six BARs in total, and would also need
> something to identify those sub-functions, so implementing that might
> get quite hairy.
>
> Possibly this could be done at a higher level, e.g. by implementing
> a PCI-virtio multiplexer that can host multiple virtio based devices
> inside of a single PCI function. If we think that would be a good idea,
> we should make sure the configfs interface is extensible enough to
> handle that.
Okay. So here the main function (actual PCI function) *can* perform the work of
virtio muliplexer if the platform wants to support sub-functions or it can be a
normal PCI function. right?
>
> One use case I have in mind for this is to have a PCI function that
> can use virtio to provide rootfs (virtio-blk or 9pfs), network
> and console to the system that implements the PCI function (note
> that this is the opposite direction of what almost everyone else
> uses PCI devices for).
Do you mean the virtio should actually be in the host side? Even here the
system that implements PCI function should have multiple functions right? (one
for network, other for console etc..). So there should be a virtio multiplexer
both in the host side and in the device side?
>
>>> Let's talk (high-level) about the DT binding. I see that the way
>>> you have done it here, one will need to have a different .dtb file
>>> for a machine depending on whether the PCIe is used in host or
>>> endpoint mode. The advantage of this way is that it's a much
>>> cleaner binding (PCIe host bindings are a mess, and adding more
>>> options to it will only make it worse), the downside is that
>>> you can't decide at runtime what you want to use it for. E.g.
>>> connecting two identical machines over PCIe requires deciding
>>> in the bootloader which one is the endpoint, or using DT
>>> overlays, which may be awkward for some users. Is this a realistic
>>> use case, or do you expect that all machines will only ever be
>>> used in one of the two ways?
>>
>> It would definitely be nice to select the mode at runtime. Even for this patch
>> series, I added a temporary dtsi patch to configure the pci controller in EP
>> mode (which can't be merged since the same controller is also used to test RC).
>
> I think it should be possible to have two bindings that define a
> distinct set of properties, and have one node that is marked
> as "compatible" with both of them in order to let the OS choose
> one or the other mode.
hmm.. okay.
Thanks
Kishon
^ permalink raw reply
* [PATCH] ARM: uniphier: select ARCH_HAS_RESET_CONTROLLER
From: Masahiro Yamada @ 2016-09-26 5:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474368275.4030.45.camel@pengutronix.de>
Hi Philipp,
2016-09-20 19:44 GMT+09:00 Philipp Zabel <p.zabel@pengutronix.de>:
> Am Dienstag, den 20.09.2016, 17:47 +0900 schrieb Masahiro Yamada:
>> Hi Philipp,
>>
>>
>> 2016-09-20 16:30 GMT+09:00 Philipp Zabel <p.zabel@pengutronix.de>:
>> > Hi Masahiro,
>> >
>> > Am Dienstag, den 20.09.2016, 13:43 +0900 schrieb Masahiro Yamada:
>> >> The UniPhier reset driver (drivers/reset/reset-uniphier.c) has been
>> >> merged. Select ARCH_HAS_RESET_CONTROLLER from the SoC Kconfig.
>> >>
>> >> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>> >> ---
>> >>
>> >> Philipp,
>> >>
>> >> IIRC, you mentioned that you were planning to consolidate the double
>> >> gurad by CONFIG_RESET_CONTROLLER and CONFIG_ARCH_HAS_RESET_CONTROLLER.
>> >>
>> >> I have not seen it in the ML, so I am sending this.
>> >>
>> >> Please let me know if you have some updates.
>> >
>> > I had started to doodle a bit, see
>> >
>> > git fetch git://git.pengutronix.de/git/pza/linux.git refs/heads/reset/kconfig
>> >
>> > but I haven't found time for cleanup and testing.
>>
>>
>> OK, I will merge this patch for now.
>>
>>
>>
>> BTW, I did not understand some of your commits under way.
>>
>>
>> commit 7fe911f9c83737449565db03bebf953d3d94bbbf
>> Author: Philipp Zabel <p.zabel@pengutronix.de>
>> Date: Tue Aug 9 11:18:51 2016 +0200
>>
>> dmaengine: sunx6i: do not depend on reset controller framework
>>
>> The reset controller framework provides inline function stubs if
>> disabled.
>>
>> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
>>
>>
>>
>>
>>
>> As far as I see from drivers/dma/sun6i-dma.c,
>> the reset control is mandatory for this driver.
>>
>> Why are you removing the dependency?
>>
>>
>> Don't you care if it works on run-time
>> as long as it can build?
>
> I have not thought about this too hard, it's just there because the
> reset framework is not a build dependency (anymore). Some patches were
> necessary to remove dependency loops, but I think this one could just be
> dropped.
I have not taken a close look at it, but
if "dependency loops" is the reason for the change,
please mention it in the git-log.
I do not think we should remove the "depends on"
only for the reason "inline function stubs are already provided".
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [RFC PATCH 2/2] ARM: i.MX: dts: add fsl, imx25-wdt compatible to all relevant watchdog nodes
From: Baruch Siach @ 2016-09-26 4:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474850361-20884-3-git-send-email-vz@mleia.com>
Hi Vladimir,
On Mon, Sep 26, 2016 at 03:39:21AM +0300, Vladimir Zapolskiy wrote:
> Watchdog device controller found on all modern SoCs from i.MX series
> and firstly introduced in i.MX25 is not one in one compatible with the
> watchdog controllers on i.MX21, i.MX27 and i.MX31, the latter
> controlles don't have WICR (and pretimeout notification support) and
> WMCR registers. To get benefit from the more advanced watchdog device
> and to avoid operations over non-existing registers on legacy SoCs add
> fsl,imx25-wdt compatible to descriptions of all i.MX25 compatible
> watchdog controllers.
Maybe also update Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt?
In a separate patch.
baruch
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply
* [PATCH v2 2/2] cpufreq: ti: Add cpufreq driver to determine available OPPs at runtime
From: Viresh Kumar @ 2016-09-26 4:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57E555B3.2010304@ti.com>
On 23-09-16, 11:17, Dave Gerlach wrote:
> On 09/23/2016 12:19 AM, Viresh Kumar wrote:
> >On 21-09-16, 14:34, Dave Gerlach wrote:
> >>Viresh,
> >>On 09/07/2016 10:39 PM, Viresh Kumar wrote:
> >>>On 07-09-16, 10:04, Dave Gerlach wrote:
> >>>>>>+static const struct of_device_id ti_cpufreq_of_match[] = {
> >>>>>>+ { .compatible = "operating-points-v2-ti-am3352-cpu",
> >>>>>>+ .data = &am3x_soc_data, },
> >>>>>>+ { .compatible = "operating-points-v2-ti-am4372-cpu",
> >>>>>>+ .data = &am4x_soc_data, },
> >>>>>>+ { .compatible = "operating-points-v2-ti-dra7-cpu",
> >>>>>>+ .data = &dra7_soc_data },
> >>>>>
> >>>>>You should be using your SoC compatible strings here. OPP compatible
> >>>>>property isn't supposed to be (mis)used for this purpose.
> >>>>>
> >>>>
> >>>>Referring to my comments in patch 1, what if we end up changing the bindings
> >>>>based on DT maintainer comments? We will have these compatible strings, and
> >>>>at that point is it acceptable to match against them? Or is it still better
> >>>>to match to SoC compatibles? I think it makes sense to just probe against
> >>>>these.
> >>>
> >>>But even then I think these are not correct. You should have added a
> >>>single compatible string: operating-points-v2-ti-cpu.
> >>>
> >>>As the properties will stay the same across machines. And then you
> >>>need to use SoC strings here.
> >>>
> >>
> >>Are you opposed to moving _of_get_opp_desc_node from
> >>drivers/base/power/opp/opp.h to include/linux/pm_opp.h and renaming it
> >>appropriately?
> >
> >I am not opposed to that, but ...
> >
> >>If I move the ti properties out of the cpu node, as discussed in patch 1 of
> >>this series, and into the operating-points-v2 table, I need a way to get the
> >>operating-points-v2 device node and I think it makes sense to reuse this as
> >>it is what the opp framework uses internally to parse the phandle to the opp
> >>table.
> >
> >I am not sure if those registers belong to the OPP bindings. What are those
> >registers really? What all can be read from them? Why shouldn't they be present
> >as a separate node in DT on the respective bus? Look at how it is done for
> >sti-cpufreq driver.
> >
>
> The sti-cpufreq driver in v4.8-rc7 appears to do what I am already doing in
> this revision of the patch, reading from a syscon phandle that is part of
> the cpu node in the DT which is what I was told not to do.
>
> The register I am referencing in the syscon is a bit-field describing which
> OPPs are valid for the system, so it is very relevant to the OPP binding.
> They really are already present in a separate node, I'm just indexing into a
> syscon, same as the sti-cpufreq driver appears to be doing.
Okay, you can move that function out.
--
viresh
^ permalink raw reply
* [PATCH v2 4/4] PM / AVS: rockchip-cpu-avs: add driver handling Rockchip cpu avs
From: Viresh Kumar @ 2016-09-26 3:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160912215515.GF7243@codeaurora.org>
On 12-09-16, 14:55, Stephen Boyd wrote:
> On 08/29, Viresh Kumar wrote:
> > On 18-08-16, 16:52, Finlye Xiao wrote:
> > > +static int rockchip_adjust_opp_table(struct device *cpu_dev,
> > > + struct cpufreq_frequency_table *table,
> > > + int volt)
> > > +{
> > > + struct opp_table *opp_table;
> > > + struct cpufreq_frequency_table *pos;
> > > + struct dev_pm_opp *opp;
> > > +
> > > + if (!volt)
> > > + return 0;
> > > +
> > > + rcu_read_lock();
> > > +
> > > + opp_table = _find_opp_table(cpu_dev);
> > > + if (IS_ERR(opp_table)) {
> > > + rcu_read_unlock();
> > > + return PTR_ERR(opp_table);
> > > + }
> > > +
> > > + cpufreq_for_each_valid_entry(pos, table) {
> > > + opp = dev_pm_opp_find_freq_exact(cpu_dev, pos->frequency * 1000,
> > > + true);
> > > + if (IS_ERR(opp))
> > > + continue;
> > > +
> > > + opp->u_volt += volt;
> > > + opp->u_volt_min += volt;
> > > + opp->u_volt_max += volt;
> > > + }
> > > +
> > > + rcu_read_unlock();
> > > +
> > > + return 0;
> > > +}
> >
> > I wouldn't prefer altering the opp tables from individual drivers at all. At the
> > least, it should be done via some helpers exposed by the core.
> >
> > But before that I would like to hear from Stephen a bit as I recall he was also
> > working on something similar.
> >
>
> I had a patch to modify the voltage at runtime for the "current"
> OPP. Now that we have regulator and clk control inside OPP that
> became a little easier to do without having to do some notifier
> from the OPP layer to the consumers. I haven't had time to revive
> those patches though. Should we do that?
Perhaps yes, we should have a common place for doing all that.
> Does this need to modify
> anything besides the OPP the device is currently running at?
Finlye, can you please answer this ?
--
viresh
^ permalink raw reply
* [PATCH] cpufreq: st: add missing \n to end of dev_err message
From: Viresh Kumar @ 2016-09-26 3:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160925214013.12430-1-colin.king@canonical.com>
On 25-09-16, 14:40, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Trival fix, dev_err message is missing a \n, so add it.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/cpufreq/sti-cpufreq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/sti-cpufreq.c b/drivers/cpufreq/sti-cpufreq.c
> index 0404203..b366e6d 100644
> --- a/drivers/cpufreq/sti-cpufreq.c
> +++ b/drivers/cpufreq/sti-cpufreq.c
> @@ -163,7 +163,7 @@ static int sti_cpufreq_set_opp_info(void)
>
> reg_fields = sti_cpufreq_match();
> if (!reg_fields) {
> - dev_err(dev, "This SoC doesn't support voltage scaling");
> + dev_err(dev, "This SoC doesn't support voltage scaling\n");
> return -ENODEV;
> }
>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* [PATCH -next] mmc: sdhci-of-arasan: Fix non static symbol warning
From: Sören Brinkmann @ 2016-09-26 3:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474818243-19207-1-git-send-email-weiyj.lk@gmail.com>
On Sun, 2016-09-25 at 15:44:03 +0000, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Fixes the following sparse warning:
>
> drivers/mmc/host/sdhci-of-arasan.c:253:6: warning:
> symbol 'sdhci_arasan_reset' was not declared. Should it be static?
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Acked-by: S?ren Brinkmann <soren.brinkmann@xilinx.com>
S?ren
^ permalink raw reply
* [RFC/PATCH] usb: misc: Add a driver for TC7USB40MU
From: Peter Chen @ 2016-09-26 3:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <147457026249.9057.8712383708019243942@sboyd-linaro>
On Thu, Sep 22, 2016 at 11:51:02AM -0700, Stephen Boyd wrote:
> Quoting Peter Chen (2016-09-16 18:16:05)
> > On Wed, Sep 14, 2016 at 01:55:02AM -0700, Stephen Boyd wrote:
> > > Quoting Stephen Boyd (2016-09-13 18:42:46)
> > > > On the db410c 96boards platform we have a TC7USB40MU[1] on the
> > > > board to mux the D+/D- lines from the SoC between a micro usb
> > > > "device" port and a USB hub for "host" roles. Upon a role switch,
> > > > we need to change this mux to forward the D+/D- lines to either
> > > > the port or the hub. Therefore, introduce a driver for this
> > > > device that intercepts extcon USB_HOST events and logically
> > > > asserts a gpio to mux the "host" D+/D- lines when a host cable is
> > > > attached. When the cable goes away, it will logically deassert
> > > > the gpio and mux the "device" lines.
> > > >
> > > > [1] https://toshiba.semicon-storage.com/ap-en/product/logic/bus-switch/detail.TC7USB40MU.html
> > > >
> > > > Cc: MyungJoo Ham <myungjoo.ham@samsung.com>
> > > > Cc: Chanwoo Choi <cw00.choi@samsung.com>
> > > > Cc: <devicetree@vger.kernel.org>
> > > > Signed-off-by: Stephen Boyd <stephen.boyd@linaro.org>
> > > > ---
> > > >
> > > > Should I make the extcon part optional? I could see a case where there are two
> > > > "OTG" ports connected to the mux (or two hubs), and for some reason the
> > > > software may want to mux between them at runtime. If we mandate an extcon,
> > > > that won't be possible to support. Perhaps it would be better to have
> > > > the node, but connect it to the usb controller with a phandle (maybe of_graph
> > > > endpoints would be useful too) so that when the controller wants to mux over
> > > > a port it can do so.
> > >
> > > Here's some dts mock-up on top of the db410c for the of_graph stuff. I
> > > haven't written any code around it, but the idea is to allow the binding
> > > to specify how the mux is connected to upstream and downstream D+/D-
> > > lines. This way, we can do some dt parsing of the endpoints and their
> > > parent nodes to figure out if the mux needs to be set high or low to use
> > > a device connector or a usb hub based on if the id cable is present.
> > > Maybe I'm over thinking things though and we could just have a DT
> > > property for that.
> > >
> > > soc {
> > > usb at 78d9000 {
> > > extcon = <&usb_id>, <&usb_id>;
> >
> > Why you have two same extcon phandler? From my mind, one should id,
> > another should is vbus. Besides, I find extcon-usb-gpio.c is lack of
> > vbus support, how you support vbus detection for
> > connection/disconnection with PC for your chipidea msm patch set?
>
> This was already in the dts files for db410c. In the chipidea binding
> one is for EXTCON_USB (vbus) and one is for EXTCON_USB_HOST (id). My
> understanding is that extcon-usb-gpio.c sends events for both EXTCON_USB
> and EXTCON_USB_HOST when the gpio changes state. vbus detection is not
> that great on this board because we only have on gpio for this.
I think extcon-usb-gpio.c needs to extend for supporting vbus event,
otherwise, the micro-b cable's connect/disconnect will introduce
EXTCON_USB_HOST event, if you use two <&usb_idx> for both id and
vbus event.
--
Best Regards,
Peter Chen
^ permalink raw reply
* [v12, 0/8] Fix eSDHC host version register bug
From: Y.B. Lu @ 2016-09-26 3:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474441040-11946-1-git-send-email-yangbo.lu@nxp.com>
Any comments about this version patchset ?
:)
> -----Original Message-----
> From: Yangbo Lu [mailto:yangbo.lu at nxp.com]
> Sent: Wednesday, September 21, 2016 2:57 PM
> To: linux-mmc at vger.kernel.org; ulf.hansson at linaro.org; Scott Wood; Arnd
> Bergmann
> Cc: linuxppc-dev at lists.ozlabs.org; devicetree at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; linux-kernel at vger.kernel.org; linux-
> clk at vger.kernel.org; linux-i2c at vger.kernel.org; iommu at lists.linux-
> foundation.org; netdev at vger.kernel.org; Mark Rutland; Rob Herring;
> Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil; Bhupesh
> Sharma; Qiang Zhao; Kumar Gala; Santosh Shilimkar; Leo Li; X.B. Xie; M.H.
> Lian; Y.B. Lu
> Subject: [v12, 0/8] Fix eSDHC host version register bug
>
> This patchset is used to fix a host version register bug in the T4240-
> R1.0-R2.0 eSDHC controller. To match the SoC version and revision, 10
> previous version patchsets had tried many methods but all of them were
> rejected by reviewers.
> Such as
> - dts compatible method
> - syscon method
> - ifdef PPC method
> - GUTS driver getting SVR method
> Anrd suggested a soc_device_match method in v10, and this is the only
> available method left now. This v11 patchset introduces the
> soc_device_match interface in soc driver.
>
> The first six patches of Yangbo are to add the GUTS driver. This is used
> to register a soc device which contain soc version and revision
> information.
> The other two patches introduce the soc_device_match method in soc driver
> and apply it on esdhc driver to fix this bug.
>
> Arnd Bergmann (1):
> base: soc: introduce soc_device_match() interface
>
> Yangbo Lu (7):
> dt: bindings: update Freescale DCFG compatible
> ARM64: dts: ls2080a: add device configuration node
> dt: bindings: move guts devicetree doc out of powerpc directory
> powerpc/fsl: move mpc85xx.h to include/linux/fsl
> soc: fsl: add GUTS driver for QorIQ platforms
> MAINTAINERS: add entry for Freescale SoC drivers
> mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
>
> Documentation/devicetree/bindings/arm/fsl.txt | 6 +-
> .../bindings/{powerpc => soc}/fsl/guts.txt | 3 +
> MAINTAINERS | 11 +-
> arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 +
> arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
> arch/powerpc/sysdev/fsl_pci.c | 2 +-
> drivers/base/Kconfig | 1 +
> drivers/base/soc.c | 66 ++++++
> drivers/clk/clk-qoriq.c | 3 +-
> drivers/i2c/busses/i2c-mpc.c | 2 +-
> drivers/iommu/fsl_pamu.c | 3 +-
> drivers/mmc/host/Kconfig | 1 +
> drivers/mmc/host/sdhci-of-esdhc.c | 20 ++
> drivers/net/ethernet/freescale/gianfar.c | 2 +-
> drivers/soc/Kconfig | 2 +-
> drivers/soc/fsl/Kconfig | 19 ++
> drivers/soc/fsl/Makefile | 1 +
> drivers/soc/fsl/guts.c | 257
> +++++++++++++++++++++
> include/linux/fsl/guts.h | 125 ++++++----
> .../asm/mpc85xx.h => include/linux/fsl/svr.h | 4 +-
> include/linux/sys_soc.h | 3 +
> 21 files changed, 478 insertions(+), 61 deletions(-) rename
> Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
> create mode 100644 drivers/soc/fsl/Kconfig create mode 100644
> drivers/soc/fsl/guts.c rename arch/powerpc/include/asm/mpc85xx.h =>
> include/linux/fsl/svr.h (97%)
>
> --
> 2.1.0.27.g96db324
^ permalink raw reply
* [PATCH 4/4] arm/versatile: support configuring versatile machine for no-MMU
From: Greg Ungerer @ 2016-09-26 0:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474851150-12532-1-git-send-email-gerg@uclinux.org>
Allow the arm versatile machine to be configured for no-MMU operation.
The approach taken is similar to the support for no-MMU arm v7 machines.
A new define, CONFIG_ARM_SINGLE_ARMV5, is used to enable a class of v5
core based machines that are supported for building with !CONFIG_MMU.
Currently only the versatile machine is configured to support this.
Older kernels had the ability to build the versatile machine with the MMU
disabled (!CONFIG_MMU). Recent changes to convert the versatile machine
to device tree lost this ability. (Although older kernels could be built
they did not run due to a bug in the IO_ADDRESS() mapping on this machine).
The motivation for this is that the versatile machine is well supported
in qemu. And this provides an excellent platform for development and
testing no-MMU support on ARM in general.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
arch/arm/Kconfig | 10 ++++++++++
arch/arm/Kconfig.debug | 3 ++-
arch/arm/mach-versatile/Kconfig | 3 ++-
3 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a9c4e48..f44fe7b 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -353,6 +353,16 @@ config ARM_SINGLE_ARMV7M
select SPARSE_IRQ
select USE_OF
+config ARM_SINGLE_ARMV5
+ bool "ARMv5 based platforms (ARM926T)"
+ depends on !MMU
+ select AUTO_ZRELADDR
+ select CLKSRC_OF
+ select COMMON_CLK
+ select GENERIC_CLOCKEVENTS
+ select SPARSE_IRQ
+ select USE_OF
+
config ARCH_GEMINI
bool "Cortina Systems Gemini"
select CLKSRC_MMIO
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index a9693b6..9897348 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -1712,7 +1712,8 @@ config DEBUG_UNCOMPRESS
config UNCOMPRESS_INCLUDE
string
default "debug/uncompress.h" if ARCH_MULTIPLATFORM || ARCH_MSM || \
- PLAT_SAMSUNG || ARM_SINGLE_ARMV7M
+ PLAT_SAMSUNG || ARM_SINGLE_ARMV7M || \
+ ARM_SINGLE_ARMV5
default "mach/uncompress.h"
config EARLY_PRINTK
diff --git a/arch/arm/mach-versatile/Kconfig b/arch/arm/mach-versatile/Kconfig
index b0cc262..904a012 100644
--- a/arch/arm/mach-versatile/Kconfig
+++ b/arch/arm/mach-versatile/Kconfig
@@ -1,6 +1,6 @@
config ARCH_VERSATILE
bool "ARM Ltd. Versatile family"
- depends on ARCH_MULTI_V5
+ depends on ARCH_MULTI_V5 || ARM_SINGLE_ARMV5
select ARM_AMBA
select ARM_TIMER_SP804
select ARM_VIC
@@ -14,6 +14,7 @@ config ARCH_VERSATILE
select POWER_RESET
select POWER_RESET_VERSATILE
select VERSATILE_FPGA_IRQ
+ select GPIOLIB
help
This enables support for ARM Ltd Versatile board.
--
1.9.1
^ permalink raw reply related
* [PATCH 3/4] arm/versatile: empty Makefile.boot needed for no-MMU compile
From: Greg Ungerer @ 2016-09-26 0:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474851150-12532-1-git-send-email-gerg@uclinux.org>
To compile the arm versatile board with the MMU disabled (!CONFIG_MMU)
a Makefile.boot is required. Without it you get:
SYSMAP System.map
arch/arm/boot/Makefile:15: arch/arm/mach-versatile//Makefile.boot: No such file or directory
make[2]: *** No rule to make target `arch/arm/mach-versatile//Makefile.boot'. Stop.
Create an empty Makefile.boot for the versatile machine. This is a
copy of the other empty machine Makefile.boot files. (A few have this
same commented empty file: stm32, ep93xx, lpc18xx, efm32 and vexpress).
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
arch/arm/mach-versatile/Makefile.boot | 3 +++
1 file changed, 3 insertions(+)
create mode 100644 arch/arm/mach-versatile/Makefile.boot
diff --git a/arch/arm/mach-versatile/Makefile.boot b/arch/arm/mach-versatile/Makefile.boot
new file mode 100644
index 0000000..eacfc3f
--- /dev/null
+++ b/arch/arm/mach-versatile/Makefile.boot
@@ -0,0 +1,3 @@
+# Empty file waiting for deletion once Makefile.boot isn't needed any more.
+# Patch waits for application at
+# http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7889/1 .
--
1.9.1
^ permalink raw reply related
* [PATCH 2/4] arm/versatile: define empty debug_ll_io_init() for no-MMU
From: Greg Ungerer @ 2016-09-26 0:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474851150-12532-1-git-send-email-gerg@uclinux.org>
No-MMU configured targets have no definition for debug_ll_io_init().
Not all machines use this and it will only be required if CONFIG_DEBUG_LL
is enabled.
But when compiling for a target that uses it and it is configured for
no-MMU (!CONFIG_MMU), for example the versatile machine, you will get:
CC arch/arm/mach-versatile/versatile_dt.o
arch/arm/mach-versatile/versatile_dt.c: In function ?versatile_map_io?:
arch/arm/mach-versatile/versatile_dt.c:283:2: error: implicit declaration of function ?debug_ll_io_init? [-Werror=implicit-function-declaration]
debug_ll_io_init();
^
Fix by adding a macro for it to the !CONFIG_MMU path in map.h.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
arch/arm/include/asm/mach/map.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/include/asm/mach/map.h b/arch/arm/include/asm/mach/map.h
index 9b7c328..b1fe9c8 100644
--- a/arch/arm/include/asm/mach/map.h
+++ b/arch/arm/include/asm/mach/map.h
@@ -62,6 +62,7 @@ extern int ioremap_page(unsigned long virt, unsigned long phys,
#else
#define iotable_init(map,num) do { } while (0)
#define vm_reserve_area_early(a,s,c) do { } while (0)
+#define debug_ll_io_init() do { } while (0)
#endif
#endif
--
1.9.1
^ permalink raw reply related
* [PATCH 1/4] arm/versatile: support no-MMU mode addressing
From: Greg Ungerer @ 2016-09-26 0:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474851150-12532-1-git-send-email-gerg@uclinux.org>
Currently for the versatile boards the IO_ADDRESS() macro applies static
virtual address mapping for built-in IO devices. When operating without
the MMU enabled IO devices are accessed at their physical address, no
address translation is required.
For the !CONFIG_MMU case then define the IO_ADDRESS() macro to return the
physical address.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
arch/arm/mach-versatile/versatile_dt.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-versatile/versatile_dt.c b/arch/arm/mach-versatile/versatile_dt.c
index 3c8d39c..8cfa05a 100644
--- a/arch/arm/mach-versatile/versatile_dt.c
+++ b/arch/arm/mach-versatile/versatile_dt.c
@@ -37,7 +37,11 @@
#include <asm/mach/map.h>
/* macro to get at MMIO space when running virtually */
+#ifdef CONFIG_MMU
#define IO_ADDRESS(x) (((x) & 0x0fffffff) + (((x) >> 4) & 0x0f000000) + 0xf0000000)
+#else
+#define IO_ADDRESS(x) (x)
+#endif
#define __io_address(n) ((void __iomem __force *)IO_ADDRESS(n))
/*
--
1.9.1
^ permalink raw reply related
* [PATCH 0/4] arm/versatile: no-MMU support
From: Greg Ungerer @ 2016-09-26 0:52 UTC (permalink / raw)
To: linux-arm-kernel
The following patches support configuring and building the versatile
machine with a no-MMU kernel.
There is only a minor few changes required. It was previously possible
in older kernels to build for versatile with CONFIG_MMU disabled, but
the change to devicetree lost that capability. These changes make it
possible again.
One patch is a fix for address translation (broken on older kernels too),
two are build problems when CONFIG_MMU is disabled, and the last is the
actuall configuration changes needed.
The motivation for this is that the versatile machine is well supported
in qemu. And this provides an excellent platform for development and
testing no-MMU support on ARM in general. With these patches applied
it is possible to build and run a kernel with MMU disabled on qemu.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
arch/arm/Kconfig | 10 ++++++++++
arch/arm/Kconfig.debug | 3 ++-
arch/arm/include/asm/mach/map.h | 1 +
arch/arm/mach-versatile/Kconfig | 3 ++-
arch/arm/mach-versatile/Makefile.boot | 3 +++
arch/arm/mach-versatile/versatile_dt.c | 4 ++++
6 files changed, 22 insertions(+), 2 deletions(-)
^ permalink raw reply
* [RFC PATCH 2/2] ARM: i.MX: dts: add fsl, imx25-wdt compatible to all relevant watchdog nodes
From: Vladimir Zapolskiy @ 2016-09-26 0:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474850361-20884-1-git-send-email-vz@mleia.com>
Watchdog device controller found on all modern SoCs from i.MX series
and firstly introduced in i.MX25 is not one in one compatible with the
watchdog controllers on i.MX21, i.MX27 and i.MX31, the latter
controlles don't have WICR (and pretimeout notification support) and
WMCR registers. To get benefit from the more advanced watchdog device
and to avoid operations over non-existing registers on legacy SoCs add
fsl,imx25-wdt compatible to descriptions of all i.MX25 compatible
watchdog controllers.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
---
arch/arm/boot/dts/imx35.dtsi | 3 ++-
arch/arm/boot/dts/imx50.dtsi | 3 ++-
arch/arm/boot/dts/imx51.dtsi | 6 ++++--
arch/arm/boot/dts/imx53.dtsi | 6 ++++--
arch/arm/boot/dts/imx6qdl.dtsi | 6 ++++--
arch/arm/boot/dts/imx6sl.dtsi | 6 ++++--
arch/arm/boot/dts/imx6sx.dtsi | 9 ++++++---
arch/arm/boot/dts/imx6ul.dtsi | 6 ++++--
arch/arm/boot/dts/imx7s.dtsi | 12 ++++++++----
arch/arm/boot/dts/ls1021a.dtsi | 2 +-
arch/arm/boot/dts/vfxxx.dtsi | 3 ++-
11 files changed, 41 insertions(+), 21 deletions(-)
diff --git a/arch/arm/boot/dts/imx35.dtsi b/arch/arm/boot/dts/imx35.dtsi
index 490b7b4..8fd4482 100644
--- a/arch/arm/boot/dts/imx35.dtsi
+++ b/arch/arm/boot/dts/imx35.dtsi
@@ -284,7 +284,8 @@
};
wdog: wdog at 53fdc000 {
- compatible = "fsl,imx35-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx35-wdt", "fsl,imx25-wdt",
+ "fsl,imx21-wdt";
reg = <0x53fdc000 0x4000>;
clocks = <&clks 74>;
clock-names = "";
diff --git a/arch/arm/boot/dts/imx50.dtsi b/arch/arm/boot/dts/imx50.dtsi
index e245713..5ba6d5a 100644
--- a/arch/arm/boot/dts/imx50.dtsi
+++ b/arch/arm/boot/dts/imx50.dtsi
@@ -260,7 +260,8 @@
};
wdog1: wdog at 53f98000 {
- compatible = "fsl,imx50-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx50-wdt", "fsl,imx25-wdt",
+ "fsl,imx21-wdt";
reg = <0x53f98000 0x4000>;
interrupts = <58>;
clocks = <&clks IMX5_CLK_DUMMY>;
diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
index f46fe9b..d91f713 100644
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -345,14 +345,16 @@
};
wdog1: wdog at 73f98000 {
- compatible = "fsl,imx51-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx51-wdt", "fsl,imx25-wdt",
+ "fsl,imx21-wdt";
reg = <0x73f98000 0x4000>;
interrupts = <58>;
clocks = <&clks IMX5_CLK_DUMMY>;
};
wdog2: wdog at 73f9c000 {
- compatible = "fsl,imx51-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx51-wdt", "fsl,imx25-wdt",
+ "fsl,imx21-wdt";
reg = <0x73f9c000 0x4000>;
interrupts = <59>;
clocks = <&clks IMX5_CLK_DUMMY>;
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index cd17037..c9edac2 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -390,14 +390,16 @@
};
wdog1: wdog at 53f98000 {
- compatible = "fsl,imx53-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx53-wdt", "fsl,imx25-wdt",
+ "fsl,imx21-wdt";
reg = <0x53f98000 0x4000>;
interrupts = <58>;
clocks = <&clks IMX5_CLK_DUMMY>;
};
wdog2: wdog at 53f9c000 {
- compatible = "fsl,imx53-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx53-wdt", "fsl,imx25-wdt",
+ "fsl,imx21-wdt";
reg = <0x53f9c000 0x4000>;
interrupts = <59>;
clocks = <&clks IMX5_CLK_DUMMY>;
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index b620ac8..d73edd7 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -593,14 +593,16 @@
};
wdog1: wdog at 020bc000 {
- compatible = "fsl,imx6q-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx6q-wdt", "fsl,imx25-wdt",
+ "fsl,imx21-wdt";
reg = <0x020bc000 0x4000>;
interrupts = <0 80 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6QDL_CLK_DUMMY>;
};
wdog2: wdog at 020c0000 {
- compatible = "fsl,imx6q-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx6q-wdt", "fsl,imx25-wdt",
+ "fsl,imx21-wdt";
reg = <0x020c0000 0x4000>;
interrupts = <0 81 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6QDL_CLK_DUMMY>;
diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
index 5425150..b8c71bd 100644
--- a/arch/arm/boot/dts/imx6sl.dtsi
+++ b/arch/arm/boot/dts/imx6sl.dtsi
@@ -430,14 +430,16 @@
};
wdog1: wdog at 020bc000 {
- compatible = "fsl,imx6sl-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx6sl-wdt", "fsl,imx25-wdt",
+ "fsl,imx21-wdt";
reg = <0x020bc000 0x4000>;
interrupts = <0 80 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6SL_CLK_DUMMY>;
};
wdog2: wdog at 020c0000 {
- compatible = "fsl,imx6sl-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx6sl-wdt", "fsl,imx25-wdt",
+ "fsl,imx21-wdt";
reg = <0x020c0000 0x4000>;
interrupts = <0 81 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6SL_CLK_DUMMY>;
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index 2863c52..2753c71 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -515,14 +515,16 @@
};
wdog1: wdog at 020bc000 {
- compatible = "fsl,imx6sx-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx6sx-wdt", "fsl,imx25-wdt",
+ "fsl,imx21-wdt";
reg = <0x020bc000 0x4000>;
interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6SX_CLK_DUMMY>;
};
wdog2: wdog at 020c0000 {
- compatible = "fsl,imx6sx-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx6sx-wdt", "fsl,imx25-wdt",
+ "fsl,imx21-wdt";
reg = <0x020c0000 0x4000>;
interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6SX_CLK_DUMMY>;
@@ -1178,7 +1180,8 @@
};
wdog3: wdog at 02288000 {
- compatible = "fsl,imx6sx-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx6sx-wdt", "fsl,imx25-wdt",
+ "fsl,imx21-wdt";
reg = <0x02288000 0x4000>;
interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6SX_CLK_DUMMY>;
diff --git a/arch/arm/boot/dts/imx6ul.dtsi b/arch/arm/boot/dts/imx6ul.dtsi
index 33b95d7..fb0373f 100644
--- a/arch/arm/boot/dts/imx6ul.dtsi
+++ b/arch/arm/boot/dts/imx6ul.dtsi
@@ -483,14 +483,16 @@
};
wdog1: wdog at 020bc000 {
- compatible = "fsl,imx6ul-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx6ul-wdt", "fsl,imx25-wdt",
+ "fsl,imx21-wdt";
reg = <0x020bc000 0x4000>;
interrupts = <GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6UL_CLK_WDOG1>;
};
wdog2: wdog at 020c0000 {
- compatible = "fsl,imx6ul-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx6ul-wdt", "fsl,imx25-wdt",
+ "fsl,imx21-wdt";
reg = <0x020c0000 0x4000>;
interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6UL_CLK_WDOG2>;
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 1e90bdb..e7c047e 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -394,14 +394,16 @@
};
wdog1: wdog at 30280000 {
- compatible = "fsl,imx7d-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx7d-wdt", "fsl,imx25-wdt",
+ "fsl,imx21-wdt";
reg = <0x30280000 0x10000>;
interrupts = <GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX7D_WDOG1_ROOT_CLK>;
};
wdog2: wdog at 30290000 {
- compatible = "fsl,imx7d-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx7d-wdt", "fsl,imx25-wdt",
+ "fsl,imx21-wdt";
reg = <0x30290000 0x10000>;
interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX7D_WDOG2_ROOT_CLK>;
@@ -409,7 +411,8 @@
};
wdog3: wdog at 302a0000 {
- compatible = "fsl,imx7d-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx7d-wdt", "fsl,imx25-wdt",
+ "fsl,imx21-wdt";
reg = <0x302a0000 0x10000>;
interrupts = <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX7D_WDOG3_ROOT_CLK>;
@@ -417,7 +420,8 @@
};
wdog4: wdog at 302b0000 {
- compatible = "fsl,imx7d-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,imx7d-wdt", "fsl,imx25-wdt",
+ "fsl,imx21-wdt";
reg = <0x302b0000 0x10000>;
interrupts = <GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX7D_WDOG4_ROOT_CLK>;
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index 368e219..7e36fd8 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -441,7 +441,7 @@
};
wdog0: watchdog at 2ad0000 {
- compatible = "fsl,imx21-wdt";
+ compatible = "fsl,imx25-wdt", "fsl,imx21-wdt";
reg = <0x0 0x2ad0000 0x0 0x10000>;
interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&platform_clk 1>;
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 2c13ec6..35f32ed 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -320,7 +320,8 @@
};
wdoga5: wdog at 4003e000 {
- compatible = "fsl,vf610-wdt", "fsl,imx21-wdt";
+ compatible = "fsl,vf610-wdt", "fsl,imx25-wdt",
+ "fsl,imx21-wdt";
reg = <0x4003e000 0x1000>;
interrupts = <20 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks VF610_CLK_WDT>;
--
2.8.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox