* Re: [PATCH 0/5] Support for LEGO MINDSTORTMS EV3
From: Lennart Sorensen @ 2016-10-21 18:45 UTC (permalink / raw)
To: David Lechner
Cc: Kevin Hilman, Sekhar Nori, Rob Herring, Mark Rutland,
Russell King, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <1477075018-20176-1-git-send-email-david@lechnology.com>
On Fri, Oct 21, 2016 at 01:36:52PM -0500, David Lechner wrote:
> This patch series adds support for LEGO MINDSTORTMS EV3[1]. This is a TI AM1808
> based board.
>
> This patch series has been tested working (along with some hacks to fix the
> GPIOs) on an EV3.
>
> There are still quite a few additional new drivers that need to be submitted
> to get everything working. This patch series just adds support for the parts
> that already have mainline kernel drivers.
>
> I have a plan/driver in progress for many of the components[2], but I could use
> some advice on a few particulars.
>
> Bluetooth: This needs a driver to sequence a GPIO to take the Bluetooth chip
> out of shutdown *after* the Bluetooth clock has been configured and started.
> Is there a generic driver that can do this sort of thing? Or, if not, which
> subsystem should the new driver go in?
>
> Input and output ports: These ports are capable of hotplugging various devices,
> such as sensors and motors. I have written a driver for these that can detect
> most devices. I created a new subsystem for this called `lego-port`. However,
> I am wondering if the existing phy or extcon subsystems might be a good fit for
> this sort of thing.
Both this cover and patch 5/5 has MINDSTORTMS instead of MINDSTORMS in
a few places (including the subject line).
--
Len Sorensen
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: Add TI SCI PM Domains
From: Kevin Hilman @ 2016-10-21 18:48 UTC (permalink / raw)
To: Dave Gerlach
Cc: Ulf Hansson, Rafael J . Wysocki, linux-arm-kernel, linux-kernel,
linux-pm, devicetree, Nishanth Menon, Keerthy, Russell King,
Tero Kristo, Sudeep Holla, Santosh Shilimkar
In-Reply-To: <20161019203347.17893-3-d-gerlach@ti.com>
Dave Gerlach <d-gerlach@ti.com> writes:
> Add a generic power domain implementation, TI SCI PM Domains, that
> will hook into the genpd framework and allow the TI SCI protocol to
> control device power states.
>
> Also, provide macros representing each device index as understood
> by TI SCI to be used in the device node power-domain references.
> These are identifiers for the K2G devices managed by the PMMC.
>
> Signed-off-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
> ---
> .../devicetree/bindings/soc/ti/sci-pm-domain.txt | 54 +++++++++++++
> MAINTAINERS | 2 +
> include/dt-bindings/genpd/k2g.h | 90 ++++++++++++++++++++++
> 3 files changed, 146 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
> create mode 100644 include/dt-bindings/genpd/k2g.h
>
> diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
> new file mode 100644
> index 000000000000..32f38a349656
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
> @@ -0,0 +1,54 @@
> +Texas Instruments TI-SCI Generic Power Domain
> +---------------------------------------------
> +
> +Some TI SoCs contain a system controller (like the PMMC, etc...) that is
> +responsible for controlling the state of the IPs that are present.
> +Communication between the host processor running an OS and the system
> +controller happens through a protocol known as TI-SCI [1]. This pm domain
> +implementation plugs into the generic pm domain framework and makes use of
> +the TI SCI protocol power on and off each device when needed.
> +
> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
> +
> +PM Domain Node
> +==============
> +The PM domain node represents the global PM domain managed by the PMMC,
> +which in this case is the single implementation as documented by the generic
> +PM domain bindings in Documentation/devicetree/bindings/power/power_domain.txt.
> +
> +Required Properties:
> +--------------------
> +- compatible: should be "ti,sci-pm-domain"
> +- #power-domain-cells: Must be 0.
> +- ti,sci: Phandle to the TI SCI device to use for managing the devices.
>
> +Example:
> +--------------------
> +k2g_pds: k2g_pds {
should use generic name like "power-contoller", e.g. k2g_pds: power-controller
> + compatible = "ti,sci-pm-domain";
> + #power-domain-cells = <0>;
> + ti,sci = <&pmmc>;
> +};
> +
> +PM Domain Consumers
> +===================
> +Hardware blocks that require SCI control over their state must provide
> +a reference to the sci-pm-domain they are part of and a unique device
> +specific ID that identifies the device.
> +
> +Required Properties:
> +--------------------
> +- power-domains: phandle pointing to the corresponding PM domain node.
> +- ti,sci-id: index representing the device id to be passed oevr SCI to
> + be used for device control.
This ID doesn't look right.
Why not use #power-domain-cells = <1> and pass the index in the DT? ...
> +See dt-bindings/genpd/k2g.h for the list of valid identifiers for k2g.
> +
> +Example:
> +--------------------
> +uart0: serial@02530c00 {
> + compatible = "ns16550a";
> + ...
> + power-domains = <&k2g_pds>;
> + ti,sci-id = <K2G_DEV_UART0>;
... like this:
power-domains = <&k2g_pds K2G_DEV_UART0>;
Kevin
^ permalink raw reply
* Re: [PATCH v3 1/3] mtd: s3c2410: make ecc mode configurable via platform data
From: Marek Vasut @ 2016-10-21 18:51 UTC (permalink / raw)
To: Krzysztof Kozlowski, Sergio Prado
Cc: mark.rutland-5wv7dgnIgG8,
boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
richard-/L3Ra7n9ekc, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
javier-JPH+aEBZ4P+UEJcrhfAQsw, kgene-DgEjT+Ai2ygdnm+yROfE0A,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
computersforpeace-Re5JQEeQqe8AvxtiuMwx3w,
dwmw2-wEGCiKHe2LqWVfeAwA7xHQ, linux-Y5A6D6n0/KfQXOPxS62xeg,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161021182710.GA17279@kozik-lap>
On 10/21/2016 08:27 PM, Krzysztof Kozlowski wrote:
> On Thu, Oct 20, 2016 at 07:42:44PM -0200, Sergio Prado wrote:
>> Removing CONFIG_MTD_NAND_S3C2410_HWECC option and adding a ecc_mode
>> field in the drivers's platform data structure so it can be selectable
>> via platform data.
>>
>> Also setting this field to NAND_ECC_SOFT in all boards using this
>> driver since none of them had CONFIG_MTD_NAND_S3C2410_HWECC enabled.
>>
>> Signed-off-by: Sergio Prado <sergio.prado-1e4yhPs3/ABSwrhanM7KvQ@public.gmane.org>
>> ---
>> arch/arm/mach-s3c24xx/common-smdk.c | 1 +
>> arch/arm/mach-s3c24xx/mach-anubis.c | 1 +
>> arch/arm/mach-s3c24xx/mach-at2440evb.c | 1 +
>> arch/arm/mach-s3c24xx/mach-bast.c | 1 +
>> arch/arm/mach-s3c24xx/mach-gta02.c | 1 +
>> arch/arm/mach-s3c24xx/mach-jive.c | 1 +
>> arch/arm/mach-s3c24xx/mach-mini2440.c | 1 +
>> arch/arm/mach-s3c24xx/mach-osiris.c | 1 +
>> arch/arm/mach-s3c24xx/mach-qt2410.c | 1 +
>> arch/arm/mach-s3c24xx/mach-rx1950.c | 1 +
>> arch/arm/mach-s3c24xx/mach-rx3715.c | 1 +
>> arch/arm/mach-s3c24xx/mach-vstms.c | 1 +
>> arch/arm/mach-s3c64xx/mach-hmt.c | 1 +
>> arch/arm/mach-s3c64xx/mach-mini6410.c | 1 +
>> arch/arm/mach-s3c64xx/mach-real6410.c | 1 +
>> drivers/mtd/nand/Kconfig | 9 --
>> drivers/mtd/nand/s3c2410.c | 119 +++++++++++++------------
>> include/linux/platform_data/mtd-nand-s3c2410.h | 6 +-
>> 18 files changed, 79 insertions(+), 70 deletions(-)
>>
>
> I acked this twice (v1 and v2)... and still you are ignoring them. I am
> sorry, I am not gonna to ack this third time!
Hi, um, I am kinda new to this mess, what's going on ? You ACKed
previous patches, next revision was submitted, so you need to ACK
the next revision too (due to the changes).
> For v2 I acked also other patches but it it is not there as well...
>
> BR,
> Krzysztof
--
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 3/4] soc: ti: Add ti_sci_pm_domains driver
From: Kevin Hilman @ 2016-10-21 19:00 UTC (permalink / raw)
To: Dave Gerlach
Cc: Ulf Hansson, Rafael J . Wysocki,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Nishanth Menon, Keerthy,
Russell King, Tero Kristo, Sudeep Holla, Santosh Shilimkar
In-Reply-To: <20161019203347.17893-4-d-gerlach-l0cyMroinI0@public.gmane.org>
Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org> writes:
> Introduce a ti_sci_pm_domains driver to act as a generic pm domain provider
> to allow each device to attach and associate it's ti-sci-id so that it can
> be controlled through the TI SCI protocol.
>
> This driver implements a simple genpd where each device node has
> a phandle to the power domain node and also must provide an index which
> represents the ID to be passed with TI SCI representing the device using a
> ti,sci-id property. Through this interface the genpd dev_ops start and
> stop hooks will use TI SCI to turn on and off each device as determined
> by pm_runtime usage.
>
> Signed-off-by: Keerthy <j-keerthy-l0cyMroinI0@public.gmane.org>
> Signed-off-by: Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>
> Signed-off-by: Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org>
> ---
> MAINTAINERS | 1 +
> arch/arm/mach-keystone/Kconfig | 1 +
> drivers/soc/ti/Kconfig | 12 +++
> drivers/soc/ti/Makefile | 1 +
> drivers/soc/ti/ti_sci_pm_domains.c | 198 +++++++++++++++++++++++++++++++++++++
> 5 files changed, 213 insertions(+)
> create mode 100644 drivers/soc/ti/ti_sci_pm_domains.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d894873c2bff..3eaac5ede847 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11894,6 +11894,7 @@ F: drivers/firmware/ti_sci*
> F: include/linux/soc/ti/ti_sci_protocol.h
> F: Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
> F: include/dt-bindings/genpd/k2g.h
> +F: drivers/soc/ti/ti_sci_pm_domains.c
>
> THANKO'S RAREMONO AM/FM/SW RADIO RECEIVER USB DRIVER
> M: Hans Verkuil <hverkuil-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org>
> diff --git a/arch/arm/mach-keystone/Kconfig b/arch/arm/mach-keystone/Kconfig
> index 24bd64dabdfc..18d49465cafb 100644
> --- a/arch/arm/mach-keystone/Kconfig
> +++ b/arch/arm/mach-keystone/Kconfig
> @@ -9,6 +9,7 @@ config ARCH_KEYSTONE
> select ARCH_SUPPORTS_BIG_ENDIAN
> select ZONE_DMA if ARM_LPAE
> select PINCTRL
> + select PM_GENERIC_DOMAINS if PM
> help
> Support for boards based on the Texas Instruments Keystone family of
> SoCs.
> diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig
> index 3557c5e32a93..39e152abe6b9 100644
> --- a/drivers/soc/ti/Kconfig
> +++ b/drivers/soc/ti/Kconfig
> @@ -38,4 +38,16 @@ config WKUP_M3_IPC
> to communicate and use the Wakeup M3 for PM features like suspend
> resume and boots it using wkup_m3_rproc driver.
>
> +config TI_SCI_PM_DOMAINS
> + tristate "TI SCI PM Domains Driver"
> + depends on TI_SCI_PROTOCOL
> + depends on PM_GENERIC_DOMAINS
> + help
> + Generic power domain implementation for TI device implementing
> + the TI SCI protocol.
> +
> + To compile this as a module, choose M here. The module will be
> + called ti_sci_pm_domains. Note this is needed early in boot before
> + rootfs may be available.
> +
> endif # SOC_TI
> diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile
> index 48ff3a79634f..7d572736c86e 100644
> --- a/drivers/soc/ti/Makefile
> +++ b/drivers/soc/ti/Makefile
> @@ -5,3 +5,4 @@ obj-$(CONFIG_KEYSTONE_NAVIGATOR_QMSS) += knav_qmss.o
> knav_qmss-y := knav_qmss_queue.o knav_qmss_acc.o
> obj-$(CONFIG_KEYSTONE_NAVIGATOR_DMA) += knav_dma.o
> obj-$(CONFIG_WKUP_M3_IPC) += wkup_m3_ipc.o
> +obj-$(CONFIG_TI_SCI_PM_DOMAINS) += ti_sci_pm_domains.o
> diff --git a/drivers/soc/ti/ti_sci_pm_domains.c b/drivers/soc/ti/ti_sci_pm_domains.c
> new file mode 100644
> index 000000000000..ec76215d64c7
> --- /dev/null
> +++ b/drivers/soc/ti/ti_sci_pm_domains.c
> @@ -0,0 +1,198 @@
> +/*
> + * TI SCI Generic Power Domain Driver
> + *
> + * Copyright (C) 2015-2016 Texas Instruments Incorporated - http://www.ti.com/
> + * J Keerthy <j-keerthy-l0cyMroinI0@public.gmane.org>
> + * Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <linux/err.h>
> +#include <linux/module.h>
> +#include <linux/mutex.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_domain.h>
> +#include <linux/slab.h>
> +#include <linux/soc/ti/ti_sci_protocol.h>
> +
> +/**
> + * struct ti_sci_genpd_dev_data: holds data needed for every device attached
> + * to this genpd
> + * @idx: index of the device that identifies it with the system
> + * control processor.
> + */
> +struct ti_sci_genpd_dev_data {
> + int idx;
> +};
If you use #power-domain-cells = <1>, you can drop this...
> +/**
> + * struct ti_sci_pm_domain: TI specific data needed for power domain
> + * @ti_sci: handle to TI SCI protocol driver that provides ops to
> + * communicate with system control processor.
> + * @dev: pointer to dev for the driver for devm allocs
> + * @pd: generic_pm_domain for use with the genpd framework
> + */
> +struct ti_sci_pm_domain {
> + const struct ti_sci_handle *ti_sci;
> + struct device *dev;
> + struct generic_pm_domain pd;
> +};
and add and 'idx' field to this which is populated on attach.
Thank you shouldn't need PATCH 1/4 which adds the new 'void * data'.
Otherwise, the driver looks pretty straight forward.
BTW, what is the the status of the TI-SCI protocol drivers themselves?
This can't be merged until that is or this won't even compile.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 3/4] soc: ti: Add ti_sci_pm_domains driver
From: Santosh Shilimkar @ 2016-10-21 19:02 UTC (permalink / raw)
To: Kevin Hilman, Dave Gerlach
Cc: Ulf Hansson, Rafael J . Wysocki,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Nishanth Menon, Keerthy,
Russell King, Tero Kristo, Sudeep Holla, Santosh Shilimkar
In-Reply-To: <7h4m45plxr.fsf-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On 10/21/2016 12:00 PM, Kevin Hilman wrote:
> Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org> writes:
>
[...]
>
> BTW, what is the the status of the TI-SCI protocol drivers themselves?
> This can't be merged until that is or this won't even compile.
>
I was just about to ask the same question.
Regards,
Santosh
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 1/3] mtd: s3c2410: make ecc mode configurable via platform data
From: Sergio Prado @ 2016-10-21 19:05 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: kgene, javier, linux, linux, boris.brezillon, richard, dwmw2,
computersforpeace, linux-arm-kernel, linux-samsung-soc,
linux-kernel, linux-mtd, robh+dt, mark.rutland, devicetree
In-Reply-To: <20161021182710.GA17279@kozik-lap>
On Fri, Oct 21, 2016 at 09:27:10PM +0300, Krzysztof Kozlowski wrote:
>
> I acked this twice (v1 and v2)... and still you are ignoring them. I am
> sorry, I am not gonna to ack this third time!
>
> For v2 I acked also other patches but it it is not there as well...
>
> BR,
> Krzysztof
I'm really sorry Krzysztof. This is my first patch series and I didn't
know I should add the acked-by tag to the patches (I thought it would be
done by the maintainer when the patches are accepted/applied).
I'll make sure to do it right next time.
Thanks for taking your time to reviewing and acking my patches.
Best regards,
Sergio Prado
--
Sergio Prado
Embedded Labworks
Office: +55 11 2628-3461
Mobile: +55 11 97123-3420
^ permalink raw reply
* Re: [PATCH V7 4/4] dmaengine: qcom_hidma: add MSI support for interrupts
From: Andy Shevchenko @ 2016-10-21 19:11 UTC (permalink / raw)
To: Sinan Kaya
Cc: dmaengine, Timur Tabi, devicetree, Christopher Covington,
Vinod Koul, Jon Masters, Andy Gross, Arnd Bergmann, linux-arm-msm,
linux-arm Mailing List, Dan Williams, Dave Jiang,
Lars-Peter Clausen, linux-kernel@vger.kernel.org
In-Reply-To: <1477067879-23750-5-git-send-email-okaya@codeaurora.org>
On Fri, Oct 21, 2016 at 7:37 PM, Sinan Kaya <okaya@codeaurora.org> wrote:
> The interrupts can now be delivered as platform MSI interrupts on newer
> platforms. The code looks for a new OF and ACPI strings in order to enable
> the functionality.
> +#ifdef CONFIG_GENERIC_MSI_IRQ_DOMAIN
> +static void hidma_write_msi_msg(struct msi_desc *desc, struct msi_msg *msg)
> +{
> + struct device *dev = msi_desc_to_dev(desc);
> + struct hidma_dev *dmadev = dev_get_drvdata(dev);
> +
> + if (!desc->platform.msi_index) {
> + writel(msg->address_lo, dmadev->dev_evca + 0x118);
> + writel(msg->address_hi, dmadev->dev_evca + 0x11C);
> + writel(msg->data, dmadev->dev_evca + 0x120);
> + }
> +}
> +#endif
> +
> +static void hidma_free_msis(struct hidma_dev *dmadev)
> +{
> +#ifdef CONFIG_GENERIC_MSI_IRQ_DOMAIN
Perhaps one #ifdef and two definitions of functions?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 5/5] ARM: dts: Add LEGO MINDSTORTMS EV3 dts
From: Kevin Hilman @ 2016-10-21 19:13 UTC (permalink / raw)
To: David Lechner
Cc: Sekhar Nori, Rob Herring, Mark Rutland, Russell King, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <1477075018-20176-6-git-send-email-david@lechnology.com>
David Lechner <david@lechnology.com> writes:
> This adds a device tree definition file for LEGO MINDSTORMS EV3.
>
> What is working:
>
> * Pin muxing
> * MicroSD card reader
> * UART on input port 1
>
> What is partially working:
>
> * Buttons - working after GPIO fix
> * LEDs - working after GPIO fix
> * Poweroff/reset - working after GPIO fix
> * Flash memory - driver loads but can't read the block devices - this is
> probably due to the fact that we are not able to configure the SPI to
> use DMA via device tree
> * EEPROM - there seems to be a hardware bug that causes the first byte
> read to be corrupted - this can be worked around by adding an I2C stop
> between writing the register and reading the data, but the at24 driver
> does not have an option to do this
>
> What is not working/to be added later:
>
> * Display - waiting for "tiny DRM" to be mainlined
> * Speaker - needs new PWM sound driver
> * USB - waiting for OHCI and MUSB device tree support to be mainlined
> * ADC - needs new iio driver
> * GPIOs - broken because of recent changes to core gpio driver
> * Bluetooth - needs new driver for sequencing power/enable/clock
> * Input and output ports - need some sort of new phy or extcon driver
> * Battery - needs new power supply driver (depends on ADC iio driver)
>
> Signed-off-by: David Lechner <david@lechnology.com>
> ---
> arch/arm/boot/dts/Makefile | 3 +-
> arch/arm/boot/dts/lego-ev3.dts | 454 +++++++++++++++++++++++++++++++++++++++++
nit: can you name this da850-lego-ev3.dts
Though it's not very strictly enforced, we *try* to use the form
<soc>-<board>.dts.
Kevin
^ permalink raw reply
* Re: [PATCH v2 3/4] soc: ti: Add ti_sci_pm_domains driver
From: Dave Gerlach @ 2016-10-21 19:15 UTC (permalink / raw)
To: Santosh Shilimkar, Kevin Hilman
Cc: Ulf Hansson, Rafael J . Wysocki, linux-arm-kernel, linux-kernel,
linux-pm, devicetree, Nishanth Menon, Keerthy, Russell King,
Tero Kristo, Sudeep Holla, Santosh Shilimkar
In-Reply-To: <e13cd925-a62d-457d-cc99-fadd4d123256@oracle.com>
On 10/21/2016 02:02 PM, Santosh Shilimkar wrote:
> On 10/21/2016 12:00 PM, Kevin Hilman wrote:
>> Dave Gerlach <d-gerlach@ti.com> writes:
>>
> [...]
>
>>
>> BTW, what is the the status of the TI-SCI protocol drivers themselves?
>> This can't be merged until that is or this won't even compile.
>>
> I was just about to ask the same question.
v4 was sent here which was just a rebase of v3 on v4.9-rc1 with no
changes: http://www.spinics.net/lists/arm-kernel/msg536851.html
Should be ready to merge, just was too late during v4.8 cycle.
Regards,
Dave
>
> Regards,
> Santosh
>
^ permalink raw reply
* Re: [RFC V4 PATCH 1/6] arm64: dts: msm8992 SoC and LG Bullhead (Nexus 5X) support
From: Stephen Boyd @ 2016-10-21 19:21 UTC (permalink / raw)
To: Jeremy McNicoll
Cc: linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, robh-DgEjT+Ai2ygdnm+yROfE0A,
andy.gross-QSEj5FYQhm4dnm+yROfE0A, arnd-r2nGTMty4D4,
bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
michael.scott-QSEj5FYQhm4dnm+yROfE0A
In-Reply-To: <1477048273-32451-2-git-send-email-jeremymc-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On 10/21, Jeremy McNicoll wrote:
> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> index 5dd05de..abb366e 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -1,6 +1,6 @@
> dtb-$(CONFIG_ARCH_QCOM) += apq8016-sbc.dtb msm8916-mtp.dtb
> -dtb-$(CONFIG_ARCH_QCOM) += msm8996-mtp.dtb
> -dtb-$(CONFIG_ARCH_QCOM) += apq8096-db820c.dtb
> +dtb-$(CONFIG_ARCH_QCOM) += msm8996-mtp.dtb apq8096-db820c.dtb
> +dtb-$(CONFIG_ARCH_QCOM) += msm8992-bullhead-rev-101.dtb
One line per dtb please.
>
> always := $(dtb-y)
> subdir-y := $(dts-dirs)
> diff --git a/arch/arm64/boot/dts/qcom/msm8992-bullhead-rev-101.dts b/arch/arm64/boot/dts/qcom/msm8992-bullhead-rev-101.dts
> new file mode 100644
> index 0000000..63fa3b0
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/msm8992-bullhead-rev-101.dts
> @@ -0,0 +1,42 @@
> +/* Copyright (c) 2015, LGE Inc. All rights reserved.
> + * Copyright (c) 2016, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * 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 "msm8992.dtsi"
> +
> +/ {
> + model = "LGE MSM8992 BULLHEAD rev-1.01";
> + compatible = "qcom,msm8992";
> + /* required for bootloader to select correct board */
> + qcom,board-id = <0xb64 0>;
> +};
Why do we end
> +
> +/ {
and then restart the root node? Just keep the same node all the
time please.
> + aliases {
> + serial0 = &blsp1_uart2;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + soc {
> + serial@f991e000 {
> + status = "okay";
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&blsp1_uart2_default>;
> + pinctrl-1 = <&blsp1_uart2_sleep>;
> + };
> + };
> +};
> diff --git a/arch/arm64/boot/dts/qcom/msm8992.dtsi b/arch/arm64/boot/dts/qcom/msm8992.dtsi
> new file mode 100644
> index 0000000..5d69a6b
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/msm8992.dtsi
> @@ -0,0 +1,214 @@
> +/* Copyright (c) 2013-2016, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include <dt-bindings/interrupt-controller/arm-gic.h>
> +#include <dt-bindings/clock/qcom,gcc-msm8994.h>
> +
> +/ {
> + model = "Qualcomm Technologies, Inc. MSM 8992";
> + compatible = "qcom,msm8992";
> + // msm-id and pmic-id are needed by bootloader for
> + // selecting correct blob
> + qcom,msm-id = <251 0>, <252 0>;
> + qcom,pmic-id = <0x10009 0x1000A 0x0 0x0>;
Can't these just be in the final dts file and not in the dtsi
file? Technically the pmic pairings are a board choice and not an
SoC choice so they shouldn't be here. The msm-id properties are
a little easier to justify, but then I thought we decided to only
put them in the boards that need them?
> + interrupt-parent = <&intc>;
> +
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + chosen { };
> +
> + cpus {
> + #address-cells = <2>;
> + #size-cells = <0>;
> + cpu-map {
> + cluster0 {
> + core0 {
> + cpu = <&CPU0>;
> + };
> + };
> + };
> +
> + CPU0: cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a53", "arm,armv8";
> + reg = <0x0 0x0>;
> + next-level-cache = <&L2_0>;
> + // The currents(uA) correspond to the frequencies in the
> + // frequency table.
> + current = < 18250 //384000 kHZ
> + 24330 //460800 kHZ
> + 26920 //600000 kHZ
> + 34600 //672000 kHz
> + 38150 //787200 kHZ
> + 46880 //864000 kHZ
> + 55940 //960000 kHZ
> + 81740 //1248000 kHZ
> + 105870>; //1440000 kHZ
I imagine these aren't used. Please remove them.
> + L2_0: l2-cache {
> + compatible = "cache";
> + cache-level = <2>;
> + };
> + };
> + };
> +
> + soc: soc { };
Just put the soc stuff here instead of having an empty node we
fill later please. That matches other qcom dtsi files.
> +
> + memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + device_type = "memory";
> + reg = <0 0 0 0>; // bootloader will update
> + };
> +
> + clocks {
> + xo_board: xo_board {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <19200000>;
> + };
> +
> + sleep_clk: sleep_clk {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <32768>;
> + };
> + };
> +};
> +
> +&soc {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0 0 0 0xffffffff>;
> + compatible = "simple-bus";
> +
> + intc: interrupt-controller@f9000000 {
> + compatible = "qcom,msm-qgic2";
> + interrupt-controller;
> + #interrupt-cells = <3>;
> + reg = <0xf9000000 0x1000>,
> + <0xf9002000 0x1000>;
> + };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + interrupts = <1 2 0xf08>,
> + <1 3 0xf08>,
> + <1 4 0xf08>,
> + <1 1 0xf08>;
> + clock-frequency = <19200000>;
Please remove this property.
> + };
This whole node should be outside of soc node.
> +
> + timer@f9020000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + compatible = "arm,armv7-timer-mem";
> + reg = <0xf9020000 0x1000>;
> + clock-frequency = <19200000>;
Please remove this property.
> +
> + frame@f9021000 {
> + frame-number = <0>;
> + interrupts = <0 9 0x4>,
> + <0 8 0x4>;
> + reg = <0xf9021000 0x1000>,
> + <0xf9022000 0x1000>;
> + };
> +
> + frame@f9023000 {
> + frame-number = <1>;
> + interrupts = <0 10 0x4>;
> + reg = <0xf9023000 0x1000>;
> + status = "disabled";
> + };
> +
> + frame@f9024000 {
> + frame-number = <2>;
> + interrupts = <0 11 0x4>;
> + reg = <0xf9024000 0x1000>;
> + status = "disabled";
> + };
> +
> + frame@f9025000 {
> + frame-number = <3>;
> + interrupts = <0 12 0x4>;
> + reg = <0xf9025000 0x1000>;
> + status = "disabled";
> + };
> +
> + frame@f9026000 {
> + frame-number = <4>;
> + interrupts = <0 13 0x4>;
> + reg = <0xf9026000 0x1000>;
> + status = "disabled";
> + };
> +
> + frame@f9027000 {
> + frame-number = <5>;
> + interrupts = <0 14 0x4>;
> + reg = <0xf9027000 0x1000>;
> + status = "disabled";
> + };
> +
> + frame@f9028000 {
> + frame-number = <6>;
> + interrupts = <0 15 0x4>;
> + reg = <0xf9028000 0x1000>;
> + status = "disabled";
> + };
> + };
> +
> + restart@fc4ab000 {
> + compatible = "qcom,pshold";
> + reg = <0xfc4ab000 0x4>;
> + };
> +
> + msmgpio: pinctrl@fd510000 {
> + compatible = "qcom,msm8994-pinctrl", "qcom,msm8974-pinctrl";
> + reg = <0xfd510000 0x4000>;
> + interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + };
> +
> + blsp1_uart2: serial@f991e000 {
> + compatible = "qcom,msm-uartdm-v1.4", "qcom,msm-uartdm";
> + reg = <0xf991e000 0x1000>;
> + interrupts = <0 108 0>;
Please add a trigger type and use the GIC_SPI/IRQ_TYPE_* macros.
> + status = "disabled";
> + clock-names = "core", "iface";
> + clocks = <&clock_gcc GCC_BLSP1_UART2_APPS_CLK>,
> + <&clock_gcc GCC_BLSP1_AHB_CLK>;
> + };
> +
> + clock_gcc: qcom,gcc@fc400000 {
> + compatible = "qcom,gcc-8994";
> + #clock-cells = <1>;
> + #reset-cells = <1>;
> + #power-domain-cells = <1>;
> + reg = <0xfc400000 0x2000>;
> + clock-names = "xo", "xo_a_clk";
What is this for? Please remove.
> + };
> +
> + clock_rpm: qcom,rpmcc@fc401880 {
> + compatible = "qcom,rpmcc";
What is this node? Please remove.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v9 1/2] usb: dwc2: assert phy reset when waking up in rk3288 platform
From: John Youn @ 2016-10-21 19:27 UTC (permalink / raw)
To: Randy Li, linux-usb@vger.kernel.org
Cc: John.Youn@synopsys.com, kishon@ti.com,
felipe.balbi@linux.intel.com, mark.rutland@arm.com,
devicetree@vger.kernel.org, heiko@sntech.de,
gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, randy.li@rock-chips.com
In-Reply-To: <1476988627-14953-2-git-send-email-ayaka@soulik.info>
On 10/20/2016 11:38 AM, Randy Li wrote:
> On the rk3288 USB host-only port (the one that's not the OTG-enabled
> port) the PHY can get into a bad state when a wakeup is asserted (not
> just a wakeup from full system suspend but also a wakeup from
> autosuspend).
>
> We can get the PHY out of its bad state by asserting its "port reset",
> but unfortunately that seems to assert a reset onto the USB bus so it
> could confuse things if we don't actually deenumerate / reenumerate the
> device.
>
> We can also get the PHY out of its bad state by fully resetting it using
> the reset from the CRU (clock reset unit) in chip, which does a more full
> reset. The CRU-based reset appears to actually cause devices on the bus
> to be removed and reinserted, which fixes the problem (albeit in a hacky
> way).
>
> It's unfortunate that we need to do a full re-enumeration of devices at
> wakeup time, but this is better than alternative of letting the bus get
> wedged.
>
> Signed-off-by: Randy Li <ayaka@soulik.info>
> ---
> drivers/usb/dwc2/core.h | 1 +
> drivers/usb/dwc2/core_intr.c | 11 +++++++++++
> drivers/usb/dwc2/platform.c | 9 +++++++++
> 3 files changed, 21 insertions(+)
>
> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
> index 2a21a04..e91ddbc 100644
> --- a/drivers/usb/dwc2/core.h
> +++ b/drivers/usb/dwc2/core.h
> @@ -859,6 +859,7 @@ struct dwc2_hsotg {
> unsigned int ll_hw_enabled:1;
>
> struct phy *phy;
> + struct work_struct phy_rst_work;
> struct usb_phy *uphy;
> struct dwc2_hsotg_plat *plat;
> struct regulator_bulk_data supplies[ARRAY_SIZE(dwc2_hsotg_supply_names)];
> diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
> index d85c5c9..c3d2168 100644
> --- a/drivers/usb/dwc2/core_intr.c
> +++ b/drivers/usb/dwc2/core_intr.c
> @@ -345,6 +345,7 @@ static void dwc2_handle_session_req_intr(struct dwc2_hsotg *hsotg)
> static void dwc2_handle_wakeup_detected_intr(struct dwc2_hsotg *hsotg)
> {
> int ret;
> + struct device_node *np = hsotg->dev->of_node;
>
> /* Clear interrupt */
> dwc2_writel(GINTSTS_WKUPINT, hsotg->regs + GINTSTS);
> @@ -379,6 +380,16 @@ static void dwc2_handle_wakeup_detected_intr(struct dwc2_hsotg *hsotg)
> /* Restart the Phy Clock */
> pcgcctl &= ~PCGCTL_STOPPCLK;
> dwc2_writel(pcgcctl, hsotg->regs + PCGCTL);
> +
> + /*
> + * It is a quirk in Rockchip RK3288, causing by
> + * a hardware bug. This will propagate out and
> + * eventually we'll re-enumerate the device.
> + * Not great but the best we can do
> + */
> + if (of_device_is_compatible(np, "rockchip,rk3288-usb"))
> + schedule_work(&hsotg->phy_rst_work);
> +
> mod_timer(&hsotg->wkp_timer,
> jiffies + msecs_to_jiffies(71));
> } else {
> diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
> index 8e1728b..65953cf 100644
> --- a/drivers/usb/dwc2/platform.c
> +++ b/drivers/usb/dwc2/platform.c
> @@ -366,6 +366,14 @@ int dwc2_lowlevel_hw_disable(struct dwc2_hsotg *hsotg)
> return ret;
> }
>
> +/* Only used to reset usb phy at interrupter runtime */
> +static void dwc2_reset_phy_work(struct work_struct *data)
> +{
> + struct dwc2_hsotg *hsotg = container_of(data, struct dwc2_hsotg,
> + phy_rst_work);
> + phy_reset(hsotg->phy);
> +}
> +
> static int dwc2_lowlevel_hw_init(struct dwc2_hsotg *hsotg)
> {
> int i, ret;
> @@ -410,6 +418,7 @@ static int dwc2_lowlevel_hw_init(struct dwc2_hsotg *hsotg)
> return ret;
> }
> }
> + INIT_WORK(&hsotg->phy_rst_work, dwc2_reset_phy_work);
>
> if (!hsotg->phy) {
> hsotg->uphy = devm_usb_get_phy(hsotg->dev, USB_PHY_TYPE_USB2);
>
Hi Randy,
This fails compile if CONFIG_GENERIC_PHY is disabled. I think you need
to make a fix to your phy_reset patch first.
Regards,
John
^ permalink raw reply
* Re: [PATCH v5 23/23] phy: Add support for Qualcomm's USB HS phy
From: Stephen Boyd @ 2016-10-21 19:33 UTC (permalink / raw)
To: Peter Chen
Cc: Felipe Balbi, Arnd Bergmann, Neil Armstrong, linux-arm-msm,
linux-usb, linux-kernel, Bjorn Andersson, devicetree, Rob Herring,
Peter Chen, Andy Gross, Kishon Vijay Abraham I, linux-arm-kernel
In-Reply-To: <20161021022030.GB16461@b29397-desktop>
Quoting Peter Chen (2016-10-20 19:20:30)
> On Thu, Oct 20, 2016 at 04:20:38PM -0700, Stephen Boyd wrote:
> > Quoting Stephen Boyd (2016-10-17 18:56:36)
> > > +
> > > +static int
> > > +qcom_usb_hs_phy_vbus_notifier(struct notifier_block *nb, unsigned long event,
> > > + void *ptr)
> > > +{
> > > + struct qcom_usb_hs_phy *uphy;
> > > + int is_host;
> > > + u8 addr;
> > > +
> > > + uphy = container_of(nb, struct qcom_usb_hs_phy, vbus_notify);
> > > + is_host = extcon_get_cable_state_(uphy->id_edev, EXTCON_USB_HOST);
> >
> > Please don't apply this patch. This call now deadlocks on v4.9-rc1
> > because of how extcon_get_cable_state_() now grabs a lock that is
> > already held here when we're inside the notifier. It's not really
> > required that we grab the lock in extcon there, but this has exposed a
> > flaw in the logic anyway. We don't know if the id pin is going to toggle
> > before or after this function is called, so we should really keep track
> > of both vbus and id state in this driver and then do the same ulpi
> > writes from two different notifiers for both vbus and id pin. We would
> > be duplicating work sometimes, but that's pretty much the best solution
> > I can come up with. Otherwise it's racy.
> >
>
> Why you need to care id status? If EXTCON_USB event has happened, and
> event is true, you can set, otherwise, it is clear operation, that's
> to say you may not need have id extcon phandle, do you think so?
>
I need to add a comment to the code here because I forgot what was going
on.
Either way, this code is pulling D+ up when we're in device mode. We
don't want to do the pullup if we're a host, and vbus extcon only tells
us if the cable is attached so we can't just rely on that one bit of
information.
I suppose that's not really appropriate to do via extcon though in the
phy driver though, so I'm thinking that it should be rewritten to use
the phy_set_mode() feature of the phy framework. Basically,
ci_udc_pullup() will call phy_set_mode() with PHY_MODE_USB_DEVICE or
PHY_MODE_USB_HOST and then we can set or clear these bits in the ulpi
register space. I think that will make things simpler here and things
like soft-connect will work better. Sound good?
^ permalink raw reply
* Re: [RFC V2 PATCH 10/12] arm64: dts: msm8994 issolate non standard bootloader/LK entries
From: Bjorn Andersson @ 2016-10-21 19:44 UTC (permalink / raw)
To: Andy Gross
Cc: Rob Herring, Arnd Bergmann, Jeremy McNicoll, Stephen Boyd,
git-LJ92rlH3Dns, Jeremy McNicoll, linux-arm-msm,
linux-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20161020031712.GD3145-3KkwrOJo9xYlRp7syxWybdHuzzzSOjJt@public.gmane.org>
On Wed 19 Oct 20:17 PDT 2016, Andy Gross wrote:
> On Wed, Oct 19, 2016 at 08:07:25PM -0500, Rob Herring wrote:
[..]
> > Makes sense to me for things like Nexus phones here. What about DB410
> > for example? Is there hope for a fix there? My bootloader is only a
> > couple of months old and needs the properties still.
>
> There won't be a fix for the 410c. We barely got them to respin to use PSCI.
> Stephen can correct me if I am wrong on this.
>
> If this is fixed, it would be 8996+. If..........
>
> So this means introducing the msm-id's for the boards that currently require it,
> and for the boards that will require it in the future. And this would stay in
> effect until the bootloader is able to parse the compatible strings or figure
> this out without the msm-ids.
>
But if the bootloader at any point in the future would support picking a
dtb by compatible strings instead of {msm,board,pmic}-id we wouldn't we
just be back to the ridiculous compatible strings that tipped over into
acceptance to these ids in the first place.
Or do we expect the boot loader to do a deep scan of the dtb to match on
multiple nodes from the tree?
Am I missing something here?
Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: Add TI SCI PM Domains
From: Dave Gerlach @ 2016-10-21 19:49 UTC (permalink / raw)
To: Kevin Hilman
Cc: Ulf Hansson, Rafael J . Wysocki, linux-arm-kernel, linux-kernel,
linux-pm, devicetree, Nishanth Menon, Keerthy, Russell King,
Tero Kristo, Sudeep Holla, Santosh Shilimkar
In-Reply-To: <7heg39pmgb.fsf@baylibre.com>
Hi,
On 10/21/2016 01:48 PM, Kevin Hilman wrote:
> Dave Gerlach <d-gerlach@ti.com> writes:
>
>> Add a generic power domain implementation, TI SCI PM Domains, that
>> will hook into the genpd framework and allow the TI SCI protocol to
>> control device power states.
>>
>> Also, provide macros representing each device index as understood
>> by TI SCI to be used in the device node power-domain references.
>> These are identifiers for the K2G devices managed by the PMMC.
>>
>> Signed-off-by: Nishanth Menon <nm@ti.com>
>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>> ---
>> .../devicetree/bindings/soc/ti/sci-pm-domain.txt | 54 +++++++++++++
>> MAINTAINERS | 2 +
>> include/dt-bindings/genpd/k2g.h | 90 ++++++++++++++++++++++
>> 3 files changed, 146 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>> create mode 100644 include/dt-bindings/genpd/k2g.h
>>
>> diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>> new file mode 100644
>> index 000000000000..32f38a349656
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>> @@ -0,0 +1,54 @@
>> +Texas Instruments TI-SCI Generic Power Domain
>> +---------------------------------------------
>> +
>> +Some TI SoCs contain a system controller (like the PMMC, etc...) that is
>> +responsible for controlling the state of the IPs that are present.
>> +Communication between the host processor running an OS and the system
>> +controller happens through a protocol known as TI-SCI [1]. This pm domain
>> +implementation plugs into the generic pm domain framework and makes use of
>> +the TI SCI protocol power on and off each device when needed.
>> +
>> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>> +
>> +PM Domain Node
>> +==============
>> +The PM domain node represents the global PM domain managed by the PMMC,
>> +which in this case is the single implementation as documented by the generic
>> +PM domain bindings in Documentation/devicetree/bindings/power/power_domain.txt.
>> +
>> +Required Properties:
>> +--------------------
>> +- compatible: should be "ti,sci-pm-domain"
>> +- #power-domain-cells: Must be 0.
>> +- ti,sci: Phandle to the TI SCI device to use for managing the devices.
>>
>> +Example:
>> +--------------------
>> +k2g_pds: k2g_pds {
>
> should use generic name like "power-contoller", e.g. k2g_pds: power-controller
Ok, that makes more sense.
>
>> + compatible = "ti,sci-pm-domain";
>> + #power-domain-cells = <0>;
>> + ti,sci = <&pmmc>;
>> +};
>> +
>> +PM Domain Consumers
>> +===================
>> +Hardware blocks that require SCI control over their state must provide
>> +a reference to the sci-pm-domain they are part of and a unique device
>> +specific ID that identifies the device.
>> +
>> +Required Properties:
>> +--------------------
>> +- power-domains: phandle pointing to the corresponding PM domain node.
>> +- ti,sci-id: index representing the device id to be passed oevr SCI to
>> + be used for device control.
>
> This ID doesn't look right.
>
> Why not use #power-domain-cells = <1> and pass the index in the DT? ...
>
>> +See dt-bindings/genpd/k2g.h for the list of valid identifiers for k2g.
>> +
>> +Example:
>> +--------------------
>> +uart0: serial@02530c00 {
>> + compatible = "ns16550a";
>> + ...
>> + power-domains = <&k2g_pds>;
>> + ti,sci-id = <K2G_DEV_UART0>;
>
> ... like this:
>
> power-domains = <&k2g_pds K2G_DEV_UART0>;
That's how I did it in version one actually. I was able to define my own
xlate function to parse the phandle and get that index, but Ulf pointed
me to this series by Jon Hunter [1] that simplified genpd providers and
dropped the concept of adding your own xlate. This locks the onecell
approach to using a fixed static array of genpds that get indexed into
(without passing the index to the provider, just the genpd that's looked
up), which doesn't fit our usecase, as we don't want a 1 to 1 genpd to
device mapping based on the comments provided in v1. Now we just use the
genpd device attach/detach hooks to parse the sci-id and then use it in
the genpd device start/stop hooks.
Regards,
Dave
[1] http://www.spinics.net/lists/arm-kernel/msg524151.html
>
> Kevin
>
^ permalink raw reply
* [PATCH v2] sh-sci: document R8A7743/5 support
From: Sergei Shtylyov @ 2016-10-21 20:00 UTC (permalink / raw)
To: gregkh, linux-serial, robh+dt, mark.rutland, devicetree; +Cc: linux-renesas-soc
Renesas RZ/G SoC also have the SCIF, SCIFA, SCIFB, and HSCIF ports and
they seem compatible with the R-Car gen2 SoC in this respect...
Document RZ/G1[ME] (also known as R8A774[35]) SoC bindings.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
This patch is against the 'tty-next' branch of GregKH's 'tty.git' repo.
Changes in version 2:
- removed the RZ/G family specific bindings, renamed the patch;
- added Simon's and Geert's ACKs.
Documentation/devicetree/bindings/serial/renesas,sci-serial.txt | 8 ++++++++
1 file changed, 8 insertions(+)
Index: tty/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
===================================================================
--- tty.orig/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
+++ tty/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
@@ -9,6 +9,14 @@ Required properties:
- "renesas,scifb-r8a73a4" for R8A73A4 (R-Mobile APE6) SCIFB compatible UART.
- "renesas,scifa-r8a7740" for R8A7740 (R-Mobile A1) SCIFA compatible UART.
- "renesas,scifb-r8a7740" for R8A7740 (R-Mobile A1) SCIFB compatible UART.
+ - "renesas,scif-r8a7743" for R8A7743 (RZ/G1M) SCIF compatible UART.
+ - "renesas,scifa-r8a7743" for R8A7743 (RZ/G1M) SCIFA compatible UART.
+ - "renesas,scifb-r8a7743" for R8A7743 (RZ/G1M) SCIFB compatible UART.
+ - "renesas,hscif-r8a7743" for R8A7743 (RZ/G1M) HSCIF compatible UART.
+ - "renesas,scif-r8a7745" for R8A7745 (RZ/G1E) SCIF compatible UART.
+ - "renesas,scifa-r8a7745" for R8A7745 (RZ/G1E) SCIFA compatible UART.
+ - "renesas,scifb-r8a7745" for R8A7745 (RZ/G1E) SCIFB compatible UART.
+ - "renesas,hscif-r8a7745" for R8A7745 (RZ/G1E) HSCIF compatible UART.
- "renesas,scif-r8a7778" for R8A7778 (R-Car M1) SCIF compatible UART.
- "renesas,scif-r8a7779" for R8A7779 (R-Car H1) SCIF compatible UART.
- "renesas,scif-r8a7790" for R8A7790 (R-Car H2) SCIF compatible UART.
^ permalink raw reply
* Re: [RFC V2 PATCH 10/12] arm64: dts: msm8994 issolate non standard bootloader/LK entries
From: Stephen Boyd @ 2016-10-21 20:04 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Andy Gross, Rob Herring, Arnd Bergmann, Jeremy McNicoll, git,
Jeremy McNicoll, linux-arm-msm, linux-soc,
devicetree@vger.kernel.org
In-Reply-To: <20161021194437.GA7509@tuxbot>
On 10/21, Bjorn Andersson wrote:
> On Wed 19 Oct 20:17 PDT 2016, Andy Gross wrote:
>
> > On Wed, Oct 19, 2016 at 08:07:25PM -0500, Rob Herring wrote:
> [..]
> > > Makes sense to me for things like Nexus phones here. What about DB410
> > > for example? Is there hope for a fix there? My bootloader is only a
> > > couple of months old and needs the properties still.
> >
> > There won't be a fix for the 410c. We barely got them to respin to use PSCI.
> > Stephen can correct me if I am wrong on this.
> >
> > If this is fixed, it would be 8996+. If..........
> >
> > So this means introducing the msm-id's for the boards that currently require it,
> > and for the boards that will require it in the future. And this would stay in
> > effect until the bootloader is able to parse the compatible strings or figure
> > this out without the msm-ids.
> >
>
> But if the bootloader at any point in the future would support picking a
> dtb by compatible strings instead of {msm,board,pmic}-id we wouldn't we
> just be back to the ridiculous compatible strings that tipped over into
> acceptance to these ids in the first place.
>
> Or do we expect the boot loader to do a deep scan of the dtb to match on
> multiple nodes from the tree?
I'm pushing the bootloader team to do the deep scan of the dtb to
match up board compatible and pmic compatible strings so that we
don't have to keep these numbers around. Basically put what
dtbtool is doing into the bootloader so we don't have to post
process the dtb anymore. We're currently discussing how to
implement it and how to move the internal codebase to the new
scheme.
At least for 96boards I think we can update the lk bootloaders on
there to adopt this code. For other platforms like nexus though I
don't see a way we can update those bootloaders, and those
bootloaders require these properties exist in the dtbs, so we
should just throw the numbers into the dts files there and be
done with post processing. For bootloaders that require the QCDT
header, we'll have to keep running dtbtool there to generate the
header. Having the ids in the dts file or not doesn't really
matter there.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v3 1/3] mtd: s3c2410: make ecc mode configurable via platform data
From: Krzysztof Kozlowski @ 2016-10-21 20:06 UTC (permalink / raw)
To: Marek Vasut
Cc: Krzysztof Kozlowski, Sergio Prado, mark.rutland-5wv7dgnIgG8,
boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
richard-/L3Ra7n9ekc, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
javier-JPH+aEBZ4P+UEJcrhfAQsw, kgene-DgEjT+Ai2ygdnm+yROfE0A,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
computersforpeace-Re5JQEeQqe8AvxtiuMwx3w,
dwmw2-wEGCiKHe2LqWVfeAwA7xHQ, linux-Y5A6D6n0/KfQXOPxS62xeg,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <5a626833-d4bf-a991-65ea-2849f2250dce-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Fri, Oct 21, 2016 at 08:51:51PM +0200, Marek Vasut wrote:
> On 10/21/2016 08:27 PM, Krzysztof Kozlowski wrote:
> > On Thu, Oct 20, 2016 at 07:42:44PM -0200, Sergio Prado wrote:
> >> Removing CONFIG_MTD_NAND_S3C2410_HWECC option and adding a ecc_mode
> >> field in the drivers's platform data structure so it can be selectable
> >> via platform data.
> >>
> >> Also setting this field to NAND_ECC_SOFT in all boards using this
> >> driver since none of them had CONFIG_MTD_NAND_S3C2410_HWECC enabled.
> >>
> >> Signed-off-by: Sergio Prado <sergio.prado-1e4yhPs3/ABSwrhanM7KvQ@public.gmane.org>
> >> ---
> >> arch/arm/mach-s3c24xx/common-smdk.c | 1 +
> >> arch/arm/mach-s3c24xx/mach-anubis.c | 1 +
> >> arch/arm/mach-s3c24xx/mach-at2440evb.c | 1 +
> >> arch/arm/mach-s3c24xx/mach-bast.c | 1 +
> >> arch/arm/mach-s3c24xx/mach-gta02.c | 1 +
> >> arch/arm/mach-s3c24xx/mach-jive.c | 1 +
> >> arch/arm/mach-s3c24xx/mach-mini2440.c | 1 +
> >> arch/arm/mach-s3c24xx/mach-osiris.c | 1 +
> >> arch/arm/mach-s3c24xx/mach-qt2410.c | 1 +
> >> arch/arm/mach-s3c24xx/mach-rx1950.c | 1 +
> >> arch/arm/mach-s3c24xx/mach-rx3715.c | 1 +
> >> arch/arm/mach-s3c24xx/mach-vstms.c | 1 +
> >> arch/arm/mach-s3c64xx/mach-hmt.c | 1 +
> >> arch/arm/mach-s3c64xx/mach-mini6410.c | 1 +
> >> arch/arm/mach-s3c64xx/mach-real6410.c | 1 +
> >> drivers/mtd/nand/Kconfig | 9 --
> >> drivers/mtd/nand/s3c2410.c | 119 +++++++++++++------------
> >> include/linux/platform_data/mtd-nand-s3c2410.h | 6 +-
> >> 18 files changed, 79 insertions(+), 70 deletions(-)
> >>
> >
> > I acked this twice (v1 and v2)... and still you are ignoring them. I am
> > sorry, I am not gonna to ack this third time!
>
> Hi, um, I am kinda new to this mess, what's going on ? You ACKed
> previous patches, next revision was submitted, so you need to ACK
> the next revision too (due to the changes).
>
Some of the patches (1/3 and 2/3) were not changed. The resubmission of
a patch should contain the ack. Otherwise one would have to ack
indefinitely...
The changes in 2/3 were quite irrelevant to my ack, so the ack could
stay.
BR,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v3 0/2] Renesas R8A7743 CPG/MSSR clock support
From: Sergei Shtylyov @ 2016-10-21 20:12 UTC (permalink / raw)
To: mturquette, linux-clk, sboyd, robh+dt, mark.rutland, devicetree
Cc: linux-renesas-soc, horms+renesas
Hello.
Here's the set of 2 patches against the 'clk-next' branch of CLK group's
'linux.git' repo. I've splitted them from the R-Car gen2 common support patch.
As the DT patches in the R8A7743/SK-RZG1M board support series depend on the
patch #1 of this series, it might make sense to merge this patch to the
'renesas.git' repo as well...
[1/2] ARM: shmobile: r8a7743: add CPG clock index macros
[2/2] clk: renesas: cpg-mssr: add R8A7743 support
MBR, Sergei
^ permalink raw reply
* [PATCH v3 1/2] ARM: shmobile: r8a7743: add CPG clock index macros
From: Sergei Shtylyov @ 2016-10-21 20:15 UTC (permalink / raw)
To: mturquette, linux-clk, sboyd, robh+dt, mark.rutland, devicetree
Cc: linux-renesas-soc, horms+renesas
In-Reply-To: <1582226.1VeLLfmmeJ@wasted.cogentembedded.com>
Add macros usable by the device tree sources to reference the R8A7743 CPG
clocks by index. The data comes from the table 7.2b in the revision 0.50
of the RZ/G Series User's Manual.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Changes in version 3:
- renumbered the #define's in order to match the R8A7791 CPG clocks;
- added the reference to the manaual to the patch description.
Changes in version 2:
- reduced the macro value indentation.
include/dt-bindings/clock/r8a7743-cpg-mssr.h | 43 +++++++++++++++++++++++++++
1 file changed, 43 insertions(+)
Index: linux/include/dt-bindings/clock/r8a7743-cpg-mssr.h
===================================================================
--- /dev/null
+++ linux/include/dt-bindings/clock/r8a7743-cpg-mssr.h
@@ -0,0 +1,43 @@
+/*
+ * Copyright (C) 2016 Cogent Embedded Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#ifndef __DT_BINDINGS_CLOCK_R8A7743_CPG_MSSR_H__
+#define __DT_BINDINGS_CLOCK_R8A7743_CPG_MSSR_H__
+
+#include <dt-bindings/clock/renesas-cpg-mssr.h>
+
+/* r8a7743 CPG Core Clocks */
+#define R8A7743_CLK_Z 0
+#define R8A7743_CLK_ZG 1
+#define R8A7743_CLK_ZTR 2
+#define R8A7743_CLK_ZTRD2 3
+#define R8A7743_CLK_ZT 4
+#define R8A7743_CLK_ZX 5
+#define R8A7743_CLK_ZS 6
+#define R8A7743_CLK_HP 7
+#define R8A7743_CLK_B 9
+#define R8A7743_CLK_LB 10
+#define R8A7743_CLK_P 11
+#define R8A7743_CLK_CL 12
+#define R8A7743_CLK_M2 13
+#define R8A7743_CLK_ZB3 15
+#define R8A7743_CLK_ZB3D2 16
+#define R8A7743_CLK_DDR 17
+#define R8A7743_CLK_SDH 18
+#define R8A7743_CLK_SD0 19
+#define R8A7743_CLK_SD2 20
+#define R8A7743_CLK_SD3 21
+#define R8A7743_CLK_MMC0 22
+#define R8A7743_CLK_MP 23
+#define R8A7743_CLK_QSPI 26
+#define R8A7743_CLK_CP 27
+#define R8A7743_CLK_RCAN 28
+#define R8A7743_CLK_R 29
+#define R8A7743_CLK_OSC 30
+
+#endif /* __DT_BINDINGS_CLOCK_R8A7743_CPG_MSSR_H__ */
^ permalink raw reply
* [PATCH v3 2/2] clk: renesas: cpg-mssr: add R8A7743 support
From: Sergei Shtylyov @ 2016-10-21 20:17 UTC (permalink / raw)
To: mturquette, linux-clk, sboyd, robh+dt, mark.rutland, devicetree
Cc: linux-renesas-soc, horms+renesas
In-Reply-To: <1582226.1VeLLfmmeJ@wasted.cogentembedded.com>
Add RZ/G1M (R8A7743) Clock Pulse Generator / Module Standby and Software
Reset support, using the CPG/MSSR driver core and the common R-Car Gen2
(and RZ/G) code.
Based on the proof-of-concept R8A7791 CPG/MSSR patch by Geert Uytterhoeven
<geert+renesas@glider.be>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Changes in version 3:
- exchanged Audio-DMAC0/1 entries in r8a7743_mod_clks[];
- renamed the I2C6 entry to IICDVFS;
- fixed the comment to the INTC-SYS entry in r8a7743_crit_mod_clks[];
- removed the useless EXTAL divisor check from r8a7743_cpg_mssr_init();
- added Rob's ACK and Geert's tag.
Changes in version 2:
- documented the R8A7743 device tree binding;
- fixed whitespace errors/warnings reported by checkpatch.pl;
- used tabs instead of spaces for indentation;
- fixed the PLL3 column name in the PLL table.
Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt | 4
drivers/clk/renesas/Kconfig | 1
drivers/clk/renesas/Makefile | 1
drivers/clk/renesas/r8a7743-cpg-mssr.c | 264 +++++++++++
drivers/clk/renesas/renesas-cpg-mssr.c | 6
drivers/clk/renesas/renesas-cpg-mssr.h | 1
6 files changed, 276 insertions(+), 1 deletion(-)
Index: linux/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
===================================================================
--- linux.orig/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
+++ linux/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt
@@ -13,6 +13,7 @@ They provide the following functionaliti
Required Properties:
- compatible: Must be one of:
+ - "renesas,r8a7743-cpg-mssr" for the r8a7743 SoC (RZ/G1M)
- "renesas,r8a7795-cpg-mssr" for the r8a7795 SoC (R-Car H3)
- "renesas,r8a7796-cpg-mssr" for the r8a7796 SoC (R-Car M3-W)
@@ -22,7 +23,8 @@ Required Properties:
- clocks: References to external parent clocks, one entry for each entry in
clock-names
- clock-names: List of external parent clock names. Valid names are:
- - "extal" (r8a7795, r8a7796)
+ - "extal" (r8a7743, r8a7795, r8a7796)
+ - "usb_extal" (r8a7743)
- "extalr" (r8a7795, r8a7796)
- #clock-cells: Must be 2
Index: linux/drivers/clk/renesas/Kconfig
===================================================================
--- linux.orig/drivers/clk/renesas/Kconfig
+++ linux/drivers/clk/renesas/Kconfig
@@ -1,5 +1,6 @@
config CLK_RENESAS_CPG_MSSR
bool
+ default y if ARCH_R8A7743
default y if ARCH_R8A7795
default y if ARCH_R8A7796
Index: linux/drivers/clk/renesas/Makefile
===================================================================
--- linux.orig/drivers/clk/renesas/Makefile
+++ linux/drivers/clk/renesas/Makefile
@@ -2,6 +2,7 @@ obj-$(CONFIG_ARCH_EMEV2) += clk-emev2.o
obj-$(CONFIG_ARCH_R7S72100) += clk-rz.o
obj-$(CONFIG_ARCH_R8A73A4) += clk-r8a73a4.o clk-div6.o
obj-$(CONFIG_ARCH_R8A7740) += clk-r8a7740.o clk-div6.o
+obj-$(CONFIG_ARCH_R8A7743) += r8a7743-cpg-mssr.o rcar-gen2-cpg.o
obj-$(CONFIG_ARCH_R8A7778) += clk-r8a7778.o
obj-$(CONFIG_ARCH_R8A7779) += clk-r8a7779.o
obj-$(CONFIG_ARCH_R8A7790) += clk-rcar-gen2.o clk-div6.o
Index: linux/drivers/clk/renesas/r8a7743-cpg-mssr.c
===================================================================
--- /dev/null
+++ linux/drivers/clk/renesas/r8a7743-cpg-mssr.c
@@ -0,0 +1,264 @@
+/*
+ * r8a7743 Clock Pulse Generator / Module Standby and Software Reset
+ *
+ * Copyright (C) 2016 Cogent Embedded Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation; of the License.
+ */
+
+#include <linux/device.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+
+#include <dt-bindings/clock/r8a7743-cpg-mssr.h>
+
+#include "renesas-cpg-mssr.h"
+#include "rcar-gen2-cpg.h"
+
+enum clk_ids {
+ /* Core Clock Outputs exported to DT */
+ LAST_DT_CORE_CLK = R8A7743_CLK_OSC,
+
+ /* External Input Clocks */
+ CLK_EXTAL,
+ CLK_USB_EXTAL,
+
+ /* Internal Core Clocks */
+ CLK_MAIN,
+ CLK_PLL0,
+ CLK_PLL1,
+ CLK_PLL3,
+ CLK_PLL1_DIV2,
+
+ /* Module Clocks */
+ MOD_CLK_BASE
+};
+
+static const struct cpg_core_clk r8a7743_core_clks[] __initconst = {
+ /* External Clock Inputs */
+ DEF_INPUT("extal", CLK_EXTAL),
+ DEF_INPUT("usb_extal", CLK_USB_EXTAL),
+
+ /* Internal Core Clocks */
+ DEF_BASE(".main", CLK_MAIN, CLK_TYPE_GEN2_MAIN, CLK_EXTAL),
+ DEF_BASE(".pll0", CLK_PLL0, CLK_TYPE_GEN2_PLL0, CLK_MAIN),
+ DEF_BASE(".pll1", CLK_PLL1, CLK_TYPE_GEN2_PLL1, CLK_MAIN),
+ DEF_BASE(".pll3", CLK_PLL3, CLK_TYPE_GEN2_PLL3, CLK_MAIN),
+
+ DEF_FIXED(".pll1_div2", CLK_PLL1_DIV2, CLK_PLL1, 2, 1),
+
+ /* Core Clock Outputs */
+ DEF_BASE("z", R8A7743_CLK_Z, CLK_TYPE_GEN2_Z, CLK_PLL0),
+ DEF_BASE("lb", R8A7743_CLK_LB, CLK_TYPE_GEN2_LB, CLK_PLL1),
+ DEF_BASE("sdh", R8A7743_CLK_SDH, CLK_TYPE_GEN2_SDH, CLK_PLL1),
+ DEF_BASE("sd0", R8A7743_CLK_SD0, CLK_TYPE_GEN2_SD0, CLK_PLL1),
+ DEF_BASE("qspi", R8A7743_CLK_QSPI, CLK_TYPE_GEN2_QSPI, CLK_PLL1_DIV2),
+ DEF_BASE("rcan", R8A7743_CLK_RCAN, CLK_TYPE_GEN2_RCAN, CLK_USB_EXTAL),
+
+ DEF_FIXED("zg", R8A7743_CLK_ZG, CLK_PLL1, 3, 1),
+ DEF_FIXED("zx", R8A7743_CLK_ZX, CLK_PLL1, 3, 1),
+ DEF_FIXED("zs", R8A7743_CLK_ZS, CLK_PLL1, 6, 1),
+ DEF_FIXED("hp", R8A7743_CLK_HP, CLK_PLL1, 12, 1),
+ DEF_FIXED("b", R8A7743_CLK_B, CLK_PLL1, 12, 1),
+ DEF_FIXED("p", R8A7743_CLK_P, CLK_PLL1, 24, 1),
+ DEF_FIXED("cl", R8A7743_CLK_CL, CLK_PLL1, 48, 1),
+ DEF_FIXED("m2", R8A7743_CLK_M2, CLK_PLL1, 8, 1),
+ DEF_FIXED("zb3", R8A7743_CLK_ZB3, CLK_PLL3, 4, 1),
+ DEF_FIXED("zb3d2", R8A7743_CLK_ZB3D2, CLK_PLL3, 8, 1),
+ DEF_FIXED("ddr", R8A7743_CLK_DDR, CLK_PLL3, 8, 1),
+ DEF_FIXED("mp", R8A7743_CLK_MP, CLK_PLL1_DIV2, 15, 1),
+ DEF_FIXED("cp", R8A7743_CLK_CP, CLK_EXTAL, 2, 1),
+ DEF_FIXED("r", R8A7743_CLK_R, CLK_PLL1, 49152, 1),
+ DEF_FIXED("osc", R8A7743_CLK_OSC, CLK_PLL1, 12288, 1),
+
+ DEF_DIV6P1("sd2", R8A7743_CLK_SD2, CLK_PLL1_DIV2, 0x078),
+ DEF_DIV6P1("sd3", R8A7743_CLK_SD3, CLK_PLL1_DIV2, 0x26c),
+ DEF_DIV6P1("mmc0", R8A7743_CLK_MMC0, CLK_PLL1_DIV2, 0x240),
+};
+
+static const struct mssr_mod_clk r8a7743_mod_clks[] __initconst = {
+ DEF_MOD("msiof0", 0, R8A7743_CLK_MP),
+ DEF_MOD("vcp0", 101, R8A7743_CLK_ZS),
+ DEF_MOD("vpc0", 103, R8A7743_CLK_ZS),
+ DEF_MOD("tmu1", 111, R8A7743_CLK_P),
+ DEF_MOD("3dg", 112, R8A7743_CLK_ZG),
+ DEF_MOD("2d-dmac", 115, R8A7743_CLK_ZS),
+ DEF_MOD("fdp1-1", 118, R8A7743_CLK_ZS),
+ DEF_MOD("fdp1-0", 119, R8A7743_CLK_ZS),
+ DEF_MOD("tmu3", 121, R8A7743_CLK_P),
+ DEF_MOD("tmu2", 122, R8A7743_CLK_P),
+ DEF_MOD("cmt0", 124, R8A7743_CLK_R),
+ DEF_MOD("tmu0", 125, R8A7743_CLK_CP),
+ DEF_MOD("vsp1du1", 127, R8A7743_CLK_ZS),
+ DEF_MOD("vsp1du0", 128, R8A7743_CLK_ZS),
+ DEF_MOD("vsp1-sy", 131, R8A7743_CLK_ZS),
+ DEF_MOD("scifa2", 202, R8A7743_CLK_MP),
+ DEF_MOD("scifa1", 203, R8A7743_CLK_MP),
+ DEF_MOD("scifa0", 204, R8A7743_CLK_MP),
+ DEF_MOD("msiof2", 205, R8A7743_CLK_MP),
+ DEF_MOD("scifb0", 206, R8A7743_CLK_MP),
+ DEF_MOD("scifb1", 207, R8A7743_CLK_MP),
+ DEF_MOD("msiof1", 208, R8A7743_CLK_MP),
+ DEF_MOD("scifb2", 216, R8A7743_CLK_MP),
+ DEF_MOD("sys-dmac1", 218, R8A7743_CLK_ZS),
+ DEF_MOD("sys-dmac0", 219, R8A7743_CLK_ZS),
+ DEF_MOD("tpu0", 304, R8A7743_CLK_CP),
+ DEF_MOD("sdhi3", 311, R8A7743_CLK_SD3),
+ DEF_MOD("sdhi2", 312, R8A7743_CLK_SD2),
+ DEF_MOD("sdhi0", 314, R8A7743_CLK_SD0),
+ DEF_MOD("mmcif0", 315, R8A7743_CLK_MMC0),
+ DEF_MOD("iic0", 318, R8A7743_CLK_HP),
+ DEF_MOD("pciec", 319, R8A7743_CLK_MP),
+ DEF_MOD("iic1", 323, R8A7743_CLK_HP),
+ DEF_MOD("usb3.0", 328, R8A7743_CLK_MP),
+ DEF_MOD("cmt1", 329, R8A7743_CLK_R),
+ DEF_MOD("usbhs-dmac0", 330, R8A7743_CLK_HP),
+ DEF_MOD("usbhs-dmac1", 331, R8A7743_CLK_HP),
+ DEF_MOD("irqc", 407, R8A7743_CLK_CP),
+ DEF_MOD("intc-sys", 408, R8A7743_CLK_ZS),
+ DEF_MOD("audio-dmac1", 501, R8A7743_CLK_HP),
+ DEF_MOD("audio-dmac0", 502, R8A7743_CLK_HP),
+ DEF_MOD("thermal", 522, CLK_EXTAL),
+ DEF_MOD("pwm", 523, R8A7743_CLK_P),
+ DEF_MOD("usb-ehci", 703, R8A7743_CLK_MP),
+ DEF_MOD("usbhs", 704, R8A7743_CLK_HP),
+ DEF_MOD("hscif2", 713, R8A7743_CLK_ZS),
+ DEF_MOD("scif5", 714, R8A7743_CLK_P),
+ DEF_MOD("scif4", 715, R8A7743_CLK_P),
+ DEF_MOD("hscif1", 716, R8A7743_CLK_ZS),
+ DEF_MOD("hscif0", 717, R8A7743_CLK_ZS),
+ DEF_MOD("scif3", 718, R8A7743_CLK_P),
+ DEF_MOD("scif2", 719, R8A7743_CLK_P),
+ DEF_MOD("scif1", 720, R8A7743_CLK_P),
+ DEF_MOD("scif0", 721, R8A7743_CLK_P),
+ DEF_MOD("du1", 723, R8A7743_CLK_ZX),
+ DEF_MOD("du0", 724, R8A7743_CLK_ZX),
+ DEF_MOD("lvds0", 726, R8A7743_CLK_ZX),
+ DEF_MOD("ipmmu-sgx", 800, R8A7743_CLK_ZX),
+ DEF_MOD("vin2", 809, R8A7743_CLK_ZG),
+ DEF_MOD("vin1", 810, R8A7743_CLK_ZG),
+ DEF_MOD("vin0", 811, R8A7743_CLK_ZG),
+ DEF_MOD("etheravb", 812, R8A7743_CLK_HP),
+ DEF_MOD("ether", 813, R8A7743_CLK_P),
+ DEF_MOD("sata1", 814, R8A7743_CLK_ZS),
+ DEF_MOD("sata0", 815, R8A7743_CLK_ZS),
+ DEF_MOD("gpio7", 904, R8A7743_CLK_CP),
+ DEF_MOD("gpio6", 905, R8A7743_CLK_CP),
+ DEF_MOD("gpio5", 907, R8A7743_CLK_CP),
+ DEF_MOD("gpio4", 908, R8A7743_CLK_CP),
+ DEF_MOD("gpio3", 909, R8A7743_CLK_CP),
+ DEF_MOD("gpio2", 910, R8A7743_CLK_CP),
+ DEF_MOD("gpio1", 911, R8A7743_CLK_CP),
+ DEF_MOD("gpio0", 912, R8A7743_CLK_CP),
+ DEF_MOD("can1", 915, R8A7743_CLK_P),
+ DEF_MOD("can0", 916, R8A7743_CLK_P),
+ DEF_MOD("qspi_mod", 917, R8A7743_CLK_QSPI),
+ DEF_MOD("i2c5", 925, R8A7743_CLK_HP),
+ DEF_MOD("iicdvfs", 926, R8A7743_CLK_CP),
+ DEF_MOD("i2c4", 927, R8A7743_CLK_HP),
+ DEF_MOD("i2c3", 928, R8A7743_CLK_HP),
+ DEF_MOD("i2c2", 929, R8A7743_CLK_HP),
+ DEF_MOD("i2c1", 930, R8A7743_CLK_HP),
+ DEF_MOD("i2c0", 931, R8A7743_CLK_HP),
+ DEF_MOD("ssi-all", 1005, R8A7743_CLK_P),
+ DEF_MOD("ssi9", 1006, MOD_CLK_ID(1005)),
+ DEF_MOD("ssi8", 1007, MOD_CLK_ID(1005)),
+ DEF_MOD("ssi7", 1008, MOD_CLK_ID(1005)),
+ DEF_MOD("ssi6", 1009, MOD_CLK_ID(1005)),
+ DEF_MOD("ssi5", 1010, MOD_CLK_ID(1005)),
+ DEF_MOD("ssi4", 1011, MOD_CLK_ID(1005)),
+ DEF_MOD("ssi3", 1012, MOD_CLK_ID(1005)),
+ DEF_MOD("ssi2", 1013, MOD_CLK_ID(1005)),
+ DEF_MOD("ssi1", 1014, MOD_CLK_ID(1005)),
+ DEF_MOD("ssi0", 1015, MOD_CLK_ID(1005)),
+ DEF_MOD("scu-all", 1017, R8A7743_CLK_P),
+ DEF_MOD("scu-dvc1", 1018, MOD_CLK_ID(1017)),
+ DEF_MOD("scu-dvc0", 1019, MOD_CLK_ID(1017)),
+ DEF_MOD("scu-ctu1-mix1", 1020, MOD_CLK_ID(1017)),
+ DEF_MOD("scu-ctu0-mix0", 1021, MOD_CLK_ID(1017)),
+ DEF_MOD("scu-src9", 1022, MOD_CLK_ID(1017)),
+ DEF_MOD("scu-src8", 1023, MOD_CLK_ID(1017)),
+ DEF_MOD("scu-src7", 1024, MOD_CLK_ID(1017)),
+ DEF_MOD("scu-src6", 1025, MOD_CLK_ID(1017)),
+ DEF_MOD("scu-src5", 1026, MOD_CLK_ID(1017)),
+ DEF_MOD("scu-src4", 1027, MOD_CLK_ID(1017)),
+ DEF_MOD("scu-src3", 1028, MOD_CLK_ID(1017)),
+ DEF_MOD("scu-src2", 1029, MOD_CLK_ID(1017)),
+ DEF_MOD("scu-src1", 1030, MOD_CLK_ID(1017)),
+ DEF_MOD("scu-src0", 1031, MOD_CLK_ID(1017)),
+ DEF_MOD("scifa3", 1106, R8A7743_CLK_MP),
+ DEF_MOD("scifa4", 1107, R8A7743_CLK_MP),
+ DEF_MOD("scifa5", 1108, R8A7743_CLK_MP),
+};
+
+static const unsigned int r8a7743_crit_mod_clks[] __initconst = {
+ MOD_CLK_ID(408), /* INTC-SYS (GIC) */
+};
+
+/*
+ * CPG Clock Data
+ */
+
+/*
+ * MD EXTAL PLL0 PLL1 PLL3
+ * 14 13 19 (MHz) *1 *1
+ *---------------------------------------------------
+ * 0 0 0 15 x 1 x172/2 x208/2 x106
+ * 0 0 1 15 x 1 x172/2 x208/2 x88
+ * 0 1 0 20 x 1 x130/2 x156/2 x80
+ * 0 1 1 20 x 1 x130/2 x156/2 x66
+ * 1 0 0 26 / 2 x200/2 x240/2 x122
+ * 1 0 1 26 / 2 x200/2 x240/2 x102
+ * 1 1 0 30 / 2 x172/2 x208/2 x106
+ * 1 1 1 30 / 2 x172/2 x208/2 x88
+ *
+ * *1 : Table 7.6 indicates VCO output (PLLx = VCO/2)
+ */
+#define CPG_PLL_CONFIG_INDEX(md) ((((md) & BIT(14)) >> 12) | \
+ (((md) & BIT(13)) >> 12) | \
+ (((md) & BIT(19)) >> 19))
+
+static const struct rcar_gen2_cpg_pll_config cpg_pll_configs[8] __initconst = {
+ /* EXTAL div PLL1 mult PLL3 mult */
+ { 1, 208, 106, },
+ { 1, 208, 88, },
+ { 1, 156, 80, },
+ { 1, 156, 66, },
+ { 2, 240, 122, },
+ { 2, 240, 102, },
+ { 2, 208, 106, },
+ { 2, 208, 88, },
+};
+
+static int __init r8a7743_cpg_mssr_init(struct device *dev)
+{
+ const struct rcar_gen2_cpg_pll_config *cpg_pll_config;
+ u32 cpg_mode = rcar_gen2_read_modemr();
+
+ cpg_pll_config = &cpg_pll_configs[CPG_PLL_CONFIG_INDEX(cpg_mode)];
+
+ return rcar_gen2_cpg_init(cpg_pll_config);
+}
+
+const struct cpg_mssr_info r8a7743_cpg_mssr_info __initconst = {
+ /* Core Clocks */
+ .core_clks = r8a7743_core_clks,
+ .num_core_clks = ARRAY_SIZE(r8a7743_core_clks),
+ .last_dt_core_clk = LAST_DT_CORE_CLK,
+ .num_total_core_clks = MOD_CLK_BASE,
+
+ /* Module Clocks */
+ .mod_clks = r8a7743_mod_clks,
+ .num_mod_clks = ARRAY_SIZE(r8a7743_mod_clks),
+ .num_hw_mod_clks = 12 * 32,
+
+ /* Critical Module Clocks */
+ .crit_mod_clks = r8a7743_crit_mod_clks,
+ .num_crit_mod_clks = ARRAY_SIZE(r8a7743_crit_mod_clks),
+
+ /* Callbacks */
+ .init = r8a7743_cpg_mssr_init,
+ .cpg_clk_register = rcar_gen2_cpg_clk_register,
+};
Index: linux/drivers/clk/renesas/renesas-cpg-mssr.c
===================================================================
--- linux.orig/drivers/clk/renesas/renesas-cpg-mssr.c
+++ linux/drivers/clk/renesas/renesas-cpg-mssr.c
@@ -503,6 +503,12 @@ static int __init cpg_mssr_add_clk_domai
}
static const struct of_device_id cpg_mssr_match[] = {
+#ifdef CONFIG_ARCH_R8A7743
+ {
+ .compatible = "renesas,r8a7743-cpg-mssr",
+ .data = &r8a7743_cpg_mssr_info,
+ },
+#endif
#ifdef CONFIG_ARCH_R8A7795
{
.compatible = "renesas,r8a7795-cpg-mssr",
Index: linux/drivers/clk/renesas/renesas-cpg-mssr.h
===================================================================
--- linux.orig/drivers/clk/renesas/renesas-cpg-mssr.h
+++ linux/drivers/clk/renesas/renesas-cpg-mssr.h
@@ -130,6 +130,7 @@ struct cpg_mssr_info {
struct clk **clks, void __iomem *base);
};
+extern const struct cpg_mssr_info r8a7743_cpg_mssr_info;
extern const struct cpg_mssr_info r8a7795_cpg_mssr_info;
extern const struct cpg_mssr_info r8a7796_cpg_mssr_info;
#endif
^ permalink raw reply
* Re: [RFC V2 PATCH 10/12] arm64: dts: msm8994 issolate non standard bootloader/LK entries
From: Arnd Bergmann @ 2016-10-21 20:25 UTC (permalink / raw)
To: Stephen Boyd
Cc: Bjorn Andersson, Andy Gross, Rob Herring, Jeremy McNicoll, git,
Jeremy McNicoll, linux-arm-msm, linux-soc,
devicetree@vger.kernel.org
In-Reply-To: <20161021200409.GN26139@codeaurora.org>
On Friday, October 21, 2016 1:04:09 PM CEST Stephen Boyd wrote:
> On 10/21, Bjorn Andersson wrote:
> > On Wed 19 Oct 20:17 PDT 2016, Andy Gross wrote:
> >
> > > On Wed, Oct 19, 2016 at 08:07:25PM -0500, Rob Herring wrote:
> > [..]
> > > > Makes sense to me for things like Nexus phones here. What about DB410
> > > > for example? Is there hope for a fix there? My bootloader is only a
> > > > couple of months old and needs the properties still.
> > >
> > > There won't be a fix for the 410c. We barely got them to respin to use PSCI.
> > > Stephen can correct me if I am wrong on this.
> > >
> > > If this is fixed, it would be 8996+. If..........
> > >
> > > So this means introducing the msm-id's for the boards that currently require it,
> > > and for the boards that will require it in the future. And this would stay in
> > > effect until the bootloader is able to parse the compatible strings or figure
> > > this out without the msm-ids.
> > >
> >
> > But if the bootloader at any point in the future would support picking a
> > dtb by compatible strings instead of {msm,board,pmic}-id we wouldn't we
> > just be back to the ridiculous compatible strings that tipped over into
> > acceptance to these ids in the first place.
> >
> > Or do we expect the boot loader to do a deep scan of the dtb to match on
> > multiple nodes from the tree?
>
> I'm pushing the bootloader team to do the deep scan of the dtb to
> match up board compatible and pmic compatible strings so that we
> don't have to keep these numbers around. Basically put what
> dtbtool is doing into the bootloader so we don't have to post
> process the dtb anymore. We're currently discussing how to
> implement it and how to move the internal codebase to the new
> scheme.
>
> At least for 96boards I think we can update the lk bootloaders on
> there to adopt this code. For other platforms like nexus though I
> don't see a way we can update those bootloaders, and those
> bootloaders require these properties exist in the dtbs, so we
> should just throw the numbers into the dts files there and be
> done with post processing. For bootloaders that require the QCDT
> header, we'll have to keep running dtbtool there to generate the
> header. Having the ids in the dts file or not doesn't really
> matter there.
I think part of the problem here is the way that the bootloader
expects multiple dtbs to be appended to the kernel binary, and
then pick one of them based on its contents. That doesn't really
change at all when changing the parser from looking at nonstandard
properties to looking at the compatible strings.
It still breaks the last-resort workaround for broken bootloaders
that we have in the form of appending the DT to the kernel
with CONFIG_ARM_APPENDED_DTB.
I think a better long-term strategy would be to make the bootloader
load the dtb separately from the kernel and finding the right file
using some information outside of the dtb. Ideally this is done
by storing all files on a file system that can also be mounted
to /boot, but there are probably other options that work equally well.
Arnd
^ permalink raw reply
* Re: [v7, 1/3] nand: pl353: Add basic driver for arm pl353 smc nand interface
From: Jason Gunthorpe @ 2016-10-21 20:33 UTC (permalink / raw)
To: Punnaiah Choudary Kalluri
Cc: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, rob,
michal.simek, grant.likely, gregkh, jason, ezequiel.garcia, arnd,
dwmw2, computersforpeace, artem.bityutskiy, jussi.kivilinna,
acourbot, ivan.khoronzhuk, joern, devicetree, linux-doc,
linux-kernel, linux-mtd, kpc528, kalluripunnaiahchoudary, punnaia
In-Reply-To: <1433786918-21500-2-git-send-email-punnaia@xilinx.com>
On Mon, Jun 08, 2015 at 11:38:36PM +0530, Punnaiah Choudary Kalluri wrote:
> Add driver for arm pl353 static memory controller nand interface with
> HW ECC support. This controller is used in xilinx zynq soc for interfacing
> the nand flash memory.
>
> Signed-off-by: Punnaiah Choudary Kalluri <punnaia@xilinx.com>
> Changes in v7:
> - Currently not implemented the memclk rate adjustments. I will
> look into this later and once the basic driver is accepted.
> - Fixed GPL licence ident
> Changes in v6:
> - Fixed the checkpatch.pl reported warnings
> - Using the address cycles information from the onfi param page
> earlier it is hardcoded to 5 in driver
> Changes in v5:
> - Configure the nand timing parameters as per the onfi spec
> Changes in v4:
> - Updated the driver to sync with pl353_smc driver APIs
> Changes in v3:
> - implemented the proper error codes
> - further breakdown this patch to multiple sets
> - added the controller and driver details to Documentation section
> - updated the licenece to GPLv2
> - reorganized the pl353_nand_ecc_init function
> Changes in v2:
> - use "depends on" rather than "select" option in kconfig
> - remove unused variable parts
> - remove dummy helper and use writel_relaxed directly
What is the status of getting this driver merged? I am interested in
this driver and can provide some help if there are still TODO items.
At the very least I will test it, is there something newer than v7 out
there?
Regards,
Jason
^ permalink raw reply
* [PATCH v4 0/7] Add R8A7743/SK-RZG1M board support
From: Sergei Shtylyov @ 2016-10-21 20:39 UTC (permalink / raw)
To: horms-/R6kz+dDXgpPR4JQBCEnsQ,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: magnus.damm-Re5JQEeQqe8AvxtiuMwx3w, linux-lFZ/pmaqli7XmaaqVzeoHQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Hello.
Here's the set of 8 patches against Simon Horman's 'renesas.git' repo's
'renesas-devel-20161021-v4.9-rc1' tag. I'm adding the device tree support for
the R8A7743-based SK-RZG1M board. The SoC is close to R8A7791 and the board
seems identical to the R8A7791/Porter board. The device tree patches depend on
the R8A7743 CPG/MSSR driver series just posted in order to compile and work.
Already merged patches from this series won't be re-posted.
[1/7] ARM: dts: r8a7743: initial SoC device tree
[2/7] ARM: dts: r8a7743: add SYS-DMAC support
[3/7] ARM: dts: r8a7743: add [H]SCIF{A|B} support
[4/7] ARM: dts: r8a7743: add Ether support
[5/7] ARM: dts: r8a7743: add IRQC support
[6/7] ARM: dts: sk-rzg1m: initial device tree
[7/7] ARM: dts: sk-rzg1m: add Ether support
WBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v4 1/7] ARM: dts: r8a7743: initial SoC device tree
From: Sergei Shtylyov @ 2016-10-21 20:40 UTC (permalink / raw)
To: horms-/R6kz+dDXgpPR4JQBCEnsQ,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: magnus.damm-Re5JQEeQqe8AvxtiuMwx3w, linux-lFZ/pmaqli7XmaaqVzeoHQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <2719479.geOc9vqcRS-gHKXc3Y1Z8zGSmamagVegGFoWSdPRAKMAL8bYrjMMd8@public.gmane.org>
The initial R8A7743 SoC device tree including CPU0, GIC, timer, SYSC, CPG,
and the required clock descriptions.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
---
Changes in version 4:
- removed the CPU1 node, updated the patch description accordingly;
- reformatted the "interrupts" props of the GIC/timer device nodes;
- added Geert's tag.
Changes in version 3:
- changed the R8A7743 clock header #include;
- replaced the multiple clock nodes with the single CPG node, updated the
"clocks" property in the CPU0 node, updated the patch description.
Changes in version 2:
- added the IRQC and Ether clocks.
arch/arm/boot/dts/r8a7743.dtsi | 115 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 115 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7743.dtsi
===================================================================
--- /dev/null
+++ renesas/arch/arm/boot/dts/r8a7743.dtsi
@@ -0,0 +1,115 @@
+/*
+ * Device Tree Source for the r8a7743 SoC
+ *
+ * Copyright (C) 2016 Cogent Embedded Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/clock/r8a7743-cpg-mssr.h>
+#include <dt-bindings/power/r8a7743-sysc.h>
+
+/ {
+ compatible = "renesas,r8a7743";
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ reg = <0>;
+ clock-frequency = <1500000000>;
+ clocks = <&cpg CPG_CORE R8A7743_CLK_Z>;
+ power-domains = <&sysc R8A7743_PD_CA15_CPU0>;
+ next-level-cache = <&L2_CA15>;
+ };
+
+ L2_CA15: cache-controller@0 {
+ compatible = "cache";
+ reg = <0>;
+ cache-unified;
+ cache-level = <2>;
+ power-domains = <&sysc R8A7743_PD_CA15_SCU>;
+ };
+ };
+
+ soc {
+ compatible = "simple-bus";
+ interrupt-parent = <&gic>;
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ gic: interrupt-controller@f1001000 {
+ compatible = "arm,gic-400";
+ #interrupt-cells = <3>;
+ #address-cells = <0>;
+ interrupt-controller;
+ reg = <0 0xf1001000 0 0x1000>,
+ <0 0xf1002000 0 0x1000>,
+ <0 0xf1004000 0 0x2000>,
+ <0 0xf1006000 0 0x2000>;
+ interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_HIGH)>;
+ };
+
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(2) |
+ IRQ_TYPE_LEVEL_LOW)>;
+ };
+
+ cpg: clock-controller@e6150000 {
+ compatible = "renesas,r8a7743-cpg-mssr";
+ reg = <0 0xe6150000 0 0x1000>;
+ clocks = <&extal_clk>, <&usb_extal_clk>;
+ clock-names = "extal", "usb_extal";
+ #clock-cells = <2>;
+ #power-domain-cells = <0>;
+ };
+
+ sysc: system-controller@e6180000 {
+ compatible = "renesas,r8a7743-sysc";
+ reg = <0 0xe6180000 0 0x0200>;
+ #power-domain-cells = <1>;
+ };
+ };
+
+ /* External root clock */
+ extal_clk: extal {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ /* This value must be overriden by the board. */
+ clock-frequency = <0>;
+ };
+
+ /* External USB clock - can be overridden by the board */
+ usb_extal_clk: usb_extal {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <48000000>;
+ };
+
+ /* External SCIF clock */
+ scif_clk: scif {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ /* This value must be overridden by the board. */
+ clock-frequency = <0>;
+ };
+};
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v4 2/7] ARM: dts: r8a7743: add SYS-DMAC support
From: Sergei Shtylyov @ 2016-10-21 20:41 UTC (permalink / raw)
To: horms-/R6kz+dDXgpPR4JQBCEnsQ,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: magnus.damm-Re5JQEeQqe8AvxtiuMwx3w, linux-lFZ/pmaqli7XmaaqVzeoHQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <2719479.geOc9vqcRS-gHKXc3Y1Z8zGSmamagVegGFoWSdPRAKMAL8bYrjMMd8@public.gmane.org>
Describe SYS-DMAC0/1 in the R8A7743 device tree.
Based on the original (and large) patch by Dmitry Shifrin
<dmitry.shifrin-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
---
Changes in version 4:
- refreshed the patch.
Changes in version 3:
- resolved a reject;
- updated the "clocks" properties for the CPG/MSSR driver.
Changes in version 2:
- added Geert's tag.
arch/arm/boot/dts/r8a7743.dtsi | 64 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 64 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7743.dtsi
===================================================================
--- renesas.orig/arch/arm/boot/dts/r8a7743.dtsi
+++ renesas/arch/arm/boot/dts/r8a7743.dtsi
@@ -88,6 +88,70 @@
reg = <0 0xe6180000 0 0x0200>;
#power-domain-cells = <1>;
};
+
+ dmac0: dma-controller@e6700000 {
+ compatible = "renesas,dmac-r8a7743",
+ "renesas,rcar-dmac";
+ reg = <0 0xe6700000 0 0x20000>;
+ interrupts = <GIC_SPI 197 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 201 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 202 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 203 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 204 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 205 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 206 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 214 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "error",
+ "ch0", "ch1", "ch2", "ch3",
+ "ch4", "ch5", "ch6", "ch7",
+ "ch8", "ch9", "ch10", "ch11",
+ "ch12", "ch13", "ch14";
+ clocks = <&cpg CPG_MOD 219>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ #dma-cells = <1>;
+ dma-channels = <15>;
+ };
+
+ dmac1: dma-controller@e6720000 {
+ compatible = "renesas,dmac-r8a7743",
+ "renesas,rcar-dmac";
+ reg = <0 0xe6720000 0 0x20000>;
+ interrupts = <GIC_SPI 220 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 216 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 218 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 219 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 310 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 311 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 312 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 313 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 314 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 315 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 317 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 318 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "error",
+ "ch0", "ch1", "ch2", "ch3",
+ "ch4", "ch5", "ch6", "ch7",
+ "ch8", "ch9", "ch10", "ch11",
+ "ch12", "ch13", "ch14";
+ clocks = <&cpg CPG_MOD 218>;
+ clock-names = "fck";
+ power-domains = <&sysc R8A7743_PD_ALWAYS_ON>;
+ #dma-cells = <1>;
+ dma-channels = <15>;
+ };
};
/* External root clock */
--
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
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