* [PATCH v3 00/18] FSI device driver introduction
From: christopher.lee.bostic @ 2017-01-19 0:30 UTC (permalink / raw)
To: robh+dt, mark.rutland, linux, gregkh, mturquette, geert+renesas,
devicetree, linux-arm-kernel, joel, linux-kernel, andrew,
alistair, benh
Cc: Christopher Bostic
From: Christopher Bostic <christopher.lee.bostic@gmail.com>
Introduction of the IBM 'Flexible Support Interface' (FSI) bus device
driver. FSI is a high fan out serial bus consisting of a clock and a serial
data line capable of running at speeds up to 166 MHz.
This set provides the basic framework to add FSI extensions to the
Linux bus and device models. Master specific implementations are
defined to utilize the core FSI function.
In Linux, we have a core FSI "bus type", along with drivers for FSI
masters and engines.
The FSI master drivers expose a read/write interface to the bus address
space. The master drivers are under drivers/fsi/fsi-master-*.c.
The core handles probing and discovery of slaves and slave
engines, using those read/write interfaces. It is responsible for
creating the endpoint Linux devices corresponding to the discovered
engines on each slave.
Slave engines are identified by an 'engine' type, and an optional
version. Engine, a.k.a. client, drivers are matched and bound to these
engines during discovery.
This patch set does not include extended FSI function such as:
* Hub master support
* Cascaded master support
* Application layer hot plug notification
* Application layer FSI bus status interface
Common FSI terminology:
* Master
Controller of the FSI bus. Only the master is allowed to control the
clock line and is the initiator of all transactions on a bus.
* Slave
The receiver or target of a master initiated transaction. The slave
cannot initiate communications on a bus and must respond to any
master requests for data.
* CFAM
Stands for Common Field replaceable unit Access Macro. A CFAM is an
ASIC residing in any device requiring FSI communications. CFAMs
consist of an array of hardware 'engines' used for various purposes.
I2C masters, UARTs, General Purpose IO hardware are common types of
these engines.
* Configuration Space / Table
A table contained at the beginning of each CFAM address space.
This table lists information such as the CFAM's ID, which engine types
and versions it has available, as well as its addressing range.
* FSI Engine driver
A device driver that registers with the FSI core so that it can access
devices it owns on an FSI bus.
Chris Bostic (8):
drivers/fsi: Kick off master scan via sysfs
drivers/fsi: Set up links for slave communication
drivers/fsi: Set slave SMODE to init communication
drivers/fsi: Remove all scanned devices during master unregister
drivers/fsi: Add FSI bus documentation
drivers/fsi: Add documentation for GPIO based FSI master
drivers/fsi: Document FSI master sysfs files in ABI
drivers/fsi: Add GPIO based FSI master
Jeremy Kerr (10):
drivers/fsi: Add empty fsi bus definitions
drivers/fsi: Add device & driver definitions
drivers/fsi: add driver to device matches
drivers/fsi: Add fsi master definition
drivers/fsi: Add slave definition
drivers/fsi: Add empty master scan
drivers/fsi: Add FSI crc calculators to library
drivers/fsi: Implement slave initialisation
drivers/fsi: scan slaves & register devices
drivers/fsi: Add device read/write/peek functions
Changes for v3:
- Patch set contained an invalid 18/18 test patch not
meant for community review, corrected.
Changes for v2:
- Change from atomic global for master number to ida simple
interface.
- Add valid pointer checks on register and unregister utils.
- Move CRC calculation utilities out of driver to lib path.
- Clean up white space issues.
- Remove added list management of master devices and use
instead the device_for_each_child method available in the
bus.
- Add new patch to document FSI bus functionality.
- Add new patch documenting FSI gpio master.
- Rearrage patch set to have documentation earlier than code
implementing it.
- Document all compatible strings used in device tree bindings.
- Elaborate documentation definition of FSI GPIO master.
- Describe in more detail what each GPIO FSI master pin is for.
- Re-order compatible strings in example binding so that most
specific device comes first.
- Indicate proper activation order of all FSI GPIO master pins.
- Fix an unmatched '>' bracket in the example for binding.
- Bracket each element of the example bindings individually.
- Add new patch documenting sysfs-bus-fsi attributes.
- Merge FSI GPIO master init into probe function.
- Set pin initial values at time of pin request.
- Assign value of master->master.dev at probe time.
- Use get_optional interface for all optional GPIO pins.
Documentation/ABI/testing/sysfs-bus-fsi | 6 +
.../devicetree/bindings/fsi/fsi-master-gpio.txt | 71 +++
Documentation/devicetree/bindings/fsi/fsi.txt | 54 +++
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/fsi/Kconfig | 23 +
drivers/fsi/Makefile | 3 +
drivers/fsi/fsi-core.c | 494 +++++++++++++++++++
drivers/fsi/fsi-master-gpio.c | 530 +++++++++++++++++++++
drivers/fsi/fsi-master.h | 39 ++
include/linux/crc-fsi.h | 29 ++
include/linux/fsi.h | 60 +++
lib/Makefile | 1 +
lib/crc-fsi.c | 39 ++
14 files changed, 1352 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-bus-fsi
create mode 100644 Documentation/devicetree/bindings/fsi/fsi-master-gpio.txt
create mode 100644 Documentation/devicetree/bindings/fsi/fsi.txt
create mode 100644 drivers/fsi/Kconfig
create mode 100644 drivers/fsi/Makefile
create mode 100644 drivers/fsi/fsi-core.c
create mode 100644 drivers/fsi/fsi-master-gpio.c
create mode 100644 drivers/fsi/fsi-master.h
create mode 100644 include/linux/crc-fsi.h
create mode 100644 include/linux/fsi.h
create mode 100644 lib/crc-fsi.c
--
1.8.2.2
^ permalink raw reply
* Re: [PATCH v4 3/4] dt-bindings: phy: Add support for QMP phy
From: Stephen Boyd @ 2017-01-19 0:40 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Vivek Gautam, Kishon Vijay Abraham I, robh+dt, linux-kernel,
devicetree, mark.rutland, srinivas.kandagatla, linux-arm-msm
In-Reply-To: <20170118182223.GP10531@minitux>
On 01/18, Bjorn Andersson wrote:
> On Tue 17 Jan 22:54 PST 2017, Vivek Gautam wrote:
> > On 01/16/2017 02:19 PM, Kishon Vijay Abraham I wrote:
> > > On Tuesday 10 January 2017 04:21 PM, Vivek Gautam wrote:
> [..]
> > > > + reset-names = "phy", "common", "cfg",
> > > > + "lane0", "lane1", "lane2";
> > > Each lane has a separate clock, separate reset.. why not create sub-nodes for
> > > each lane?
> >
> > Yes, each lane has separate pipe clock and resets.
> > I can have a binding such as written below.
>
> +1
>
> > Does it makes sense to pull in the tx, rx and pcs offsets as well
> > to the child node, and iomap the entire address space of the phy ?
> >
>
> Note that you don't have to follow the same structure in your device
> driver as you describe your hardware in devicetree.
>
> I would suggest that you replace the lane-offset and various lane
> specific resources with subnodes, but keep the driver "as is".
>
Didn't we already move away from subnodes for lanes in an earlier
revision of these patches? I seem to recall we did that because
lanes are not devices and the whole "phy as a bus" concept not
making sense.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCHv4 2/5] arm: mvebu: support for SMP on 98DX3336 SoC
From: Stephen Boyd @ 2017-01-19 0:47 UTC (permalink / raw)
To: Chris Packham
Cc: linux-arm-kernel, Rob Herring, Mark Rutland, Jason Cooper,
Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Russell King,
Geert Uytterhoeven, Florian Fainelli, Chris Brand, Juri Lelli,
Sudeep Holla, Jayachandran C, devicetree, linux-kernel
In-Reply-To: <20170113091222.7132-3-chris.packham@alliedtelesis.co.nz>
On 01/13, Chris Packham wrote:
> diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
> index 46c742d3bd41..59be3ca0464f 100644
> --- a/arch/arm/mach-mvebu/platsmp.c
> +++ b/arch/arm/mach-mvebu/platsmp.c
> @@ -184,3 +184,89 @@ const struct smp_operations armada_xp_smp_ops __initconst = {
>
> CPU_METHOD_OF_DECLARE(armada_xp_smp, "marvell,armada-xp-smp",
> &armada_xp_smp_ops);
> +
> +struct resume_controller {
> + u32 resume_control;
> + u32 resume_boot_addr;
> +};
> +
> +static const struct resume_controller mv98dx3336_resume_controller = {
> + .resume_control = 0x08,
> + .resume_boot_addr = 0x04,
> +};
> +
> +static const struct of_device_id of_mv98dx3236_resume_table[] = {
> + {
> + .compatible = "marvell,98dx3336-resume-ctrl",
> + .data = (void *)&mv98dx3336_resume_controller,
Useless cast?
> + },
> + { /* end of list */ },
> +};
> +
> +static int mv98dx3236_resume_set_cpu_boot_addr(int hw_cpu, void *boot_addr)
> +{
> + const struct of_device_id *match;
> + struct device_node *np;
> + void __iomem *base;
> + struct resume_controller *rc;
> +
> + WARN_ON(hw_cpu != 1);
> +
> + np = of_find_matching_node_and_match(NULL, of_mv98dx3236_resume_table,
> + &match);
> + if (!np)
> + return -ENODEV;
> +
> + base = of_io_request_and_map(np, 0, of_node_full_name(np));
> + rc = (struct resume_controller *)match->data;
Useless cast?
> + of_node_put(np);
> + if (IS_ERR(base))
> + return PTR_ERR(base);
> +
> + writel(0, base + rc->resume_control);
> + writel(virt_to_phys(boot_addr), base + rc->resume_boot_addr);
> +
Otherwise
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v5] ARM64: dts: meson-gx: Add firmware reserved memory zones
From: Andreas Färber @ 2017-01-19 1:18 UTC (permalink / raw)
To: Neil Armstrong, xypron.glpk, khilman, carlo
Cc: linux-amlogic, linux-kernel, linux-arm-kernel, devicetree
In-Reply-To: <2bdb6818-4620-53b1-112d-2d6a29e484d9@suse.de>
Am 19.01.2017 um 01:20 schrieb Andreas Färber:
> Hi,
>
> Am 18.01.2017 um 17:50 schrieb Neil Armstrong:
>> The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
>> this patch adds these reserved zones.
>>
>> Without such reserved memory zones, running the following stress command :
>> $ stress-ng --vm 16 --vm-bytes 128M --timeout 10s
>> multiple times:
>>
>> Could lead to the following kernel crashes :
>> [ 46.937975] Bad mode in Error handler detected on CPU1, code 0xbf000000 -- SError
>> ...
>> [ 47.058536] Internal error: Attempting to execute userspace memory: 8600000f [#3] PREEMPT SMP
>> ...
>> Instead of the OOM killer.
>>
>
> I miss a Fixes: or Cc: here for the backport you desired. To have it
> fixed back to my very introduction:
>
> Fixes: 4f24eda8401f ("ARM64: dts: Prepare configs for Amlogic Meson GXBaby")
>
> People backporting it would need to handle the meson-{gx => gxbb}.dtsi
> transition for 4.9 down to 4.6, which seems fairly straightforward.
>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 18 ++++++++++++++++++
>> 1 file changed, 18 insertions(+)
>>
>> Changes since v4 at [5]:
>> - Move start of ddr memory to reserved-memory node
>> - Drop memory node move
>> - Fix typo in sizes
>>
>> Changes since resent v2 at [4]:
>> - Fix invalid comment of useable memory attributes
>>
>> Changes since original v2 at [3]:
>> - Typo in commit 2GiB -> 1GiB, 4GiB -> 2GiB
>>
>> Changes since v2 at [2]:
>> - Moved all memory node out of dtsi
>> - Added comment about useable memory
>> - Fixed comment about secmon reserved zone
>>
>> Changes since v1 at [1] :
>> - Renamed reg into linux,usable-memory to ovveride u-boot memory
>> - only kept secmon memory zone
>>
>> [1] http://lkml.kernel.org/r/20161212101801.28491-1-narmstrong@baylibre.com
>> [2] http://lkml.kernel.org/r/1483105232-6242-1-git-send-email-narmstrong@baylibre.com
>> [3] http://lkml.kernel.org/r/1484128128-22454-1-git-send-email-narmstrong@baylibre.com
>> [4] http://lkml.kernel.org/r/1484128540-22662-1-git-send-email-narmstrong@baylibre.com
>> [5] http://lkml.kernel.org/r/1484129414-23325-1-git-send-email-narmstrong@baylibre.com
>>
>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>> index eada0b5..63d52b7 100644
>> --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>> +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>> @@ -55,6 +55,24 @@
>> #address-cells = <2>;
>> #size-cells = <2>;
>>
>> + reserved-memory {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges;
>> +
>> + /* 16 MiB reserved for Hardware ROM Firmware */
>> + hwrom: hwrom {
>
> Both sub-nodes get a label that is unused, but reserved-memory itself
> does not (my v4 remark). Intentional?
>
>> + reg = <0x0 0x0 0x0 0x1000000>;
>> + no-map;
>> + };
>> +
>> + /* 2 MiB reserved for ARM Trusted Firmware (BL31) */
>> + secmon: secmon {
>
> I note that this .dtsi further down has a node /firmware/secure-monitor
> with label sm.
> a) Is there any naming convention such as secmon_mem to adopt here to
> avoid mixups with sm?
> b) Should this secmon node be referenced in the secure-monitor node via
> memory-node = <&secmon>; to model their connection, thereby giving the
> label a use? Or should we maybe merge the two nodes by moving the
> compatible string here?
>
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
Answering my own question: the example labels use _reserved suffix.
>> + reg = <0x0 0x10000000 0x0 0x200000>;
And since we use a reg property here, the node name should get a unit
address to avoid future dtc warnings/errors. Ditto for hwrom.
>> + no-map;
>> + };
>> + };
>> +
>> cpus {
>> #address-cells = <0x2>;
>> #size-cells = <0x0>;
>
> Anyway, objection resolved,
>
> Reviewed-by: Andreas Färber <afaerber@suse.de>
>
> I don't expect breakage from these more confined additions, but I can
> try to test tomorrow.
>
> Thanks,
> Andreas
>
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* [PATCH v2 0/3] Add support for Broadcom iProc mailbox controller
From: Jonathan Richardson @ 2017-01-19 1:39 UTC (permalink / raw)
To: Jassi Brar
Cc: Mark Rutland, devicetree, Jonathan Richardson, Scott Branden,
Jon Mason, Ray Jui, Russell King, Vikram Prakash, Rob Herring,
BCM Kernel Feedback, linux-arm-kernel
This patch set contains mailbox support for Broadcom iProc based SoC's. The
mailbox controller handles all communication with a Cortex-M0 MCU processor that
provides support for power, clock, and reset management.
The patch set enables the mailbox controller for Cygnus and also interrupt
support for the Cygnus CRMU GPIO driver which requires use of the M0 processor.
Changes from v1:
- Interrupt handling has been removed and will be added to an interrupt
controller driver and sent out in a separate patchset.
- Moved location of bcm_iproc_mailbox.h to include/linux/mailbox as suggested by
Jassi.
- Removed reading of client timeout from driver and used canned timeout. This
removes the need of including the client mailbox header.
Jonathan Richardson (3):
dt-bindings: Document Broadcom iProc mailbox controller driver
mailbox: Add iProc mailbox controller driver
ARM: dts: Enable Broadcom iProc mailbox controller
.../bindings/mailbox/brcm,iproc-mailbox.txt | 14 ++
arch/arm/boot/dts/bcm-cygnus.dtsi | 6 +
drivers/mailbox/Kconfig | 10 ++
drivers/mailbox/Makefile | 2 +
drivers/mailbox/bcm-iproc-mailbox.c | 199 +++++++++++++++++++++
include/linux/mailbox/bcm_iproc_mailbox.h | 32 ++++
6 files changed, 263 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/brcm,iproc-mailbox.txt
create mode 100644 drivers/mailbox/bcm-iproc-mailbox.c
create mode 100644 include/linux/mailbox/bcm_iproc_mailbox.h
--
1.9.1
^ permalink raw reply
* [PATCH v2 1/3] dt-bindings: Document Broadcom iProc mailbox controller driver
From: Jonathan Richardson @ 2017-01-19 1:39 UTC (permalink / raw)
To: Jassi Brar
Cc: Rob Herring, Mark Rutland, Ray Jui, Scott Branden, Jon Mason,
Russell King, Jonathan Richardson, Vikram Prakash,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
BCM Kernel Feedback
In-Reply-To: <1484789980-6812-1-git-send-email-jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Reviewed-by: Jonathan Richardson <jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Tested-by: Jonathan Richardson <jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Reviewed-by: Vikram Prakash <vikram.prakash-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Reviewed-by: Ray Jui <ray.jui-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Reviewed-by: Shreesha Rajashekar <shreesha.rajashekar-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Reviewed-by: Scott Branden <scott.branden-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Signed-off-by: Jonathan Richardson <jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
---
.../devicetree/bindings/mailbox/brcm,iproc-mailbox.txt | 14 ++++++++++++++
1 file changed, 14 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/brcm,iproc-mailbox.txt
diff --git a/Documentation/devicetree/bindings/mailbox/brcm,iproc-mailbox.txt b/Documentation/devicetree/bindings/mailbox/brcm,iproc-mailbox.txt
new file mode 100644
index 0000000..f4c4f96
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/brcm,iproc-mailbox.txt
@@ -0,0 +1,14 @@
+* Broadcom's iProc Mailbox Controller
+
+Required properties:
+- compatible: Must be "brcm,iproc-mailbox"
+- reg: Defines the base address of the mailbox controller.
+- #mbox-cells: Must be 1.
+
+Example:
+
+ mailbox: mailbox@03024024 {
+ compatible = "brcm,iproc-mailbox";
+ reg = <0x03024024 0x8>;
+ #mbox-cells = <1>;
+ };
--
1.9.1
--
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 v2 2/3] mailbox: Add iProc mailbox controller driver
From: Jonathan Richardson @ 2017-01-19 1:39 UTC (permalink / raw)
To: Jassi Brar
Cc: Rob Herring, Mark Rutland, Ray Jui, Scott Branden, Jon Mason,
Russell King, Jonathan Richardson, Vikram Prakash,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
BCM Kernel Feedback
In-Reply-To: <1484789980-6812-1-git-send-email-jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
The Broadcom iProc mailbox controller handles all communication with a
Cortex-M0 MCU processor that provides support for power, clock, and
reset management.
Tested-by: Jonathan Richardson <jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Reviewed-by: Jonathan Richardson <jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Reviewed-by: Vikram Prakash <vikram.prakash-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Reviewed-by: Shreesha Rajashekar <shreesha.rajashekar-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Reviewed-by: Ray Jui <ray.jui-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Reviewed-by: Scott Branden <scott.branden-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Signed-off-by: Jonathan Richardson <jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
---
drivers/mailbox/Kconfig | 10 ++
drivers/mailbox/Makefile | 2 +
drivers/mailbox/bcm-iproc-mailbox.c | 199 ++++++++++++++++++++++++++++++
include/linux/mailbox/bcm_iproc_mailbox.h | 32 +++++
4 files changed, 243 insertions(+)
create mode 100644 drivers/mailbox/bcm-iproc-mailbox.c
create mode 100644 include/linux/mailbox/bcm_iproc_mailbox.h
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index 11eebfe..284916d 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -143,4 +143,14 @@ config BCM_PDC_MBOX
Mailbox implementation for the Broadcom PDC ring manager,
which provides access to various offload engines on Broadcom
SoCs. Say Y here if you want to use the Broadcom PDC.
+
+config BCM_IPROC_MBOX
+ bool "Broadcom iProc Mailbox"
+ depends on ARCH_BCM_IPROC || COMPILE_TEST
+ default ARCH_BCM_IPROC
+ help
+ Broadcom iProc architected SoC's have an always on Cortex-M0 MCU processor
+ that handles support for power, clock, and reset management. The iProc
+ mailbox controller handles all communication with this processor.
+
endif
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index ace6fed..f96eab6 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -29,3 +29,5 @@ obj-$(CONFIG_XGENE_SLIMPRO_MBOX) += mailbox-xgene-slimpro.o
obj-$(CONFIG_HI6220_MBOX) += hi6220-mailbox.o
obj-$(CONFIG_BCM_PDC_MBOX) += bcm-pdc-mailbox.o
+
+obj-$(CONFIG_BCM_IPROC_MBOX) += bcm-iproc-mailbox.o
diff --git a/drivers/mailbox/bcm-iproc-mailbox.c b/drivers/mailbox/bcm-iproc-mailbox.c
new file mode 100644
index 0000000..36ecad5
--- /dev/null
+++ b/drivers/mailbox/bcm-iproc-mailbox.c
@@ -0,0 +1,199 @@
+/*
+ * Copyright (C) 2017 Broadcom.
+ *
+ * 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 version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include <linux/kernel.h>
+#include <linux/slab.h>
+#include <linux/module.h>
+#include <linux/io.h>
+#include <linux/platform_device.h>
+#include <linux/of.h>
+#include <linux/mailbox_controller.h>
+#include <linux/mailbox/bcm_iproc_mailbox.h>
+#include <linux/delay.h>
+
+#define IPROC_CRMU_MAILBOX0_OFFSET 0x0
+#define IPROC_CRMU_MAILBOX1_OFFSET 0x4
+
+#define M0_IPC_CMD_DONE_MASK 0x80000000
+#define M0_IPC_CMD_REPLY_MASK 0x3fff0000
+#define M0_IPC_CMD_REPLY_SHIFT 16
+
+/* Max time the M0 will take to respond to a message. */
+#define MAX_M0_TIMEOUT_MS 2
+
+struct iproc_mbox {
+ struct device *dev;
+ void __iomem *base;
+ spinlock_t lock;
+ struct mbox_controller controller;
+ u32 num_chans;
+};
+
+static const struct of_device_id iproc_mbox_of_match[] = {
+ { .compatible = "brcm,iproc-mailbox" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, iproc_mbox_of_match);
+
+/*
+ * Sends a message to M0. The mailbox framework prevents multiple accesses to
+ * the same channel but there is only one h/w "channel". This driver allows
+ * multiple clients to create channels to the controller but must serialize
+ * access to the mailbox registers used to communicate with the M0.
+ */
+static int iproc_mbox_send_data_m0(struct mbox_chan *chan, void *data)
+{
+ struct iproc_mbox *mbox = dev_get_drvdata(chan->mbox->dev);
+ struct iproc_mbox_msg *msg = (struct iproc_mbox_msg *)data;
+ unsigned long flags;
+ int err = 0;
+ const int poll_period_us = 5;
+ const int max_retries = (MAX_M0_TIMEOUT_MS * 1000) / poll_period_us;
+
+ if (!msg)
+ return -EINVAL;
+
+ spin_lock_irqsave(&mbox->lock, flags);
+
+ dev_dbg(mbox->dev, "Send msg to M0: cmd=0x%x, param=0x%x, wait_ack=%d\n",
+ msg->cmd, msg->param, msg->wait_ack);
+
+ writel(msg->cmd, mbox->base + IPROC_CRMU_MAILBOX0_OFFSET);
+ writel(msg->param, mbox->base + IPROC_CRMU_MAILBOX1_OFFSET);
+
+ if (msg->wait_ack) {
+ int retries;
+
+ err = msg->reply_code = -ETIMEDOUT;
+ for (retries = 0; retries < max_retries; retries++) {
+ u32 val = readl(
+ mbox->base + IPROC_CRMU_MAILBOX0_OFFSET);
+ if (val & M0_IPC_CMD_DONE_MASK) {
+ /*
+ * M0 replied - save reply code and
+ * clear error.
+ */
+ msg->reply_code = (val &
+ M0_IPC_CMD_REPLY_MASK) >>
+ M0_IPC_CMD_REPLY_SHIFT;
+ err = 0;
+ break;
+ }
+ udelay(poll_period_us);
+ }
+ }
+
+ spin_unlock_irqrestore(&mbox->lock, flags);
+
+ return err;
+}
+
+static int iproc_mbox_startup(struct mbox_chan *chan)
+{
+ /* Do nothing. */
+ return 0;
+}
+
+static void iproc_mbox_shutdown(struct mbox_chan *chan)
+{
+ /* Do nothing. */
+}
+
+static struct mbox_chan_ops iproc_mbox_ops = {
+ .send_data = iproc_mbox_send_data_m0,
+ .startup = iproc_mbox_startup,
+ .shutdown = iproc_mbox_shutdown,
+};
+
+static int iproc_mbox_probe(struct platform_device *pdev)
+{
+ int err;
+ struct device *dev = &pdev->dev;
+ struct resource *res;
+ struct iproc_mbox *iproc_mbox;
+ struct device_node *node;
+ const char *mbox_prop_name = "mboxes";
+ struct mbox_chan *chans;
+
+ dev_info(&pdev->dev, "Initializing iproc mailbox controller\n");
+
+ iproc_mbox = devm_kzalloc(dev, sizeof(*iproc_mbox), GFP_KERNEL);
+ if (!iproc_mbox)
+ return -ENOMEM;
+
+ iproc_mbox->dev = dev;
+ spin_lock_init(&iproc_mbox->lock);
+
+ platform_set_drvdata(pdev, iproc_mbox);
+
+ /* Count number of "mboxes" properties to determine # channels. */
+ for_each_of_allnodes(node) {
+ struct property *prop = of_find_property(
+ node, mbox_prop_name, NULL);
+ if (prop) {
+ struct device_node *mbox_phandle = of_parse_phandle(
+ node, mbox_prop_name, 0);
+ if (mbox_phandle == dev->of_node)
+ iproc_mbox->num_chans++;
+ }
+ }
+
+ if (iproc_mbox->num_chans == 0) {
+ dev_err(dev, "No mailbox clients configured\n");
+ return -ENODEV;
+ }
+
+ chans = devm_kzalloc(&pdev->dev,
+ sizeof(*chans) * iproc_mbox->num_chans, GFP_KERNEL);
+ if (!chans)
+ return -ENOMEM;
+
+ /* Initialize mailbox controller. */
+ iproc_mbox->controller.dev = iproc_mbox->dev;
+ iproc_mbox->controller.num_chans = iproc_mbox->num_chans;
+ iproc_mbox->controller.chans = chans;
+ iproc_mbox->controller.ops = &iproc_mbox_ops;
+ iproc_mbox->controller.txdone_irq = false;
+ iproc_mbox->controller.txdone_poll = false;
+ err = mbox_controller_register(&iproc_mbox->controller);
+ if (err) {
+ dev_err(&pdev->dev, "Register mailbox failed\n");
+ return err;
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ iproc_mbox->base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(iproc_mbox->base)) {
+ dev_err(&pdev->dev, "unable to map I/O memory\n");
+ return PTR_ERR(iproc_mbox->base);
+ }
+
+ return 0;
+}
+
+static struct platform_driver iproc_mbox_driver = {
+ .driver = {
+ .name = "brcm,iproc-mailbox",
+ .of_match_table = iproc_mbox_of_match,
+ },
+ .probe = iproc_mbox_probe,
+};
+
+static int __init iproc_mbox_init(void)
+{
+ return platform_driver_register(&iproc_mbox_driver);
+}
+arch_initcall(iproc_mbox_init);
+
+MODULE_AUTHOR("Broadcom");
+MODULE_DESCRIPTION("Broadcom iProc Mailbox Driver");
+MODULE_LICENSE("GPL v2");
diff --git a/include/linux/mailbox/bcm_iproc_mailbox.h b/include/linux/mailbox/bcm_iproc_mailbox.h
new file mode 100644
index 0000000..68f37e4
--- /dev/null
+++ b/include/linux/mailbox/bcm_iproc_mailbox.h
@@ -0,0 +1,32 @@
+/*
+ * Copyright (C) 2016 Broadcom.
+ *
+ * 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 version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#ifndef _BCM_IPROC_MAILBOX_H_
+#define _BCM_IPROC_MAILBOX_H_
+
+/*
+ * A message to send to the M0 processor.
+ * @cmd Command to send.
+ * @param Parameter corresponding to command.
+ * @wait_ack true if mbox_send_message() should wait for a reply from the M0,
+ * false if the M0 doesn't reply. This depends on the message being sent.
+ * @reply_code The response code from the M0 for the command sent (wait_ack was
+ * set to true).
+ */
+struct iproc_mbox_msg {
+ u32 cmd;
+ u32 param;
+ bool wait_ack;
+ u32 reply_code;
+};
+
+#endif
--
1.9.1
--
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 v2 3/3] ARM: dts: Enable Broadcom iProc mailbox controller
From: Jonathan Richardson @ 2017-01-19 1:39 UTC (permalink / raw)
To: Jassi Brar
Cc: Rob Herring, Mark Rutland, Ray Jui, Scott Branden, Jon Mason,
Russell King, Jonathan Richardson, Vikram Prakash,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
BCM Kernel Feedback
In-Reply-To: <1484789980-6812-1-git-send-email-jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Reviewed-by: Jonathan Richardson <jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Reviewed-by: Shreesha Rajashekar <shreesha.rajashekar-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Reviewed-by: Ray Jui <ray.jui-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Tested-by: Jonathan Richardson <jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Reviewed-by: Vikram Prakash <vikram.prakash-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Reviewed-by: Scott Branden <scott.branden-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Signed-off-by: Jonathan Richardson <jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
---
arch/arm/boot/dts/bcm-cygnus.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
index fabc9f3..488bf42 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -114,6 +114,12 @@
<0x0301d24c 0x2c>;
};
+ mailbox: mailbox@03024024 {
+ compatible = "brcm,iproc-mailbox";
+ reg = <0x03024024 0x8>;
+ #mbox-cells = <1>;
+ };
+
gpio_crmu: gpio@03024800 {
compatible = "brcm,cygnus-crmu-gpio";
reg = <0x03024800 0x50>,
--
1.9.1
--
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
* Re: [PATCH v11 10/12] drm/mediatek: add non-continuous clock mode and EOT packet control
From: CK Hu @ 2017-01-19 1:42 UTC (permalink / raw)
To: YT Shen
Cc: Mark Rutland, devicetree, srv_heupstream, emil.l.velikov,
linux-kernel, dri-devel, Rob Herring, linux-mediatek,
Matthias Brugger, yingjoe.chen, shaoming chen, linux-arm-kernel
In-Reply-To: <1484117473-46644-11-git-send-email-yt.shen@mediatek.com>
Hi, YT:
On Wed, 2017-01-11 at 14:51 +0800, YT Shen wrote:
> This patch will update dsi clock control method.
> 1. dsi non-continue clock mode will enhance antistatic effect for panel
> 2. EOT packet control will judge whether dsi send end of packet or not
> by customize
>
> Signed-off-by: shaoming chen <shaoming.chen@mediatek.com>
> Signed-off-by: YT Shen <yt.shen@mediatek.com>
Acked-by: CK Hu <ck.hu@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index b3c7fd8..85f22d2 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -431,6 +431,9 @@ static void mtk_dsi_rxtx_control(struct mtk_dsi *dsi)
> break;
> }
>
> + tmp_reg |= (dsi->mode_flags & MIPI_DSI_CLOCK_NON_CONTINUOUS) << 6;
> + tmp_reg |= (dsi->mode_flags & MIPI_DSI_MODE_EOT_PACKET) >> 3;
> +
> writel(tmp_reg, dsi->regs + DSI_TXRX_CTRL);
> }
>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v3 16/24] media: Add i.MX media core driver
From: Steve Longerbeam @ 2017-01-19 1:44 UTC (permalink / raw)
To: Philipp Zabel
Cc: mark.rutland, andrew-ct.chen, minghsiu.tsai, nick, songjun.wu,
hverkuil, Steve Longerbeam, robert.jarzmik, devel, markus.heiser,
laurent.pinchart+renesas, linux, geert, linux-media, devicetree,
arnd, mchehab, bparrot, robh+dt, horms+renesas, tiffany.lin,
linux-arm-kernel, niklas.soderlund+renesas, gregkh, linux-kernel,
jean-christophe.trotin, kernel, fabio.estevam, shawnguo,
sudipm.mukherjee
In-Reply-To: <2b1d2418-1ad4-6373-cb07-c3aeab48187f@gmail.com>
On 01/14/2017 02:42 PM, Steve Longerbeam wrote:
>
>>> +/* parse inputs property from a sensor node */
>>> +static void of_parse_sensor_inputs(struct imx_media_dev *imxmd,
>>> + struct imx_media_subdev *sensor,
>>> + struct device_node *sensor_np)
>>> +{
>>> + struct imx_media_sensor_input *sinput = &sensor->input;
>>> + int ret, i;
>>> +
>>> + for (i = 0; i < IMX_MEDIA_MAX_SENSOR_INPUTS; i++) {
>>> + const char *input_name;
>>> + u32 val;
>>> +
>>> + ret = of_property_read_u32_index(sensor_np, "inputs", i, &val);
>>> + if (ret)
>>> + break;
>>> +
>>> + sinput->value[i] = val;
>>> +
>>> + ret = of_property_read_string_index(sensor_np, "input-names",
>>> + i, &input_name);
>>> + /*
>>> + * if input-names not provided, they will be set using
>>> + * the subdev name once the sensor is known during
>>> + * async bind
>>> + */
>>> + if (!ret)
>>> + strncpy(sinput->name[i], input_name,
>>> + sizeof(sinput->name[i]));
>>> + }
>>> +
>>> + sinput->num = i;
>>> +
>>> + /* if no inputs provided just assume a single input */
>>> + if (sinput->num == 0)
>>> + sinput->num = 1;
>>> +}
>> This should be parsed by the sensor driver, not imx-media.
>
> you're probably right. I'll submit a patch for adv7180.c.
Actually, the problem here is that this parses an input routing value to
pass to s_routing, and an input name string. There would need to be
another subdev callback, maybe enum_imput, that would return this
information for the bridge driver, if this info were to be parsed and
maintained by the sensor.
But this info should really be known and parsed by the bridge anyway,
because as the header for s_routing states,
"An i2c device shouldn't know about whether an input pin is connected
to a Composite connector, because on another board or platform it
might be connected to something else entirely. The calling driver is
responsible for mapping a user-level input to the right pins on the i2c
device."
Steve
^ permalink raw reply
* [PATCH v2 1/3] dt: bindings: add documentation for zx2967 family watchdog controller
From: Baoyou Xie @ 2017-01-19 1:59 UTC (permalink / raw)
To: jun.nie, wim, linux, robh+dt, mark.rutland
Cc: devicetree, linux-watchdog, xie.baoyou, linux-kernel,
chen.chaokai, wang.qiang01, baoyou.xie, shawnguo,
linux-arm-kernel
This patch adds dt-binding documentation for zx2967 family
watchdog controller.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
.../bindings/watchdog/zte,zx2967-wdt.txt | 32 ++++++++++++++++++++++
1 file changed, 32 insertions(+)
create mode 100644 Documentation/devicetree/bindings/watchdog/zte,zx2967-wdt.txt
diff --git a/Documentation/devicetree/bindings/watchdog/zte,zx2967-wdt.txt b/Documentation/devicetree/bindings/watchdog/zte,zx2967-wdt.txt
new file mode 100644
index 0000000..6e35ce7
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/zte,zx2967-wdt.txt
@@ -0,0 +1,32 @@
+ZTE zx2967 Watchdog timer
+
+Required properties:
+
+- compatible : should be one of the following.
+ * zte,zx296718-wdt
+- reg : Specifies base physical address and size of the registers.
+- clocks : Pairs of phandle and specifier referencing the controller's clocks.
+- clock-names: "wdtclk" for the watchdog clock.
+- resets : Reference to the reset controller controlling the watchdog
+ controller.
+- reset-names : Must include the following entries:
+ * wdtrst
+
+Optional properties:
+
+- wdt-reset-sysctrl : should include following fields.
+ * phandle of aon-sysctrl.
+ * configuare value that be wrote to aon-sysctrl.
+ * bit mask, corresponding bits will be affected.
+
+Example:
+
+wdt_ares: watchdog@1465000 {
+ compatible = "zte,zx296718-wdt";
+ reg = <0x1465000 0x1000>;
+ clocks = <&topcrm WDT_WCLK>;
+ clock-names = "wdtclk";
+ resets = <&toprst 35>;
+ reset-names = "wdtrst";
+ wdt-reset-sysctrl = <&aon_sysctrl 1 0x115>;
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/3] MAINTAINERS: add zx2967 watchdog controller driver to ARM ZTE architecture
From: Baoyou Xie @ 2017-01-19 1:59 UTC (permalink / raw)
To: jun.nie, wim, linux, robh+dt, mark.rutland
Cc: devicetree, linux-watchdog, xie.baoyou, linux-kernel,
chen.chaokai, wang.qiang01, baoyou.xie, shawnguo,
linux-arm-kernel
In-Reply-To: <1484791192-31674-1-git-send-email-baoyou.xie@linaro.org>
Add the zx2967 watchdog controller driver as maintained by ARM ZTE
architecture maintainers, as they're parts of the core IP.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index edfdea3..275c434 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1990,11 +1990,13 @@ F: drivers/clk/zte/
F: drivers/reset/reset-zx2967.c
F: drivers/soc/zte/
F: drivers/thermal/zx*
+F: drivers/watchdog/zx2967_wdt.c
F: Documentation/devicetree/bindings/arm/zte.txt
F: Documentation/devicetree/bindings/clock/zx296702-clk.txt
F: Documentation/devicetree/bindings/reset/zte,zx2967-reset.txt
F: Documentation/devicetree/bindings/soc/zte/
F: Documentation/devicetree/bindings/thermal/zx*
+F: Documentation/devicetree/bindings/watchdog/zte,zx2967-wdt.txt
F: include/dt-bindings/soc/zx*.h
ARM/ZYNQ ARCHITECTURE
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/3] watchdog: zx2967: add watchdog controller driver for ZTE's zx2967 family
From: Baoyou Xie @ 2017-01-19 1:59 UTC (permalink / raw)
To: jun.nie, wim, linux, robh+dt, mark.rutland
Cc: devicetree, linux-watchdog, xie.baoyou, linux-kernel,
chen.chaokai, wang.qiang01, baoyou.xie, shawnguo,
linux-arm-kernel
In-Reply-To: <1484791192-31674-1-git-send-email-baoyou.xie@linaro.org>
This patch adds watchdog controller driver for ZTE's zx2967 family.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
drivers/watchdog/Kconfig | 10 ++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/zx2967_wdt.c | 383 ++++++++++++++++++++++++++++++++++++++++++
3 files changed, 394 insertions(+)
create mode 100644 drivers/watchdog/zx2967_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index acb00b5..05093a2 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -714,6 +714,16 @@ config ASPEED_WATCHDOG
To compile this driver as a module, choose M here: the
module will be called aspeed_wdt.
+config ZX2967_WATCHDOG
+ tristate "ZTE zx2967 SoCs watchdog support"
+ depends on ARCH_ZX
+ select WATCHDOG_CORE
+ help
+ Say Y here to include support for the watchdog timer
+ in ZTE zx2967 SoCs.
+ To compile this driver as a module, choose M here: the
+ module will be called zx2967_wdt.
+
# AVR32 Architecture
config AT32AP700X_WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 0c3d35e..bf2d296 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -82,6 +82,7 @@ obj-$(CONFIG_BCM7038_WDT) += bcm7038_wdt.o
obj-$(CONFIG_ATLAS7_WATCHDOG) += atlas7_wdt.o
obj-$(CONFIG_RENESAS_WDT) += renesas_wdt.o
obj-$(CONFIG_ASPEED_WATCHDOG) += aspeed_wdt.o
+obj-$(CONFIG_ZX2967_WATCHDOG) += zx2967_wdt.o
# AVR32 Architecture
obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
diff --git a/drivers/watchdog/zx2967_wdt.c b/drivers/watchdog/zx2967_wdt.c
new file mode 100644
index 0000000..35eaecd
--- /dev/null
+++ b/drivers/watchdog/zx2967_wdt.c
@@ -0,0 +1,383 @@
+/*
+ * watchdog driver for ZTE's zx2967 family
+ *
+ * Copyright (C) 2017 ZTE Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie@linaro.org>
+ *
+ * License terms: GNU General Public License (GPL) version 2
+ */
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of_address.h>
+#include <linux/platform_device.h>
+#include <linux/reboot.h>
+#include <linux/regmap.h>
+#include <linux/reset.h>
+#include <linux/watchdog.h>
+
+#define ZX2967_WDT_CFG_REG 0x4
+#define ZX2967_WDT_LOAD_REG 0x8
+#define ZX2967_WDT_REFRESH_REG 0x18
+#define ZX2967_WDT_START_REG 0x1c
+
+#define ZX2967_WDT_REFRESH_MASK 0x3f
+
+#define ZX2967_WDT_CFG_DIV(n) ((((n) & 0xff) - 1) << 8)
+#define ZX2967_WDT_START_EN 0x1
+
+#define ZX2967_WDT_WRITEKEY 0x12340000
+
+#define ZX2967_WDT_DIV_DEFAULT 16
+#define ZX2967_WDT_DEFAULT_TIMEOUT 32
+#define ZX2967_WDT_MIN_TIMEOUT 1
+#define ZX2967_WDT_MAX_TIMEOUT 500
+#define ZX2967_WDT_MAX_COUNT 0xffff
+
+#define ZX2967_WDT_FLAG_REBOOT_MON (1 << 0)
+
+#define ZX2967_RESET_MASK_REG 0xb0
+
+struct zx2967_wdt {
+ struct device *dev;
+ struct clk *clock;
+ void __iomem *reg_base;
+ unsigned int conf;
+ unsigned int load;
+ unsigned int flags;
+ struct watchdog_device wdt_device;
+ struct notifier_block restart_handler;
+ struct notifier_block reboot_handler;
+};
+
+#define zx2967_wdt_read_reg(r) readl_relaxed(r)
+
+static inline void
+zx2967_wdt_write_reg(u32 val, void __iomem *addr)
+{
+ writel_relaxed(val | ZX2967_WDT_WRITEKEY, addr);
+}
+
+static void zx2967_wdt_refresh(struct zx2967_wdt *wdt)
+{
+ u32 val;
+
+ val = zx2967_wdt_read_reg(wdt->reg_base + ZX2967_WDT_REFRESH_REG);
+ val ^= ZX2967_WDT_REFRESH_MASK;
+ zx2967_wdt_write_reg(val, wdt->reg_base + ZX2967_WDT_REFRESH_REG);
+}
+
+static unsigned int
+__zx2967_wdt_set_timeout(struct zx2967_wdt *wdt, unsigned int timeout)
+{
+ unsigned int freq = clk_get_rate(wdt->clock);
+ unsigned int divisor = ZX2967_WDT_DIV_DEFAULT;
+ unsigned int count;
+
+ count = timeout * freq;
+ if (count > divisor * ZX2967_WDT_MAX_COUNT)
+ divisor = DIV_ROUND_UP(count, ZX2967_WDT_MAX_COUNT);
+ count = DIV_ROUND_UP(count, divisor);
+ zx2967_wdt_write_reg(ZX2967_WDT_CFG_DIV(divisor),
+ wdt->reg_base + ZX2967_WDT_CFG_REG);
+ zx2967_wdt_write_reg(count, wdt->reg_base + ZX2967_WDT_LOAD_REG);
+ zx2967_wdt_refresh(wdt);
+ wdt->load = count;
+
+ return (count * divisor) / freq;
+}
+
+static int zx2967_wdt_set_timeout(struct watchdog_device *wdd,
+ unsigned int timeout)
+{
+ struct zx2967_wdt *wdt = watchdog_get_drvdata(wdd);
+
+ if (watchdog_timeout_invalid(&wdt->wdt_device, timeout)) {
+ dev_err(wdt->dev, "timeout %d is invalid\n", timeout);
+ return -EINVAL;
+ }
+
+ wdd->timeout = __zx2967_wdt_set_timeout(wdt, timeout);
+
+ return 0;
+}
+
+static void __zx2967_wdt_start(struct zx2967_wdt *wdt)
+{
+ u32 val;
+
+ val = zx2967_wdt_read_reg(wdt->reg_base + ZX2967_WDT_START_REG);
+ val |= ZX2967_WDT_START_EN;
+ zx2967_wdt_write_reg(val, wdt->reg_base + ZX2967_WDT_START_REG);
+}
+
+static void __zx2967_wdt_stop(struct zx2967_wdt *wdt)
+{
+ u32 val;
+
+ val = zx2967_wdt_read_reg(wdt->reg_base + ZX2967_WDT_START_REG);
+ val &= ~ZX2967_WDT_START_EN;
+ zx2967_wdt_write_reg(val, wdt->reg_base + ZX2967_WDT_START_REG);
+}
+
+static int zx2967_wdt_start(struct watchdog_device *wdd)
+{
+ struct zx2967_wdt *wdt = watchdog_get_drvdata(wdd);
+
+ __zx2967_wdt_stop(wdt);
+ zx2967_wdt_set_timeout(wdd, wdd->timeout);
+ __zx2967_wdt_start(wdt);
+
+ return 0;
+}
+
+static int zx2967_wdt_stop(struct watchdog_device *wdd)
+{
+ struct zx2967_wdt *wdt = watchdog_get_drvdata(wdd);
+
+ __zx2967_wdt_stop(wdt);
+
+ return 0;
+}
+
+static int zx2967_wdt_keepalive(struct watchdog_device *wdd)
+{
+ struct zx2967_wdt *wdt = watchdog_get_drvdata(wdd);
+
+ zx2967_wdt_refresh(wdt);
+
+ return 0;
+}
+
+#define ZX2967_WDT_OPTIONS \
+ (WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING | WDIOF_MAGICCLOSE)
+static const struct watchdog_info zx2967_wdt_ident = {
+ .options = ZX2967_WDT_OPTIONS,
+ .firmware_version = 0,
+ .identity = "zx2967 watchdog",
+};
+
+static struct watchdog_ops zx2967_wdt_ops = {
+ .owner = THIS_MODULE,
+ .start = zx2967_wdt_start,
+ .stop = zx2967_wdt_stop,
+ .ping = zx2967_wdt_keepalive,
+ .set_timeout = zx2967_wdt_set_timeout,
+};
+
+static void zx2967_wdt_fix_sysdown(struct zx2967_wdt *wdt)
+{
+ __zx2967_wdt_stop(wdt);
+ __zx2967_wdt_set_timeout(wdt, 15);
+ __zx2967_wdt_start(wdt);
+}
+
+static int zx2967_wdt_notify_sys(struct notifier_block *this,
+ unsigned long code, void *unused)
+{
+ struct zx2967_wdt *wdt = container_of(this, struct zx2967_wdt,
+ reboot_handler);
+
+ wdt->flags |= ZX2967_WDT_FLAG_REBOOT_MON;
+ switch (code) {
+ case SYS_HALT:
+ case SYS_POWER_OFF:
+ case SYS_RESTART:
+ zx2967_wdt_fix_sysdown(wdt);
+ break;
+ default:
+ break;
+ }
+
+ return 0;
+}
+
+static int zx2967_wdt_restart(struct notifier_block *this,
+ unsigned long mode, void *cmd)
+{
+ struct zx2967_wdt *wdt;
+
+ wdt = container_of(this, struct zx2967_wdt, restart_handler);
+
+ zx2967_wdt_stop(&wdt->wdt_device);
+
+ zx2967_wdt_write_reg(0x80, wdt->reg_base + ZX2967_WDT_LOAD_REG);
+ zx2967_wdt_refresh(wdt);
+ zx2967_wdt_write_reg(ZX2967_WDT_START_EN,
+ wdt->reg_base + ZX2967_WDT_START_REG);
+
+ zx2967_wdt_start(&wdt->wdt_device);
+ /* wait for reset*/
+ mdelay(500);
+
+ return NOTIFY_DONE;
+}
+
+static void zx2967_wdt_reset_sysctrl(struct device *dev)
+{
+ int ret;
+ struct device_node *np = NULL;
+ void __iomem *regmap;
+ unsigned int val, mask, config;
+ struct of_phandle_args out_args;
+
+ ret = of_parse_phandle_with_fixed_args(dev->of_node,
+ "wdt-reset-sysctrl", 2, 0, &out_args);
+ if (ret) {
+ dev_info(dev, "have no wdt-reset-sysctrl node");
+ return;
+ }
+ config = out_args.args[0];
+ mask = out_args.args[1];
+
+ regmap = syscon_node_to_regmap(out_args.np);
+ if (IS_ERR(regmap))
+ goto out;
+
+ ret = regmap_read(regmap, ZX2967_RESET_MASK_REG, &val);
+
+ val &= ~mask;
+ val |= config;
+ regmap_write(regmap, ZX2967_RESET_MASK_REG, val);
+out:
+ of_node_put(np);
+}
+
+static int zx2967_wdt_probe(struct platform_device *pdev)
+{
+ struct device *dev;
+ struct zx2967_wdt *wdt;
+ struct resource *base;
+ int err, ret = 0;
+ unsigned int rate;
+
+ struct reset_control *rstc;
+
+ dev = &pdev->dev;
+
+ wdt = devm_kzalloc(dev, sizeof(*wdt), GFP_KERNEL);
+ if (!wdt)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, wdt);
+
+ wdt->dev = dev;
+ wdt->wdt_device.info = &zx2967_wdt_ident;
+ wdt->wdt_device.ops = &zx2967_wdt_ops;
+ wdt->wdt_device.timeout = ZX2967_WDT_DEFAULT_TIMEOUT;
+ wdt->wdt_device.max_timeout = ZX2967_WDT_MAX_TIMEOUT;
+ wdt->wdt_device.min_timeout = ZX2967_WDT_MIN_TIMEOUT;
+ wdt->wdt_device.parent = &pdev->dev;
+
+ base = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ wdt->reg_base = devm_ioremap_resource(dev, base);
+ if (IS_ERR(wdt->reg_base)) {
+ dev_err(dev, "ioremap failed\n");
+ return PTR_ERR(wdt->reg_base);
+ }
+
+ zx2967_wdt_reset_sysctrl(dev);
+
+ wdt->reboot_handler.notifier_call = zx2967_wdt_notify_sys;
+ ret = register_reboot_notifier(&wdt->reboot_handler);
+ wdt->clock = devm_clk_get(dev, "wdtclk");
+ if (IS_ERR(wdt->clock)) {
+ dev_err(dev, "failed to find watchdog clock source\n");
+ return PTR_ERR(wdt->clock);
+ }
+ ret = clk_prepare_enable(wdt->clock);
+ if (ret < 0) {
+ dev_err(dev, "failed to enable clock\n");
+ return ret;
+ }
+
+ rate = clk_get_rate(wdt->clock);
+ if (rate == 24000000)
+ clk_set_rate(wdt->clock, 32768);
+
+ rstc = devm_reset_control_get(dev, "wdtrst");
+ if (!rstc) {
+ dev_err(dev, "rstc get failed");
+ } else {
+ reset_control_assert(rstc);
+ mdelay(10);
+ reset_control_deassert(rstc);
+ }
+
+ watchdog_set_drvdata(&wdt->wdt_device, wdt);
+
+ watchdog_init_timeout(&wdt->wdt_device,
+ ZX2967_WDT_DEFAULT_TIMEOUT, dev);
+ watchdog_set_nowayout(&wdt->wdt_device, WATCHDOG_NOWAYOUT);
+
+ zx2967_wdt_stop(&wdt->wdt_device);
+
+ err = watchdog_register_device(&wdt->wdt_device);
+ if (unlikely(err)) {
+ ret = err;
+ goto fail_register;
+ }
+
+ wdt->restart_handler.notifier_call = zx2967_wdt_restart;
+ wdt->restart_handler.priority = 128;
+ ret = register_restart_handler(&wdt->restart_handler);
+ if (ret) {
+ dev_err(dev, "cannot register restart handler, %d\n", ret);
+ goto fail_restart;
+ }
+
+ dev_info(dev, "watchdog enabled (timeout=%d sec, nowayout=%d)",
+ wdt->wdt_device.timeout, WATCHDOG_NOWAYOUT);
+
+ return 0;
+
+fail_restart:
+ watchdog_unregister_device(&wdt->wdt_device);
+fail_register:
+ clk_disable_unprepare(wdt->clock);
+ return ret;
+}
+
+static int zx2967_wdt_remove(struct platform_device *pdev)
+{
+ struct zx2967_wdt *wdt = platform_get_drvdata(pdev);
+
+ unregister_restart_handler(&wdt->restart_handler);
+ watchdog_unregister_device(&wdt->wdt_device);
+ clk_disable_unprepare(wdt->clock);
+
+ return 0;
+}
+
+static void zx2967_wdt_shutdown(struct platform_device *pdev)
+{
+ struct zx2967_wdt *wdt = platform_get_drvdata(pdev);
+
+ if (!(wdt->flags & ZX2967_WDT_FLAG_REBOOT_MON))
+ zx2967_wdt_stop(&wdt->wdt_device);
+}
+
+static const struct of_device_id zx2967_wdt_match[] = {
+ { .compatible = "zte,zx296718-wdt", },
+ {}
+};
+MODULE_DEVICE_TABLE(of, zx2967_wdt_match);
+
+static struct platform_driver zx2967_wdt_driver = {
+ .probe = zx2967_wdt_probe,
+ .remove = zx2967_wdt_remove,
+ .shutdown = zx2967_wdt_shutdown,
+ .driver = {
+ .name = "zx2967-wdt",
+ .of_match_table = of_match_ptr(zx2967_wdt_match),
+ },
+};
+module_platform_driver(zx2967_wdt_driver);
+
+MODULE_AUTHOR("Baoyou Xie <baoyou.xie@linaro.org>");
+MODULE_DESCRIPTION("ZTE zx2967 Watchdog Device Driver");
+MODULE_LICENSE("GPL v2");
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2 15/18] drivers/fsi: Add documentation for GPIO based FSI master
From: Jeremy Kerr @ 2017-01-19 2:11 UTC (permalink / raw)
To: Rob Herring, christopher.lee.bostic
Cc: mark.rutland, devicetree, benh, geert+renesas, andrew, gregkh,
mturquette, linux, Chris Bostic, linux-kernel, joel, alistair,
linux-arm-kernel
In-Reply-To: <20170118215755.xoamoc2rrzhy4kyz@rob-hp-laptop>
Hi Chris,
>From this:
>> +
>> +The standard FSI master node
>> +----------------------------
>> +This node describes a FSI master implmemented fully in hardware
>> +with dedicated input/output pins required for its function (i.e.
>> +not using generic GPIO pins).
>> +Required property:
>> + compatible = "ibm,fsi-master"
and this:
>> +Example:
>> +
>> +fsi-master {
>> + compatible = "ibm,fsi-master-gpio", "ibm,fsi-master";
>
> From the description, these should be mutually exclusive.
I agree with Rob here. The intention is for "ibm,fsi-master" to be an
abstract master -- simply indicating that this node describes a master,
with no specific implementation, and "ibm,fsi-master-gpio" to be a
GPIO-based implementation. A hardware-based FSI master would have a
different compatible value, based on the hardware.
We should remove references to implementations in the "The standard FSI
master node" section, because this is independent of implementation.
>> + clk-gpios = <&gpio 0>, <&gpio 6>;
>> + data-gpios = <&gpio 1>, <&gpio 7>;
>> + enable-gpios = <&gpio 2>, <&gpio 8>;
>> + trans-gpios = <&gpio 3>, <&gpio 9>;
>> + mux-gpios = <&gpio 4>, <&gpio 10>;
Do we support multiple-link masters? This example implies a 2-link
master.
Cheers,
Jeremy
^ permalink raw reply
* [PATCH 0/2] Add support for RK3288 Tinker board
From: Eddie Cai @ 2017-01-19 2:11 UTC (permalink / raw)
To: robh+dt, mark.rutland, heiko, linux
Cc: devicetree, Eddie Cai, linux-kernel, linux-arm-kernel,
linux-rockchip
This patch set add support for RK3288 Tinker board.
Tinker board is a credit card size develop board powered by RK3288.
Eddie Cai (2):
dt-bindings: add Asus Tinker board
ARM: dts: rockchip: add dts for RK3288-Tinker board
Documentation/devicetree/bindings/arm/rockchip.txt | 3 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/rk3288-tinker.dts | 556 +++++++++++++++++++++
3 files changed, 560 insertions(+)
create mode 100644 arch/arm/boot/dts/rk3288-tinker.dts
--
2.7.4
^ permalink raw reply
* [PATCH 1/2] dt-bindings: add Asus Tinker board
From: Eddie Cai @ 2017-01-19 2:11 UTC (permalink / raw)
To: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
heiko-4mtYJXux2i+zQB+pC5nmwQ, linux-I+IVW8TIWO2tmTQ+vhA3Yw
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Eddie Cai,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1484791919-4665-1-git-send-email-eddie.cai-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
Tinker board is a credit card size develop board designed by Asus.
Powered by RK3288.
Signed-off-by: Eddie Cai <eddie.cai-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
---
Documentation/devicetree/bindings/arm/rockchip.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt b/Documentation/devicetree/bindings/arm/rockchip.txt
index cc4ace6..ce1f04a 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.txt
+++ b/Documentation/devicetree/bindings/arm/rockchip.txt
@@ -1,5 +1,8 @@
Rockchip platforms device tree bindings
---------------------------------------
+- Asus Tinker board
+ Required root node properties:
+ - compatible = "rockchip,rk3288-tinker", "rockchip,rk3288";
- Kylin RK3036 board:
Required root node properties:
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: rockchip: add dts for RK3288-Tinker board
From: Eddie Cai @ 2017-01-19 2:11 UTC (permalink / raw)
To: robh+dt, mark.rutland, heiko, linux
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
Eddie Cai
In-Reply-To: <1484791919-4665-1-git-send-email-eddie.cai@rock-chips.com>
This patch add basic support for RK3288-Tinker board. We can boot in to rootfs
with this patch.
Signed-off-by: Eddie Cai <eddie.cai@rock-chips.com>
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/rk3288-tinker.dts | 556 ++++++++++++++++++++++++++++++++++++
2 files changed, 557 insertions(+)
create mode 100644 arch/arm/boot/dts/rk3288-tinker.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7327250..4fc05b7 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -679,6 +679,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3288-popmetal.dtb \
rk3288-r89.dtb \
rk3288-rock2-square.dtb \
+ rk3288-tinker.dtb \
rk3288-veyron-brain.dtb \
rk3288-veyron-jaq.dtb \
rk3288-veyron-jerry.dtb \
diff --git a/arch/arm/boot/dts/rk3288-tinker.dts b/arch/arm/boot/dts/rk3288-tinker.dts
new file mode 100644
index 0000000..37cb431
--- /dev/null
+++ b/arch/arm/boot/dts/rk3288-tinker.dts
@@ -0,0 +1,556 @@
+/*
+ * Copyright (c) 2017 Fuzhou Rockchip Electronics Co., Ltd.
+ *
+ * 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.
+ *
+ * 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 "rk3288.dtsi"
+
+/ {
+ model = "Rockchip RK3288 Tinker Board";
+ compatible = "rockchip,rk3288-tinker", "rockchip,rk3288";
+
+ memory {
+ reg = <0x0 0x80000000>;
+ device_type = "memory";
+ };
+
+ ext_gmac: external-gmac-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <125000000>;
+ clock-output-names = "ext_gmac";
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ autorepeat;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwrbtn>;
+
+ button@0 {
+ gpios = <&gpio0 5 GPIO_ACTIVE_LOW>;
+ linux,code = <116>;
+ label = "GPIO Key Power";
+ linux,input-type = <1>;
+ gpio-key,wakeup = <1>;
+ debounce-interval = <100>;
+ };
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+
+ pwr-led {
+ gpios = <&gpio2 2 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-on";
+ };
+
+ act-led {
+ gpios=<&gpio2 3 GPIO_ACTIVE_LOW>;
+ linux,default-trigger="mmc0";
+ };
+ };
+
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,name = "rockchip,tinker-codec";
+ simple-audio-card,mclk-fs = <512>;
+ simple-audio-card,cpu {
+ sound-dai = <&i2s>;
+ };
+ simple-audio-card,codec {
+ sound-dai = <&hdmi>;
+ };
+ };
+
+ vcc_sys: vsys-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_sys";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ /*
+ * NOTE: vcc_sd isn't hooked up on v1.0 boards where power comes from
+ * vcc_io directly. Those boards won't be able to power cycle SD cards
+ * but it shouldn't hurt to toggle this pin there anyway.
+ */
+ vcc_sd: sdmmc-regulator {
+ compatible = "regulator-fixed";
+ gpio = <&gpio7 11 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc_pwr>;
+ regulator-name = "vcc_sd";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ startup-delay-us = <100000>;
+ vin-supply = <&vcc_io>;
+ };
+};
+
+&cpu0 {
+ cpu0-supply = <&vdd_cpu>;
+};
+
+&gmac {
+ phy-supply = <&vcc33_lan>;
+ phy-mode = "rgmii";
+ clock_in_out = "input";
+ snps,reset-gpio = <&gpio4 7 0>;
+ snps,reset-active-low;
+ snps,reset-delays-us = <0 10000 1000000>;
+ assigned-clocks = <&cru SCLK_MAC>;
+ assigned-clock-parents = <&ext_gmac>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmii_pins>;
+ tx_delay = <0x30>;
+ rx_delay = <0x10>;
+ status = "ok";
+};
+
+&hdmi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #sound-dai-cells = <0>;
+ ddc-i2c-bus = <&i2c5>;
+ status = "okay";
+ /* Don't use vopl for HDMI */
+ ports {
+ hdmi_in: port {
+ /delete-node/ endpoint@1;
+ };
+ };
+};
+
+&i2c0 {
+ status = "okay";
+ clock-frequency = <400000>;
+
+ rk808: pmic@1b {
+ compatible = "rockchip,rk808";
+ reg = <0x1b>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_int &global_pwroff &dvs_1 &dvs_2>;
+ dvs-gpios = <&gpio0 11 GPIO_ACTIVE_HIGH>,
+ <&gpio0 12 GPIO_ACTIVE_HIGH>;
+
+ rockchip,system-power-controller;
+ wakeup-source;
+ #clock-cells = <1>;
+ clock-output-names = "xin32k", "rk808-clkout2";
+
+ vcc1-supply = <&vcc_sys>;
+ vcc2-supply = <&vcc_sys>;
+ vcc3-supply = <&vcc_sys>;
+ vcc4-supply = <&vcc_sys>;
+ vcc6-supply = <&vcc_sys>;
+ vcc7-supply = <&vcc_sys>;
+ vcc8-supply = <&vcc_18>;
+ vcc9-supply = <&vcc_io>;
+ vcc10-supply = <&vcc_io>;
+ vcc11-supply = <&vcc_sys>;
+ vcc12-supply = <&vcc_io>;
+ vddio-supply = <&vcc18_ldo1>;
+
+ regulators {
+ vdd_cpu: DCDC_REG1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <750000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-name = "vdd_arm";
+ regulator-ramp-delay = <6000>;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_gpu: DCDC_REG2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <1250000>;
+ regulator-name = "vdd_gpu";
+ regulator-ramp-delay = <6000>;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1000000>;
+ };
+ };
+
+ vcc_ddr: DCDC_REG3 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-name = "vcc_ddr";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ vcc_io: DCDC_REG4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc_io";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3300000>;
+ };
+ };
+
+ vcc18_ldo1: LDO_REG1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc18_ldo1";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vcc33_mipi: LDO_REG2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vcc33_mipi";
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_10: LDO_REG3 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-name = "vdd_10";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1000000>;
+ };
+ };
+
+ vcc18_codec: LDO_REG4 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc18_codec";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vccio_sd: LDO_REG5 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "vccio_sd";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <3300000>;
+ };
+ };
+
+ vdd10_lcd: LDO_REG6 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-name = "vdd10_lcd";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1000000>;
+ };
+ };
+
+ vcc_18: LDO_REG7 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc_18";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vcc18_lcd: LDO_REG8 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "vcc18_lcd";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1800000>;
+ };
+ };
+
+ vcc33_sd: SWITCH_REG1 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-name = "vcc33_sd";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ vcc33_lan: SWITCH_REG2 {
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-name = "vcc33_lan";
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+ };
+ };
+};
+
+&i2c2 {
+ status = "okay";
+};
+
+&i2c5 {
+ status = "okay";
+};
+
+&i2s {
+ #sound-dai-cells = <0>;
+ status = "okay";
+};
+
+&io_domains {
+ status = "okay";
+
+ sdcard-supply = <&vccio_sd>;
+};
+
+&pinctrl {
+ pcfg_pull_none_drv_8ma: pcfg-pull-none-drv-8ma {
+ drive-strength = <8>;
+ };
+
+ pcfg_pull_up_drv_8ma: pcfg-pull-up-drv-8ma {
+ bias-pull-up;
+ drive-strength = <8>;
+ };
+
+ backlight {
+ bl_en: bl-en {
+ rockchip,pins = <7 2 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ buttons {
+ pwrbtn: pwrbtn {
+ rockchip,pins = <0 5 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+
+ eth_phy {
+ eth_phy_pwr: eth-phy-pwr {
+ rockchip,pins = <0 6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ pmic {
+ pmic_int: pmic-int {
+ rockchip,pins = <RK_GPIO0 4 RK_FUNC_GPIO \
+ &pcfg_pull_up>;
+ };
+
+ dvs_1: dvs-1 {
+ rockchip,pins = <RK_GPIO0 11 RK_FUNC_GPIO \
+ &pcfg_pull_down>;
+ };
+
+ dvs_2: dvs-2 {
+ rockchip,pins = <RK_GPIO0 12 RK_FUNC_GPIO \
+ &pcfg_pull_down>;
+ };
+ };
+
+ sdmmc {
+ /*
+ * Default drive strength isn't enough to achieve even
+ * high-speed mode on EVB board so bump up to 8ma.
+ */
+ sdmmc_bus4: sdmmc-bus4 {
+ rockchip,pins = <6 16 RK_FUNC_1 &pcfg_pull_up_drv_8ma>,
+ <6 17 RK_FUNC_1 &pcfg_pull_up_drv_8ma>,
+ <6 18 RK_FUNC_1 &pcfg_pull_up_drv_8ma>,
+ <6 19 RK_FUNC_1 &pcfg_pull_up_drv_8ma>;
+ };
+
+ sdmmc_clk: sdmmc-clk {
+ rockchip,pins = <6 20 RK_FUNC_1 \
+ &pcfg_pull_none_drv_8ma>;
+ };
+
+ sdmmc_cmd: sdmmc-cmd {
+ rockchip,pins = <6 21 RK_FUNC_1 &pcfg_pull_up_drv_8ma>;
+ };
+
+ sdmmc_pwr: sdmmc-pwr {
+ rockchip,pins = <7 11 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ usb {
+ host_vbus_drv: host-vbus-drv {
+ rockchip,pins = <0 14 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ pwr_3g: pwr-3g {
+ rockchip,pins = <7 8 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+};
+
+&pwm0 {
+ status = "okay";
+};
+
+&saradc {
+ vref-supply = <&vcc18_ldo1>;
+ status ="okay";
+};
+
+&sdmmc {
+ bus-width = <4>;
+ cap-mmc-highspeed;
+ cap-sd-highspeed;
+ card-detect-delay = <200>;
+ disable-wp; /* wp not hooked up */
+ num-slots = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc_clk &sdmmc_cmd &sdmmc_cd &sdmmc_bus4>;
+ status = "okay";
+ supports-sd;
+ vmmc-supply = <&vcc_sd>;
+ vqmmc-supply = <&vccio_sd>;
+};
+
+&tsadc {
+ rockchip,hw-tshut-mode = <1>; /* tshut mode 0:CRU 1:GPIO */
+ rockchip,hw-tshut-polarity = <1>; /* tshut polarity 0:LOW 1:HIGH */
+ status = "okay";
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&uart1 {
+ status = "okay";
+};
+
+&uart2 {
+ status = "okay";
+};
+
+&uart3 {
+ status = "okay";
+};
+
+&uart4 {
+ status = "okay";
+};
+
+&usbphy {
+ status = "okay";
+};
+
+&usb_host0_ehci {
+ no-relinquish-port;
+ status = "okay";
+};
+
+&usb_host1 {
+ status = "okay";
+};
+
+&usb_otg {
+ status= "okay";
+};
+
+&vopb {
+ status = "okay";
+};
+
+&vopb_mmu {
+ status = "okay";
+};
+
+&vopl {
+ status = "okay";
+ /* Don't use vopl for HDMI */
+ vopl_out: port {
+ /delete-node/ endpoint@0;
+ };
+};
+
+&vopl_mmu {
+ status = "okay";
+};
+
+&wdt {
+ status = "okay";
+};
+
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v1 2/2] arm: dts: mt2701: add nor flash node
From: Rob Herring @ 2017-01-19 2:51 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Boris Brezillon, Marek Vasut, Mark Rutland,
devicetree@vger.kernel.org, Guochun Mao, Richard Weinberger,
Russell King, linux-kernel@vger.kernel.org,
linux-mtd@lists.infradead.org, Matthias Brugger, linux-mediatek,
Cyrille Pitchen, Brian Norris, David Woodhouse,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20170119103829.524ce715@free-electrons.com>
On Wed, Jan 18, 2017 at 5:38 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Wed, 18 Jan 2017 16:20:10 -0600, Rob Herring wrote:
>
>> > > Rob, Mark, any opinion?
>> >
>>
>> Sigh, is how to do compatibles really not yet understood?
>
> Well, it seems like not everyone necessarily understands what is the
> best strategy to adopt (me included).
>
>> > I agree that a clarification would be good. There are really two
>> > options:
>> >
>> > 1. Have two compatible strings in the DT, the one that matches the
>> > exact SoC where the IP is found (first compatible string) and the
>> > one that matches some other SoC where the same IP is found (second
>> > compatible string). Originally, Linux only supports the second
>> > compatible string in its device driver, but if it happens that a
>> > difference is found between two IPs that we thought were the same,
>> > we can add support for the first compatible string in the driver,
>> > with a slightly different behavior.
>>
>> This. And no wildcards in the compatible string.
>
> OK. So it means that today we do something like:
>
> compatible = "baz,foo-12", "baz,foo-00";
>
> and support only baz,foo-00 in the driver. If tomorrow we discover
> that there is in fact a difference between the two IP blocks, we can
> add support for baz,foo-12 in the driver, and handle the differences.
>
> But then, the DT still contains:
>
> compatible = "baz,foo-12", "baz,foo-00";
>
> and therefore pretends that the IP block is compatible with
> "baz,foo-00" which is in fact *not* the case. It was a mistake to
> consider it as compatible. So we keep living with a DT that has
> incorrect information.
I wouldn't say it's a mistake necessarily. The old compatible would
probably work to some extent. I'd assume it was tested to some level.
Or it could be other changes exposing a difference.
>> > 2. Have a single compatible string in the DT, matching the exact SoC
>> > where the IP is found. This involves adding immediately this
>> > compatible string in the corresponding driver.
>>
>> I wouldn't object to this from a DT perspective as I have no clue
>> generally if IP blocks are "the same" or not. Subsystem maintainers will
>> object though.
>
> Knowing if IP blocks are "the same" is in fact not necessarily trivial.
> What appears to be identical IP blocks today might be discovered later
> as actually having subtle differences (sometimes not even visible in
> the datasheet).
Yes, I know. That's exactly when you should have multiple compatibles.
Trying to guarantee things are the same is just going to get you in
trouble. You only need to figure out if blocks are obviously different
and only drop the old compatible in that case.
>> > I've not really been able to figure out which of the two options is the
>> > most future-proof/appropriate.
>>
>> They are both future-proof. #2 has the disadvantage of requiring a
>> kernel update for a new SoC.
>
> Which is generally anyway needed because a new SoC will almost always
> require some new drivers, adjusting pin-muxing or clock drivers, etc.
Yes, but you don't want to have to update every single driver.
Rob
^ permalink raw reply
* Re: [PATCH v3 2/3] Documentation: devicetree: Add document bindings for mtk-cir
From: Sean Wang @ 2017-01-19 3:00 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree@vger.kernel.org, Ivaylo Dimitrov,
sean wang, Sean Young, Mauro Carvalho Chehab,
linux-kernel@vger.kernel.org, Andi Shyti, Hans Verkuil,
Hans de Goede, linux-mediatek, Matthias Brugger,
linux-media@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Heiner Kallweit
In-Reply-To: <CAL_JsqKsxwY+v-8Q=o1ERpyfFkR7d+83kKUdfY=u21FHUX5UEw@mail.gmail.com>
On Wed, 2017-01-18 at 16:42 -0600, Rob Herring wrote:
> On Wed, Jan 18, 2017 at 4:23 PM, Rob Herring <robh@kernel.org> wrote:
> > On Fri, Jan 13, 2017 at 03:35:38PM +0800, sean.wang@mediatek.com wrote:
> >> From: Sean Wang <sean.wang@mediatek.com>
> >>
> >> This patch adds documentation for devicetree bindings for
> >> consumer Mediatek IR controller.
> >>
> >> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> >> ---
> >> .../devicetree/bindings/media/mtk-cir.txt | 24 ++++++++++++++++++++++
> >> 1 file changed, 24 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/media/mtk-cir.txt
> >
> > Acked-by: Rob Herring <robh@kernel.org>
>
> I guess I rescind my ack if this email doesn't work:
>
> "The response from the remote server was:
>
> 550 Relaying mail to sean.wang@mediatek.com is not allowed"
sorry for causing you inconvenience.
it should be able to work because i almost use this daily
maybe that's just a sudden problem from internal server (?)
but if the problem still continues, please let me know and
i will try to fix this.
^ permalink raw reply
* Re: [PATCH v4 1/2] mailbox: Add driver for Broadcom FlexRM ring manager
From: Anup Patel @ 2017-01-19 3:15 UTC (permalink / raw)
To: Jassi Brar, Rob Herring
Cc: Mark Rutland, Device Tree, Anup Patel, Scott Branden, Ray Jui,
Linux Kernel, Pramod KUMAR, BCM Kernel Feedback, Rob Rice,
Linux ARM Kernel
In-Reply-To: <1483614475-3442-2-git-send-email-anup.patel@broadcom.com>
Hi All,
Any comments on this patch ??
Regards,
Anup
^ permalink raw reply
* Re: [PATCH v11 11/12] drm/mediatek: update DSI sub driver flow for sending commands to panel
From: CK Hu @ 2017-01-19 3:20 UTC (permalink / raw)
To: YT Shen
Cc: Mark Rutland, devicetree, srv_heupstream, emil.l.velikov,
linux-kernel, dri-devel, Rob Herring, linux-mediatek,
Matthias Brugger, yingjoe.chen, shaoming chen, linux-arm-kernel
In-Reply-To: <1484117473-46644-12-git-send-email-yt.shen@mediatek.com>
Hi, YT:
one comment inline.
On Wed, 2017-01-11 at 14:51 +0800, YT Shen wrote:
> This patch update enable/disable flow of DSI module.
> Original flow works on there is a bridge chip: DSI -> bridge -> panel.
> In this case: DSI -> panel, the DSI sub driver flow should be updated.
> We need to initialize DSI first so that we can send commands to panel.
>
> Signed-off-by: shaoming chen <shaoming.chen@mediatek.com>
> Signed-off-by: YT Shen <yt.shen@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 89 +++++++++++++++++++++++++++++++-------
> 1 file changed, 74 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
> index 85f22d2..21392c4 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dsi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
> @@ -126,6 +126,10 @@
> #define CLK_HS_POST (0xff << 8)
> #define CLK_HS_EXIT (0xff << 16)
>
> +#define DSI_VM_CMD_CON 0x130
> +#define VM_CMD_EN BIT(0)
> +#define TS_VFP_EN BIT(5)
> +
> #define DSI_CMDQ0 0x180
> #define CONFIG (0xff << 0)
> #define SHORT_PACKET 0
> @@ -365,16 +369,23 @@ static void mtk_dsi_set_mode(struct mtk_dsi *dsi)
> u32 vid_mode = CMD_MODE;
>
> if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO) {
> - vid_mode = SYNC_PULSE_MODE;
> -
> - if ((dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) &&
> - !(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE))
> + if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
> vid_mode = BURST_MODE;
> + else if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
> + vid_mode = SYNC_PULSE_MODE;
> + else
> + vid_mode = SYNC_EVENT_MODE;
> }
>
> writel(vid_mode, dsi->regs + DSI_MODE_CTRL);
> }
>
> +static void mtk_dsi_set_vm_cmd(struct mtk_dsi *dsi)
> +{
> + mtk_dsi_mask(dsi, DSI_VM_CMD_CON, VM_CMD_EN, VM_CMD_EN);
> + mtk_dsi_mask(dsi, DSI_VM_CMD_CON, TS_VFP_EN, TS_VFP_EN);
> +}
> +
> static void mtk_dsi_ps_control_vact(struct mtk_dsi *dsi)
> {
> struct videomode *vm = &dsi->vm;
> @@ -512,6 +523,16 @@ static void mtk_dsi_start(struct mtk_dsi *dsi)
> writel(1, dsi->regs + DSI_START);
> }
>
> +static void mtk_dsi_stop(struct mtk_dsi *dsi)
> +{
> + writel(0, dsi->regs + DSI_START);
> +}
> +
> +static void mtk_dsi_set_cmd_mode(struct mtk_dsi *dsi)
> +{
> + writel(CMD_MODE, dsi->regs + DSI_MODE_CTRL);
> +}
> +
> static void mtk_dsi_set_interrupt_enable(struct mtk_dsi *dsi)
> {
> u32 inten = LPRX_RD_RDY_INT_FLAG | CMD_DONE_INT_FLAG | VM_DONE_INT_FLAG;
> @@ -570,6 +591,19 @@ static irqreturn_t mtk_dsi_irq(int irq, void *dev_id)
> return IRQ_HANDLED;
> }
>
> +static s32 mtk_dsi_switch_to_cmd_mode(struct mtk_dsi *dsi, u8 irq_flag, u32 t)
> +{
> + mtk_dsi_irq_data_clear(dsi, irq_flag);
> + mtk_dsi_set_cmd_mode(dsi);
> +
> + if (!mtk_dsi_wait_for_irq_done(dsi, irq_flag, t)) {
> + DRM_ERROR("failed to switch cmd mode\n");
> + return -ETIME;
> + } else {
> + return 0;
> + }
> +}
> +
> static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
> {
> if (WARN_ON(dsi->refcount == 0))
> @@ -578,6 +612,17 @@ static void mtk_dsi_poweroff(struct mtk_dsi *dsi)
> if (--dsi->refcount != 0)
> return;
>
> + mtk_dsi_stop(dsi);
> + if (!mtk_dsi_switch_to_cmd_mode(dsi, VM_DONE_INT_FLAG, 500)) {
> + if (dsi->panel) {
> + if (drm_panel_unprepare(dsi->panel)) {
Why drm_panel_unprepare() in mtk_dsi_poweroff() but drm_panel_prepare()
in mtk_output_dsi_enable()? This asymmetric design would easily cause
some bugs.
Regards,
CK
> + DRM_ERROR("failed to unprepare the panel\n");
> + return;
> + }
> + }
> + }
> +
> + mtk_dsi_reset_engine(dsi);
> mtk_dsi_lane0_ulp_mode_enter(dsi);
> mtk_dsi_clk_ulp_mode_enter(dsi);
>
> @@ -596,13 +641,6 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
> if (dsi->enabled)
> return;
>
> - if (dsi->panel) {
> - if (drm_panel_prepare(dsi->panel)) {
> - DRM_ERROR("failed to setup the panel\n");
> - return;
> - }
> - }
> -
> ret = mtk_dsi_poweron(dsi);
> if (ret < 0) {
> DRM_ERROR("failed to power on dsi\n");
> @@ -610,22 +648,43 @@ static void mtk_output_dsi_enable(struct mtk_dsi *dsi)
> }
>
> mtk_dsi_rxtx_control(dsi);
> + mtk_dsi_ps_control_vact(dsi);
> + mtk_dsi_set_vm_cmd(dsi);
> + mtk_dsi_config_vdo_timing(dsi);
> + mtk_dsi_set_interrupt_enable(dsi);
>
> mtk_dsi_clk_ulp_mode_leave(dsi);
> mtk_dsi_lane0_ulp_mode_leave(dsi);
> mtk_dsi_clk_hs_mode(dsi, 0);
> - mtk_dsi_set_mode(dsi);
>
> - mtk_dsi_ps_control_vact(dsi);
> - mtk_dsi_config_vdo_timing(dsi);
> - mtk_dsi_set_interrupt_enable(dsi);
> + if (dsi->panel) {
> + if (drm_panel_prepare(dsi->panel)) {
> + DRM_ERROR("failed to prepare the panel\n");
> + goto err_dsi_power_off;
> + }
> + }
>
> mtk_dsi_set_mode(dsi);
> mtk_dsi_clk_hs_mode(dsi, 1);
>
> mtk_dsi_start(dsi);
>
> + if (dsi->panel) {
> + if (drm_panel_enable(dsi->panel)) {
> + DRM_ERROR("failed to enable the panel\n");
> + goto err_panel_disable;
> + }
> + }
> +
> dsi->enabled = true;
> +
> + return;
> +err_panel_disable:
> + mtk_dsi_stop(dsi);
> + if (dsi->panel)
> + drm_panel_unprepare(dsi->panel);
> +err_dsi_power_off:
> + mtk_dsi_poweroff(dsi);
> }
>
> static void mtk_output_dsi_disable(struct mtk_dsi *dsi)
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCHv4 2/5] arm: mvebu: support for SMP on 98DX3336 SoC
From: Chris Packham @ 2017-01-19 3:23 UTC (permalink / raw)
To: Stephen Boyd
Cc: Mark Rutland, Andrew Lunn, Florian Fainelli, Jayachandran C,
Jason Cooper, Geert Uytterhoeven, devicetree@vger.kernel.org,
Russell King, Juri Lelli, linux-kernel@vger.kernel.org,
Rob Herring, Chris Brand, Sudeep Holla, Gregory Clement,
linux-arm-kernel@lists.infradead.org, Sebastian Hesselbarth
In-Reply-To: <20170119004750.GC4857@codeaurora.org>
On 19/01/17 13:48, Stephen Boyd wrote:
> On 01/13, Chris Packham wrote:
>> diff --git a/arch/arm/mach-mvebu/platsmp.c b/arch/arm/mach-mvebu/platsmp.c
>> index 46c742d3bd41..59be3ca0464f 100644
>> --- a/arch/arm/mach-mvebu/platsmp.c
>> +++ b/arch/arm/mach-mvebu/platsmp.c
>> @@ -184,3 +184,89 @@ const struct smp_operations armada_xp_smp_ops __initconst = {
>>
>> CPU_METHOD_OF_DECLARE(armada_xp_smp, "marvell,armada-xp-smp",
>> &armada_xp_smp_ops);
>> +
>> +struct resume_controller {
>> + u32 resume_control;
>> + u32 resume_boot_addr;
>> +};
>> +
>> +static const struct resume_controller mv98dx3336_resume_controller = {
>> + .resume_control = 0x08,
>> + .resume_boot_addr = 0x04,
>> +};
>> +
>> +static const struct of_device_id of_mv98dx3236_resume_table[] = {
>> + {
>> + .compatible = "marvell,98dx3336-resume-ctrl",
>> + .data = (void *)&mv98dx3336_resume_controller,
>
> Useless cast?
>
>> + },
>> + { /* end of list */ },
>> +};
>> +
>> +static int mv98dx3236_resume_set_cpu_boot_addr(int hw_cpu, void *boot_addr)
>> +{
>> + const struct of_device_id *match;
>> + struct device_node *np;
>> + void __iomem *base;
>> + struct resume_controller *rc;
>> +
>> + WARN_ON(hw_cpu != 1);
>> +
>> + np = of_find_matching_node_and_match(NULL, of_mv98dx3236_resume_table,
>> + &match);
>> + if (!np)
>> + return -ENODEV;
>> +
>> + base = of_io_request_and_map(np, 0, of_node_full_name(np));
>> + rc = (struct resume_controller *)match->data;
>
> Useless cast?
>
>> + of_node_put(np);
>> + if (IS_ERR(base))
>> + return PTR_ERR(base);
>> +
>> + writel(0, base + rc->resume_control);
>> + writel(virt_to_phys(boot_addr), base + rc->resume_boot_addr);
>> +
>
> Otherwise
>
> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
>
Thanks for the review. Changes will be in v5.
^ permalink raw reply
* Re: [PATCHv4 1/5] clk: mvebu: support for 98DX3236 SoC
From: Chris Packham @ 2017-01-19 3:24 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree@vger.kernel.org, Michael Turquette,
Stephen Boyd, linux-kernel@vger.kernel.org,
linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20170118222508.prn5xk63nuc3ocr7@rob-hp-laptop>
On 19/01/17 11:25, Rob Herring wrote:
> On Fri, Jan 13, 2017 at 10:12:16PM +1300, Chris Packham wrote:
>> The 98DX3236, 98DX3336, 98DX4521 and variants have a different TCLK from
>> the Armada XP (200MHz vs 250MHz). The CPU core clock is fixed at 800MHz.
>>
>> The clock gating options are a subset of those on the Armada XP.
>>
>> The core clock divider is different to the Armada XP also.
>>
>> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
>> ---
>>
>> Notes:
>> Changes in v2:
>> - Update devicetree binding documentation for new compatible string
>> Changes in v3:
>> - Add 98dx3236 support to mvebu/clk-corediv.c rather than creating a new
>> driver.
>> - Document mv98dx3236-corediv-clock binding
>> Changes in v4:
>> - None
>>
>> .../bindings/clock/mvebu-corediv-clock.txt | 1 +
>> .../devicetree/bindings/clock/mvebu-cpu-clock.txt | 1 +
>
> Please add acks when posting new versions.
>
> Acked-by: Rob Herring <robh@kernel.org>
>
Thanks Rob. I must have missed the earlier ack. Will be in v5.
^ permalink raw reply
* [PATCH] arm64: dts: msm8996: Add ADSP PIL node
From: Sarangdhar Joshi @ 2017-01-19 3:31 UTC (permalink / raw)
To: Andy Gross, David Brown, Rob Herring, Mark Rutland,
Catalin Marinas, Will Deacon, Bjorn Andersson
Cc: Trilok Soni, devicetree, linux-arm-msm, Stephen Boyd,
linux-kernel, linux-soc, linux-arm-kernel
Add ADSP node required for Qualcomm ADSP Peripheral Image Loader.
Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
---
This patch uses "xo_board" clock for now. We would have to move to
rpmcc once it is available.
arch/arm64/boot/dts/qcom/msm8996.dtsi | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index c9c7fd7..7cebf63 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -181,6 +181,26 @@
method = "smc";
};
+ adsp-pil {
+ compatible = "qcom,msm8996-adsp-pil";
+
+ interrupts-extended = <&intc 0 162 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+ <&adsp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>;
+ interrupt-names = "wdog", "fatal", "ready",
+ "handover", "stop-ack";
+
+ clocks = <&xo_board>;
+ clock-names = "xo";
+
+ memory-region = <&adsp_region>;
+
+ qcom,smem-states = <&adsp_smp2p_out 0>;
+ qcom,smem-state-names = "stop";
+ };
+
adsp-smp2p {
compatible = "qcom,smp2p";
qcom,smem = <443>, <429>;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* Re: [PATCH v5] ARM64: dts: meson-gx: Add firmware reserved memory zones
From: Kevin Hilman @ 2017-01-19 4:36 UTC (permalink / raw)
To: Andreas Färber
Cc: Neil Armstrong, xypron.glpk-Mmb7MZpHnFY,
carlo-KA+7E9HrN00dnm+yROfE0A,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <eca803d3-1a67-cda5-554d-4313ae56635e-l3A5Bk7waGM@public.gmane.org>
Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org> writes:
> Am 19.01.2017 um 01:20 schrieb Andreas Färber:
>> Hi,
>>
>> Am 18.01.2017 um 17:50 schrieb Neil Armstrong:
>>> The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
>>> this patch adds these reserved zones.
>>>
>>> Without such reserved memory zones, running the following stress command :
>>> $ stress-ng --vm 16 --vm-bytes 128M --timeout 10s
>>> multiple times:
>>>
>>> Could lead to the following kernel crashes :
>>> [ 46.937975] Bad mode in Error handler detected on CPU1, code 0xbf000000 -- SError
>>> ...
>>> [ 47.058536] Internal error: Attempting to execute userspace memory: 8600000f [#3] PREEMPT SMP
>>> ...
>>> Instead of the OOM killer.
>>>
>>
>> I miss a Fixes: or Cc: here for the backport you desired. To have it
>> fixed back to my very introduction:
>>
>> Fixes: 4f24eda8401f ("ARM64: dts: Prepare configs for Amlogic Meson GXBaby")
>>
>> People backporting it would need to handle the meson-{gx => gxbb}.dtsi
>> transition for 4.9 down to 4.6, which seems fairly straightforward.
>>
>>> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>>> ---
>>> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 18 ++++++++++++++++++
>>> 1 file changed, 18 insertions(+)
>>>
>>> Changes since v4 at [5]:
>>> - Move start of ddr memory to reserved-memory node
>>> - Drop memory node move
>>> - Fix typo in sizes
>>>
>>> Changes since resent v2 at [4]:
>>> - Fix invalid comment of useable memory attributes
>>>
>>> Changes since original v2 at [3]:
>>> - Typo in commit 2GiB -> 1GiB, 4GiB -> 2GiB
>>>
>>> Changes since v2 at [2]:
>>> - Moved all memory node out of dtsi
>>> - Added comment about useable memory
>>> - Fixed comment about secmon reserved zone
>>>
>>> Changes since v1 at [1] :
>>> - Renamed reg into linux,usable-memory to ovveride u-boot memory
>>> - only kept secmon memory zone
>>>
>>> [1] http://lkml.kernel.org/r/20161212101801.28491-1-narmstrong@baylibre.com
>>> [2] http://lkml.kernel.org/r/1483105232-6242-1-git-send-email-narmstrong@baylibre.com
>>> [3] http://lkml.kernel.org/r/1484128128-22454-1-git-send-email-narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org
>>> [4] http://lkml.kernel.org/r/1484128540-22662-1-git-send-email-narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org
>>> [5] http://lkml.kernel.org/r/1484129414-23325-1-git-send-email-narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org
>>>
>>> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>>> index eada0b5..63d52b7 100644
>>> --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>>> +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
>>> @@ -55,6 +55,24 @@
>>> #address-cells = <2>;
>>> #size-cells = <2>;
>>>
>>> + reserved-memory {
>>> + #address-cells = <2>;
>>> + #size-cells = <2>;
>>> + ranges;
>>> +
>>> + /* 16 MiB reserved for Hardware ROM Firmware */
>>> + hwrom: hwrom {
>>
>> Both sub-nodes get a label that is unused, but reserved-memory itself
>> does not (my v4 remark). Intentional?
>>
>>> + reg = <0x0 0x0 0x0 0x1000000>;
>>> + no-map;
>>> + };
>>> +
>>> + /* 2 MiB reserved for ARM Trusted Firmware (BL31) */
>>> + secmon: secmon {
>>
>> I note that this .dtsi further down has a node /firmware/secure-monitor
>> with label sm.
>> a) Is there any naming convention such as secmon_mem to adopt here to
>> avoid mixups with sm?
>> b) Should this secmon node be referenced in the secure-monitor node via
>> memory-node = <&secmon>; to model their connection, thereby giving the
>> label a use? Or should we maybe merge the two nodes by moving the
>> compatible string here?
>>
>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
>
> Answering my own question: the example labels use _reserved suffix.
>
>>> + reg = <0x0 0x10000000 0x0 0x200000>;
>
> And since we use a reg property here, the node name should get a unit
> address to avoid future dtc warnings/errors. Ditto for hwrom.
OK, I added Fixes:, your Reviewed-by, added the _reserved suffix and
unit address and applied to v4.10/fixes.
Update patch below for reference.
Other cleanups/fixups (like adding a phandle from secure monitor) can be
done as add-ons, as they are not strictly related to this fix.
Kevin
>From ecb88f3001ed9ee8c53450d971de8c18bcbf7925 Mon Sep 17 00:00:00 2001
From: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Date: Wed, 18 Jan 2017 17:50:45 +0100
Subject: [PATCH] ARM64: dts: meson-gx: Add firmware reserved memory zones
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The Amlogic Meson GXBB/GXL/GXM secure monitor uses part of the memory space,
this patch adds these reserved zones.
Without such reserved memory zones, running the following stress command :
$ stress-ng --vm 16 --vm-bytes 128M --timeout 10s
multiple times:
Could lead to the following kernel crashes :
[ 46.937975] Bad mode in Error handler detected on CPU1, code 0xbf000000 -- SError
...
[ 47.058536] Internal error: Attempting to execute userspace memory: 8600000f [#3] PREEMPT SMP
...
Instead of the OOM killer.
Fixes: 4f24eda8401f ("ARM64: dts: Prepare configs for Amlogic Meson GXBaby")
Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Reviewed-by: Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>
[khilman: added Fixes tag, added _reserved and unit addresses]
Signed-off-by: Kevin Hilman <khilman-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
---
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index eada0b58ba1c..0cbe24b49710 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -55,6 +55,24 @@
#address-cells = <2>;
#size-cells = <2>;
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ /* 16 MiB reserved for Hardware ROM Firmware */
+ hwrom_reserved: hwrom@0 {
+ reg = <0x0 0x0 0x0 0x1000000>;
+ no-map;
+ };
+
+ /* 2 MiB reserved for ARM Trusted Firmware (BL31) */
+ secmon_reserved: secmon@10000000 {
+ reg = <0x0 0x10000000 0x0 0x200000>;
+ no-map;
+ };
+ };
+
cpus {
#address-cells = <0x2>;
#size-cells = <0x0>;
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox