* [PATCH v2 13/14] ARM: dts: da850: add the SATA node
From: Bartosz Golaszewski @ 2017-01-17 12:26 UTC (permalink / raw)
To: Kevin Hilman, Sekhar Nori, Patrick Titiano, Michael Turquette,
Tejun Heo, Rob Herring, Mark Rutland, Russell King, David Lechner
Cc: linux-ide, devicetree, linux-kernel, linux-arm-kernel,
Bartosz Golaszewski
In-Reply-To: <1484655976-25382-1-git-send-email-bgolaszewski@baylibre.com>
Add the SATA node to the da850 device tree.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/boot/dts/da850.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 1f6a47d..7c32bf7 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -427,6 +427,12 @@
phy-names = "usb-phy";
status = "disabled";
};
+ sata: ahci@218000 {
+ compatible = "ti,da850-ahci";
+ reg = <0x218000 0x2000>, <0x22c018 0x4>;
+ interrupts = <67>;
+ status = "disabled";
+ };
mdio: mdio@224000 {
compatible = "ti,davinci_mdio";
#address-cells = <1>;
--
2.9.3
^ permalink raw reply related
* [PATCH v2 14/14] ARM: dts: da850-lcdk: enable the SATA node
From: Bartosz Golaszewski @ 2017-01-17 12:26 UTC (permalink / raw)
To: Kevin Hilman, Sekhar Nori, Patrick Titiano, Michael Turquette,
Tejun Heo, Rob Herring, Mark Rutland, Russell King, David Lechner
Cc: linux-ide, devicetree, linux-kernel, linux-arm-kernel,
Bartosz Golaszewski
In-Reply-To: <1484655976-25382-1-git-send-email-bgolaszewski@baylibre.com>
Enable the SATA node for da850-lcdk. We omit the pinctrl property on
purpose - the muxed SATA pins are not hooked up to anything
SATA-related on the lcdk.
The REFCLKN/P rate on the board is 100MHz, so we need a multiplier of
15 for 1.5GHz PLL rate.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
arch/arm/boot/dts/da850-lcdk.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index afcb482..fbeee3c 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -105,6 +105,10 @@
status = "okay";
};
+&sata {
+ status = "okay";
+};
+
&mdio {
pinctrl-names = "default";
pinctrl-0 = <&mdio_pins>;
--
2.9.3
^ permalink raw reply related
* Re: [PATCH 00/10] ARM: da850-lcdk: add SATA support
From: Bartosz Golaszewski @ 2017-01-17 12:34 UTC (permalink / raw)
To: Kevin Hilman, Sekhar Nori, Patrick Titiano, Michael Turquette,
Tejun Heo, Rob Herring, Mark Rutland, Russell King, David Lechner
Cc: linux-ide-u79uwXL29TY76Z2rM5mHXA, linux-devicetree, LKML, arm-soc,
Bartosz Golaszewski
In-Reply-To: <1484311084-31547-1-git-send-email-bgolaszewski-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
2017-01-13 13:37 GMT+01:00 Bartosz Golaszewski <bgolaszewski-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>:
> This series contains all the changes necessary to make SATA work on
> the da850-lcdk board.
>
> The first patch adds a clock lookup entry required for the ahci core
> to retrieve a functional clock.
>
> The second enables relevant config options for all davinci boards.
>
> The third adds device tree bindings for the ahci_da850 driver.
>
> The fourth adds a workaround for a SATA controller instability we
> detected after increasing the PLL0 frequency for proper LCD
> controller support.
>
> Patches 5 through 7 extend the ahci_da850 driver - add DT support,
> un-hardcode the clock multiplier value and add a workaround for
> a quirk present on the da850 SATA controller.
>
> Patches 8-10 add the device tree changes required to probe the driver.
>
> I'm posting the series as a whole to give all reviewers the full
> picture and visibility of the changes required, if needed I can resend
> the patches separately.
>
Superseded by v2.
--
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] ARM: davinci: da850-evm: fix read access to SPI flash
From: Fabien Parent @ 2017-01-17 12:57 UTC (permalink / raw)
To: devicetree, linux-arm-kernel, linux-kernel
Cc: khilman, nsekhar, robh+dt, mark.rutland, Fabien Parent
Read access to the SPI flash are broken on da850-evm, i.e. the data
read is not what is actually programmed on the flash.
According to the datasheet for the M25P64 part present on the da850-evm,
if the SPI frequency is higher than 20MHz then the READ command is not
usable anymore and only the FAST_READ command can be used to read data.
This commit specifies in the DTS that we should use FAST_READ command
instead of the READ command.
Signed-off-by: Fabien Parent <fparent@baylibre.com>
---
arch/arm/boot/dts/da850-evm.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 41de15fe15a2..78492a0bbbab 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -99,6 +99,7 @@
#size-cells = <1>;
compatible = "m25p64";
spi-max-frequency = <30000000>;
+ m25p,fast-read;
reg = <0>;
partition@0 {
label = "U-Boot-SPL";
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v3] mtd: spi-nor: add dt support for Everspin MRAMs
From: Cyrille Pitchen @ 2017-01-17 13:04 UTC (permalink / raw)
To: Uwe Kleine-König, Masahiko Iwamoto, Jagan Teki, Marek Vasut
Cc: Mark Rutland, devicetree, Rafał Miłecki,
Geert Uytterhoeven, kernel, linux-mtd
In-Reply-To: <20170117110338.10756-1-u.kleine-koenig@pengutronix.de>
Le 17/01/2017 à 12:03, Uwe Kleine-König a écrit :
> The MR25 family doesn't support JEDEC, so they need explicit mentioning
> in the list of supported spi IDs. This makes it possible to add these
> using for example:
>
> compatible = "everspin,mr25h40";
>
> There was already an entry for mr25h256. Move that one out of the "keep
> for compatibility" section and put in a new group for Everspin MRAMs.
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
By the way, you've forgotten to collect Marek's ack from v1 but no need to
resend for that. I wait a little bit more for some DT guy ack if they want
but otherwise I think this patch is ready to be merged into the spi-nor tree.
Thanks !
> ---
> Changes since (implicit) v1:
>
> - use Kib instead of kib
>
> Changes since v2:
>
> - update dt docs
> - handle already existing mr25h256 in m25p_ids[]
>
> Thanks to Cyrille for catching these.
>
> Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt | 2 ++
> drivers/mtd/devices/m25p80.c | 6 +++++-
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
> index 2c91c03e7eb0..3e920ec5c4d3 100644
> --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
> +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
> @@ -14,6 +14,8 @@ Required properties:
> at25df641
> at26df081a
> mr25h256
> + mr25h10
> + mr25h40
> mx25l4005a
> mx25l1606e
> mx25l6405d
> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> index 9cf7fcd28034..0e2d3a64651a 100644
> --- a/drivers/mtd/devices/m25p80.c
> +++ b/drivers/mtd/devices/m25p80.c
> @@ -288,7 +288,6 @@ static const struct spi_device_id m25p_ids[] = {
> * should be kept for backward compatibility.
> */
> {"at25df321a"}, {"at25df641"}, {"at26df081a"},
> - {"mr25h256"},
> {"mx25l4005a"}, {"mx25l1606e"}, {"mx25l6405d"}, {"mx25l12805d"},
> {"mx25l25635e"},{"mx66l51235l"},
> {"n25q064"}, {"n25q128a11"}, {"n25q128a13"}, {"n25q512a"},
> @@ -305,6 +304,11 @@ static const struct spi_device_id m25p_ids[] = {
> {"m25p40-nonjedec"}, {"m25p80-nonjedec"}, {"m25p16-nonjedec"},
> {"m25p32-nonjedec"}, {"m25p64-nonjedec"}, {"m25p128-nonjedec"},
>
> + /* Everspin MRAMs (non-JEDEC) */
> + { "mr25h256" }, /* 256 Kib, 40 MHz */
> + { "mr25h10" }, /* 1 Mib, 40 MHz */
> + { "mr25h40" }, /* 4 Mib, 40 MHz */
> +
> { },
> };
> MODULE_DEVICE_TABLE(spi, m25p_ids);
>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH v3] mtd: spi-nor: add dt support for Everspin MRAMs
From: Rafał Miłecki @ 2017-01-17 13:16 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Masahiko Iwamoto, Jagan Teki, Marek Vasut, Cyrille Pitchen,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Sascha Hauer, Geert Uytterhoeven, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <20170117110338.10756-1-u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
On 17 January 2017 at 12:03, Uwe Kleine-König
<u.kleine-koenig-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
> The MR25 family doesn't support JEDEC, so they need explicit mentioning
> in the list of supported spi IDs. This makes it possible to add these
> using for example:
>
> compatible = "everspin,mr25h40";
(...)
> diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
> index 2c91c03e7eb0..3e920ec5c4d3 100644
> --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
> +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
> @@ -14,6 +14,8 @@ Required properties:
> at25df641
> at26df081a
> mr25h256
> + mr25h10
> + mr25h40
> mx25l4005a
> mx25l1606e
> mx25l6405d
Uh, this is getting a never-ending-story...
If these chipsets don't support JEDEC, should we keep them in jedec,spi-nor.txt?
--
Rafał
--
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 0/4] cpufreq: Introduce TI CPUFreq/OPP Driver
From: Dave Gerlach @ 2017-01-17 13:18 UTC (permalink / raw)
To: Rob Herring, Viresh Kumar, Rafael J . Wysocki
Cc: linux-arm-kernel, linux-omap, linux-pm, devicetree, Tony Lindgren,
Dave Gerlach, Nishanth Menon
Hi,
This is v4 of the series to introduce the ti-cpufreq driver
which parses SoC data and provides opp-supported-hw data to the
OPP core in order to enable the proper OPPs for the silicon in use.
Based on v4.10-rc4.
History:
v3: http://www.spinics.net/lists/linux-omap/msg132733.html
v2: http://www.spinics.net/lists/linux-omap/msg131601.html
v1: http://www.spinics.net/lists/linux-omap/msg129089.html
This series has two changes from v3:
* Export dev_pm_opp_of_get_opp_desc_node for modules
* Simplify the dt binding by just providing a "syscon" phandle and
letting the driver handle offsets.
* Add a patch to remove the automatic platdev creation for am335x
and dra7 platforms as this driver will now do it. Note that this
will *not* break existing cpufreq implementations on these platforms
as the ti-cpufreq can fall back to opp v1 tables for backwards
compatibility.
DT patches to enable this driver will follow after the DT binding is merged.
Finally, branch for testing, with updated DT nodes, pushed here [1].
Regards,
Dave
[1] https://github.com/dgerlach/linux-pm/commits/upstream/ti-cpufreq-driver-new-v4
Dave Gerlach (4):
PM / OPP: Expose _of_get_opp_desc_node as dev_pm_opp API
Documentation: dt: add bindings for ti-cpufreq
cpufreq: ti: Add cpufreq driver to determine available OPPs at runtime
cpufreq: dt: Don't use generic platdev driver for ti-cpufreq platforms
.../devicetree/bindings/cpufreq/ti-cpufreq.txt | 128 ++++++++++
drivers/base/power/opp/of.c | 9 +-
drivers/cpufreq/Kconfig.arm | 11 +
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/cpufreq-dt-platdev.c | 2 -
drivers/cpufreq/ti-cpufreq.c | 272 +++++++++++++++++++++
include/linux/pm_opp.h | 6 +
7 files changed, 423 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
create mode 100644 drivers/cpufreq/ti-cpufreq.c
--
2.11.0
^ permalink raw reply
* [PATCH v4 1/4] PM / OPP: Expose _of_get_opp_desc_node as dev_pm_opp API
From: Dave Gerlach @ 2017-01-17 13:18 UTC (permalink / raw)
To: Rob Herring, Viresh Kumar, Rafael J . Wysocki
Cc: Nishanth Menon, devicetree, Dave Gerlach, Tony Lindgren, linux-pm,
linux-omap, linux-arm-kernel
In-Reply-To: <20170117131808.29798-1-d-gerlach@ti.com>
Rename _of_get_opp_desc_node to dev_pm_opp_of_get_opp_desc_node and add it
to include/linux/pm_opp.h to allow other drivers, such as platform OPP
and cpufreq drivers, to make use of it.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
v3->v4:
Export dev_pm_opp_of_get_opp_desc_node for use in modules.
drivers/base/power/opp/of.c | 9 +++++----
include/linux/pm_opp.h | 6 ++++++
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/base/power/opp/of.c b/drivers/base/power/opp/of.c
index 3f7d2591b173..fe14d231f1db 100644
--- a/drivers/base/power/opp/of.c
+++ b/drivers/base/power/opp/of.c
@@ -243,7 +243,7 @@ void dev_pm_opp_of_remove_table(struct device *dev)
EXPORT_SYMBOL_GPL(dev_pm_opp_of_remove_table);
/* Returns opp descriptor node for a device, caller must do of_node_put() */
-static struct device_node *_of_get_opp_desc_node(struct device *dev)
+struct device_node *dev_pm_opp_of_get_opp_desc_node(struct device *dev)
{
/*
* TODO: Support for multiple OPP tables.
@@ -254,6 +254,7 @@ static struct device_node *_of_get_opp_desc_node(struct device *dev)
return of_parse_phandle(dev->of_node, "operating-points-v2", 0);
}
+EXPORT_SYMBOL_GPL(dev_pm_opp_of_get_opp_desc_node);
/**
* _opp_add_static_v2() - Allocate static OPPs (As per 'v2' DT bindings)
@@ -495,7 +496,7 @@ int dev_pm_opp_of_add_table(struct device *dev)
* OPPs have two version of bindings now. The older one is deprecated,
* try for the new binding first.
*/
- opp_np = _of_get_opp_desc_node(dev);
+ opp_np = dev_pm_opp_of_get_opp_desc_node(dev);
if (!opp_np) {
/*
* Try old-deprecated bindings for backward compatibility with
@@ -605,7 +606,7 @@ int dev_pm_opp_of_get_sharing_cpus(struct device *cpu_dev,
int cpu, ret = 0;
/* Get OPP descriptor node */
- np = _of_get_opp_desc_node(cpu_dev);
+ np = dev_pm_opp_of_get_opp_desc_node(cpu_dev);
if (!np) {
dev_dbg(cpu_dev, "%s: Couldn't find opp node.\n", __func__);
return -ENOENT;
@@ -630,7 +631,7 @@ int dev_pm_opp_of_get_sharing_cpus(struct device *cpu_dev,
}
/* Get OPP descriptor node */
- tmp_np = _of_get_opp_desc_node(tcpu_dev);
+ tmp_np = dev_pm_opp_of_get_opp_desc_node(tcpu_dev);
if (!tmp_np) {
dev_err(tcpu_dev, "%s: Couldn't find opp node.\n",
__func__);
diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
index 0edd88f93904..a5b1aaeae229 100644
--- a/include/linux/pm_opp.h
+++ b/include/linux/pm_opp.h
@@ -270,6 +270,7 @@ void dev_pm_opp_of_remove_table(struct device *dev);
int dev_pm_opp_of_cpumask_add_table(const struct cpumask *cpumask);
void dev_pm_opp_of_cpumask_remove_table(const struct cpumask *cpumask);
int dev_pm_opp_of_get_sharing_cpus(struct device *cpu_dev, struct cpumask *cpumask);
+struct device_node *dev_pm_opp_of_get_opp_desc_node(struct device *dev);
#else
static inline int dev_pm_opp_of_add_table(struct device *dev)
{
@@ -293,6 +294,11 @@ static inline int dev_pm_opp_of_get_sharing_cpus(struct device *cpu_dev, struct
{
return -ENOTSUPP;
}
+
+static inline struct device_node *dev_pm_opp_of_get_opp_desc_node(struct device *dev)
+{
+ return NULL;
+}
#endif
#endif /* __LINUX_OPP_H__ */
--
2.11.0
^ permalink raw reply related
* [PATCH v4 2/4] Documentation: dt: add bindings for ti-cpufreq
From: Dave Gerlach @ 2017-01-17 13:18 UTC (permalink / raw)
To: Rob Herring, Viresh Kumar, Rafael J . Wysocki
Cc: Nishanth Menon, devicetree, Dave Gerlach, Tony Lindgren, linux-pm,
linux-omap, linux-arm-kernel
In-Reply-To: <20170117131808.29798-1-d-gerlach@ti.com>
Add the device tree bindings document for the TI CPUFreq/OPP driver
on AM33xx, AM43xx, DRA7xx, and AM57xx SoCs. The operating-points-v2
binding allows us to provide an opp-supported-hw property for each OPP
to define when it is available. This driver is responsible for reading
and parsing registers to determine which OPPs can be selectively enabled
based on the specific SoC in use by matching against the opp-supported-hw
data.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
v3->v4:
Update to simplify binding, only use "syscon" now to pass control
module register space and let driver handle offsets.
.../devicetree/bindings/cpufreq/ti-cpufreq.txt | 128 +++++++++++++++++++++
1 file changed, 128 insertions(+)
create mode 100644 Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
diff --git a/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
new file mode 100644
index 000000000000..58efa4c72545
--- /dev/null
+++ b/Documentation/devicetree/bindings/cpufreq/ti-cpufreq.txt
@@ -0,0 +1,128 @@
+TI CPUFreq and OPP bindings
+================================
+
+Certain TI SoCs, like those in the am335x, am437x, am57xx, and dra7xx
+families support different OPPs depending on the silicon variant in use.
+The ti-cpufreq driver can use revision and an efuse value from the SoC to
+provide the OPP framework with supported hardware information. This is
+used to determine which OPPs from the operating-points-v2 table get enabled
+when it is parsed by the OPP framework.
+
+Required properties:
+--------------------
+In 'cpus' nodes:
+- operating-points-v2: Phandle to the operating-points-v2 table to use.
+
+In 'operating-points-v2' table:
+- compatible: Should be
+ - 'operating-points-v2-ti-cpu' for am335x, am43xx, and dra7xx/am57xx SoCs
+- syscon: A phandle pointing to a syscon node representing the control module
+ register space of the SoC.
+
+Optional properties:
+--------------------
+For each opp entry in 'operating-points-v2' table:
+- opp-supported-hw: Two bitfields indicating:
+ 1. Which revision of the SoC the OPP is supported by
+ 2. Which eFuse bits indicate this OPP is available
+
+ A bitwise AND is performed against these values and if any bit
+ matches, the OPP gets enabled.
+
+Example:
+--------
+
+/* From arch/arm/boot/dts/am33xx.dtsi */
+cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cpu@0 {
+ compatible = "arm,cortex-a8";
+ device_type = "cpu";
+ reg = <0>;
+
+ operating-points-v2 = <&cpu0_opp_table>;
+
+ clocks = <&dpll_mpu_ck>;
+ clock-names = "cpu";
+
+ clock-latency = <300000>; /* From omap-cpufreq driver */
+ };
+};
+
+/*
+ * cpu0 has different OPPs depending on SoC revision and some on revisions
+ * 0x2 and 0x4 have eFuse bits that indicate if they are available or not
+ */
+cpu0_opp_table: opp_table0 {
+ compatible = "operating-points-v2-ti-cpu";
+ syscon = <&scm_conf>;
+
+ /*
+ * The three following nodes are marked with opp-suspend
+ * because they can not be enabled simultaneously on a
+ * single SoC.
+ */
+ opp50@300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ opp-microvolt = <950000 931000 969000>;
+ opp-supported-hw = <0x06 0x0010>;
+ opp-suspend;
+ };
+
+ opp100@275000000 {
+ opp-hz = /bits/ 64 <275000000>;
+ opp-microvolt = <1100000 1078000 1122000>;
+ opp-supported-hw = <0x01 0x00FF>;
+ opp-suspend;
+ };
+
+ opp100@300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ opp-microvolt = <1100000 1078000 1122000>;
+ opp-supported-hw = <0x06 0x0020>;
+ opp-suspend;
+ };
+
+ opp100@500000000 {
+ opp-hz = /bits/ 64 <500000000>;
+ opp-microvolt = <1100000 1078000 1122000>;
+ opp-supported-hw = <0x01 0xFFFF>;
+ };
+
+ opp100@600000000 {
+ opp-hz = /bits/ 64 <600000000>;
+ opp-microvolt = <1100000 1078000 1122000>;
+ opp-supported-hw = <0x06 0x0040>;
+ };
+
+ opp120@600000000 {
+ opp-hz = /bits/ 64 <600000000>;
+ opp-microvolt = <1200000 1176000 1224000>;
+ opp-supported-hw = <0x01 0xFFFF>;
+ };
+
+ opp120@720000000 {
+ opp-hz = /bits/ 64 <720000000>;
+ opp-microvolt = <1200000 1176000 1224000>;
+ opp-supported-hw = <0x06 0x0080>;
+ };
+
+ oppturbo@720000000 {
+ opp-hz = /bits/ 64 <720000000>;
+ opp-microvolt = <1260000 1234800 1285200>;
+ opp-supported-hw = <0x01 0xFFFF>;
+ };
+
+ oppturbo@800000000 {
+ opp-hz = /bits/ 64 <800000000>;
+ opp-microvolt = <1260000 1234800 1285200>;
+ opp-supported-hw = <0x06 0x0100>;
+ };
+
+ oppnitro@1000000000 {
+ opp-hz = /bits/ 64 <1000000000>;
+ opp-microvolt = <1325000 1298500 1351500>;
+ opp-supported-hw = <0x04 0x0200>;
+ };
+};
--
2.11.0
^ permalink raw reply related
* [PATCH v4 3/4] cpufreq: ti: Add cpufreq driver to determine available OPPs at runtime
From: Dave Gerlach @ 2017-01-17 13:18 UTC (permalink / raw)
To: Rob Herring, Viresh Kumar, Rafael J . Wysocki
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Tony Lindgren, Dave Gerlach,
Nishanth Menon
In-Reply-To: <20170117131808.29798-1-d-gerlach-l0cyMroinI0@public.gmane.org>
Some TI SoCs, like those in the AM335x, AM437x, DRA7x, and AM57x families,
have different OPPs available for the MPU depending on which specific
variant of the SoC is in use. This can be determined through use of the
revision and an eFuse register present in the silicon. Introduce a
ti-cpufreq driver that can read the aformentioned values and provide
them as version matching data to the opp framework. Through this the
opp-supported-hw dt binding that is part of the operating-points-v2
table can be used to indicate availability of OPPs for each device.
This driver also creates the "cpufreq-dt" platform_device after passing
the version matching data to the OPP framework so that the cpufreq-dt
handles the actual cpufreq implementation. Even without the necessary
data to pass the version matching data the driver will still create this
device to maintain backwards compatibility with operating-points v1
tables.
Signed-off-by: Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org>
---
v3->v4:
Update to use simplified binding, only use "syscon" now to pass control
module register space and add offsets to relevant data for each SoC.
drivers/cpufreq/Kconfig.arm | 11 ++
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/ti-cpufreq.c | 272 +++++++++++++++++++++++++++++++++++++++++++
3 files changed, 284 insertions(+)
create mode 100644 drivers/cpufreq/ti-cpufreq.c
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index 920c469f3953..6d87742fc5aa 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -247,6 +247,17 @@ config ARM_TEGRA124_CPUFREQ
help
This adds the CPUFreq driver support for Tegra124 SOCs.
+config ARM_TI_CPUFREQ
+ bool "Texas Instruments CPUFreq support"
+ depends on ARCH_OMAP2PLUS
+ help
+ This driver enables valid OPPs on the running platform based on
+ values contained within the SoC in use. Enable this in order to
+ use the cpufreq-dt driver on all Texas Instruments platforms that
+ provide dt based operating-points-v2 tables with opp-supported-hw
+ data provided. Required for cpufreq support on AM335x, AM437x,
+ DRA7x, and AM57x platforms.
+
config ARM_PXA2xx_CPUFREQ
tristate "Intel PXA2xx CPUfreq driver"
depends on PXA27x || PXA25x
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 1e46c3918e7a..2078a0f212d8 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -77,6 +77,7 @@ obj-$(CONFIG_ARM_SPEAR_CPUFREQ) += spear-cpufreq.o
obj-$(CONFIG_ARM_STI_CPUFREQ) += sti-cpufreq.o
obj-$(CONFIG_ARM_TEGRA20_CPUFREQ) += tegra20-cpufreq.o
obj-$(CONFIG_ARM_TEGRA124_CPUFREQ) += tegra124-cpufreq.o
+obj-$(CONFIG_ARM_TI_CPUFREQ) += ti-cpufreq.o
obj-$(CONFIG_ARM_VEXPRESS_SPC_CPUFREQ) += vexpress-spc-cpufreq.o
obj-$(CONFIG_ACPI_CPPC_CPUFREQ) += cppc_cpufreq.o
obj-$(CONFIG_MACH_MVEBU_V7) += mvebu-cpufreq.o
diff --git a/drivers/cpufreq/ti-cpufreq.c b/drivers/cpufreq/ti-cpufreq.c
new file mode 100644
index 000000000000..a2a4e84c6166
--- /dev/null
+++ b/drivers/cpufreq/ti-cpufreq.c
@@ -0,0 +1,272 @@
+/*
+ * TI CPUFreq/OPP hw-supported driver
+ *
+ * Copyright (C) 2016-2017 Texas Instruments, Inc.
+ * 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/cpu.h>
+#include <linux/io.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/pm_opp.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+
+#define REVISION_MASK 0xF
+#define REVISION_SHIFT 28
+
+#define AM33XX_800M_ARM_MPU_MAX_FREQ 0x1E2F
+#define AM43XX_600M_ARM_MPU_MAX_FREQ 0xFFA
+
+#define DRA7_EFUSE_HAS_OD_MPU_OPP 11
+#define DRA7_EFUSE_HAS_HIGH_MPU_OPP 15
+#define DRA7_EFUSE_HAS_ALL_MPU_OPP 23
+
+#define DRA7_EFUSE_NOM_MPU_OPP BIT(0)
+#define DRA7_EFUSE_OD_MPU_OPP BIT(1)
+#define DRA7_EFUSE_HIGH_MPU_OPP BIT(2)
+
+#define VERSION_COUNT 2
+
+struct ti_cpufreq_data;
+
+struct ti_cpufreq_soc_data {
+ unsigned long (*efuse_xlate)(struct ti_cpufreq_data *opp_data,
+ unsigned long efuse);
+ unsigned long efuse_fallback;
+ unsigned long efuse_offset;
+ unsigned long efuse_mask;
+ unsigned long efuse_shift;
+ unsigned long rev_offset;
+};
+
+struct ti_cpufreq_data {
+ struct device *cpu_dev;
+ struct device_node *opp_node;
+ struct regmap *syscon;
+ const struct ti_cpufreq_soc_data *soc_data;
+};
+
+static unsigned long amx3_efuse_xlate(struct ti_cpufreq_data *opp_data,
+ unsigned long efuse)
+{
+ if (!efuse)
+ efuse = opp_data->soc_data->efuse_fallback;
+ /* AM335x and AM437x use "OPP disable" bits, so invert */
+ return ~efuse;
+}
+
+static unsigned long dra7_efuse_xlate(struct ti_cpufreq_data *opp_data,
+ unsigned long efuse)
+{
+ unsigned long calculated_efuse = DRA7_EFUSE_NOM_MPU_OPP;
+
+ /*
+ * The efuse on dra7 and am57 parts contains a specific
+ * value indicating the highest available OPP.
+ */
+
+ switch (efuse) {
+ case DRA7_EFUSE_HAS_ALL_MPU_OPP:
+ case DRA7_EFUSE_HAS_HIGH_MPU_OPP:
+ calculated_efuse |= DRA7_EFUSE_HIGH_MPU_OPP;
+ case DRA7_EFUSE_HAS_OD_MPU_OPP:
+ calculated_efuse |= DRA7_EFUSE_OD_MPU_OPP;
+ }
+
+ return calculated_efuse;
+}
+
+static struct ti_cpufreq_soc_data am3x_soc_data = {
+ .efuse_xlate = amx3_efuse_xlate,
+ .efuse_fallback = AM33XX_800M_ARM_MPU_MAX_FREQ,
+ .efuse_offset = 0x07fc,
+ .efuse_mask = 0x1fff,
+ .rev_offset = 0x600,
+};
+
+static struct ti_cpufreq_soc_data am4x_soc_data = {
+ .efuse_xlate = amx3_efuse_xlate,
+ .efuse_fallback = AM43XX_600M_ARM_MPU_MAX_FREQ,
+ .efuse_offset = 0x0610,
+ .efuse_mask = 0x3f,
+ .rev_offset = 0x600,
+};
+
+static struct ti_cpufreq_soc_data dra7_soc_data = {
+ .efuse_xlate = dra7_efuse_xlate,
+ .efuse_offset = 0x020c,
+ .efuse_mask = 0xf80000,
+ .efuse_shift = 19,
+ .rev_offset = 0x204,
+};
+
+/**
+ * ti_cpufreq_get_efuse() - Parse and return efuse value present on SoC
+ * @opp_data: pointer to ti_cpufreq_data context
+ * @efuse_value: Set to the value parsed from efuse
+ *
+ * Returns error code if efuse not read properly.
+ */
+static int ti_cpufreq_get_efuse(struct ti_cpufreq_data *opp_data,
+ u32 *efuse_value)
+{
+ struct device *dev = opp_data->cpu_dev;
+ u32 efuse;
+ int ret;
+
+ ret = regmap_read(opp_data->syscon, opp_data->soc_data->efuse_offset,
+ &efuse);
+ if (ret) {
+ dev_err(dev,
+ "Failed to read the efuse value from syscon: %d\n",
+ ret);
+ return ret;
+ }
+
+ efuse = (efuse & opp_data->soc_data->efuse_mask);
+ efuse >>= opp_data->soc_data->efuse_shift;
+
+ *efuse_value = opp_data->soc_data->efuse_xlate(opp_data, efuse);
+
+ return 0;
+}
+
+/**
+ * ti_cpufreq_get_rev() - Parse and return rev value present on SoC
+ * @opp_data: pointer to ti_cpufreq_data context
+ * @revision_value: Set to the value parsed from revision register
+ *
+ * Returns error code if revision not read properly.
+ */
+static int ti_cpufreq_get_rev(struct ti_cpufreq_data *opp_data,
+ u32 *revision_value)
+{
+ struct device *dev = opp_data->cpu_dev;
+ u32 revision;
+ int ret;
+
+ ret = regmap_read(opp_data->syscon, opp_data->soc_data->rev_offset,
+ &revision);
+ if (ret) {
+ dev_err(dev,
+ "Failed to read the revision number from syscon: %d\n",
+ ret);
+ return ret;
+ }
+
+ *revision_value = BIT((revision >> REVISION_SHIFT) & REVISION_MASK);
+
+ return 0;
+}
+
+static int ti_cpufreq_setup_syscon_register(struct ti_cpufreq_data *opp_data)
+{
+ struct device *dev = opp_data->cpu_dev;
+ struct device_node *np = opp_data->opp_node;
+
+ opp_data->syscon = syscon_regmap_lookup_by_phandle(np,
+ "syscon");
+ if (IS_ERR(opp_data->syscon)) {
+ dev_err(dev,
+ "\"syscon\" is missing, cannot use OPPv2 table.\n");
+ return PTR_ERR(opp_data->syscon);
+ }
+
+ return 0;
+}
+
+static const struct of_device_id ti_cpufreq_of_match[] = {
+ { .compatible = "ti,am33xx", .data = &am3x_soc_data, },
+ { .compatible = "ti,am4372", .data = &am4x_soc_data, },
+ { .compatible = "ti,dra7", .data = &dra7_soc_data },
+ {},
+};
+
+static int ti_cpufreq_init(void)
+{
+ u32 version[VERSION_COUNT];
+ struct device_node *np;
+ const struct of_device_id *match;
+ struct ti_cpufreq_data *opp_data;
+ int ret;
+
+ np = of_find_node_by_path("/");
+ match = of_match_node(ti_cpufreq_of_match, np);
+ if (!match)
+ return -ENODEV;
+
+ opp_data = kzalloc(sizeof(*opp_data), GFP_KERNEL);
+ if (!opp_data)
+ return -ENOMEM;
+
+ opp_data->soc_data = match->data;
+
+ opp_data->cpu_dev = get_cpu_device(0);
+ if (!opp_data->cpu_dev) {
+ pr_err("%s: Failed to get device for CPU0\n", __func__);
+ return -ENODEV;
+ }
+
+ opp_data->opp_node = dev_pm_opp_of_get_opp_desc_node(opp_data->cpu_dev);
+ if (!opp_data->opp_node) {
+ dev_info(opp_data->cpu_dev,
+ "OPP-v2 not supported, cpufreq-dt will attempt to use legacy tables.\n");
+ goto register_cpufreq_dt;
+ }
+
+ ret = ti_cpufreq_setup_syscon_register(opp_data);
+ if (ret)
+ goto fail_put_node;
+
+ /*
+ * OPPs determine whether or not they are supported based on
+ * two metrics:
+ * 0 - SoC Revision
+ * 1 - eFuse value
+ */
+ ret = ti_cpufreq_get_rev(opp_data, &version[0]);
+ if (ret)
+ goto fail_put_node;
+
+ ret = ti_cpufreq_get_efuse(opp_data, &version[1]);
+ if (ret)
+ goto fail_put_node;
+
+ of_node_put(opp_data->opp_node);
+
+ ret = dev_pm_opp_set_supported_hw(opp_data->cpu_dev, version,
+ VERSION_COUNT);
+ if (ret) {
+ dev_err(opp_data->cpu_dev,
+ "Failed to set supported hardware\n");
+ goto fail_put_node;
+ }
+
+register_cpufreq_dt:
+ platform_device_register_simple("cpufreq-dt", -1, NULL, 0);
+
+ return 0;
+
+fail_put_node:
+ of_node_put(opp_data->opp_node);
+
+ return ret;
+}
+module_init(ti_cpufreq_init);
+
+MODULE_DESCRIPTION("TI CPUFreq/OPP hw-supported driver");
+MODULE_AUTHOR("Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org>");
+MODULE_LICENSE("GPL v2");
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v4 4/4] cpufreq: dt: Don't use generic platdev driver for ti-cpufreq platforms
From: Dave Gerlach @ 2017-01-17 13:18 UTC (permalink / raw)
To: Rob Herring, Viresh Kumar, Rafael J . Wysocki
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Tony Lindgren, Dave Gerlach,
Nishanth Menon
In-Reply-To: <20170117131808.29798-1-d-gerlach-l0cyMroinI0@public.gmane.org>
Some TI platforms, specifically those in the am33xx, am43xx, dra7xx, and
am57xx families of SoCs can make use of the ti-cpufreq driver to
selectively enable OPPs based on the exact configuration in use. The
ti-cpufreq is given the responsibility of creating the cpufreq-dt
platform device when the driver is in use so drop am33xx and dra7xx
from the cpufreq-dt-platdev driver so it is not created twice.
Signed-off-by: Dave Gerlach <d-gerlach-l0cyMroinI0@public.gmane.org>
---
drivers/cpufreq/cpufreq-dt-platdev.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index 7fcaf26e8f81..921b4a6c3d16 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -87,8 +87,6 @@ static const struct of_device_id machines[] __initconst = {
{ .compatible = "socionext,uniphier-ld11", },
{ .compatible = "socionext,uniphier-ld20", },
- { .compatible = "ti,am33xx", },
- { .compatible = "ti,dra7", },
{ .compatible = "ti,omap2", },
{ .compatible = "ti,omap3", },
{ .compatible = "ti,omap4", },
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v4 3/4] arm64: dts: juno: add CoreSight support for Juno r1/r2 variants
From: Suzuki K Poulose @ 2017-01-17 13:27 UTC (permalink / raw)
To: Sudeep Holla, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: Mike Leach, Mathieu Poirier, Lorenzo Pieralisi,
coresight-cunTk1MwBs8s++Sfvej+rw, Liviu Dudau,
devicetree-u79uwXL29TY76Z2rM5mHXA, Olof Johansson
In-Reply-To: <1484655313-9025-4-git-send-email-sudeep.holla-5wv7dgnIgG8@public.gmane.org>
On 17/01/17 12:15, Sudeep Holla wrote:
> From: Mike Leach <mike.leach-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>
> The CoreSight support added for Juno is valid for only Juno r0.
> The Juno r1 and r2 variants have additional components and alternative
> connection routes between trace source and sinks.
>
> This patch builds on top of the existing r0 support and extends it to
> Juno r1/r2 variants.
>
> Reviewed-by: Mathieu Poirier <mathieu.poirier-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Signed-off-by: Mike Leach <mike.leach-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> [sudeep.holla-5wv7dgnIgG8@public.gmane.org: minor changelog update and major reorganisation of
> the common coresight components back into juno-base.dtsi to avoid
> duplication, also renamed funnel node names]
> Signed-off-by: Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>
> ---
> arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi | 100 ++++++++++++++++++++++++++++++
> arch/arm64/boot/dts/arm/juno-r1.dts | 9 +++
> arch/arm64/boot/dts/arm/juno-r2.dts | 9 +++
> 3 files changed, 118 insertions(+)
> create mode 100644 arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
>
> diff --git a/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi b/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
> new file mode 100644
> index 000000000000..563463ed28c7
> --- /dev/null
> +++ b/arch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi
> @@ -0,0 +1,100 @@
> +/ {
> + funnel@20130000 { /* cssys2 */
Typo, that should be csys1. Rest looks good to me.
Reviewed-by: Suzuki K Poulose <suzuki.poulose-5wv7dgnIgG8@public.gmane.org>
--
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 1/2] arm64: dts: exynos: Add USB 3.0 controller node for Exynos7
From: Javier Martinez Canillas @ 2017-01-17 13:37 UTC (permalink / raw)
To: Pankaj Dubey, linux-samsung-soc, linux-arm-kernel, devicetree
Cc: krzk, kgene, robh+dt, sanath, gautamvivek1987
In-Reply-To: <1484649143-19423-2-git-send-email-pankaj.dubey@samsung.com>
Hello Pankaj,
On 01/17/2017 07:32 AM, Pankaj Dubey wrote:
> Add USB 3.0 DRD controller device node, with its clock
> and phy information to enable the same on Exynos7.
>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> Signed-off-by: Vivek Gautam <gautamvivek1987@gmail.com>
The S-o-B order isn't correct. You are the one posting the patch so
yours should be the last one.
Also, wasn't this patch originally from Vivek? If you didn't change
that much, I think that he should be listed as the patch author.
I don't have an Exynos7 manual to verify but the patch looks good.
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* Re: [PATCH v4 4/4] arm64: dts: juno: add missing CoreSight STM component
From: Suzuki K Poulose @ 2017-01-17 13:39 UTC (permalink / raw)
To: Sudeep Holla, linux-arm-kernel
Cc: devicetree, Lorenzo Pieralisi, Mathieu Poirier, coresight,
Liviu Dudau, Olof Johansson, Mike Leach
In-Reply-To: <1484655313-9025-5-git-send-email-sudeep.holla@arm.com>
On 17/01/17 12:15, Sudeep Holla wrote:
> From: Mike Leach <mike.leach@linaro.org>
>
> This patch adds the missing CoreSight STM component definition to the
> device tree of all the juno variants(r0,r1,r2)
>
> STM component is connected to different funnels depending on Juno
> platform variant.
>
> Reviewed-and-Tested-by: Mathieu Poirier <mathieu.poirier@linaro.org>
> Signed-off-by: Mike Leach <mike.leach@linaro.org>
> [sudeep.holla@arm.com: minor changelog update and reorganising the STM
> node back into juno-base.dtsi to avoid duplication]
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> arch/arm64/boot/dts/arm/juno-base.dtsi | 15 +++++++++++++++
> arch/arm64/boot/dts/arm/juno-r1.dts | 4 ++++
> arch/arm64/boot/dts/arm/juno-r2.dts | 4 ++++
> arch/arm64/boot/dts/arm/juno.dts | 16 ++++++++++++++++
> 4 files changed, 39 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi b/arch/arm64/boot/dts/arm/juno-base.dtsi
> index faedf357db3b..58c1773c3aa4 100644
> --- a/arch/arm64/boot/dts/arm/juno-base.dtsi
> +++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
> @@ -185,6 +185,21 @@
> };
> };
>
> + stm@20100000 {
> + compatible = "arm,coresight-stm", "arm,primecell";
> + reg = <0 0x20100000 0 0x1000>,
> + <0 0x28000000 0 0x180000>;
The size of the stimulus base is 16MB (as per TRM), implies => 0x1000000.
with that fixed :
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
^ permalink raw reply
* [PATCH v2 0/7] dmaengine: cppi41: Make CPPI 4.1 driver more generic
From: Alexandre Bailon @ 2017-01-17 13:45 UTC (permalink / raw)
To: vinod.koul-ral2JQCrhuEAvxtiuMwx3w, b-liu-l0cyMroinI0,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: dmaengine-u79uwXL29TY76Z2rM5mHXA, nsekhar-l0cyMroinI0,
khilman-rdvid1DuHRBWk0Htik3J/w, ptitiano-rdvid1DuHRBWk0Htik3J/w,
tony-4v6yS6AI5VpBDgjK7y7TUQ, linux-omap-u79uwXL29TY76Z2rM5mHXA,
sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8,
devicetree-u79uwXL29TY76Z2rM5mHXA, Alexandre Bailon
Most of the patch of this series were part of
"[PATCH 00/11] dmaengine: cppi41: Add dma support to da8xx"
This series intend to make the CPPI 4.1 more generic in order to
add a new platform (the DA8xx).
To achieve that, all the IRQ code present in CPPI 4.1 driver has been moved
to MUSB DSPS driver.
Other changes mainly update the glue layer and platform code to make the
whole driver more generic.
This series needs the patchset
"[PATCH v2 0/2] usb: musb: cppi41: Add a way to manage DMA irq" to build.
Alexandre Bailon (7):
usb: musb: dsps: Manage CPPI 4.1 DMA interrupt in dsps
usb: usb: dsps: update device tree bindings
dmaengine: cppi41: Remove usbss_mem
dmaengine: cppi41: rename platform variables
dmaengine: cppi41: Move some constants to glue layer
dmaengine: cppi41: init_sched(): Get number of channels from DT
dmaengine: cppi41: Fix a race between PM runtime and channel abort
.../devicetree/bindings/usb/am33xx-usb.txt | 9 +-
drivers/dma/cppi41.c | 120 +++++++++++----------
drivers/usb/musb/musb_dsps.c | 73 ++++++++++++-
3 files changed, 138 insertions(+), 64 deletions(-)
--
2.10.2
--
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 v2 1/7] usb: musb: dsps: Manage CPPI 4.1 DMA interrupt in dsps
From: Alexandre Bailon @ 2017-01-17 13:45 UTC (permalink / raw)
To: vinod.koul-ral2JQCrhuEAvxtiuMwx3w, b-liu-l0cyMroinI0,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: dmaengine-u79uwXL29TY76Z2rM5mHXA, nsekhar-l0cyMroinI0,
khilman-rdvid1DuHRBWk0Htik3J/w, ptitiano-rdvid1DuHRBWk0Htik3J/w,
tony-4v6yS6AI5VpBDgjK7y7TUQ, linux-omap-u79uwXL29TY76Z2rM5mHXA,
sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8,
devicetree-u79uwXL29TY76Z2rM5mHXA, Alexandre Bailon
In-Reply-To: <20170117134540.9988-1-abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Despite the CPPI 4.1 is a generic DMA, it is tied to USB.
On the dsps, CPPI 4.1 interrupt's registers are in USBSS (the MUSB glue).
Currently, to enable / disable and clear interrupts, the CPPI 4.1 driver
maps and accesses to USBSS's register, which making CPPI 4.1 driver not
really generic.
Move the interrupt management to dsps driver.
Signed-off-by: Alexandre Bailon <abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
---
drivers/dma/cppi41.c | 28 +++++------------
drivers/usb/musb/musb_dsps.c | 73 ++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 78 insertions(+), 23 deletions(-)
diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
index d5ba43a..4999e7d 100644
--- a/drivers/dma/cppi41.c
+++ b/drivers/dma/cppi41.c
@@ -79,14 +79,6 @@
#define QMGR_QUEUE_C(n) (0x2008 + (n) * 0x10)
#define QMGR_QUEUE_D(n) (0x200c + (n) * 0x10)
-/* Glue layer specific */
-/* USBSS / USB AM335x */
-#define USBSS_IRQ_STATUS 0x28
-#define USBSS_IRQ_ENABLER 0x2c
-#define USBSS_IRQ_CLEARR 0x30
-
-#define USBSS_IRQ_PD_COMP (1 << 2)
-
/* Packet Descriptor */
#define PD2_ZERO_LENGTH (1 << 19)
@@ -288,14 +280,8 @@ static irqreturn_t cppi41_irq(int irq, void *data)
{
struct cppi41_dd *cdd = data;
struct cppi41_channel *c;
- u32 status;
int i;
- status = cppi_readl(cdd->usbss_mem + USBSS_IRQ_STATUS);
- if (!(status & USBSS_IRQ_PD_COMP))
- return IRQ_NONE;
- cppi_writel(status, cdd->usbss_mem + USBSS_IRQ_STATUS);
-
for (i = QMGR_PENDING_SLOT_Q(FIST_COMPLETION_QUEUE); i < QMGR_NUM_PEND;
i++) {
u32 val;
@@ -599,6 +585,7 @@ static void cppi41_compute_td_desc(struct cppi41_desc *d)
static int cppi41_tear_down_chan(struct cppi41_channel *c)
{
+ struct dmaengine_result abort_result;
struct cppi41_dd *cdd = c->cdd;
struct cppi41_desc *td;
u32 reg;
@@ -682,6 +669,12 @@ static int cppi41_tear_down_chan(struct cppi41_channel *c)
c->td_seen = 0;
c->td_desc_seen = 0;
cppi_writel(0, c->gcr_reg);
+
+ /* Invoke the callback to do the necessary clean-up */
+ abort_result.result = DMA_TRANS_ABORTED;
+ dma_cookie_complete(&c->txd);
+ dmaengine_desc_get_callback_invoke(&c->txd, &abort_result);
+
return 0;
}
@@ -1044,8 +1037,6 @@ static int cppi41_dma_probe(struct platform_device *pdev)
goto err_irq;
}
- cppi_writel(USBSS_IRQ_PD_COMP, cdd->usbss_mem + USBSS_IRQ_ENABLER);
-
ret = devm_request_irq(&pdev->dev, irq, glue_info->isr, IRQF_SHARED,
dev_name(dev), cdd);
if (ret)
@@ -1069,7 +1060,6 @@ static int cppi41_dma_probe(struct platform_device *pdev)
dma_async_device_unregister(&cdd->ddev);
err_dma_reg:
err_irq:
- cppi_writel(0, cdd->usbss_mem + USBSS_IRQ_CLEARR);
cleanup_chans(cdd);
err_chans:
deinit_cppi41(dev, cdd);
@@ -1097,7 +1087,6 @@ static int cppi41_dma_remove(struct platform_device *pdev)
of_dma_controller_free(pdev->dev.of_node);
dma_async_device_unregister(&cdd->ddev);
- cppi_writel(0, cdd->usbss_mem + USBSS_IRQ_CLEARR);
devm_free_irq(&pdev->dev, cdd->irq, cdd);
cleanup_chans(cdd);
deinit_cppi41(&pdev->dev, cdd);
@@ -1116,7 +1105,6 @@ static int __maybe_unused cppi41_suspend(struct device *dev)
struct cppi41_dd *cdd = dev_get_drvdata(dev);
cdd->dma_tdfdq = cppi_readl(cdd->ctrl_mem + DMA_TDFDQ);
- cppi_writel(0, cdd->usbss_mem + USBSS_IRQ_CLEARR);
disable_sched(cdd);
return 0;
@@ -1142,8 +1130,6 @@ static int __maybe_unused cppi41_resume(struct device *dev)
cppi_writel(QMGR_SCRATCH_SIZE, cdd->qmgr_mem + QMGR_LRAM_SIZE);
cppi_writel(0, cdd->qmgr_mem + QMGR_LRAM1_BASE);
- cppi_writel(USBSS_IRQ_PD_COMP, cdd->usbss_mem + USBSS_IRQ_ENABLER);
-
return 0;
}
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 9f125e1..2a20eef 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -121,6 +121,7 @@ struct dsps_glue {
struct timer_list timer; /* otg_workaround timer */
unsigned long last_timer; /* last timer data for each instance */
bool sw_babble_enabled;
+ void __iomem *usbss_base;
struct dsps_context context;
struct debugfs_regset32 regset;
@@ -145,6 +146,13 @@ static const struct debugfs_reg32 dsps_musb_regs[] = {
{ "mode", 0xe8 },
};
+/* USBSS / USB AM335x */
+#define USBSS_IRQ_STATUS 0x28
+#define USBSS_IRQ_ENABLER 0x2c
+#define USBSS_IRQ_CLEARR 0x30
+
+#define USBSS_IRQ_PD_COMP (1 << 2)
+
/**
* dsps_musb_enable - enable interrupts
*/
@@ -619,14 +627,68 @@ static void dsps_read_fifo32(struct musb_hw_ep *hw_ep, u16 len, u8 *dst)
}
}
+static void dsps_dma_controller_callback(struct musb *musb);
+
+static struct dma_controller *
+dsps_dma_controller_create(struct musb *musb, void __iomem *base)
+{
+ struct dma_controller *controller;
+ struct dsps_glue *glue = dev_get_drvdata(musb->controller->parent);
+ void __iomem *usbss_base = glue->usbss_base;
+
+ controller = cppi41_dma_controller_create(musb, base);
+ if (!IS_ERR_OR_NULL(controller)) {
+ musb_writel(usbss_base, USBSS_IRQ_ENABLER, USBSS_IRQ_PD_COMP);
+ cppi41_register_dma_callback(controller,
+ dsps_dma_controller_callback);
+ }
+
+ return controller;
+}
+
+static void dsps_dma_controller_destroy(struct dma_controller *c)
+{
+ struct musb *musb = cppi41_dma_controller_to_musb(c);
+ struct dsps_glue *glue = dev_get_drvdata(musb->controller->parent);
+ void __iomem *usbss_base = glue->usbss_base;
+
+ musb_writel(usbss_base, USBSS_IRQ_CLEARR, USBSS_IRQ_PD_COMP);
+ cppi41_dma_controller_destroy(c);
+}
+
+static void dsps_dma_controller_suspend(struct dsps_glue *glue)
+{
+ void __iomem *usbss_base = glue->usbss_base;
+
+ musb_writel(usbss_base, USBSS_IRQ_CLEARR, USBSS_IRQ_PD_COMP);
+}
+
+static void dsps_dma_controller_resume(struct dsps_glue *glue)
+{
+ void __iomem *usbss_base = glue->usbss_base;
+
+ musb_writel(usbss_base, USBSS_IRQ_ENABLER, USBSS_IRQ_PD_COMP);
+}
+
+static void dsps_dma_controller_callback(struct musb *musb)
+{
+ struct dsps_glue *glue = dev_get_drvdata(musb->controller->parent);
+ void __iomem *usbss_base = glue->usbss_base;
+ u32 status;
+
+ status = musb_readl(usbss_base, USBSS_IRQ_STATUS);
+ if (status & USBSS_IRQ_PD_COMP)
+ musb_writel(usbss_base, USBSS_IRQ_STATUS, USBSS_IRQ_PD_COMP);
+}
+
static struct musb_platform_ops dsps_ops = {
.quirks = MUSB_DMA_CPPI41 | MUSB_INDEXED_EP,
.init = dsps_musb_init,
.exit = dsps_musb_exit,
#ifdef CONFIG_USB_TI_CPPI41_DMA
- .dma_init = cppi41_dma_controller_create,
- .dma_exit = cppi41_dma_controller_destroy,
+ .dma_init = dsps_dma_controller_create,
+ .dma_exit = dsps_dma_controller_destroy,
#endif
.enable = dsps_musb_enable,
.disable = dsps_musb_disable,
@@ -792,6 +854,9 @@ static int dsps_probe(struct platform_device *pdev)
glue->dev = &pdev->dev;
glue->wrp = wrp;
+ glue->usbss_base = of_iomap(pdev->dev.parent->of_node, 0);
+ if (!glue->usbss_base)
+ return -ENXIO;
platform_set_drvdata(pdev, glue);
pm_runtime_enable(&pdev->dev);
@@ -880,6 +945,8 @@ static int dsps_suspend(struct device *dev)
glue->context.tx_mode = musb_readl(mbase, wrp->tx_mode);
glue->context.rx_mode = musb_readl(mbase, wrp->rx_mode);
+ dsps_dma_controller_suspend(glue);
+
return 0;
}
@@ -893,6 +960,8 @@ static int dsps_resume(struct device *dev)
if (!musb)
return 0;
+ dsps_dma_controller_resume(glue);
+
mbase = musb->ctrl_base;
musb_writel(mbase, wrp->control, glue->context.control);
musb_writel(mbase, wrp->epintr_set, glue->context.epintr);
--
2.10.2
--
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/7] usb: usb: dsps: update device tree bindings
From: Alexandre Bailon @ 2017-01-17 13:45 UTC (permalink / raw)
To: vinod.koul-ral2JQCrhuEAvxtiuMwx3w, b-liu-l0cyMroinI0,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: dmaengine-u79uwXL29TY76Z2rM5mHXA, nsekhar-l0cyMroinI0,
khilman-rdvid1DuHRBWk0Htik3J/w, ptitiano-rdvid1DuHRBWk0Htik3J/w,
tony-4v6yS6AI5VpBDgjK7y7TUQ, linux-omap-u79uwXL29TY76Z2rM5mHXA,
sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8,
devicetree-u79uwXL29TY76Z2rM5mHXA, Alexandre Bailon
In-Reply-To: <20170117134540.9988-1-abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
In order to make CPPI 4.1 DMA driver more generic, accesses to USBSS
have been removed. So it is not required anymore to define "glue"
register's address and size in DT.
Update dsps device tree bindings.
Signed-off-by: Alexandre Bailon <abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
---
Documentation/devicetree/bindings/usb/am33xx-usb.txt | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
index 20c2ff2..ef89010 100644
--- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -54,9 +54,9 @@ node.
DMA
~~~
- compatible: ti,am3359-cppi41
-- reg: offset and length of the following register spaces: USBSS, USB
+- reg: offset and length of the following register spaces: USB
CPPI DMA Controller, USB CPPI DMA Scheduler, USB Queue Manager
-- reg-names: glue, controller, scheduler, queuemgr
+- reg-names: controller, scheduler, queuemgr
- #dma-cells: should be set to 2. The first number represents the
endpoint number (0 … 14 for endpoints 1 … 15 on instance 0 and 15 … 29
for endpoints 1 … 15 on instance 1). The second number is 0 for RX and
@@ -183,11 +183,10 @@ usb: usb@47400000 {
cppi41dma: dma-controller@07402000 {
compatible = "ti,am3359-cppi41";
- reg = <0x47400000 0x1000
- 0x47402000 0x1000
+ reg = <0x47402000 0x1000
0x47403000 0x1000
0x47404000 0x4000>;
- reg-names = "glue", "controller", "scheduler", "queuemgr";
+ reg-names = "controller", "scheduler", "queuemgr";
interrupts = <17>;
interrupt-names = "glue";
#dma-cells = <2>;
--
2.10.2
--
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/7] dmaengine: cppi41: Remove usbss_mem
From: Alexandre Bailon @ 2017-01-17 13:45 UTC (permalink / raw)
To: vinod.koul-ral2JQCrhuEAvxtiuMwx3w, b-liu-l0cyMroinI0,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: dmaengine-u79uwXL29TY76Z2rM5mHXA, nsekhar-l0cyMroinI0,
khilman-rdvid1DuHRBWk0Htik3J/w, ptitiano-rdvid1DuHRBWk0Htik3J/w,
tony-4v6yS6AI5VpBDgjK7y7TUQ, linux-omap-u79uwXL29TY76Z2rM5mHXA,
sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8,
devicetree-u79uwXL29TY76Z2rM5mHXA, Alexandre Bailon
In-Reply-To: <20170117134540.9988-1-abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
In order to make CPPI 4.1 DMA driver more generic, accesses to USBSS
have been removed. So it is not required anymore to map the "glue"
register's.
Remove usbss_mem.
Signed-off-by: Alexandre Bailon <abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
---
drivers/dma/cppi41.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
index 4999e7d..ecccf7b 100644
--- a/drivers/dma/cppi41.c
+++ b/drivers/dma/cppi41.c
@@ -131,7 +131,6 @@ struct cppi41_dd {
u32 first_td_desc;
struct cppi41_channel *chan_busy[ALLOC_DECS_NUM];
- void __iomem *usbss_mem;
void __iomem *ctrl_mem;
void __iomem *sched_mem;
void __iomem *qmgr_mem;
@@ -999,16 +998,15 @@ static int cppi41_dma_probe(struct platform_device *pdev)
INIT_LIST_HEAD(&cdd->ddev.channels);
cpp41_dma_info.dma_cap = cdd->ddev.cap_mask;
- cdd->usbss_mem = of_iomap(dev->of_node, 0);
- cdd->ctrl_mem = of_iomap(dev->of_node, 1);
- cdd->sched_mem = of_iomap(dev->of_node, 2);
- cdd->qmgr_mem = of_iomap(dev->of_node, 3);
+ cdd->ctrl_mem = of_iomap(dev->of_node, 0);
+ cdd->sched_mem = of_iomap(dev->of_node, 1);
+ cdd->qmgr_mem = of_iomap(dev->of_node, 2);
spin_lock_init(&cdd->lock);
INIT_LIST_HEAD(&cdd->pending);
platform_set_drvdata(pdev, cdd);
- if (!cdd->usbss_mem || !cdd->ctrl_mem || !cdd->sched_mem ||
+ if (!cdd->ctrl_mem || !cdd->sched_mem ||
!cdd->qmgr_mem)
return -ENXIO;
@@ -1068,7 +1066,6 @@ static int cppi41_dma_probe(struct platform_device *pdev)
err_get_sync:
pm_runtime_put_sync(dev);
pm_runtime_disable(dev);
- iounmap(cdd->usbss_mem);
iounmap(cdd->ctrl_mem);
iounmap(cdd->sched_mem);
iounmap(cdd->qmgr_mem);
@@ -1090,7 +1087,6 @@ static int cppi41_dma_remove(struct platform_device *pdev)
devm_free_irq(&pdev->dev, cdd->irq, cdd);
cleanup_chans(cdd);
deinit_cppi41(&pdev->dev, cdd);
- iounmap(cdd->usbss_mem);
iounmap(cdd->ctrl_mem);
iounmap(cdd->sched_mem);
iounmap(cdd->qmgr_mem);
--
2.10.2
--
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 4/7] dmaengine: cppi41: rename platform variables
From: Alexandre Bailon @ 2017-01-17 13:45 UTC (permalink / raw)
To: vinod.koul-ral2JQCrhuEAvxtiuMwx3w, b-liu-l0cyMroinI0,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: dmaengine-u79uwXL29TY76Z2rM5mHXA, nsekhar-l0cyMroinI0,
khilman-rdvid1DuHRBWk0Htik3J/w, ptitiano-rdvid1DuHRBWk0Htik3J/w,
tony-4v6yS6AI5VpBDgjK7y7TUQ, linux-omap-u79uwXL29TY76Z2rM5mHXA,
sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8,
devicetree-u79uwXL29TY76Z2rM5mHXA, Alexandre Bailon
In-Reply-To: <20170117134540.9988-1-abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Currently, only the AM335x is supported by the driver.
Though the driver has a glue layer to support different platforms,
some platform variable names are not prefixed with the platform name.
To facilitate the addition of a new platform,
rename some variables owned by the AM335x glue.
Signed-off-by: Alexandre Bailon <abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
---
drivers/dma/cppi41.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
index ecccf7b..5527376 100644
--- a/drivers/dma/cppi41.c
+++ b/drivers/dma/cppi41.c
@@ -147,7 +147,7 @@ struct cppi41_dd {
};
#define FIST_COMPLETION_QUEUE 93
-static struct chan_queues usb_queues_tx[] = {
+static struct chan_queues am335x_usb_queues_tx[] = {
/* USB0 ENDP 1 */
[ 0] = { .submit = 32, .complete = 93},
[ 1] = { .submit = 34, .complete = 94},
@@ -183,7 +183,7 @@ static struct chan_queues usb_queues_tx[] = {
[29] = { .submit = 90, .complete = 139},
};
-static const struct chan_queues usb_queues_rx[] = {
+static const struct chan_queues am335x_usb_queues_rx[] = {
/* USB0 ENDP 1 */
[ 0] = { .submit = 1, .complete = 109},
[ 1] = { .submit = 2, .complete = 110},
@@ -910,8 +910,9 @@ static bool cpp41_dma_filter_fn(struct dma_chan *chan, void *param)
else
queues = cdd->queues_rx;
- BUILD_BUG_ON(ARRAY_SIZE(usb_queues_rx) != ARRAY_SIZE(usb_queues_tx));
- if (WARN_ON(cchan->port_num > ARRAY_SIZE(usb_queues_rx)))
+ BUILD_BUG_ON(ARRAY_SIZE(am335x_usb_queues_rx) !=
+ ARRAY_SIZE(am335x_usb_queues_tx));
+ if (WARN_ON(cchan->port_num > ARRAY_SIZE(am335x_usb_queues_rx)))
return false;
cchan->q_num = queues[cchan->port_num].submit;
@@ -939,15 +940,15 @@ static struct dma_chan *cppi41_dma_xlate(struct of_phandle_args *dma_spec,
&dma_spec->args[0]);
}
-static const struct cppi_glue_infos usb_infos = {
+static const struct cppi_glue_infos am335x_usb_infos = {
.isr = cppi41_irq,
- .queues_rx = usb_queues_rx,
- .queues_tx = usb_queues_tx,
+ .queues_rx = am335x_usb_queues_rx,
+ .queues_tx = am335x_usb_queues_tx,
.td_queue = { .submit = 31, .complete = 0 },
};
static const struct of_device_id cppi41_dma_ids[] = {
- { .compatible = "ti,am3359-cppi41", .data = &usb_infos},
+ { .compatible = "ti,am3359-cppi41", .data = &am335x_usb_infos},
{},
};
MODULE_DEVICE_TABLE(of, cppi41_dma_ids);
--
2.10.2
--
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 5/7] dmaengine: cppi41: Move some constants to glue layer
From: Alexandre Bailon @ 2017-01-17 13:45 UTC (permalink / raw)
To: vinod.koul-ral2JQCrhuEAvxtiuMwx3w, b-liu-l0cyMroinI0,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: dmaengine-u79uwXL29TY76Z2rM5mHXA, nsekhar-l0cyMroinI0,
khilman-rdvid1DuHRBWk0Htik3J/w, ptitiano-rdvid1DuHRBWk0Htik3J/w,
tony-4v6yS6AI5VpBDgjK7y7TUQ, linux-omap-u79uwXL29TY76Z2rM5mHXA,
sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8,
devicetree-u79uwXL29TY76Z2rM5mHXA, Alexandre Bailon
In-Reply-To: <20170117134540.9988-1-abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Some constants are defined and use by the driver whereas they are
specifics to AM335x.
Add new variables to the glue layer, initialize them with the constants,
and use them in the driver.
Signed-off-by: Alexandre Bailon <abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
---
drivers/dma/cppi41.c | 20 ++++++++++++++------
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
index 5527376..3b2f57f 100644
--- a/drivers/dma/cppi41.c
+++ b/drivers/dma/cppi41.c
@@ -68,7 +68,6 @@
#define QMGR_MEMCTRL_IDX_SH 16
#define QMGR_MEMCTRL_DESC_SH 8
-#define QMGR_NUM_PEND 5
#define QMGR_PEND(x) (0x90 + (x) * 4)
#define QMGR_PENDING_SLOT_Q(x) (x / 32)
@@ -138,6 +137,8 @@ struct cppi41_dd {
const struct chan_queues *queues_rx;
const struct chan_queues *queues_tx;
struct chan_queues td_queue;
+ u16 first_completion_queue;
+ u16 qmgr_num_pend;
struct list_head pending; /* Pending queued transfers */
spinlock_t lock; /* Lock for pending list */
@@ -146,7 +147,6 @@ struct cppi41_dd {
unsigned int dma_tdfdq;
};
-#define FIST_COMPLETION_QUEUE 93
static struct chan_queues am335x_usb_queues_tx[] = {
/* USB0 ENDP 1 */
[ 0] = { .submit = 32, .complete = 93},
@@ -224,6 +224,8 @@ struct cppi_glue_infos {
const struct chan_queues *queues_rx;
const struct chan_queues *queues_tx;
struct chan_queues td_queue;
+ u16 first_completion_queue;
+ u16 qmgr_num_pend;
};
static struct cppi41_channel *to_cpp41_chan(struct dma_chan *c)
@@ -278,19 +280,21 @@ static u32 cppi41_pop_desc(struct cppi41_dd *cdd, unsigned queue_num)
static irqreturn_t cppi41_irq(int irq, void *data)
{
struct cppi41_dd *cdd = data;
+ u16 first_completion_queue = cdd->first_completion_queue;
+ u16 qmgr_num_pend = cdd->qmgr_num_pend;
struct cppi41_channel *c;
int i;
- for (i = QMGR_PENDING_SLOT_Q(FIST_COMPLETION_QUEUE); i < QMGR_NUM_PEND;
+ for (i = QMGR_PENDING_SLOT_Q(first_completion_queue); i < qmgr_num_pend;
i++) {
u32 val;
u32 q_num;
val = cppi_readl(cdd->qmgr_mem + QMGR_PEND(i));
- if (i == QMGR_PENDING_SLOT_Q(FIST_COMPLETION_QUEUE) && val) {
+ if (i == QMGR_PENDING_SLOT_Q(first_completion_queue) && val) {
u32 mask;
/* set corresponding bit for completetion Q 93 */
- mask = 1 << QMGR_PENDING_BIT_Q(FIST_COMPLETION_QUEUE);
+ mask = 1 << QMGR_PENDING_BIT_Q(first_completion_queue);
/* not set all bits for queues less than Q 93 */
mask--;
/* now invert and keep only Q 93+ set */
@@ -862,7 +866,7 @@ static int init_cppi41(struct device *dev, struct cppi41_dd *cdd)
return -ENOMEM;
cppi_writel(cdd->scratch_phys, cdd->qmgr_mem + QMGR_LRAM0_BASE);
- cppi_writel(QMGR_SCRATCH_SIZE, cdd->qmgr_mem + QMGR_LRAM_SIZE);
+ cppi_writel(TOTAL_DESCS_NUM, cdd->qmgr_mem + QMGR_LRAM_SIZE);
cppi_writel(0, cdd->qmgr_mem + QMGR_LRAM1_BASE);
ret = init_descs(dev, cdd);
@@ -945,6 +949,8 @@ static const struct cppi_glue_infos am335x_usb_infos = {
.queues_rx = am335x_usb_queues_rx,
.queues_tx = am335x_usb_queues_tx,
.td_queue = { .submit = 31, .complete = 0 },
+ .first_completion_queue = 93,
+ .qmgr_num_pend = 5,
};
static const struct of_device_id cppi41_dma_ids[] = {
@@ -1021,6 +1027,8 @@ static int cppi41_dma_probe(struct platform_device *pdev)
cdd->queues_rx = glue_info->queues_rx;
cdd->queues_tx = glue_info->queues_tx;
cdd->td_queue = glue_info->td_queue;
+ cdd->qmgr_num_pend = glue_info->qmgr_num_pend;
+ cdd->first_completion_queue = glue_info->first_completion_queue;
ret = init_cppi41(dev, cdd);
if (ret)
--
2.10.2
--
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 6/7] dmaengine: cppi41: init_sched(): Get number of channels from DT
From: Alexandre Bailon @ 2017-01-17 13:45 UTC (permalink / raw)
To: vinod.koul-ral2JQCrhuEAvxtiuMwx3w, b-liu-l0cyMroinI0,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: dmaengine-u79uwXL29TY76Z2rM5mHXA, nsekhar-l0cyMroinI0,
khilman-rdvid1DuHRBWk0Htik3J/w, ptitiano-rdvid1DuHRBWk0Htik3J/w,
tony-4v6yS6AI5VpBDgjK7y7TUQ, linux-omap-u79uwXL29TY76Z2rM5mHXA,
sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8,
devicetree-u79uwXL29TY76Z2rM5mHXA, Alexandre Bailon
In-Reply-To: <20170117134540.9988-1-abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Despite the driver is already using DT to get the number of channels,
init_sched() is using an hardcoded value to get it.
Use DT to get the number of channels.
Signed-off-by: Alexandre Bailon <abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
---
drivers/dma/cppi41.c | 33 ++++++++++++++++++++-------------
1 file changed, 20 insertions(+), 13 deletions(-)
diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
index 3b2f57f..303ccee 100644
--- a/drivers/dma/cppi41.c
+++ b/drivers/dma/cppi41.c
@@ -139,6 +139,8 @@ struct cppi41_dd {
struct chan_queues td_queue;
u16 first_completion_queue;
u16 qmgr_num_pend;
+ u32 n_chans;
+ u8 platform;
struct list_head pending; /* Pending queued transfers */
spinlock_t lock; /* Lock for pending list */
@@ -720,13 +722,8 @@ static int cppi41_add_chans(struct device *dev, struct cppi41_dd *cdd)
{
struct cppi41_channel *cchan;
int i;
- int ret;
- u32 n_chans;
+ u32 n_chans = cdd->n_chans;
- ret = of_property_read_u32(dev->of_node, "#dma-channels",
- &n_chans);
- if (ret)
- return ret;
/*
* The channels can only be used as TX or as RX. So we add twice
* that much dma channels because USB can only do RX or TX.
@@ -832,7 +829,7 @@ static int init_descs(struct device *dev, struct cppi41_dd *cdd)
return 0;
}
-static void init_sched(struct cppi41_dd *cdd)
+static int init_sched(struct device *dev, struct cppi41_dd *cdd)
{
unsigned ch;
unsigned word;
@@ -840,7 +837,7 @@ static void init_sched(struct cppi41_dd *cdd)
word = 0;
cppi_writel(0, cdd->sched_mem + DMA_SCHED_CTRL);
- for (ch = 0; ch < 15 * 2; ch += 2) {
+ for (ch = 0; ch < cdd->n_chans; ch += 2) {
reg = SCHED_ENTRY0_CHAN(ch);
reg |= SCHED_ENTRY1_CHAN(ch) | SCHED_ENTRY1_IS_RX;
@@ -850,9 +847,11 @@ static void init_sched(struct cppi41_dd *cdd)
cppi_writel(reg, cdd->sched_mem + DMA_SCHED_WORD(word));
word++;
}
- reg = 15 * 2 * 2 - 1;
+ reg = cdd->n_chans * 2 - 1;
reg |= DMA_SCHED_CTRL_EN;
cppi_writel(reg, cdd->sched_mem + DMA_SCHED_CTRL);
+
+ return 0;
}
static int init_cppi41(struct device *dev, struct cppi41_dd *cdd)
@@ -871,12 +870,14 @@ static int init_cppi41(struct device *dev, struct cppi41_dd *cdd)
ret = init_descs(dev, cdd);
if (ret)
- goto err_td;
+ goto deinit;
cppi_writel(cdd->td_queue.submit, cdd->ctrl_mem + DMA_TDFDQ);
- init_sched(cdd);
+ ret = init_sched(dev, cdd);
+ if (ret)
+ goto deinit;
return 0;
-err_td:
+deinit:
deinit_cppi41(dev, cdd);
return ret;
}
@@ -1030,6 +1031,11 @@ static int cppi41_dma_probe(struct platform_device *pdev)
cdd->qmgr_num_pend = glue_info->qmgr_num_pend;
cdd->first_completion_queue = glue_info->first_completion_queue;
+ ret = of_property_read_u32(dev->of_node,
+ "#dma-channels", &cdd->n_chans);
+ if (ret)
+ goto err_get_n_chans;
+
ret = init_cppi41(dev, cdd);
if (ret)
goto err_init_cppi;
@@ -1072,6 +1078,7 @@ static int cppi41_dma_probe(struct platform_device *pdev)
deinit_cppi41(dev, cdd);
err_init_cppi:
pm_runtime_dont_use_autosuspend(dev);
+err_get_n_chans:
err_get_sync:
pm_runtime_put_sync(dev);
pm_runtime_disable(dev);
@@ -1128,7 +1135,7 @@ static int __maybe_unused cppi41_resume(struct device *dev)
if (!c->is_tx)
cppi_writel(c->q_num, c->gcr_reg + RXHPCRA0);
- init_sched(cdd);
+ init_sched(dev, cdd);
cppi_writel(cdd->dma_tdfdq, cdd->ctrl_mem + DMA_TDFDQ);
cppi_writel(cdd->scratch_phys, cdd->qmgr_mem + QMGR_LRAM0_BASE);
--
2.10.2
--
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 7/7] dmaengine: cppi41: Fix a race between PM runtime and channel abort
From: Alexandre Bailon @ 2017-01-17 13:45 UTC (permalink / raw)
To: vinod.koul-ral2JQCrhuEAvxtiuMwx3w, b-liu-l0cyMroinI0,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A
Cc: dmaengine-u79uwXL29TY76Z2rM5mHXA, nsekhar-l0cyMroinI0,
khilman-rdvid1DuHRBWk0Htik3J/w, ptitiano-rdvid1DuHRBWk0Htik3J/w,
tony-4v6yS6AI5VpBDgjK7y7TUQ, linux-omap-u79uwXL29TY76Z2rM5mHXA,
sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8,
devicetree-u79uwXL29TY76Z2rM5mHXA, Alexandre Bailon
In-Reply-To: <20170117134540.9988-1-abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
cppi41_dma_issue_pending() may be called while the device is runtime
suspended. In that case, the descriptor will be pushed to the pending
list and then be queued to hardware queue.
But if cppi41_stop_chan() is called before the device got time to
resume, then the descriptor will remain in the pending list and be
queued to hardware queue after the teardown.
During the channel stop, check if there is a pending descriptor
and if so, remove it.
Signed-off-by: Alexandre Bailon <abailon-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
---
drivers/dma/cppi41.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
index 303ccee..0bc4f1a 100644
--- a/drivers/dma/cppi41.c
+++ b/drivers/dma/cppi41.c
@@ -687,10 +687,17 @@ static int cppi41_stop_chan(struct dma_chan *chan)
{
struct cppi41_channel *c = to_cpp41_chan(chan);
struct cppi41_dd *cdd = c->cdd;
+ unsigned long flags;
u32 desc_num;
u32 desc_phys;
int ret;
+ /* Remove pending descriptor that haven't been pushed to queue */
+ spin_lock_irqsave(&cdd->lock, flags);
+ if (!list_empty(&c->node))
+ list_del_init(&c->node);
+ spin_unlock_irqrestore(&cdd->lock, flags);
+
desc_phys = lower_32_bits(c->desc_phys);
desc_num = (desc_phys - cdd->descs_phys) / sizeof(struct cppi41_desc);
if (!cdd->chan_busy[desc_num])
@@ -748,6 +755,7 @@ static int cppi41_add_chans(struct device *dev, struct cppi41_dd *cdd)
cchan->desc_phys = cdd->descs_phys;
cchan->desc_phys += i * sizeof(struct cppi41_desc);
cchan->chan.device = &cdd->ddev;
+ INIT_LIST_HEAD(&cchan->node);
list_add_tail(&cchan->chan.device_node, &cdd->ddev.channels);
}
cdd->first_td_desc = n_chans;
@@ -1163,7 +1171,7 @@ static int __maybe_unused cppi41_runtime_resume(struct device *dev)
spin_lock_irqsave(&cdd->lock, flags);
list_for_each_entry_safe(c, _c, &cdd->pending, node) {
push_desc_queue(c);
- list_del(&c->node);
+ list_del_init(&c->node);
}
spin_unlock_irqrestore(&cdd->lock, flags);
--
2.10.2
--
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 1/5] ARM: OMAP2+: omap_hwmod: Add support for earlycon
From: Lokesh Vutla @ 2017-01-17 13:47 UTC (permalink / raw)
To: Mark Rutland
Cc: Tony Lindgren, Linux OMAP Mailing List, Device Tree Mailing List,
Rob Herring, Tero Kristo, Sekhar Nori, Vignesh R, Nishanth Menon
In-Reply-To: <20170117104703.GA11939@leverpostej>
On Tuesday 17 January 2017 04:17 PM, Mark Rutland wrote:
> On Tue, Jan 17, 2017 at 09:33:32AM +0530, Lokesh Vutla wrote:
>> Hwmod core tries to reset and idles each IP that is registered with hwmod.
>> In case of earlycon, that specific uart IP cannot be reset or keep it in
>> idle state else earlycon hangs once hwmod resets that uart IP. So add support
>> to not reset uart that is being used as earlycon only if CONFIG_SERIAL_EARLYCON
>> is enabled.
>
>> + np = of_find_node_by_path("/chosen");
>> + if (!np)
>> + np = of_find_node_by_path("/chosen@0");
>
> I think you can drop the second case here. There shouldn't be an "@0" on
> a chosen node; core code handles that only to cater for some legacy
> (PPC?) DTBs, and I don't beleive it's necessary for OMAP.
Right. Ill repost this series by dropping this case.
Thanks and regards,
Lokesh
--
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 2/2] arm64: dts: exynos: Add regulators for Vbus and Vbus-Boost
From: Javier Martinez Canillas @ 2017-01-17 13:47 UTC (permalink / raw)
To: Pankaj Dubey, linux-samsung-soc, linux-arm-kernel, devicetree
Cc: krzk, kgene, robh+dt, sanath, gautamvivek1987
In-Reply-To: <1484649143-19423-3-git-send-email-pankaj.dubey@samsung.com>
Hello Pankaj,
On 01/17/2017 07:32 AM, Pankaj Dubey wrote:
> Adding fixed voltage regulators for Vbus and Vbus-boost required
> by USB 3.0 DRD controller on Exynos7-espresso board.
>
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> Signed-off-by: Vivek Gautam <gautamvivek1987@gmail.com>
Same comment than 1/2 here.
> ---
> arch/arm64/boot/dts/exynos/exynos7-espresso.dts | 44 +++++++++++++++++++++++++
> 1 file changed, 44 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> index 9cf73cf..68f3a51 100644
> --- a/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos7-espresso.dts
> @@ -33,6 +33,29 @@
> device_type = "memory";
> reg = <0x0 0x40000000 0x0 0xC0000000>;
> };
> +
> + usb30_vbus_reg: regulator-usb30 {
> + compatible = "regulator-fixed";
> + regulator-name = "VBUS_5V";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + gpio = <&gph1 1 0>;
Please use the GPIO_ACTIVE_HIGH instead for the GPIO polarity.
> + pinctrl-names = "default";
> + pinctrl-0 = <&usb30_vbus_en>;
> + enable-active-high;
> + };
> +
> + usb3drd_boost_5v: regulator-usb3drd-boost {
> + compatible = "regulator-fixed";
> + regulator-name = "VUSB_VBUS_5V";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + gpio = <&gpf4 1 0>;
Same here.
> + pinctrl-names = "default";
> + pinctrl-0 = <&usb3drd_boost_en>;
> + enable-active-high;
> + };
> +
> };
>
> &fin_pll {
> @@ -366,3 +389,24 @@
> vqmmc-supply = <&ldo2_reg>;
> disable-wp;
> };
> +
> +&usbdrd_phy {
> + vbus-supply = <&usb30_vbus_reg>;
> + vbus-boost-supply = <&usb3drd_boost_5v>;
> +};
> +
> +&pinctrl_bus1 {
> + usb30_vbus_en: usb30-vbus-en {
> + samsung,pins = "gph1-1";
> + samsung,pin-function = <1>;
EXYNOS_PIN_FUNC_OUTPUT
> + samsung,pin-pud = <0>;
EXYNOS_PIN_PULL_NONE
> + samsung,pin-drv = <0>;
I see that there are no Exynos7 drive strengths values for
Exynos7 in include/dt-bindings/pinctrl/samsung.h. It would
be good to add those (on a different series of course).
The patch looks good to me, so after the minor nits:
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH v3 0/3] iio: distance: srf08: add IIO driver for us ranger
From: Andreas Klinger @ 2017-01-17 13:48 UTC (permalink / raw)
To: jic23, knaack.h, lars, pmeerw, linux-iio, linux-kernel, ktsai,
wsa, robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak,
trivial, mranostay, linux-i2c, devicetree
Cc: ak
This patch series adds IIO driver support for srf08 ultrasonic ranger
devices.
The first patch add a trivial device tree binding for the device together
with a new vendor devantech.
The second patch is the IIO driver which in turn is using I2C to talk to
the device.
The third patch documents the added userspace ABI
Documentation about the sensor can be found here:
http://www.robot-electronics.co.uk/htm/srf08tech.html
Changes in v3:
Thanks to the reviews of Jonathan, Rob and Lars.
Some changes to the driver were made:
* Patch 2: "iio: distance: srf08: add IIO driver for us ranger"
- defaults values for sensitivity (gain) and max. range are set in
probe()
- while waiting for ultrasonic echo first wait as long as the physically
measurement need as a function of the max. range and then wait in
smaller steps until the response can be read.
- attributes are now called sensor_sensitivity instead of gain and
sensor_max_range instead of range_mm
- device-name is now "srf08"
- config menu is now calles "Proximity and distance sensors" instead of a
separate menu
* Patch 3: "iio: distance: srf08: add driver ABI documentation"
- newly created to document the driver specific interfaces
Changes in v2:
Lots of updates thanks to Peters really fast review within 30 minutes
after first submission of the driver.
* Patch 2: "iio: distance: srf08: add IIO driver for us ranger"
- alphabetic order in Makefile
- use of u8 while accessing registers
- avoid endianness problems with 16 bit values
- missing return value checks
- some explaining documentation added
Andreas Klinger (3):
iio: distance: srf08: add trivial DT binding
iio: distance: srf08: add IIO driver for us ranger
iio: distance: srf08: add driver ABI documentation
.../ABI/testing/sysfs-bus-iio-distance-srf08 | 27 ++
.../devicetree/bindings/i2c/trivial-devices.txt | 1 +
.../devicetree/bindings/vendor-prefixes.txt | 1 +
drivers/iio/proximity/Kconfig | 13 +-
drivers/iio/proximity/Makefile | 1 +
drivers/iio/proximity/srf08.c | 405 +++++++++++++++++++++
6 files changed, 447 insertions(+), 1 deletion(-)
create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-distance-srf08
create mode 100644 drivers/iio/proximity/srf08.c
--
2.1.4
--
^ 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