* Re: [PATCH v3 4/6] ARM: dts: sun6i: Add audio codec device node
From: Maxime Ripard @ 2016-11-07 18:28 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20161107100703.5586-5-wens-jdAy2FN1RRM@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 940 bytes --]
On Mon, Nov 07, 2016 at 06:07:01PM +0800, Chen-Yu Tsai wrote:
> The A31 SoC includes the Allwinner audio codec, capable of 24-bit
> playback up to 192 kHz and 24-bit capture up to 48 kHz.
>
> Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
> ---
> arch/arm/boot/dts/sun6i-a31.dtsi | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
> index 2e8bf93dcfb2..f68e6102b01b 100644
> --- a/arch/arm/boot/dts/sun6i-a31.dtsi
> +++ b/arch/arm/boot/dts/sun6i-a31.dtsi
> @@ -784,6 +784,19 @@
> reset-names = "ahb";
> };
>
> + codec: codec@01c22c00 {
> + #sound-dai-cells = <0>;
> + compatible = "allwinner,sun6i-a31-codec";
> + reg = <0x01c22c00 0x98>;
The memory mapped region is 0x400. I fixed this and applied.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v8 3/3] fpga: Add support for Lattice iCE40 FPGAs
From: Moritz Fischer @ 2016-11-07 18:26 UTC (permalink / raw)
To: Joel Holdsworth
Cc: Alan Tull, Geert Uytterhoeven, Rob Herring, Devicetree List,
Linux Kernel Mailing List, linux-spi-u79uwXL29TY76Z2rM5mHXA,
Marek Vašut, clifford-cPpHkPqGOEfk7+2FdBfRIA
In-Reply-To: <1478486962-26794-3-git-send-email-joel-IJEoVVyKhCJXvIrf17iDB/XRex20P6io@public.gmane.org>
Hi Joel,
couple of nits inline below:
On Sun, Nov 6, 2016 at 6:49 PM, Joel Holdsworth
<joel-IJEoVVyKhCJXvIrf17iDB/XRex20P6io@public.gmane.org> wrote:
> The Lattice iCE40 is a family of FPGAs with a minimalistic architecture
> and very regular structure, designed for low-cost, high-volume consumer
> and system applications.
>
> This patch adds support to the FPGA manager for configuring the SRAM of
> iCE40LM, iCE40LP, iCE40HX, iCE40 Ultra, iCE40 UltraLite and iCE40
> UltraPlus devices, through slave SPI.
>
> The iCE40 family is notable because it is the first FPGA family to have
> complete reverse engineered bit-stream documentation for the iCE40LP and
> iCE40HX devices. Furthermore, there is now a Free Software Verilog
> synthesis tool-chain: the "IceStorm" tool-chain.
>
> This project is the work of Clifford Wolf, who is the maintainer of
> Yosys Verilog RTL synthesis framework, and Mathias Lasser, with notable
> contributions from "Cotton Seed", the main author of "arachne-pnr"; a
> place-and-route tool for iCE40 FPGAs.
>
> Having a Free Software synthesis tool-chain offers interesting
> opportunities for embedded devices that are able reconfigure themselves
> with open firmware that is generated on the device itself. For example
> a mobile device might have an application processor with an iCE40 FPGA
> attached, which implements slave devices, or through which the processor
> communicates with other devices through the FPGA fabric.
>
> A kernel driver for the iCE40 is useful, because in some cases, the FPGA
> may need to be configured before other devices can be accessed.
>
> An example of such a device is the icoBoard; a RaspberryPI HAT which
> features an iCE40HX8K with a 1 or 8 MBit SRAM and ports for
> Digilent-compatible PMOD modules. A PMOD module may contain a device
> with which the kernel communicates, via the FPGA.
Personally I find this a bit verbose, but that's just me.
>
> Signed-off-by: Joel Holdsworth <joel-IJEoVVyKhCJXvIrf17iDB/XRex20P6io@public.gmane.org>
> ---
> drivers/fpga/Kconfig | 6 ++
> drivers/fpga/Makefile | 1 +
> drivers/fpga/ice40-spi.c | 217 +++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 224 insertions(+)
> create mode 100644 drivers/fpga/ice40-spi.c
>
> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> index d614102..5b0f137 100644
> --- a/drivers/fpga/Kconfig
> +++ b/drivers/fpga/Kconfig
> @@ -13,6 +13,12 @@ config FPGA
>
> if FPGA
>
> +config FPGA_MGR_ICE40_SPI
> + tristate "Lattice iCE40 SPI"
> + depends on OF && SPI
> + help
> + FPGA manager driver support for Lattice iCE40 FPGAs over SPI.
> +
> config FPGA_MGR_SOCFPGA
> tristate "Altera SOCFPGA FPGA Manager"
> depends on ARCH_SOCFPGA
> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> index 8d83fc6..adb5811 100644
> --- a/drivers/fpga/Makefile
> +++ b/drivers/fpga/Makefile
> @@ -6,5 +6,6 @@
> obj-$(CONFIG_FPGA) += fpga-mgr.o
>
> # FPGA Manager Drivers
> +obj-$(CONFIG_FPGA_MGR_ICE40_SPI) += ice40-spi.o
> obj-$(CONFIG_FPGA_MGR_SOCFPGA) += socfpga.o
> obj-$(CONFIG_FPGA_MGR_ZYNQ_FPGA) += zynq-fpga.o
> diff --git a/drivers/fpga/ice40-spi.c b/drivers/fpga/ice40-spi.c
> new file mode 100644
> index 0000000..7d7595b
> --- /dev/null
> +++ b/drivers/fpga/ice40-spi.c
> @@ -0,0 +1,217 @@
> +/*
> + * FPGA Manager Driver for Lattice iCE40.
> + *
> + * Copyright (c) 2016 Joel Holdsworth
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; version 2 of the License.
> + *
> + * This driver adds support to the FPGA manager for configuring the SRAM of
> + * Lattice iCE40 FPGAs through slave SPI.
> + */
> +
> +#include <linux/fpga/fpga-mgr.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/module.h>
> +#include <linux/of_gpio.h>
> +#include <linux/spi/spi.h>
> +
> +#define ICE40_SPI_FPGAMGR_RESET_DELAY 1 /* us (>200ns) */
> +#define ICE40_SPI_FPGAMGR_HOUSEKEEPING_DELAY 1200 /* us */
> +
> +#define ICE40_SPI_FPGAMGR_NUM_ACTIVATION_BYTES DIV_ROUND_UP(49, 8)
> +
> +struct ice40_fpga_priv {
> + struct spi_device *dev;
> + struct gpio_desc *reset;
> + struct gpio_desc *cdone;
> +};
> +
> +static enum fpga_mgr_states ice40_fpga_ops_state(struct fpga_manager *mgr)
> +{
> + struct ice40_fpga_priv *priv = mgr->priv;
> +
> + return gpiod_get_value(priv->cdone) ? FPGA_MGR_STATE_OPERATING :
> + FPGA_MGR_STATE_UNKNOWN;
> +}
> +
> +static int ice40_fpga_ops_write_init(struct fpga_manager *mgr, u32 flags,
> + const char *buf, size_t count)
> +{
> + struct ice40_fpga_priv *priv = mgr->priv;
> + struct spi_device *dev = priv->dev;
> + struct spi_message message;
> + struct spi_transfer assert_cs_then_reset_delay = {.cs_change = 1,
> + .delay_usecs = ICE40_SPI_FPGAMGR_RESET_DELAY};
Formatting looks odd, can you move the .cs_change to the next line?
> + struct spi_transfer housekeeping_delay_then_release_cs = {
> + .delay_usecs = ICE40_SPI_FPGAMGR_HOUSEKEEPING_DELAY};
> + int ret;
> +
> + if ((flags & FPGA_MGR_PARTIAL_RECONFIG)) {
> + dev_err(&dev->dev,
> + "Partial reconfiguration is not supported\n");
> + return -ENOTSUPP;
> + }
> +
> + /* Lock the bus, assert CRESET_B and SS_B and delay >200ns */
> + spi_bus_lock(dev->master);
> +
> + gpiod_set_value(priv->reset, 1);
> +
> + spi_message_init(&message);
> + spi_message_add_tail(&assert_cs_then_reset_delay, &message);
> + ret = spi_sync_locked(dev, &message);
> +
> + /* Come out of reset */
> + gpiod_set_value(priv->reset, 0);
> +
> + /* Abort if the chip-select failed */
> + if (ret)
> + goto fail;
> +
> + /* Check CDONE is de-asserted i.e. the FPGA is reset */
> + if (gpiod_get_value(priv->cdone)) {
> + dev_err(&dev->dev, "Device reset failed, CDONE is asserted\n");
> + ret = -EIO;
> + goto fail;
> + }
> +
> + /* Wait for the housekeeping to complete, and release SS_B */
> + spi_message_init(&message);
> + spi_message_add_tail(&housekeeping_delay_then_release_cs, &message);
> + ret = spi_sync_locked(dev, &message);
> +
> +fail:
> + spi_bus_unlock(dev->master);
> +
> + return ret;
> +}
> +
> +static int ice40_fpga_ops_write(struct fpga_manager *mgr,
> + const char *buf, size_t count)
> +{
> + struct ice40_fpga_priv *priv = mgr->priv;
> +
> + return spi_write(priv->dev, buf, count);
> +}
> +
> +static int ice40_fpga_ops_write_complete(struct fpga_manager *mgr, u32 flags)
> +{
> + struct ice40_fpga_priv *priv = mgr->priv;
> + struct spi_device *dev = priv->dev;
> + const u8 padding[ICE40_SPI_FPGAMGR_NUM_ACTIVATION_BYTES] = {0,};
> +
> + /* Check CDONE is asserted */
> + if (!gpiod_get_value(priv->cdone)) {
> + dev_err(&dev->dev,
> + "CDONE was not asserted after firmware transfer\n");
> + return -EIO;
> + }
> +
> + /* Send of zero-padding to activate the firmware */
> + return spi_write(dev, padding, sizeof(padding));
I'd move all of these into the write() callback.
> +}
> +
> +static void ice40_fpga_ops_fpga_remove(struct fpga_manager *mgr)
> +{
> + struct ice40_fpga_priv *priv = mgr->priv;
> +
> + /* Enter reset */
> + gpiod_set_value(priv->reset, 1);
I know Marek had suggested this, none of the other drivers behave like that.
I'm not sure this is expected behavior for most people.
> +}
> +
> +static const struct fpga_manager_ops ice40_fpga_ops = {
> + .state = ice40_fpga_ops_state,
> + .write_init = ice40_fpga_ops_write_init,
> + .write = ice40_fpga_ops_write,
> + .write_complete = ice40_fpga_ops_write_complete,
> + .fpga_remove = ice40_fpga_ops_fpga_remove
> +};
> +
> +static int ice40_fpga_probe(struct spi_device *spi)
> +{
> + struct device *dev = &spi->dev;
> + struct device_node *np = spi->dev.of_node;
> + struct ice40_fpga_priv *priv;
> + int ret;
> +
> + if (!np) {
> + dev_err(dev, "No Device Tree entry\n");
> + return -EINVAL;
> + }
> +
> + priv = devm_kzalloc(&spi->dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->dev = spi;
> +
> + /* Check board setup data. */
> + if (spi->max_speed_hz > 25000000) {
> + dev_err(dev, "Speed is too high\n");
> + return -EINVAL;
> + }
> +
> + if (spi->max_speed_hz < 1000000) {
> + dev_err(dev, "Speed is too low\n");
> + return -EINVAL;
> + }
> +
> + if (spi->mode & SPI_CPHA) {
> + dev_err(dev, "Bad mode\n");
> + return -EINVAL;
> + }
> +
> + /* Set up the GPIOs */
> + priv->cdone = devm_gpiod_get(dev, "cdone", GPIOD_IN);
> + if (IS_ERR(priv->cdone)) {
> + dev_err(dev, "Failed to get CDONE GPIO: %ld\n",
> + PTR_ERR(priv->cdone));
> + return -EINVAL;
> + }
> +
> + priv->reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
> + if (IS_ERR(priv->reset)) {
> + dev_err(dev, "Failed to get CRESET_B GPIO: %ld\n",
> + PTR_ERR(priv->reset));
> + return -EINVAL;
> + }
> +
> + /* Register with the FPGA manager */
> + ret = fpga_mgr_register(dev, "Lattice iCE40 FPGA Manager",
> + &ice40_fpga_ops, priv);
> + if (ret) {
> + dev_err(dev, "Unable to register FPGA manager");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int ice40_fpga_remove(struct spi_device *spi)
> +{
> + fpga_mgr_unregister(&spi->dev);
> + return 0;
> +}
> +
> +static const struct of_device_id ice40_fpga_of_match[] = {
> + { .compatible = "lattice,ice40-fpga-mgr", },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, ice40_fpga_of_match);
> +
> +static struct spi_driver ice40_fpga_driver = {
> + .probe = ice40_fpga_probe,
> + .remove = ice40_fpga_remove,
> + .driver = {
> + .name = "ice40spi",
> + .of_match_table = of_match_ptr(ice40_fpga_of_match),
> + },
> +};
> +
> +module_spi_driver(ice40_fpga_driver);
> +
> +MODULE_AUTHOR("Joel Holdsworth <joel-IJEoVVyKhCJXvIrf17iDB/XRex20P6io@public.gmane.org>");
> +MODULE_DESCRIPTION("Lattice iCE40 FPGA Manager");
> +MODULE_LICENSE("GPL v2");
> --
> 2.7.4
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v3 2/3] ARM64: dts: sun6i: add dma node for a64.
From: Hao Zhang @ 2016-11-07 18:22 UTC (permalink / raw)
To: maxime.ripard, wens, robh+dt, mark.rutland, catalin.marinas,
will.deacon
Cc: hao5781286, devicetree, linux-kernel, linux-arm-kernel
This adds the dma node for sun50i a64.
Signed-off-by: Hao Zhang <hao5781286@gmail.com>
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index e3c3d7d8..855ae2c 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -227,6 +227,15 @@
};
};
+ dma: dma-controller@01c02000 {
+ compatible = "allwinner,sun50i-a64-dma";
+ reg = <0x01c02000 0x1000>;
+ interrupts = <GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_DMA>;
+ resets = <&ccu RST_BUS_DMA>;
+ #dma-cells = <1>;
+ };
+
uart0: serial@1c28000 {
compatible = "snps,dw-apb-uart";
reg = <0x01c28000 0x400>;
--
2.7.4
^ permalink raw reply related
* [PATCH v3 1/3] Documentation: DT: add dma compatible for sun50i A64 SOC.
From: Hao Zhang @ 2016-11-07 18:14 UTC (permalink / raw)
To: maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
mark.rutland-5wv7dgnIgG8, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
vinod.koul-ral2JQCrhuEAvxtiuMwx3w
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
hao5781286-Re5JQEeQqe8AvxtiuMwx3w
This adds documentation of the sun50i a64 dma binding compatible.
Signed-off-by: Hao Zhang <hao5781286-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
Documentation/devicetree/bindings/dma/sun6i-dma.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/dma/sun6i-dma.txt b/Documentation/devicetree/bindings/dma/sun6i-dma.txt
index 6b26704..4398b99 100644
--- a/Documentation/devicetree/bindings/dma/sun6i-dma.txt
+++ b/Documentation/devicetree/bindings/dma/sun6i-dma.txt
@@ -9,6 +9,7 @@ Required properties:
"allwinner,sun8i-a23-dma"
"allwinner,sun8i-a83t-dma"
"allwinner,sun8i-h3-dma"
+ "allwinner,sun50i-a64-dma"
- reg: Should contain the registers base address and length
- interrupts: Should contain a reference to the interrupt used by this device
- clocks: Should contain a reference to the parent AHB clock
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v6 0/7] add NS2 support to bgmac
From: David Miller @ 2016-11-07 18:11 UTC (permalink / raw)
To: jon.mason
Cc: robh+dt, mark.rutland, f.fainelli, rafal,
bcm-kernel-feedback-list, netdev, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <1478236262-3351-1-git-send-email-jon.mason@broadcom.com>
From: Jon Mason <jon.mason@broadcom.com>
Date: Fri, 4 Nov 2016 01:10:55 -0400
> Changes in v6:
> * Use a common bgmac_phy_connect_direct (per Rafal Milecki)
> * Rebased on latest net-next
> * Added Reviewed-by to the relevant patches
>
>
> Changes in v5:
> * Change a pr_err to netdev_err (per Scott Branden)
> * Reword the lane swap binding documentation (per Andrew Lunn)
>
>
> Changes in v4:
> * Actually send out the lane swap binding doc patch (Per Scott Branden)
> * Remove unused #define (Per Andrew Lunn)
>
>
> Changes in v3:
> * Clean-up the bgmac DT binding doc (per Rob Herring)
> * Document the lane swap binding and make it generic (Per Andrew Lunn)
>
>
> Changes in v2:
> * Remove the PHY power-on (per Andrew Lunn)
> * Misc PHY clean-ups regarding comments and #defines (per Andrew Lunn)
> This results on none of the original PHY code from Vikas being
> present. So, I'm removing him as an author and giving him
> "Inspired-by" credit.
> * Move PHY lane swapping to PHY driver (per Andrew Lunn and Florian
> Fainelli)
> * Remove bgmac sleep (per Florian Fainelli)
> * Re-add bgmac chip reset (per Florian Fainelli and Ray Jui)
> * Rebased on latest net-next
> * Added patch for bcm54xx_auxctl_read, which is used in the BCM54810
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH v8 3/3] fpga: Add support for Lattice iCE40 FPGAs
From: Marek Vasut @ 2016-11-07 18:01 UTC (permalink / raw)
To: Joel Holdsworth, atull-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx,
moritz.fischer-+aYTwkv1SeIAvxtiuMwx3w,
geert-Td1EMuHUCqxL1ZNQvxDV9g, robh-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-spi-u79uwXL29TY76Z2rM5mHXA, clifford-cPpHkPqGOEfk7+2FdBfRIA
In-Reply-To: <1478486962-26794-3-git-send-email-joel-IJEoVVyKhCJXvIrf17iDB/XRex20P6io@public.gmane.org>
On 11/07/2016 03:49 AM, Joel Holdsworth wrote:
> The Lattice iCE40 is a family of FPGAs with a minimalistic architecture
> and very regular structure, designed for low-cost, high-volume consumer
> and system applications.
[...]
> +static int ice40_fpga_ops_write_init(struct fpga_manager *mgr, u32 flags,
> + const char *buf, size_t count)
> +{
> + struct ice40_fpga_priv *priv = mgr->priv;
> + struct spi_device *dev = priv->dev;
> + struct spi_message message;
> + struct spi_transfer assert_cs_then_reset_delay = {.cs_change = 1,
> + .delay_usecs = ICE40_SPI_FPGAMGR_RESET_DELAY};
Should be this way for the sake of readability, fix globally:
struct spi_transfer assert_cs_then_reset_delay = {
.cs_change = 1,
.delay_usecs = ICE40_SPI_FPGAMGR_RESET_DELAY
};
Also I believe this could be const.
> + struct spi_transfer housekeeping_delay_then_release_cs = {
> + .delay_usecs = ICE40_SPI_FPGAMGR_HOUSEKEEPING_DELAY};
Don't we have some less hacky way of toggling the nCS ? Is this even nCS
or is this some control pin of the FPGA ? Maybe it should be treated
like a regular GPIO instead ?
[...]
> +static int ice40_fpga_ops_write_complete(struct fpga_manager *mgr, u32 flags)
> +{
> + struct ice40_fpga_priv *priv = mgr->priv;
> + struct spi_device *dev = priv->dev;
> + const u8 padding[ICE40_SPI_FPGAMGR_NUM_ACTIVATION_BYTES] = {0,};
The comma is not needed.
> +
> + /* Check CDONE is asserted */
> + if (!gpiod_get_value(priv->cdone)) {
> + dev_err(&dev->dev,
> + "CDONE was not asserted after firmware transfer\n");
> + return -EIO;
> + }
> +
> + /* Send of zero-padding to activate the firmware */
> + return spi_write(dev, padding, sizeof(padding));
> +}
[...]
> + /* Check board setup data. */
> + if (spi->max_speed_hz > 25000000) {
> + dev_err(dev, "Speed is too high\n");
> + return -EINVAL;
> + }
> +
> + if (spi->max_speed_hz < 1000000) {
> + dev_err(dev, "Speed is too low\n");
> + return -EINVAL;
> + }
Do you have some explanation for this limitation ?
[...]
--
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" 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 v8 2/3] Documentation: Add binding document for Lattice iCE40 FPGA manager
From: Marek Vasut @ 2016-11-07 17:53 UTC (permalink / raw)
To: Joel Holdsworth, atull-yzvPICuk2ABMcg4IHK0kFoH6Mc4MB0Vx,
moritz.fischer-+aYTwkv1SeIAvxtiuMwx3w,
geert-Td1EMuHUCqxL1ZNQvxDV9g, robh-DgEjT+Ai2ygdnm+yROfE0A,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-spi-u79uwXL29TY76Z2rM5mHXA, clifford-cPpHkPqGOEfk7+2FdBfRIA
In-Reply-To: <1478486962-26794-2-git-send-email-joel-IJEoVVyKhCJXvIrf17iDB/XRex20P6io@public.gmane.org>
On 11/07/2016 03:49 AM, Joel Holdsworth wrote:
> This adds documentation of the device tree bindings of the Lattice iCE40
> FPGA driver for the FPGA manager framework.
>
> Signed-off-by: Joel Holdsworth <joel-IJEoVVyKhCJXvIrf17iDB/XRex20P6io@public.gmane.org>
> ---
> .../bindings/fpga/lattice-ice40-fpga-mgr.txt | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt
>
> diff --git a/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt b/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt
> new file mode 100644
> index 0000000..7e7a78b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/fpga/lattice-ice40-fpga-mgr.txt
> @@ -0,0 +1,21 @@
> +Lattice iCE40 FPGA Manager
> +
> +Required properties:
> +- compatible: Should contain "lattice,ice40-fpga-mgr"
> +- reg: SPI chip select
> +- spi-max-frequency: Maximum SPI frequency (>=1000000, <=25000000)
> +- cdone-gpios: GPIO input connected to CDONE pin
> +- reset-gpios: Active-low GPIO output connected to CRESET_B pin. Note
> + that unless the GPIO is held low during startup, the
> + FPGA will enter Master SPI mode and drive SCK with a
> + clock signal potentially jamming other devices on the
> + bus until the firmware is loaded.
> +
> +Example:
> + ice40: ice40@0 {
> + compatible = "lattice,ice40-fpga-mgr";
> + reg = <0>;
> + spi-max-frequency = <1000000>;
> + cdone-gpios = <&gpio 24 GPIO_ACTIVE_HIGH>;
> + reset-gpios = <&gpio 22 GPIO_ACTIVE_LOW>;
Wouldn't it make more sense to have "gpios" and "gpio-names" ? That
scales better imo, although in this case we cannot really talk about
scaling.
> + };
>
--
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" 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 6/6] ARM: dts: Extend the S3C RTC node with rtc_src clock
From: Krzysztof Kozlowski @ 2016-11-07 17:44 UTC (permalink / raw)
To: Pankaj Dubey
Cc: linux-samsung-soc, linux-arm-kernel, krzk, javier, kgene,
thomas.ab, myungjoo.ham, Rob Herring, devicetree
In-Reply-To: <1478513376-14307-7-git-send-email-pankaj.dubey@samsung.com>
On Mon, Nov 07, 2016 at 03:39:36PM +0530, Pankaj Dubey wrote:
> Extend the S3C RTC node with rtc_src clock so it could be operational.
> The rtc_src clock is provided by MAX8997.
>
> CC: Rob Herring <robh+dt@kernel.org>
> CC: devicetree@vger.kernel.org
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
> arch/arm/boot/dts/exynos4210-origen.dts | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos4210-origen.dts b/arch/arm/boot/dts/exynos4210-origen.dts
> index 6c7ef4e..4cac9b6 100644
> --- a/arch/arm/boot/dts/exynos4210-origen.dts
> +++ b/arch/arm/boot/dts/exynos4210-origen.dts
> @@ -18,6 +18,7 @@
> #include "exynos4210.dtsi"
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/input/input.h>
> +#include <dt-bindings/clock/maxim,max8997.h>
Just a nit: put the system-wide includes in alphabetical order, so
clock, gpio and finally input. It helps reducing conflicting changes
(when more people add includes in the same time).
Beside that, looks good, but it requires a dt-bindings in separate patch
so I could pull it.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 3/6] clk: Add driver for Maxim-8997 PMIC clocks
From: Krzysztof Kozlowski @ 2016-11-07 17:41 UTC (permalink / raw)
To: Pankaj Dubey
Cc: linux-samsung-soc, linux-arm-kernel, krzk, javier, kgene,
thomas.ab, myungjoo.ham, Michael Turquette, Rob Herring,
devicetree, linux-clk
In-Reply-To: <1478513376-14307-4-git-send-email-pankaj.dubey@samsung.com>
On Mon, Nov 07, 2016 at 03:39:33PM +0530, Pankaj Dubey wrote:
> The MAX8997 PMIC has 32.786kHz crystal oscillator which provides an
> accurate low frequency clock for MAX8997 internal circuit as well as
> external circuit. This patch adds support for these two clocks.
>
> CC: Michael Turquette <mturquette@baylibre.com>
> CC: Rob Herring <robh+dt@kernel.org>
> CC: devicetree@vger.kernel.org
> CC: linux-clk@vger.kernel.org
> Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
> ---
> drivers/clk/Kconfig | 10 ++++
> drivers/clk/Makefile | 1 +
> drivers/clk/clk-max8997.c | 76 +++++++++++++++++++++++++++++++
> include/dt-bindings/clock/maxim,max8997.h | 23 ++++++++++
You need to split the dt-bindings header into separate one so others
could pull it. Please also mention the dependencies between patches in
cover letter, because it does not look like it could be applied as is.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 4/4] ARM: dts: Add #pinctrl-cells for pinctrl-single instances
From: Tony Lindgren @ 2016-11-07 17:39 UTC (permalink / raw)
To: Linus Walleij
Cc: Jon Hunter, Mark Rutland, Rob Herring, Grygorii Strashko,
Nishanth Menon,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-OMAP
In-Reply-To: <CACRpkdaRGmUg19zu1kTm6ZcODPFxjXnOKxATbp7HbKnGsPESCQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
* Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> [161104 14:55]:
> On Thu, Nov 3, 2016 at 5:35 PM, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
>
> > Drivers using pinctrl-single,pins have #pinctrl-cells = <1>, while
> > pinctrl-single,bits need #pinctrl-cells = <2>.
> >
> > Note that this patch can be optionally applied separately from the
> > driver changes as the driver supports also the legacy binding without
> > #pinctrl-cells.
> >
> > Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
>
> Reviewed-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>
> Please take this through the OMAP tree to avoid hazzle.
OK applied into omap-for-v4.10/pinctrl-cells.
Thanks,
Tony
--
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 1/9] doc: DT: vidc: binding document for Qualcomm video driver
From: Stanimir Varbanov @ 2016-11-07 17:33 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Hans Verkuil
Cc: Andy Gross, Bjorn Andersson, Stephen Boyd, Srinivas Kandagatla,
linux-media, linux-kernel, linux-arm-msm, Stanimir Varbanov,
Rob Herring, Mark Rutland, devicetree
In-Reply-To: <1478540043-24558-1-git-send-email-stanimir.varbanov@linaro.org>
Add binding document for Venus video encoder/decoder driver
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: devicetree@vger.kernel.org
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
---
.../devicetree/bindings/media/qcom,venus.txt | 98 ++++++++++++++++++++++
1 file changed, 98 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/qcom,venus.txt
diff --git a/Documentation/devicetree/bindings/media/qcom,venus.txt b/Documentation/devicetree/bindings/media/qcom,venus.txt
new file mode 100644
index 000000000000..b2af347fbce4
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,venus.txt
@@ -0,0 +1,98 @@
+* Qualcomm Venus video encode/decode accelerator
+
+- compatible:
+ Usage: required
+ Value type: <stringlist>
+ Definition: Value should contain one of:
+ - "qcom,venus-msm8916"
+ - "qcom,venus-msm8996"
+- reg:
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: Register ranges as listed in the reg-names property.
+- reg-names:
+ Usage: required
+ Value type: <stringlist>
+ Definition: Should contain following entries:
+ - "venus" Venus register base
+- reg-names:
+ Usage: optional for msm8996
+ Value type: <stringlist>
+ Definition: Should contain following entries:
+ - "vmem" Video memory register base
+- interrupts:
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: Should contain interrupts as listed in the interrupt-names
+ property.
+- interrupt-names:
+ Usage: required
+ Value type: <stringlist>
+ Definition: Should contain following entries:
+ - "venus" Venus interrupt line
+- interrupt-names:
+ Usage: optional for msm8996
+ Value type: <stringlist>
+ Definition: Should contain following entries:
+ - "vmem" Video memory interrupt line
+- clocks:
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: A List of phandle and clock specifier pairs as listed
+ in clock-names property.
+- clock-names:
+ Usage: required
+ Value type: <stringlist>
+ Definition: Should contain the following entries:
+ - "core" Core video accelerator clock
+ - "iface" Video accelerator AHB clock
+ - "bus" Video accelerator AXI clock
+- clock-names:
+ Usage: required for msm8996
+ Value type: <stringlist>
+ Definition: Should contain the following entries:
+ - "subcore0" Subcore0 video accelerator clock
+ - "subcore1" Subcore1 video accelerator clock
+ - "mmssnoc_axi" Multimedia subsystem NOC AXI clock
+ - "mmss_mmagic_iface" Multimedia subsystem MMAGIC AHB clock
+ - "mmss_mmagic_mbus" Multimedia subsystem MMAGIC MAXI clock
+ - "mmagic_video_bus" MMAGIC video AXI clock
+ - "video_mbus" Video MAXI clock
+- clock-names:
+ Usage: optional for msm8996
+ Value type: <stringlist>
+ Definition: Should contain the following entries:
+ - "vmem_bus" Video memory MAXI clock
+ - "vmem_iface" Video memory AHB clock
+- power-domains:
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: A phandle and power domain specifier pairs to the
+ power domain which is responsible for collapsing
+ and restoring power to the peripheral.
+- rproc:
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: A phandle to remote processor responsible for
+ firmware loading and processor booting.
+
+- iommus:
+ Usage: required
+ Value type: <prop-encoded-array>
+ Definition: A list of phandle and IOMMU specifier pairs.
+
+* An Example
+ video-codec@1d00000 {
+ compatible = "qcom,venus-msm8916";
+ reg = <0x01d00000 0xff000>;
+ reg-names = "venus";
+ interrupts = <GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "venus";
+ clocks = <&gcc GCC_VENUS0_VCODEC0_CLK>,
+ <&gcc GCC_VENUS0_AHB_CLK>,
+ <&gcc GCC_VENUS0_AXI_CLK>;
+ clock-names = "core", "iface", "bus";
+ power-domains = <&gcc VENUS_GDSC>;
+ rproc = <&venus_rproc>;
+ iommus = <&apps_iommu 5>;
+ };
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/3] remoteproc: qcom: add Venus video core firmware loader driver
From: Stanimir Varbanov @ 2016-11-07 17:30 UTC (permalink / raw)
To: Ohad Ben-Cohen, Bjorn Andersson, Stephen Boyd, Andy Gross,
Rob Herring, Mark Rutland
Cc: Srinivas Kandagatla, linux-remoteproc, linux-kernel,
linux-arm-msm, linux-soc, devicetree, Stanimir Varbanov
In-Reply-To: <1478539853-23218-1-git-send-email-stanimir.varbanov@linaro.org>
This driver will load and authenticate the Venus firmware and
bringing it core out of reset. Those two functionalities are
via secure monitor calls to trusted environment.
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
---
drivers/remoteproc/Kconfig | 12 ++
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/qcom_venus_pil.c | 213 ++++++++++++++++++++++++++++++++++++
3 files changed, 226 insertions(+)
create mode 100644 drivers/remoteproc/qcom_venus_pil.c
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index f396bfef5d42..0e90a2491873 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -107,6 +107,18 @@ config QCOM_WCNSS_PIL
Say y here to support the Peripheral Image Loader for the Qualcomm
Wireless Connectivity Subsystem.
+config QCOM_VENUS_PIL
+ tristate "Qualcomm Venus Peripheral Image Loader"
+ depends on OF && ARCH_QCOM
+ depends on QCOM_SCM
+ select QCOM_MDT_LOADER
+ select REMOTEPROC
+ help
+ Say y here to support Qualcomm Peripherial Image Loader for the
+ Venus remote processor. The Venus remote processor is a
+ micro-controller plus dedicated hardware for video acceleration
+ of video decoding and encoding operations.
+
config ST_REMOTEPROC
tristate "ST remoteproc support"
depends on ARCH_STI
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 6dfb62ed643f..852711b89844 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -15,4 +15,5 @@ obj-$(CONFIG_QCOM_MDT_LOADER) += qcom_mdt_loader.o
obj-$(CONFIG_QCOM_Q6V5_PIL) += qcom_q6v5_pil.o
obj-$(CONFIG_QCOM_WCNSS_IRIS) += qcom_wcnss_iris.o
obj-$(CONFIG_QCOM_WCNSS_PIL) += qcom_wcnss.o
+obj-$(CONFIG_QCOM_VENUS_PIL) += qcom_venus_pil.o
obj-$(CONFIG_ST_REMOTEPROC) += st_remoteproc.o
diff --git a/drivers/remoteproc/qcom_venus_pil.c b/drivers/remoteproc/qcom_venus_pil.c
new file mode 100644
index 000000000000..6d4e55bffef5
--- /dev/null
+++ b/drivers/remoteproc/qcom_venus_pil.c
@@ -0,0 +1,213 @@
+/*
+ * Qualcomm Venus Peripheral Image Loader
+ *
+ * Copyright (C) 2016 Linaro Ltd
+ *
+ * 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/dma-mapping.h>
+#include <linux/firmware.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of_reserved_mem.h>
+#include <linux/platform_device.h>
+#include <linux/qcom_scm.h>
+#include <linux/remoteproc.h>
+
+#include "qcom_mdt_loader.h"
+#include "remoteproc_internal.h"
+
+#define VENUS_CRASH_REASON_SMEM 425
+#define VENUS_FIRMWARE_NAME "venus.mdt"
+#define VENUS_PAS_ID 9
+#define VENUS_FW_MEM_SIZE SZ_8M
+
+struct qcom_venus {
+ struct device *dev;
+ struct rproc *rproc;
+ phys_addr_t fw_addr;
+ phys_addr_t mem_phys;
+ void *mem_va;
+ size_t mem_size;
+};
+
+static int venus_load(struct rproc *rproc, const struct firmware *fw)
+{
+ struct qcom_venus *venus = rproc->priv;
+ phys_addr_t pa;
+ size_t fw_size;
+ bool relocate;
+ int ret;
+
+ ret = qcom_scm_pas_init_image(VENUS_PAS_ID, fw->data, fw->size);
+ if (ret) {
+ dev_err(&rproc->dev, "invalid firmware metadata (%d)\n", ret);
+ return -EINVAL;
+ }
+
+ ret = qcom_mdt_parse(fw, &venus->fw_addr, &fw_size, &relocate);
+ if (ret) {
+ dev_err(&rproc->dev, "failed to parse mdt header (%d)\n", ret);
+ return ret;
+ }
+
+ if (fw_size > venus->mem_size)
+ return -ENOMEM;
+
+ pa = relocate ? venus->mem_phys : venus->fw_addr;
+
+ ret = qcom_scm_pas_mem_setup(VENUS_PAS_ID, pa, fw_size);
+ if (ret) {
+ dev_err(&rproc->dev, "unable to setup memory (%d)\n", ret);
+ return -EINVAL;
+ }
+
+ return qcom_mdt_load(rproc, fw, VENUS_FIRMWARE_NAME);
+}
+
+static const struct rproc_fw_ops venus_fw_ops = {
+ .find_rsc_table = qcom_mdt_find_rsc_table,
+ .load = venus_load,
+};
+
+static int venus_start(struct rproc *rproc)
+{
+ struct qcom_venus *venus = rproc->priv;
+ int ret;
+
+ ret = qcom_scm_pas_auth_and_reset(VENUS_PAS_ID);
+ if (ret)
+ dev_err(venus->dev,
+ "authentication image and release reset failed (%d)\n",
+ ret);
+
+ return ret;
+}
+
+static int venus_stop(struct rproc *rproc)
+{
+ struct qcom_venus *venus = rproc->priv;
+ int ret;
+
+ ret = qcom_scm_pas_shutdown(VENUS_PAS_ID);
+ if (ret)
+ dev_err(venus->dev, "failed to shutdown: %d\n", ret);
+
+ return ret;
+}
+
+static void *venus_da_to_va(struct rproc *rproc, u64 da, int len)
+{
+ struct qcom_venus *venus = rproc->priv;
+ s64 offset;
+
+ offset = da - venus->fw_addr;
+
+ if (offset < 0 || offset + len > venus->mem_size)
+ return NULL;
+
+ return venus->mem_va + offset;
+}
+
+static const struct rproc_ops venus_ops = {
+ .start = venus_start,
+ .stop = venus_stop,
+ .da_to_va = venus_da_to_va,
+};
+
+static int venus_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct qcom_venus *venus;
+ struct rproc *rproc;
+ int ret;
+
+ if (!qcom_scm_is_available())
+ return -EPROBE_DEFER;
+
+ if (!qcom_scm_pas_supported(VENUS_PAS_ID)) {
+ dev_err(dev, "PAS is not available for venus\n");
+ return -ENXIO;
+ }
+
+ ret = of_reserved_mem_device_init(dev);
+ if (ret)
+ return ret;
+
+ rproc = rproc_alloc(dev, pdev->name, &venus_ops, VENUS_FIRMWARE_NAME,
+ sizeof(*venus));
+ if (!rproc) {
+ dev_err(dev, "unable to allocate remoteproc\n");
+ ret = -ENOMEM;
+ goto release_mem;
+ }
+
+ rproc->fw_ops = &venus_fw_ops;
+ venus = rproc->priv;
+ venus->dev = dev;
+ venus->rproc = rproc;
+ venus->mem_size = VENUS_FW_MEM_SIZE;
+
+ platform_set_drvdata(pdev, venus);
+
+ venus->mem_va = dma_alloc_coherent(dev, venus->mem_size,
+ &venus->mem_phys, GFP_KERNEL);
+ if (!venus->mem_va) {
+ ret = -ENOMEM;
+ goto free_rproc;
+ }
+
+ ret = rproc_add(rproc);
+ if (ret)
+ goto free_mem;
+
+ return 0;
+
+free_mem:
+ dma_free_coherent(dev, venus->mem_size, venus->mem_va, venus->mem_phys);
+free_rproc:
+ rproc_put(rproc);
+release_mem:
+ of_reserved_mem_device_release(dev);
+
+ return ret;
+}
+
+static int venus_remove(struct platform_device *pdev)
+{
+ struct qcom_venus *venus = platform_get_drvdata(pdev);
+ struct device *dev = venus->dev;
+
+ rproc_del(venus->rproc);
+ rproc_put(venus->rproc);
+ dma_free_coherent(dev, venus->mem_size, venus->mem_va, venus->mem_phys);
+ of_reserved_mem_device_release(dev);
+
+ return 0;
+}
+
+static const struct of_device_id venus_of_match[] = {
+ { .compatible = "qcom,venus-pil" },
+ { },
+};
+
+static struct platform_driver venus_driver = {
+ .probe = venus_probe,
+ .remove = venus_remove,
+ .driver = {
+ .name = "qcom-venus-pil",
+ .of_match_table = venus_of_match,
+ },
+};
+
+module_platform_driver(venus_driver);
+MODULE_DESCRIPTION("Peripheral Image Loader for Venus");
+MODULE_LICENSE("GPL v2");
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/3] dt-binding: remoteproc: venus rproc dt binding document
From: Stanimir Varbanov @ 2016-11-07 17:30 UTC (permalink / raw)
To: Ohad Ben-Cohen, Bjorn Andersson, Stephen Boyd, Andy Gross,
Rob Herring, Mark Rutland
Cc: Srinivas Kandagatla, linux-remoteproc, linux-kernel,
linux-arm-msm, linux-soc, devicetree, Stanimir Varbanov
In-Reply-To: <1478539853-23218-1-git-send-email-stanimir.varbanov@linaro.org>
Add devicetree binding document for Venus remote processor.
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
---
.../devicetree/bindings/remoteproc/qcom,venus.txt | 33 ++++++++++++++++++++++
1 file changed, 33 insertions(+)
create mode 100644 Documentation/devicetree/bindings/remoteproc/qcom,venus.txt
diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,venus.txt b/Documentation/devicetree/bindings/remoteproc/qcom,venus.txt
new file mode 100644
index 000000000000..06a2db60fa38
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,venus.txt
@@ -0,0 +1,33 @@
+Qualcomm Venus Peripheral Image Loader
+
+This document defines the binding for a component that loads and boots firmware
+on the Qualcomm Venus remote processor core.
+
+- compatible:
+ Usage: required
+ Value type: <string>
+ Definition: must contain "qcom,venus-pil"
+
+- memory-region:
+ Usage: required
+ Value type: <phandle>
+ Definition: a phandle to a node describing reserved memory
+
+* An example
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ venus_mem: venus@89900000 {
+ compatible = "shared-dma-pool";
+ reg = <0x0 0x89900000 0x0 0x800000>;
+ alignment = <0x1000>;
+ no-map;
+ };
+ };
+
+ rproc_venus@0 {
+ compatible = "qcom,venus-pil";
+ memory-region = <&venus_mem>;
+ };
--
2.7.4
^ permalink raw reply related
* [PATCH v2 1/3] firmware: qcom: scm: add a video command for state setting
From: Stanimir Varbanov @ 2016-11-07 17:30 UTC (permalink / raw)
To: Ohad Ben-Cohen, Bjorn Andersson, Stephen Boyd, Andy Gross,
Rob Herring, Mark Rutland
Cc: Srinivas Kandagatla, linux-remoteproc, linux-kernel,
linux-arm-msm, linux-soc, devicetree, Stanimir Varbanov
In-Reply-To: <1478539853-23218-1-git-send-email-stanimir.varbanov@linaro.org>
This scm call is used to change the video core state, more
specifically it is used to suspend and resume the core.
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
---
drivers/firmware/qcom_scm-32.c | 18 ++++++++++++++++++
drivers/firmware/qcom_scm-64.c | 16 ++++++++++++++++
drivers/firmware/qcom_scm.c | 16 ++++++++++++++++
drivers/firmware/qcom_scm.h | 2 ++
include/linux/qcom_scm.h | 2 ++
5 files changed, 54 insertions(+)
diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
index c6aeedbdcbb0..82c1d8d0d36b 100644
--- a/drivers/firmware/qcom_scm-32.c
+++ b/drivers/firmware/qcom_scm-32.c
@@ -560,3 +560,21 @@ int __qcom_scm_pas_mss_reset(struct device *dev, bool reset)
return ret ? : le32_to_cpu(out);
}
+
+int __qcom_scm_video_set_state(struct device *dev, u32 state, u32 spare)
+{
+ struct {
+ __le32 state;
+ __le32 spare;
+ } req;
+ __le32 scm_ret = 0;
+ int ret;
+
+ req.state = cpu_to_le32(state);
+ req.spare = cpu_to_le32(spare);
+
+ ret = qcom_scm_call(dev, QCOM_SCM_SVC_BOOT, QCOM_SCM_VIDEO_SET_STATE,
+ &req, sizeof(req), &scm_ret, sizeof(scm_ret));
+
+ return ret ? : le32_to_cpu(scm_ret);
+}
diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c
index 4a0f5ead4fb5..68484ea2aa51 100644
--- a/drivers/firmware/qcom_scm-64.c
+++ b/drivers/firmware/qcom_scm-64.c
@@ -358,3 +358,19 @@ int __qcom_scm_pas_mss_reset(struct device *dev, bool reset)
return ret ? : res.a1;
}
+
+int __qcom_scm_video_set_state(struct device *dev, u32 state, u32 spare)
+{
+ struct qcom_scm_desc desc = {0};
+ struct arm_smccc_res res;
+ int ret;
+
+ desc.args[0] = state;
+ desc.args[1] = spare;
+ desc.arginfo = QCOM_SCM_ARGS(2);
+
+ ret = qcom_scm_call(dev, QCOM_SCM_SVC_BOOT, QCOM_SCM_VIDEO_SET_STATE,
+ &desc, &res);
+
+ return ret ? : res.a1;
+}
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index d95c70227c05..7e364691a87c 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -320,6 +320,22 @@ bool qcom_scm_is_available(void)
}
EXPORT_SYMBOL(qcom_scm_is_available);
+int qcom_scm_video_set_state(u32 state, u32 spare)
+{
+ int ret;
+
+ ret = qcom_scm_clk_enable();
+ if (ret)
+ return ret;
+
+ ret = __qcom_scm_video_set_state(__scm->dev, state, spare);
+
+ qcom_scm_clk_disable();
+
+ return ret;
+}
+EXPORT_SYMBOL(qcom_scm_video_set_state);
+
static int qcom_scm_probe(struct platform_device *pdev)
{
struct qcom_scm *scm;
diff --git a/drivers/firmware/qcom_scm.h b/drivers/firmware/qcom_scm.h
index 3584b00fe7e6..4830559b2639 100644
--- a/drivers/firmware/qcom_scm.h
+++ b/drivers/firmware/qcom_scm.h
@@ -15,6 +15,8 @@
#define QCOM_SCM_SVC_BOOT 0x1
#define QCOM_SCM_BOOT_ADDR 0x1
#define QCOM_SCM_BOOT_ADDR_MC 0x11
+#define QCOM_SCM_VIDEO_SET_STATE 0xa
+extern int __qcom_scm_video_set_state(struct device *dev, u32 state, u32 spare);
#define QCOM_SCM_FLAG_HLOS 0x01
#define QCOM_SCM_FLAG_COLDBOOT_MC 0x02
diff --git a/include/linux/qcom_scm.h b/include/linux/qcom_scm.h
index cc32ab852fbc..2ece81a6b078 100644
--- a/include/linux/qcom_scm.h
+++ b/include/linux/qcom_scm.h
@@ -46,4 +46,6 @@ extern void qcom_scm_cpu_power_down(u32 flags);
extern u32 qcom_scm_get_version(void);
+extern int qcom_scm_video_set_state(u32 state, u32 spare);
+
#endif
--
2.7.4
^ permalink raw reply related
* [PATCH v2 0/3] Venus remoteproc driver
From: Stanimir Varbanov @ 2016-11-07 17:30 UTC (permalink / raw)
To: Ohad Ben-Cohen, Bjorn Andersson, Stephen Boyd, Andy Gross,
Rob Herring, Mark Rutland
Cc: Srinivas Kandagatla, linux-remoteproc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Stanimir Varbanov
Hi,
here is v2 of the Venus remoteproc driver, the changes are:
- removed page table size and page table init SCM calls.
regards,
Stan
Stanimir Varbanov (3):
firmware: qcom: scm: add a video command for state setting
dt-binding: remoteproc: venus rproc dt binding document
remoteproc: qcom: add Venus video core firmware loader driver
.../devicetree/bindings/remoteproc/qcom,venus.txt | 33 ++++
drivers/firmware/qcom_scm-32.c | 18 ++
drivers/firmware/qcom_scm-64.c | 16 ++
drivers/firmware/qcom_scm.c | 16 ++
drivers/firmware/qcom_scm.h | 2 +
drivers/remoteproc/Kconfig | 12 ++
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/qcom_venus_pil.c | 213 +++++++++++++++++++++
include/linux/qcom_scm.h | 2 +
9 files changed, 313 insertions(+)
create mode 100644 Documentation/devicetree/bindings/remoteproc/qcom,venus.txt
create mode 100644 drivers/remoteproc/qcom_venus_pil.c
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/6] clk: Add driver for Maxim-8997 PMIC clocks
From: Pankaj Dubey @ 2016-11-07 17:20 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-samsung-soc,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA,
thomas.ab-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org, Kukjin Kim,
Michael Turquette, Krzysztof Kozlowski, Rob Herring,
myungjoo.ham-Sze3O3UU22JBDgjK7y7TUQ,
linux-clk-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <63750c2f-35cb-91ab-276b-c788f51081cb-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org>
Hi Javier,
On 7 November 2016 at 20:31, Javier Martinez Canillas
<javier-JPH+aEBZ4P+UEJcrhfAQsw@public.gmane.org> wrote:
> Hello Pankaj,
>
> On 11/07/2016 07:09 AM, Pankaj Dubey wrote:
>> The MAX8997 PMIC has 32.786kHz crystal oscillator which provides an
>> accurate low frequency clock for MAX8997 internal circuit as well as
>> external circuit. This patch adds support for these two clocks.
>>
>> CC: Michael Turquette <mturquette-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
>> CC: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> CC: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> CC: linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> Signed-off-by: Pankaj Dubey <pankaj.dubey-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>> ---
>
> What kernel version are you basing this on? The Maxim common clock code
This patch series, I have prepared on Krzysztof's for-next which is 4.9-rc1,
> is going away for v4.9 and instead the clk-max77686 driver supports both
> 77686 and 77802 clocks. See commit 8ad313fe4e00 ("clk: max77686: Combine
> Maxim max77686 and max77802 driver").
>
> Since the 8997 clock IP looks very similar to 77802 AFAICT, you should
> also extend the clk-max77686 driver to have 8997 support.
>
I was not aware of this change. I will check this and if I can
reuse/extend max77686 for 8997 I will do it.
Thanks,
Pankaj Dubey
> Best regards,
> --
> Javier Martinez Canillas
> Open Source Group
> Samsung Research America
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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: [REGRESSION] "console: don't prefer first registered if DT specifies stdout-path" breaks console on video outputs of various ARM boards
From: Paul Burton @ 2016-11-07 17:16 UTC (permalink / raw)
To: Hans de Goede
Cc: Linus Torvalds, Andrew Morton, Rob Herring, Frank Rowand,
Thorsten Leemhuis, Greg Kroah-Hartman, Tejun Heo, devicetree,
linux-kernel
In-Reply-To: <cf275db8-6d2b-c891-9280-f141c6f10733@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2849 bytes --]
Hi Hans,
On Sunday, 6 November 2016 11:54:35 GMT Hans de Goede wrote:
> > What I see in my systems, and what 05fd007e4629 ("console: don't prefer
> > first registered if DT specifies stdout-path") addressed, is that if
> > there are for example 2 UARTs uart0 & uart1 that are probed in that order
> > and stdout-path indicates that we should use uart1 we wind up essentially
> > ignoring it because>
> > the ordering of the relevant calls goes:
> > - of_console_check() for uart0
> > - add_preferred_console() for uart0
> > - register_console() for uart0
> > - of_console_check() for uart1
> > - add_preferred_console() for uart1
> > - register_console() for uart1
> >
> > Since of_check_console() doesn't get called for uart1 until after uart0
> > has
> > been probed, we don't add an entry for it to the console_cmdline array
> > until after register_console() has already decided to enable uart0
> > because preferred_console == -1.
> >
> > I'm not the only one seeing this oddity either, for example see the
> > discussion on this patch:
> >
> > https://patchwork.kernel.org/patch/9263753/
> >
> > By simply reverting my patch you restore us to a position where so far as
> > I
> > can see we simply do not honor stdout-path for the real kernel console.
>
> As said before, we do still honor it, but in your probe example we also get
> a (second) serial console on uart0, where as you only want one on uart1.
...but don't we only support one console per type of device? That's what
Documentation/serial-console.txt says anyway, which means having a console on
both uart0 & uart1 does not work. I could live with having console output on
an extra UART, but that's not what I was seeing when I wrote this patch.
> So I see a few possible solutions here:
>
> 1) Do a new version of your patch which changes the "&&
> !of_specified_console" check to "&& (newcon == tty0 ||
> !of_specified_console)", then we would still always register tty0 (as long
> as it gets registered first, just like now) and we would not register uart0
> in your above example, note the "newcon == tty0" check in my example is
> pseudo-code. I would be happy to try out such a patch
>
> 2) Add a new dt property to enable the new behavior you seek
>
> I'm myself tending towards 1 as a better solution: treat tty0 special,
> because some existing setups rely on it always being registered as a
> console even if stdout-path is specified and otherwise always honor
> stdout-path.
>
> Regards,
>
> Hans
That does feel a little hack-ish to me though... I don't like the reliance on
probe ordering, nor special casing tty0 in general.
In any case I don't think I have the time to unpick all this at the moment, so
I suggest we go ahead with your revert for now & I'll revisit the system I was
working on when I find the time.
Thanks,
Paul
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: Add Broadcom Northstar2 device tree entries for PDC driver.
From: Florian Fainelli @ 2016-11-07 17:06 UTC (permalink / raw)
To: Rob Rice, Jassi Brar, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Ray Jui, Scott Branden,
Jon Mason, Florian Fainelli, Anup Patel, Catalin Marinas,
Will Deacon, Rob Rice
In-Reply-To: <1467316764-19686-4-git-send-email-rob.rice-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On 06/30/2016 12:59 PM, Rob Rice wrote:
> From: Rob Rice <rrice-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>
> Add Broadcom Northstar2 SoC device tree entries for PDC driver.
>
> Signed-off-by: Rob Rice <rob.rice-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Reviewed-by: Ray Jui <ray.jui-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Reviewed-by: Scott Branden <scott.branden-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Applied, thanks Rob!
--
Florian
--
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: [v17 2/2] drm/bridge: Add I2C based driver for ps8640 bridge
From: Matthias Brugger @ 2016-11-07 16:53 UTC (permalink / raw)
To: Daniel Kurtz
Cc: Enric Balletbo Serra, Jitao Shi, David Airlie, Thierry Reding,
Mark Rutland, stonea168-9Onoh4P/yGk, dri-devel, Andy Yan,
Ajay Kumar, Vincent Palatin, cawa cheng,
Bibby Hsieh (謝濟遠),
CK Hu (胡俊光), Russell King,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Sascha Hauer,
Pawel Moll, Ian Campbell
In-Reply-To: <CAGS+omDmFdqzuFqcCe9gFGemZc88Yt0_3_o2KwOgW=GN_kCakQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 05/11/16 00:21, Daniel Kurtz wrote:
> On Tue, Oct 25, 2016 at 6:23 AM, Matthias Brugger
> <matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>
>> On 10/18/2016 04:37 PM, Enric Balletbo Serra wrote:
>> [...]
>>>> --- /dev/null
>>>> +++ b/drivers/gpu/drm/bridge/parade-ps8640.c
>> [...]
>>>>
>>>> +
>>>> +/* Firmware */
>>>> +#define PS_FW_NAME "ps864x_fw.bin"
>>>> +
>>>
>>> From where I can download this firmware image?
>>
>> I suppose this FW bits have to be added to linux-firmware repository first, before this patch can be accepted.
>
> All PS8640 devices should already ship with working firmware.
> The firmware update procedure is only used in the unlikely event where
> one wants to update the bridge to a different firmware provided by
> Parade.
>
> Why must the lack of firmware really block landing this driver?
>
> If this is really so, can we just land the functional part of the
> driver first, and add the firmware update in a follow-up patch.
>
After checking other users of request_firmware and check them against
linux-firmware I think we don't need the FW in linux-firmware to get the
driver merged. Especially as there already is a working FW stored on the
device.
Regards,
Matthias
--
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/8] iio:core: add a callback to allow drivers to provide _available attributes
From: Slawomir Stepien @ 2016-11-07 16:46 UTC (permalink / raw)
To: Peter Rosin
Cc: Daniel Baluta, Linux Kernel Mailing List, Jonathan Cameron,
Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
Rob Herring, Mark Rutland, linux-iio@vger.kernel.org,
Devicetree List
In-Reply-To: <62f150ba-abc0-8e45-1355-8a61354ee3e1@axentia.se>
On Nov 07, 2016 12:57, Peter Rosin wrote:
> On 2016-11-07 12:37, Daniel Baluta wrote:
> > On Mon, Oct 24, 2016 at 1:39 AM, Peter Rosin <peda@axentia.se> wrote:
> >> From: Jonathan Cameron <jic23@kernel.org>
> >>
> >> A large number of attributes can only take a limited range of values.
> >> Currently in IIO this is handled by directly registering additional
> >> *_available attributes thus providing this information to userspace.
> >>
> >> It is desirable to provide this information via the core for much the same
> >> reason this was done for the actual channel information attributes in the
> >> first place. If it isn't there, then it can only really be accessed from
> >> userspace. Other in kernel IIO consumers have no access to what valid
> >> parameters are.
> >>
> >> Two forms are currently supported:
> >> * list of values in one particular IIO_VAL_* format.
> >> e.g. 1.300000 1.500000 1.730000
> >> * range specification with a step size:
> >> e.g. [1.000000 0.500000 2.500000]
> >> equivalent to 1.000000 1.5000000 2.000000 2.500000
> >
> > Is there any driver using this format? :)
>
> Yes, soon. Hopefully. See patch 3/8
> iio: mcp4531: provide range of available raw values
> https://patchwork.kernel.org/patch/9391283/
I would also like to add this to mcp4131.c and ds1803.c.
--
Slawomir Stepien
^ permalink raw reply
* [PATCH 3/3] arm64: dts: hisi: add refclk node to hip06 dts files for SAS
From: John Garry @ 2016-11-07 16:44 UTC (permalink / raw)
To: xuwei5-C8/M+/jPZTeaMJb+Lgu22Q
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linuxarm-hv44wF8Li93QT0dZR+AlfA, John Garry
In-Reply-To: <1478537065-169286-1-git-send-email-john.garry-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
We will only maintain 1 dts for D03 and there are 50MHz
and 66MHz versions of D03: so we expect UEFI to update
refclk rate in the fdt at boot time.
Signed-off-by: John Garry <john.garry-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Reviewed-by: Xiang Chen <chenxiang66-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
---
arch/arm64/boot/dts/hisilicon/hip06.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hip06.dtsi b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
index 5330abb..7b40dce 100644
--- a/arch/arm64/boot/dts/hisilicon/hip06.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
@@ -318,6 +318,12 @@
#size-cells = <2>;
ranges;
+ refclk: refclk {
+ compatible = "fixed-clock";
+ clock-frequency = <50000000>;
+ #clock-cells = <0>;
+ };
+
usb_ohci: ohci@a7030000 {
compatible = "generic-ohci";
reg = <0x0 0xa7030000 0x0 0x10000>;
@@ -552,6 +558,7 @@
ctrl-reset-reg = <0xa60>;
ctrl-reset-sts-reg = <0x5a30>;
ctrl-clock-ena-reg = <0x338>;
+ clocks = <&refclk 0>;
queue-count = <16>;
phy-count = <8>;
dma-coherent;
@@ -594,6 +601,7 @@
ctrl-reset-reg = <0xa18>;
ctrl-reset-sts-reg = <0x5a0c>;
ctrl-clock-ena-reg = <0x318>;
+ clocks = <&refclk 0>;
queue-count = <16>;
phy-count = <8>;
dma-coherent;
@@ -635,6 +643,7 @@
ctrl-reset-reg = <0xae0>;
ctrl-reset-sts-reg = <0x5a70>;
ctrl-clock-ena-reg = <0x3a8>;
+ clocks = <&refclk 0>;
queue-count = <16>;
phy-count = <9>;
dma-coherent;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 2/3] arm64: dts: hisi: disable sas0 and sas2 for d03
From: John Garry @ 2016-11-07 16:44 UTC (permalink / raw)
To: xuwei5
Cc: robh+dt, mark.rutland, will.deacon, catalin.marinas,
linux-arm-kernel, devicetree, linux-kernel, linuxarm, John Garry
In-Reply-To: <1478537065-169286-1-git-send-email-john.garry@huawei.com>
The SAS nodes sas0 and sas2 are not available on d03, so
disable them.
Signed-off-by: John Garry <john.garry@huawei.com>
Acked-by: Xu Wei <xuwei5@hisilicon.com>
---
arch/arm64/boot/dts/hisilicon/hip06-d03.dts | 8 --------
1 file changed, 8 deletions(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hip06-d03.dts b/arch/arm64/boot/dts/hisilicon/hip06-d03.dts
index f54b283..7c4114a 100644
--- a/arch/arm64/boot/dts/hisilicon/hip06-d03.dts
+++ b/arch/arm64/boot/dts/hisilicon/hip06-d03.dts
@@ -41,18 +41,10 @@
status = "ok";
};
-&sas0 {
- status = "ok";
-};
-
&sas1 {
status = "ok";
};
-&sas2 {
- status = "ok";
-};
-
&usb_ohci {
status = "ok";
};
--
1.9.1
^ permalink raw reply related
* [PATCH 1/3] arm64: dts: hisi: fix hip06 sas am-max-trans quirk
From: John Garry @ 2016-11-07 16:44 UTC (permalink / raw)
To: xuwei5-C8/M+/jPZTeaMJb+Lgu22Q
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linuxarm-hv44wF8Li93QT0dZR+AlfA, John Garry
In-Reply-To: <1478537065-169286-1-git-send-email-john.garry-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
The string for the am max transmissions quirk property
is not correct -> fix it.
Signed-off-by: John Garry <john.garry-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
Reviewed-by: Xiang Chen <chenxiang66-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>
---
arch/arm64/boot/dts/hisilicon/hip06.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hip06.dtsi b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
index b548763..5330abb 100644
--- a/arch/arm64/boot/dts/hisilicon/hip06.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
@@ -590,7 +590,7 @@
reg = <0 0xa2000000 0 0x10000>;
sas-addr = [50 01 88 20 16 00 00 00];
hisilicon,sas-syscon = <&pcie_subctl>;
- am-max-trans;
+ hip06-sas-v2-quirk-amt;
ctrl-reset-reg = <0xa18>;
ctrl-reset-sts-reg = <0x5a0c>;
ctrl-clock-ena-reg = <0x318>;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 0/3] arm64: dts: hisi: hip06 SAS device tree fixes
From: John Garry @ 2016-11-07 16:44 UTC (permalink / raw)
To: xuwei5
Cc: robh+dt, mark.rutland, will.deacon, catalin.marinas,
linux-arm-kernel, devicetree, linux-kernel, linuxarm, John Garry
This patchset resolves some hip06 SAS device tree issues.
John Garry (3):
arm64: dts: hisi: fix hip06 sas am-max-trans quirk
arm64: dts: hisi: disable sas0 and sas2 for d03
arm64: dts: hisi: add refclk node to hip06 dts files for SAS
arch/arm64/boot/dts/hisilicon/hip06-d03.dts | 8 --------
arch/arm64/boot/dts/hisilicon/hip06.dtsi | 11 ++++++++++-
2 files changed, 10 insertions(+), 9 deletions(-)
--
1.9.1
^ permalink raw reply
* Re: [PATCH v2 1/2] regulator: Add coupled regulator
From: Maxime Ripard @ 2016-11-07 15:47 UTC (permalink / raw)
To: Mark Brown
Cc: Rob Herring, Chen-Yu Tsai, Liam Girdwood,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20160205153258.GW4455-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2647 bytes --]
Hi Mark,
On Fri, Feb 05, 2016 at 03:32:58PM +0000, Mark Brown wrote:
> On Fri, Feb 05, 2016 at 03:33:28PM +0100, Maxime Ripard wrote:
> > On Thu, Jan 21, 2016 at 04:28:02PM +0000, Mark Brown wrote:
> > > On Thu, Jan 21, 2016 at 04:46:49PM +0100, Maxime Ripard wrote:
>
> > > > Anyway, I'm fine with both approaches, just let me know what you
> > > > prefer.
>
> > > Without seeing an implementation of the lists it's hard to say.
>
> > Just to make sure we're on the same page: you want to keep the
> > regulator, but instead of giving the parent through vinX-supplies
> > properties, you want to have a single *-supply property, with a list
> > of regulators, right?
>
> Either that or an explicit regulator describing the merge. Rob wants
> the list I think but I really don't care.
So, I'm reviving this old thread after speaking to you about it at
ELCE and trying to code something up, and getting lost..
To put a bit of context, I'm still trying to tackle the issue of
devices that have two regulators powering them on the same pin for
example when each regulator cannot provide enough current alone to
power the device (all the setups like this one I've seen so far were
for WiFi chips, but it might be different).
I guess we already agreed on the fact that the DT binding should just
be to allow a *-supply property to take multiple regulators, and mark
them as "coupled" (or whatever name we see fit) in such a case.
Since regulator_get returns a struct regulator pointer, it felt
logical to try to add the list of parent regulators to it, especially
as this structure is per-consumer, and different consumers might have
different combinations of regulators.
However, this structure embeds a pointer to a struct regulator_dev,
which seems to model the regulator itself, but will also contain
pointer to the struct regulator, probably to model its parent? I guess
my first question would be do we care about nesting? or having a
regulator with multiple parents?
It also contains the constraints on each regulator, which might or
might not be different for each of the coupled regulators, but I'm
guessing the couple might have contraints of its own too I guess. Is
it something that might happen? Should we care about it?
And finally, my real question is, do we want to aggregate them in
struct regulator, at the consumer level, which might make the more
sense, or do we want to create an intermediate regulator internally?
What is your take on this?
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox