* [PATCH 05/10] PCI: Export pci_find_host_bridge()
From: Manikanta Maddireddy @ 2017-11-24 15:53 UTC (permalink / raw)
To: thierry.reding, jonathanh, robh+dt, frowand.list, bhelgaas, rjw,
tglx
Cc: vidyas, kthota, linux-tegra, devicetree, linux-pci, linux-pm,
Manikanta Maddireddy
In-Reply-To: <1511538800-8275-1-git-send-email-mmaddireddy@nvidia.com>
Allow PCI host driver to use pci_find_host_bridge() to get
pci_host_bridge from pci_bus.
Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
---
drivers/pci/host-bridge.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pci/host-bridge.c b/drivers/pci/host-bridge.c
index add66236215c..e0942fc086ad 100644
--- a/drivers/pci/host-bridge.c
+++ b/drivers/pci/host-bridge.c
@@ -22,6 +22,7 @@ struct pci_host_bridge *pci_find_host_bridge(struct pci_bus *bus)
return to_pci_host_bridge(root_bus->bridge);
}
+EXPORT_SYMBOL(pci_find_host_bridge);
struct device *pci_get_host_bridge_device(struct pci_dev *dev)
{
--
2.1.4
^ permalink raw reply related
* [PATCH 04/10] ARM: tegra: EXPORT tegra_cpuidle_pcie_irqs_in_use()
From: Manikanta Maddireddy @ 2017-11-24 15:53 UTC (permalink / raw)
To: thierry.reding, jonathanh, robh+dt, frowand.list, bhelgaas, rjw,
tglx
Cc: vidyas, kthota, linux-tegra, devicetree, linux-pci, linux-pm,
Manikanta Maddireddy
In-Reply-To: <1511538800-8275-1-git-send-email-mmaddireddy@nvidia.com>
EXPORT tegra_cpuidle_pcie_irqs_in_use() to allow Tegra PCIe driver to be
compiled as loadable kernel module.
Signed-off-by: Manikanta Maddireddy <mmaddireddy@nvidia.com>
---
arch/arm/mach-tegra/cpuidle.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-tegra/cpuidle.c b/arch/arm/mach-tegra/cpuidle.c
index 316563141add..7d7e6d3ce32d 100644
--- a/arch/arm/mach-tegra/cpuidle.c
+++ b/arch/arm/mach-tegra/cpuidle.c
@@ -57,3 +57,4 @@ void tegra_cpuidle_pcie_irqs_in_use(void)
break;
}
}
+EXPORT_SYMBOL(tegra_cpuidle_pcie_irqs_in_use);
--
2.1.4
^ permalink raw reply related
* [PATCH 03/10] PM / QoS: Fix device resume latency for non PM QoS devices
From: Manikanta Maddireddy @ 2017-11-24 15:53 UTC (permalink / raw)
To: thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
jonathanh-DDmLM1+adcrQT0dZR+AlfA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, rjw-LthD3rsA81gm4RdzfppkhA,
tglx-hfZtesqFncYOwBW4kG4KsQ
Cc: vidyas-DDmLM1+adcrQT0dZR+AlfA, kthota-DDmLM1+adcrQT0dZR+AlfA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, linux-pm-u79uwXL29TY76Z2rM5mHXA,
Manikanta Maddireddy
In-Reply-To: <1511538800-8275-1-git-send-email-mmaddireddy-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
In 'commit 0cc2b4e5a020 ("PM / QoS: Fix device resume latency PM QoS")'
PM QoS resume latency modified 0 as "no latency at all". However
dev_pm_qos_raw_read_value() returns 0 for devices which doesn't have
PM QoS constraints. This is blocking runtime suspend for these devices
in rpm_check_suspend_allowed(). Return PM_QOS_RESUME_LATENCY_NO_CONSTRAINT
when PM QoS constraints are not available for a particular device.
Fixes: 0cc2b4e5a020 ("PM / QoS: Fix device resume latency PM QoS")
Signed-off-by: Manikanta Maddireddy <mmaddireddy-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
include/linux/pm_qos.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/pm_qos.h b/include/linux/pm_qos.h
index 6737a8c9e8c6..d68b0569a5eb 100644
--- a/include/linux/pm_qos.h
+++ b/include/linux/pm_qos.h
@@ -175,7 +175,8 @@ static inline s32 dev_pm_qos_requested_flags(struct device *dev)
static inline s32 dev_pm_qos_raw_read_value(struct device *dev)
{
return IS_ERR_OR_NULL(dev->power.qos) ?
- 0 : pm_qos_read_value(&dev->power.qos->resume_latency);
+ PM_QOS_RESUME_LATENCY_NO_CONSTRAINT :
+ pm_qos_read_value(&dev->power.qos->resume_latency);
}
#else
static inline enum pm_qos_flags_status __dev_pm_qos_flags(struct device *dev,
--
2.1.4
^ permalink raw reply related
* [PATCH 02/10] of: Export of_pci_range_to_resource()
From: Manikanta Maddireddy @ 2017-11-24 15:53 UTC (permalink / raw)
To: thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
jonathanh-DDmLM1+adcrQT0dZR+AlfA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, rjw-LthD3rsA81gm4RdzfppkhA,
tglx-hfZtesqFncYOwBW4kG4KsQ
Cc: vidyas-DDmLM1+adcrQT0dZR+AlfA, kthota-DDmLM1+adcrQT0dZR+AlfA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, linux-pm-u79uwXL29TY76Z2rM5mHXA,
Manikanta Maddireddy
In-Reply-To: <1511538800-8275-1-git-send-email-mmaddireddy-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Allow PCI host driver to use of_pci_range_to_resource() to create a
resource from an of_pci_range.
Signed-off-by: Manikanta Maddireddy <mmaddireddy-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
drivers/of/address.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/of/address.c b/drivers/of/address.c
index 792722e7d458..9c7b2071bf2f 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -348,6 +348,7 @@ int of_pci_range_to_resource(struct of_pci_range *range,
res->end = (resource_size_t)OF_BAD_ADDR;
return err;
}
+EXPORT_SYMBOL(of_pci_range_to_resource);
#endif /* CONFIG_PCI */
/*
--
2.1.4
^ permalink raw reply related
* [PATCH 01/10] genirq: Export irq_set_msi_desc()
From: Manikanta Maddireddy @ 2017-11-24 15:53 UTC (permalink / raw)
To: thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
jonathanh-DDmLM1+adcrQT0dZR+AlfA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, rjw-LthD3rsA81gm4RdzfppkhA,
tglx-hfZtesqFncYOwBW4kG4KsQ
Cc: vidyas-DDmLM1+adcrQT0dZR+AlfA, kthota-DDmLM1+adcrQT0dZR+AlfA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, linux-pm-u79uwXL29TY76Z2rM5mHXA,
Manikanta Maddireddy
In-Reply-To: <1511538800-8275-1-git-send-email-mmaddireddy-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
PCI bus support MSI interrupts, allow PCI host driver to set MSI descriptor
data for an irq.
Signed-off-by: Manikanta Maddireddy <mmaddireddy-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
kernel/irq/chip.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 5a2ef92c2782..bfbd17386bc4 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -136,6 +136,7 @@ int irq_set_msi_desc(unsigned int irq, struct msi_desc *entry)
{
return irq_set_msi_desc_off(irq, 0, entry);
}
+EXPORT_SYMBOL(irq_set_msi_desc);
/**
* irq_set_chip_data - set irq chip data for an irq
--
2.1.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
* [PATCH 00/10] Add loadable kernel module and power management support
From: Manikanta Maddireddy @ 2017-11-24 15:53 UTC (permalink / raw)
To: thierry.reding-Re5JQEeQqe8AvxtiuMwx3w,
jonathanh-DDmLM1+adcrQT0dZR+AlfA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, rjw-LthD3rsA81gm4RdzfppkhA,
tglx-hfZtesqFncYOwBW4kG4KsQ
Cc: vidyas-DDmLM1+adcrQT0dZR+AlfA, kthota-DDmLM1+adcrQT0dZR+AlfA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, linux-pm-u79uwXL29TY76Z2rM5mHXA,
Manikanta Maddireddy
This series of patches add loadable kernel module and power management
support to Tegra PCIe host controller driver.
These patches are tested on Jetson TK1, TX1 and TX2 platforms, following
are the verification details.
- Multiple module insert & remove
- PCIe device functionality after module insert
- Free clock, resets, regulators, powergate, iomem and interrupt
resources after module remove
- PCIe device functionality after resume from RAM
Tegra PCIe host controller driver is using ioremap_page_range() which is
not exported. This is switched with devm_ioremap() in the series
'https://patchwork.ozlabs.org/project/linux-tegra/list/?series=9907'.
Both these series will complete the loadable module support for Tegra
PCIe host driver.
Manikanta Maddireddy (10):
genirq: Export irq_set_msi_desc()
of: Export of_pci_range_to_resource()
PM / QoS: Fix device resume latency for non PM QoS devices
ARM: tegra: EXPORT tegra_cpuidle_pcie_irqs_in_use()
PCI: Export pci_find_host_bridge()
PCI: Export pci_flags
PCI: tegra: free resources on probe failure
PCI: tegra: Add loadable kernel module support
PCI: tegra: Broadcast PME_turn_Off message before link goes to L2
PCI: tegra: Add power management support
arch/arm/mach-tegra/cpuidle.c | 1 +
drivers/of/address.c | 1 +
drivers/pci/host-bridge.c | 1 +
drivers/pci/host/Kconfig | 2 +-
drivers/pci/host/pci-tegra.c | 359 +++++++++++++++++++++++++++++++++---------
drivers/pci/setup-bus.c | 1 +
include/linux/pm_qos.h | 3 +-
kernel/irq/chip.c | 1 +
8 files changed, 294 insertions(+), 75 deletions(-)
--
2.1.4
^ permalink raw reply
* Re: [PATCH 2/3] hwrng: exynos - add Samsung Exynos True RNG driver
From: PrasannaKumar Muralidharan @ 2017-11-24 15:25 UTC (permalink / raw)
To: Łukasz Stelmach
Cc: Rob Herring, Matt Mackall, Herbert Xu, Krzysztof Kozlowski,
devicetree, open list:HARDWARE RANDOM NUMBER GENERATOR CORE,
linux-samsung-soc, open list, Marek Szyprowski,
Bartlomiej Zolnierkiewicz
In-Reply-To: <20171123150914.31462-3-l.stelmach@samsung.com>
Hi Lukasz,
Some minor comments below.
On 23 November 2017 at 20:39, Łukasz Stelmach <l.stelmach@samsung.com> wrote:
> Add support for True Random Number Generator found in Samsung Exynos
> 5250+ SoCs.
>
> Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
> ---
> MAINTAINERS | 7 +
> drivers/char/hw_random/Kconfig | 12 ++
> drivers/char/hw_random/Makefile | 1 +
> drivers/char/hw_random/exynos-trng.c | 256 +++++++++++++++++++++++++++++++++++
> 4 files changed, 276 insertions(+)
> create mode 100644 drivers/char/hw_random/exynos-trng.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2811a211632c..992074cca612 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -11780,6 +11780,13 @@ S: Maintained
> F: drivers/crypto/exynos-rng.c
> F: Documentation/devicetree/bindings/rng/samsung,exynos-rng4.txt
>
> +SAMSUNG EXYNOS TRUE RANDOM NUMBER GENERATOR (TRNG) DRIVER
> +M: Łukasz Stelmach <l.stelmach@samsung.com>
> +L: linux-samsung-soc@vger.kernel.org
> +S: Maintained
> +F: drivers/char/hw_random/exynos-trng.c
> +F: Documentation/devicetree/bindings/rng/samsung,exynos5250-trng.txt
> +
> SAMSUNG FRAMEBUFFER DRIVER
> M: Jingoo Han <jingoohan1@gmail.com>
> L: linux-fbdev@vger.kernel.org
> diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
> index 95a031e9eced..a788ac07081b 100644
> --- a/drivers/char/hw_random/Kconfig
> +++ b/drivers/char/hw_random/Kconfig
> @@ -449,6 +449,18 @@ config HW_RANDOM_S390
>
> If unsure, say Y.
>
> +config HW_RANDOM_EXYNOS
> + tristate "Samsung Exynos True Random Number Generator support"
> + depends on ARCH_EXYNOS || COMPILE_TEST
> + default HW_RANDOM
> + ---help---
> + This driver provides support for the True Random Number
> + Generator available in Exynos SoCs.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called exynos-trng.
> +
> + If unsure, say Y.
> endif # HW_RANDOM
>
> config UML_RANDOM
> diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
> index f3728d008fff..5595df97da7a 100644
> --- a/drivers/char/hw_random/Makefile
> +++ b/drivers/char/hw_random/Makefile
> @@ -14,6 +14,7 @@ obj-$(CONFIG_HW_RANDOM_GEODE) += geode-rng.o
> obj-$(CONFIG_HW_RANDOM_N2RNG) += n2-rng.o
> n2-rng-y := n2-drv.o n2-asm.o
> obj-$(CONFIG_HW_RANDOM_VIA) += via-rng.o
> +obj-$(CONFIG_HW_RANDOM_EXYNOS) += exynos-trng.o
> obj-$(CONFIG_HW_RANDOM_IXP4XX) += ixp4xx-rng.o
> obj-$(CONFIG_HW_RANDOM_OMAP) += omap-rng.o
> obj-$(CONFIG_HW_RANDOM_OMAP3_ROM) += omap3-rom-rng.o
> diff --git a/drivers/char/hw_random/exynos-trng.c b/drivers/char/hw_random/exynos-trng.c
> new file mode 100644
> index 000000000000..340e106cae24
> --- /dev/null
> +++ b/drivers/char/hw_random/exynos-trng.c
> @@ -0,0 +1,256 @@
> +/*
> + * RNG driver for Exynos TRNGs
> + *
> + * Author: Łukasz Stelmach <l.stelmach@samsung.com>
> + *
> + * Copyright 2017 (c) Samsung Electronics Software, Inc.
> + *
> + * Based on the Exynos PRNG driver drivers/crypto/exynos-rng by
> + * Krzysztof Kozłowski <krzk@kernel.org>
> + *
> + * 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;
> + *
> + * 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/clk.h>
> +#include <linux/crypto.h>
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/hw_random.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_runtime.h>
> +
> +#define EXYNOS_TRNG_CLKDIV (0x0)
> +#define EXYNOS_TRNG_CTRL (0x20)
> +#define EXYNOS_TRNG_POST_CTRL (0x30)
> +#define EXYNOS_TRNG_ONLINE_CTRL (0x40)
> +#define EXYNOS_TRNG_ONLINE_STAT (0x44)
> +#define EXYNOS_TRNG_ONLINE_MAXCHI2 (0x48)
> +#define EXYNOS_TRNG_FIFO_CTRL (0x50)
> +#define EXYNOS_TRNG_FIFO_0 (0x80)
> +#define EXYNOS_TRNG_FIFO_1 (0x84)
> +#define EXYNOS_TRNG_FIFO_2 (0x88)
> +#define EXYNOS_TRNG_FIFO_3 (0x8c)
> +#define EXYNOS_TRNG_FIFO_4 (0x90)
> +#define EXYNOS_TRNG_FIFO_5 (0x94)
> +#define EXYNOS_TRNG_FIFO_6 (0x98)
> +#define EXYNOS_TRNG_FIFO_7 (0x9c)
> +#define EXYNOS_TRNG_FIFO_LEN (8)
> +#define EXYNOS_TRNG_CLOCK_RATE (500000)
> +
> +struct exynos_trng_dev {
> + struct device *dev;
> + void __iomem *mem;
> + struct clk *clk;
> + struct hwrng rng;
> +};
> +
> +struct exynos_trng_dev *exynos_trng_dev;
> +
> +static inline void exynos_trng_set_reg(struct exynos_trng_dev *trng, u16 reg,
> + u32 val)
> +{
> + /* Check range of reg? */
> + __raw_writel(val, trng->mem + reg);
Any specific reason to use __raw_writel? Why not just writel?
> +}
> +
> +static inline u32 exynos_trng_get_reg(struct exynos_trng_dev *trng, u16 reg)
> +{
> + /* Check range of reg? */
> + return __raw_readl(trng->mem + reg);
Same as above.
> +}
> +
> +static int exynos_trng_do_read(struct hwrng *rng, void *data, size_t max,
> + bool wait)
> +{
> + struct exynos_trng_dev *trng;
> + u32 val;
> +
> + max = max > (EXYNOS_TRNG_FIFO_LEN * 4) ?
> + (EXYNOS_TRNG_FIFO_LEN * 4) : max;
max is always > 32. This condition is not required.
> +
> + trng = (struct exynos_trng_dev *)rng->priv;
> +
> + exynos_trng_set_reg(trng, EXYNOS_TRNG_FIFO_CTRL, max * 8);
> + val = readl_poll_timeout(trng->mem + EXYNOS_TRNG_FIFO_CTRL, val,
> + val == 0, 200, 1000000);
> + if (val < 0)
> + return val;
> +
> + memcpy_fromio(data, trng->mem + EXYNOS_TRNG_FIFO_0, max);
> +
> + return max;
> +}
> +
> +static int exynos_trng_init(struct hwrng *rng)
> +{
> + struct exynos_trng_dev *trng;
> + unsigned long sss_rate;
> + u32 val;
> +
> + trng = (struct exynos_trng_dev *)rng->priv;
> + sss_rate = clk_get_rate(trng->clk);
> +
> + /* For most TRNG circuits the clock frequency of under 500 kHz
> + * is safe.
> + */
> + val = sss_rate / (EXYNOS_TRNG_CLOCK_RATE * 2);
> + if (val > 0x7fff) {
> + dev_err(trng->dev, "clock divider too large: %d", val);
> + return -ERANGE;
> + }
> + val = val << 1;
> + exynos_trng_set_reg(trng, EXYNOS_TRNG_CLKDIV, val);
> +
> + /* Enable the generator. */
> + val = 1 << 31;
> + exynos_trng_set_reg(trng, EXYNOS_TRNG_CTRL, val);
> +
> + /* Disable post processing. /dev/hwrng is supposed to deliver
> + * unprocessed data.
> + */
> + exynos_trng_set_reg(trng, EXYNOS_TRNG_POST_CTRL, 0);
> +
> + return 0;
> +}
> +
> +static int exynos_trng_probe(struct platform_device *pdev)
> +{
> + struct exynos_trng_dev *trng;
> + struct resource *res;
> + int ret = -ENOMEM;
> +
> + if (exynos_trng_dev)
> + return -EEXIST;
> +
> + trng = devm_kzalloc(&pdev->dev, sizeof(*trng), GFP_KERNEL);
> + if (!trng)
> + goto err_ioremap;
> +
> + trng->rng.name = devm_kstrdup(&pdev->dev, dev_name(&pdev->dev),
> + GFP_KERNEL);
> + if (!trng->rng.name)
> + goto err_ioremap;
> +
> + trng->rng.init = exynos_trng_init;
> + trng->rng.read = exynos_trng_do_read;
> + trng->rng.priv = (unsigned long) trng;
> +
> + platform_set_drvdata(pdev, trng);
> + trng->dev = &pdev->dev;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + trng->mem = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(trng->mem)) {
> + dev_err(&pdev->dev, "Couldn't map IO resources.\n");
> + ret = PTR_ERR(trng->mem);
> + goto err_ioremap;
> + }
> +
> + pm_runtime_enable(&pdev->dev);
> + ret = pm_runtime_get_sync(&pdev->dev);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "pm_runtime_get_sync() failed: %d.\n", ret);
> + goto err_ioremap;
> + }
> +
> + trng->clk = devm_clk_get(&pdev->dev, "secss");
> + if (IS_ERR(trng->clk)) {
> + /* XXX: EPROBE_DEFER ? */
> + dev_err(&pdev->dev, "Couldn't get clock.\n");
> + ret = PTR_ERR(trng->clk);
> + goto err_clock;
> + }
> +
> + ret = clk_prepare_enable(trng->clk);
> + if (ret) {
> + dev_err(&pdev->dev, "Unable to enable the clk: %d.\n", ret);
> + goto err_clock;
> + }
Why not move clk_prepare_enable to init call? While at it please add a
cleanup callback as well.
> +
> + ret = hwrng_register(&trng->rng);
> + if (ret) {
> + dev_err(&pdev->dev, "Couldn't register hwrng device.\n");
> + goto err_register;
> + }
> +
> + dev_info(&pdev->dev, "Exynos True Random Number Generator.\n");
> +
> + return 0;
> +
> +err_register:
> + clk_disable_unprepare(trng->clk);
> +
> +err_clock:
> + trng->mem = NULL;
> + pm_runtime_put_sync(&pdev->dev);
> + pm_runtime_disable(&pdev->dev);
> +
> +err_ioremap:
> + dev_err(&pdev->dev, "Initialisation failed.\n");
> + return ret;
> +}
> +
> +static int exynos_trng_remove(struct platform_device *pdev)
> +{
> + exynos_trng_dev = NULL;
> +
> + return 0;
> +}
remove is not required as it does not do anything significant.
> +
> +static int __maybe_unused exynos_trng_suspend(struct device *dev)
> +{
> + pm_runtime_put_sync(dev);
> +
> + return 0;
> +}
> +
> +static int __maybe_unused exynos_trng_resume(struct device *dev)
> +{
> + int ret;
> +
> + ret = pm_runtime_get_sync(dev);
> + if (ret < 0) {
> + dev_err(dev, "pm_runtime_get_sync() failed: %d.\n", ret);
> + pm_runtime_put_noidle(dev);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static SIMPLE_DEV_PM_OPS(exynos_trng_pm_ops, exynos_trng_suspend,
> + exynos_trng_resume);
> +
> +static const struct of_device_id exynos_trng_dt_match[] = {
> + {
> + .compatible = "samsung,exynos5250-trng",
> + },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, exynos_rng_dt_match);
> +
> +static struct platform_driver exynos_trng_driver = {
> + .driver = {
> + .name = "exynos-trng",
> + .pm = &exynos_trng_pm_ops,
> + .of_match_table = exynos_trng_dt_match,
> + },
> + .probe = exynos_trng_probe,
> + .remove = exynos_trng_remove,
> +};
> +
> +module_platform_driver(exynos_trng_driver);
> +MODULE_AUTHOR("Łukasz Stelmach");
> +MODULE_DESCRIPTION("H/W TRNG driver for Exynos chips");
> +MODULE_LICENSE("GPL");
> --
> 2.11.0
>
Regards,
PrasannaKumar
^ permalink raw reply
* Re: [PATCH v4 1/6] can: flexcan: Remodel FlexCAN register r/w APIs for big endian FlexCAN controllers.
From: Marc Kleine-Budde @ 2017-11-24 15:02 UTC (permalink / raw)
To: Pankaj Bansal, wg-5Yr1BZd7O62+XT7JhA+gdA,
linux-can-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: V.Sethi-3arQi8VN3Tc, poonam.aggrwal-3arQi8VN3Tc, Bhupesh Sharma,
Sakar Arora
In-Reply-To: <1511529733-27942-2-git-send-email-pankaj.bansal-3arQi8VN3Tc@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 3511 bytes --]
On 11/24/2017 02:22 PM, Pankaj Bansal wrote:
> The FlexCAN driver assumed that FlexCAN controller is big endian for
> powerpc architecture and little endian for other architectures.
>
> But this may not be the case. FlexCAN controller can be little or big
> endian on any architecture. For e.g. NXP LS1021A ARM based SOC has big
> endian FlexCAN controller.
>
> Therefore, the driver has been modified to add a provision for both
> types of controllers using an additional device tree property. On a
> "fsl,p1010-flexcan" device BE is default, on all other devices LE is.
>
> Big Endian controllers should have "big-endian" set in the device tree.
> check "Documentation/devicetree/bindings/net/can/fsl-flexcan.txt" for
> usage.
>
> This is the standard practice followed in linux. for more info check:
> Documentation/devicetree/bindings/common-properties.txt
>
> Signed-off-by: Pankaj Bansal <pankaj.bansal-3arQi8VN3Tc@public.gmane.org>
> Signed-off-by: Bhupesh Sharma <bhupesh.sharma-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> Signed-off-by: Sakar Arora <Sakar.Arora-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> Reviewed-by: Zhengxiong Jin <Jason.Jin-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> Reviewed-by: Poonam Aggrwal <poonam.aggrwal-3arQi8VN3Tc@public.gmane.org>
> ---
> Changes in v4:
> - Merged device tree changes and driver changes in one series
> Changes in v3:
> - Added fsl,imx25-flexcan, fsl,imx35-flexcan and fsl,imx53-flexcan
> support to the driver.
> - Modified patch deciption to state default endianness followed and
> to include fsl-flexcan.txt referance.
> Changes in v2:
> - Modified patch deciption to include common-properties.txt reference.
> - Reorder the LE/BE read/write APIs for better readability of code
> - Added an exception to force BE API selection, for powerpc based platform
> P1010. This ensures that new linux kernel works with old P1010
> device-tree, while future powerpc platforms that use big endian
> FlexCAN controller need to specify big-endian in device tree in
> FlexCAN node.
> - Tested on P1010 after backporting to freescale sdk 1.4 linux, without
> any change in device-tree.
> - Tested on NXP LS1021A arm based platform.
>
> drivers/net/can/flexcan.c | 233 ++++++++++++++++++++----------------
> 1 file changed, 131 insertions(+), 102 deletions(-)
>
> diff --git a/drivers/net/can/flexcan.c b/drivers/net/can/flexcan.c
> index a13a489..4c873fb 100644
> --- a/drivers/net/can/flexcan.c
> +++ b/drivers/net/can/flexcan.c
[...]
I think this will select LE for non DT devices, right?
> + if (of_property_read_bool(pdev->dev.of_node, "big-endian")) {
> + priv->read = flexcan_read_be;
> + priv->write = flexcan_write_be;
> + } else {
> + if (of_device_is_compatible(pdev->dev.of_node,
> + "fsl,p1010-flexcan")) {
> + priv->read = flexcan_read_be;
> + priv->write = flexcan_write_be;
> + } else {
> + priv->read = flexcan_read_le;
> + priv->write = flexcan_write_le;
> + }
> + }
> +
> priv->can.clock.freq = clock_freq;
> priv->can.bittiming_const = &flexcan_bittiming_const;
> priv->can.do_set_mode = flexcan_set_mode;
>
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* AW: [PATCH 1/5] drm/panel: Add support for the EDT ETM0700G0BDH6
From: Türk, Jan @ 2017-11-24 14:59 UTC (permalink / raw)
To: 'Fabio Estevam'
Cc: Rob Herring, Mark Rutland, Thierry Reding, David Airlie,
Russell King, Shawn Guo, Sascha Hauer, Fabio Estevam,
Andreas Färber, Kevin Hilman, Maxime Ripard,
Alexandre Belloni, Greg Kroah-Hartman, SZ Lin,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel,
DRI mailing list
In-Reply-To: <CAOMZO5C+LST4xky5cDV=+aKjEic-cO2eX1J7X+jhK-nUZ_ATMw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Fabio,
(and all others)
> Von: Fabio Estevam [mailto:festevam@gmail.com]
> Gesendet: Freitag, 24. November 2017 15:22
> Betreff: Re: [PATCH 1/5] drm/panel: Add support for the EDT ETM0700G0BDH6
>
> Hi Jan,
>
> On Thu, Nov 23, 2017 at 1:18 PM, Türk, Jan <Jan.Tuerk@emtrion.de> wrote:
> > Hi Fabio,
> >
> > I've used git send-email and tested the patches by checkpatch.pl before
> without any problems.
> > So it might have been touched by the mail server, so can you send me your
> checkpatch.pl log (directly)?
>
> Take a look at your patch here: https://patchwork.kernel.org/patch/10072765/
>
> Click in the "patch" link and download it. You will notice that all tabs have been
> converted into spaces.
>
> checkpatch will warn about it.
thanks for your feedback. Meanwhile I also did some investigation and found out that our SMTP modified the message in the redmond style.
I'll resend the patches as soon as the issue has been solved.
emtrion GmbH
Kreativpark - Alter Schlachthof 45
76131 Karlsruhe
GERMANY
http://www.emtrion.de
_______________________________________
Amtsgericht Mannheim
HRB 110 300
Geschäftsführer: Dieter Baur, Ramona Maurer
_______________________________________
^ permalink raw reply
* Re: [PATCH v4 09/12] IIO: ADC: add stm32 DFSDM support for PDM microphone
From: Arnaud Pouliquen @ 2017-11-24 14:52 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Mark Rutland, devicetree@vger.kernel.org,
alsa-devel@alsa-project.org, Lars-Peter Clausen, Maxime Coquelin,
Liam Girdwood, linux-iio@vger.kernel.org, Mark Brown,
Takashi Iwai, Rob Herring, Peter Meerwald-Stadler, Hartmut Knaack,
linux-arm-kernel@lists.infradead.org, Alexandre TORGUE
In-Reply-To: <20171119141830.29f1cfc9@archlinux>
On 11/19/2017 03:18 PM, Jonathan Cameron wrote:
> On Thu, 9 Nov 2017 11:12:31 +0100
> Arnaud Pouliquen <arnaud.pouliquen@st.com> wrote:
>
>> This code offers a way to handle PDM audio microphones in
>> ASOC framework. Audio driver should use consumer API.
>> A specific management is implemented for DMA, with a
>> callback, to allows to handle audio buffers efficiently.
>>
>> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
>
> A few minor points inline. I'm not sure I really 'like' the
> solution we've ended up with currently but if it works it will
> do just fine for now :)
>
> Jonathan
>
>
>> ---
>> V3 -> V4 changes:
>> - Merge audio implementation in stm32-dfsdm-adc.c instead of creating separate file
>> - Add sysfs document for exported attributes
>>
>> .../ABI/testing/sysfs-bus-iio-dfsdm-adc-stm32 | 22 +
>> drivers/iio/adc/stm32-dfsdm-adc.c | 517 ++++++++++++++++++++-
>> include/linux/iio/adc/stm32-dfsdm-adc.h | 27 ++
>> 3 files changed, 562 insertions(+), 4 deletions(-)
>> create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-dfsdm-adc-stm32
>> create mode 100644 include/linux/iio/adc/stm32-dfsdm-adc.h
>>
>> diff --git a/Documentation/ABI/testing/sysfs-bus-iio-dfsdm-adc-stm32 b/Documentation/ABI/testing/sysfs-bus-iio-dfsdm-adc-stm32
>> new file mode 100644
>> index 0000000..0ce5508
>> --- /dev/null
>> +++ b/Documentation/ABI/testing/sysfs-bus-iio-dfsdm-adc-stm32
>> @@ -0,0 +1,22 @@
>> +What: /sys/bus/iio/devices/iio:deviceX/in_voltage_audio_sampling_rate
>> +KernelVersion: 4.14
>> +Contact: arnaud.pouliquen@st.com
>> +Description:
>> + For audio purpose only.
>> + Used by audio driver to set/get the audio sampling rate.
>> + Reading returns current audio sample frequency.
>> + Writing value before starting conversions.
>
> I would like to see a note here on why sampling_frequency can't be used for
> this purpose.
The IIO_CHAN_INFO_SAMP_FREQ can not be used because consumer API allows
only to access to ext_info attributes.
An alternate is to export channel attribute functions the consumer API.
- iio_read_channel_attribute (already exist)
- iio_write_channel_attribute
Please, tell me your preference.
>
>> +
>> +What: /sys/bus/iio/devices/iio:deviceX/in_voltage_spi_clk_freq
>> +KernelVersion: 4.14
>> +Contact: arnaud.pouliquen@st.com
>> +Description:
>> + For audio purpose only.
>> + Used by audio driver to set/get the spi input frequency
>> + when DFSDM SPI input channel is in slave mode.
>> + if DFSDM input is SPI master
>> + Reading 0,
>> + error on writing
>> + If DFSDM input is SPI Slave:
>> + Reading returns value previously set.
>> + Writing value before starting conversions.
>
> I'd like a brief note here on why we might change this at runtime.
Sure, i will add it, output audio sample frequency is computed from the
SPI_clock bus. User can need to change it depending on the Audio
frequency configured for the audio card. This configuration occurs after
audio driver probing.
>
>> diff --git a/drivers/iio/adc/stm32-dfsdm-adc.c b/drivers/iio/adc/stm32-dfsdm-adc.c
>> index f9419ab..f0952e26 100644
>> --- a/drivers/iio/adc/stm32-dfsdm-adc.c
>> +++ b/drivers/iio/adc/stm32-dfsdm-adc.c
>> @@ -19,11 +19,15 @@
>> * this program. If not, see <http://www.gnu.org/licenses/>.
>> */
>>
>> +#include <linux/dmaengine.h>
>> +#include <linux/dma-mapping.h>
>> #include <linux/interrupt.h>
>> #include <linux/iio/buffer.h>
>> #include <linux/iio/hw-consumer.h>
>> #include <linux/iio/iio.h>
>> #include <linux/iio/sysfs.h>
>> +#include <linux/iio/trigger_consumer.h>
>> +#include <linux/iio/triggered_buffer.h>
>> #include <linux/module.h>
>> #include <linux/of.h>
>> #include <linux/platform_device.h>
>> @@ -32,6 +36,8 @@
>>
>> #include "stm32-dfsdm.h"
>>
>> +#define DFSDM_DMA_BUFFER_SIZE (4 * PAGE_SIZE)
>> +
>> /* Conversion timeout */
>> #define DFSDM_TIMEOUT_US 100000
>> #define DFSDM_TIMEOUT (msecs_to_jiffies(DFSDM_TIMEOUT_US / 1000))
>> @@ -71,6 +77,18 @@ struct stm32_dfsdm_adc {
>> struct completion completion;
>> u32 *buffer;
>>
>> + /* Audio specific */
>> + unsigned int spi_freq; /* SPI bus clock frequency */
>> + unsigned int sample_freq; /* Sample frequency after filter decimation */
>> + int (*cb)(const void *data, size_t size, void *cb_priv);
>> + void *cb_priv;
>> +
>> + /* DMA */
>> + u8 *rx_buf;
>> + unsigned int bufi; /* Buffer current position */
>> + unsigned int buf_sz; /* Buffer size */
>> + struct dma_chan *dma_chan;
>> + dma_addr_t dma_buf;
>> };
>>
>> struct stm32_dfsdm_str2field {
>> @@ -364,10 +382,110 @@ int stm32_dfsdm_channel_parse_of(struct stm32_dfsdm *dfsdm,
>> return 0;
>> }
>>
>> +static ssize_t dfsdm_adc_audio_get_rate(struct iio_dev *indio_dev,
>> + uintptr_t priv,
>> + const struct iio_chan_spec *chan,
>> + char *buf)
>> +{
>> + struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
>> +
>> + return snprintf(buf, PAGE_SIZE, "%d\n", adc->sample_freq);
>> +}
>> +
>> +static ssize_t dfsdm_adc_audio_set_rate(struct iio_dev *indio_dev,
>> + uintptr_t priv,
>> + const struct iio_chan_spec *chan,
>> + const char *buf, size_t len)
>> +{
>> + struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
>> + struct stm32_dfsdm_filter *fl = &adc->dfsdm->fl_list[adc->fl_id];
>> + struct stm32_dfsdm_channel *ch = &adc->dfsdm->ch_list[adc->ch_id];
>> + unsigned int spi_freq = adc->spi_freq;
>> + unsigned int sample_freq;
>> + int ret;
>> +
>> + ret = kstrtoint(buf, 0, &sample_freq);
>> + if (ret)
>> + return ret;
>> + dev_dbg(&indio_dev->dev, "Requested sample_freq :%d\n", sample_freq);
>> +
>> + if (!sample_freq)
>> + return -EINVAL;
>> +
>> + if (ch->src != DFSDM_CHANNEL_SPI_CLOCK_EXTERNAL)
>> + spi_freq = adc->dfsdm->spi_master_freq;
>> +
>> + if (spi_freq % sample_freq)
>> + dev_warn(&indio_dev->dev, "Sampling rate not accurate (%d)\n",
>> + spi_freq / (spi_freq / sample_freq));
>> +
>> + ret = stm32_dfsdm_set_osrs(fl, 0, (spi_freq / sample_freq));
>> + if (ret < 0) {
>> + dev_err(&indio_dev->dev,
>> + "Not able to find filter parameter that match!\n");
>> + return ret;
>> + }
>> + adc->sample_freq = sample_freq;
>> +
>> + return len;
>> +}
>> +
>> +static ssize_t dfsdm_adc_audio_get_spiclk(struct iio_dev *indio_dev,
>> + uintptr_t priv,
>> + const struct iio_chan_spec *chan,
>> + char *buf)
>> +{
>> + struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
>> +
>> + return snprintf(buf, PAGE_SIZE, "%d\n", adc->spi_freq);
>> +}
>> +
>> +static ssize_t dfsdm_adc_audio_set_spiclk(struct iio_dev *indio_dev,
>> + uintptr_t priv,
>> + const struct iio_chan_spec *chan,
>> + const char *buf, size_t len)
>> +{
>> + struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
>> + struct stm32_dfsdm_filter *fl = &adc->dfsdm->fl_list[adc->fl_id];
>> + struct stm32_dfsdm_channel *ch = &adc->dfsdm->ch_list[adc->ch_id];
>> + unsigned int sample_freq = adc->sample_freq;
>> + unsigned int spi_freq;
>> + int ret;
>> +
>> + dev_err(&indio_dev->dev, "enter %s\n", __func__);
>> + /* If DFSDM is master on SPI, SPI freq can not be updated */
>> + if (ch->src != DFSDM_CHANNEL_SPI_CLOCK_EXTERNAL)
>> + return -EPERM;
>> +
>> + ret = kstrtoint(buf, 0, &spi_freq);
>> + if (ret)
>> + return ret;
>> +
>> + if (!spi_freq)
>> + return -EINVAL;
>> +
>> + if (sample_freq) {
>> + if (spi_freq % sample_freq)
>> + dev_warn(&indio_dev->dev,
>> + "Sampling rate not accurate (%d)\n",
>> + spi_freq / (spi_freq / sample_freq));
>> +
>> + ret = stm32_dfsdm_set_osrs(fl, 0, (spi_freq / sample_freq));
>> + if (ret < 0) {
>> + dev_err(&indio_dev->dev,
>> + "No filter parameters that match!\n");
>> + return ret;
>> + }
>> + }
>> + adc->spi_freq = spi_freq;
>> +
>> + return len;
>> +}
> blank line here please.
>
>> static int stm32_dfsdm_start_conv(struct stm32_dfsdm_adc *adc, bool dma)
>> {
>> struct regmap *regmap = adc->dfsdm->regmap;
>> int ret;
>> + unsigned int dma_en = 0, cont_en = 0;
>>
>> ret = stm32_dfsdm_start_channel(adc->dfsdm, adc->ch_id);
>> if (ret < 0)
>> @@ -378,6 +496,24 @@ static int stm32_dfsdm_start_conv(struct stm32_dfsdm_adc *adc, bool dma)
>> if (ret < 0)
>> goto stop_channels;
>>
>> + if (dma) {
>> + /* Enable DMA transfer*/
>> + dma_en = DFSDM_CR1_RDMAEN(1);
>> + /* Enable conversion triggered by SPI clock*/
>> + cont_en = DFSDM_CR1_RCONT(1);
>> + }
>> + /* Enable DMA transfer*/
>> + ret = regmap_update_bits(regmap, DFSDM_CR1(adc->fl_id),
>> + DFSDM_CR1_RDMAEN_MASK, dma_en);
>> + if (ret < 0)
>> + goto stop_channels;
>> +
>> + /* Enable conversion triggered by SPI clock*/
>> + ret = regmap_update_bits(regmap, DFSDM_CR1(adc->fl_id),
>> + DFSDM_CR1_RCONT_MASK, cont_en);
>> + if (ret < 0)
>> + goto stop_channels;
>> +
>> ret = stm32_dfsdm_start_filter(adc->dfsdm, adc->fl_id);
>> if (ret < 0)
>> goto stop_channels;
>> @@ -411,6 +547,241 @@ static void stm32_dfsdm_stop_conv(struct stm32_dfsdm_adc *adc)
>> stm32_dfsdm_stop_channel(adc->dfsdm, adc->ch_id);
>> }
>>
>> +static int stm32_dfsdm_set_watermark(struct iio_dev *indio_dev,
>> + unsigned int val)
>> +{
>> + struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
>> + unsigned int watermark = DFSDM_DMA_BUFFER_SIZE / 2;
>> +
>> + /*
>> + * DMA cyclic transfers are used, buffer is split into two periods.
>> + * There should be :
>> + * - always one buffer (period) DMA is working on
>> + * - one buffer (period) driver pushed to ASoC side.
>> + */
>> + watermark = min(watermark, val * (unsigned int)(sizeof(u32)));
>> + adc->buf_sz = watermark * 2;
>> +
>> + return 0;
>> +}
>> +
>> +static const struct iio_info stm32_dfsdm_info_audio = {
>> + .hwfifo_set_watermark = stm32_dfsdm_set_watermark,
>> + .driver_module = THIS_MODULE,
>
> This has gone - now handled by macro magic...
>
>> +};
>> +
>> +static unsigned int stm32_dfsdm_adc_dma_residue(struct stm32_dfsdm_adc *adc)
>> +{
>> + struct dma_tx_state state;
>> + enum dma_status status;
>> +
>> + status = dmaengine_tx_status(adc->dma_chan,
>> + adc->dma_chan->cookie,
>> + &state);
>> + if (status == DMA_IN_PROGRESS) {
>> + /* Residue is size in bytes from end of buffer */
>> + unsigned int i = adc->buf_sz - state.residue;
>> + unsigned int size;
>> +
>> + /* Return available bytes */
>> + if (i >= adc->bufi)
>> + size = i - adc->bufi;
>> + else
>> + size = adc->buf_sz + i - adc->bufi;
>> +
>> + return size;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static void stm32_dfsdm_audio_dma_buffer_done(void *data)
>> +{
>> + struct iio_dev *indio_dev = data;
>> + struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
>> + int available = stm32_dfsdm_adc_dma_residue(adc);
>> + size_t old_pos;
>> +
>> + /*
>> + * FIXME: Buffer interface does not support cyclic DMA buffer,and offers
>> + * only an interface to push data samples per samples.
>> + * For this reason IIO buffer interface is not used and interface is
>> + * bypassed using a private callback registered by ASoC.
>> + * This should be a temporary solution waiting a cyclic DMA engine
>> + * support in IIO.
> More specifically the in kernel interfaces don't support dma cyclic
> buffers. We can already do them to userspace. Doesn't really matter
> though!
Ok I will change comment
>
>> + */
>> +
>> + dev_dbg(&indio_dev->dev, "%s: pos = %d, available = %d\n", __func__,
>> + adc->bufi, available);
>> + old_pos = adc->bufi;
>> +
>> + while (available >= indio_dev->scan_bytes) {
>> + u32 *buffer = (u32 *)&adc->rx_buf[adc->bufi];
>> +
>> + /* Mask 8 LSB that contains the channel ID */
>> + *buffer = (*buffer & 0xFFFFFF00) << 8;
>> + available -= indio_dev->scan_bytes;
>> + adc->bufi += indio_dev->scan_bytes;
>> + if (adc->bufi >= adc->buf_sz) {
>> + if (adc->cb)
>> + adc->cb(&adc->rx_buf[old_pos],
>> + adc->buf_sz - old_pos, adc->cb_priv);
>> + adc->bufi = 0;
>> + old_pos = 0;
>> + }
>> + }
>> + if (adc->cb)
>> + adc->cb(&adc->rx_buf[old_pos], adc->bufi - old_pos,
>> + adc->cb_priv);
>> +}
>> +
>> +static int stm32_dfsdm_adc_dma_start(struct iio_dev *indio_dev)
>> +{
>> + struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
>> + struct dma_async_tx_descriptor *desc;
>> + dma_cookie_t cookie;
>> + int ret;
>> +
>> + if (!adc->dma_chan)
>> + return -EINVAL;
>> +
>> + dev_dbg(&indio_dev->dev, "%s size=%d watermark=%d\n", __func__,
>> + adc->buf_sz, adc->buf_sz / 2);
>> +
>> + /* Prepare a DMA cyclic transaction */
>> + desc = dmaengine_prep_dma_cyclic(adc->dma_chan,
>> + adc->dma_buf,
>> + adc->buf_sz, adc->buf_sz / 2,
>> + DMA_DEV_TO_MEM,
>> + DMA_PREP_INTERRUPT);
>> + if (!desc)
>> + return -EBUSY;
>> +
>> + desc->callback = stm32_dfsdm_audio_dma_buffer_done;
>> + desc->callback_param = indio_dev;
>> +
>> + cookie = dmaengine_submit(desc);
>> + ret = dma_submit_error(cookie);
>> + if (ret) {
>> + dmaengine_terminate_all(adc->dma_chan);
>> + return ret;
>> + }
>> +
>> + /* Issue pending DMA requests */
>> + dma_async_issue_pending(adc->dma_chan);
>> +
>> + return 0;
>> +}
>> +
>> +static int stm32_dfsdm_postenable(struct iio_dev *indio_dev)
>> +{
>> + struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
>> + int ret;
>> +
>> + /* Reset adc buffer index */
>> + adc->bufi = 0;
>> +
>> + ret = stm32_dfsdm_start_dfsdm(adc->dfsdm);
>> + if (ret < 0)
>> + return ret;
>> +
>> + ret = stm32_dfsdm_start_conv(adc, true);
>> + if (ret) {
>> + dev_err(&indio_dev->dev, "Can't start conversion\n");
>> + goto stop_dfsdm;
>> + }
>> +
>> + if (adc->dma_chan) {
>> + ret = stm32_dfsdm_adc_dma_start(indio_dev);
>> + if (ret) {
>> + dev_err(&indio_dev->dev, "Can't start DMA\n");
>> + goto err_stop_conv;
>> + }
>> + }
>> +
>> + return 0;
>> +
>> +err_stop_conv:
>> + stm32_dfsdm_stop_conv(adc);
>> +stop_dfsdm:
>> + stm32_dfsdm_stop_dfsdm(adc->dfsdm);
>> +
>> + return ret;
>> +}
>> +
>> +static int stm32_dfsdm_predisable(struct iio_dev *indio_dev)
>> +{
>> + struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
>> +
>> + if (adc->dma_chan)
>> + dmaengine_terminate_all(adc->dma_chan);
>> +
>> + stm32_dfsdm_stop_conv(adc);
>> +
>> + stm32_dfsdm_stop_dfsdm(adc->dfsdm);
>> +
>> + return 0;
>> +}
>> +
>> +static const struct iio_buffer_setup_ops stm32_dfsdm_buffer_setup_ops = {
>> + .postenable = &stm32_dfsdm_postenable,
>> + .predisable = &stm32_dfsdm_predisable,
>> +};
>> +
>> +/**
>> + * stm32_dfsdm_get_buff_cb - register a callback
>> + * that will be called when DMA transfer period is achieved.
> Please run kernel-doc over this file. I'm fairly sure this isn't
> quite meeting the spec...
Sorry it is not crystal clear for me, could you detail what you would
mean by
"I'm fairly sure this isn't quite meeting the spec.."?
>
>> + *
>> + * @iio_dev: Handle to IIO device.
>> + * @cb: pointer to callback function.
>> + * @data: pointer to data buffer
>> + * @size: size in byte of the data buffer
>> + * @private: pointer to consumer private structure
>> + * @private: pointer to consumer private structure
>> + */
>> +int stm32_dfsdm_get_buff_cb(struct iio_dev *iio_dev,
>> + int (*cb)(const void *data, size_t size,
>> + void *private),
>> + void *private)
>> +{
>> + struct stm32_dfsdm_adc *adc;
>> +
>> + if (!iio_dev)
>> + return -EINVAL;
>> + adc = iio_priv(iio_dev);
>> +
>> + if (iio_dev != iio_priv_to_dev(adc))
>> + return -EINVAL;
> Same as for the case below..
>
>> +
>> + adc->cb = cb;
>> + adc->cb_priv = private;
>> +
>> + return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(stm32_dfsdm_get_buff_cb);
>> +
>> +/**
>> + * stm32_dfsdm_release_buff_cb - unregister buffer callback
>> + *
>> + * @iio_dev: Handle to IIO device.
>> + */
>> +int stm32_dfsdm_release_buff_cb(struct iio_dev *iio_dev)
>> +{
>> + struct stm32_dfsdm_adc *adc;
>> +
>> + if (!iio_dev)
>> + return -EINVAL;
>> + adc = iio_priv(iio_dev);
>> +
>> + if (iio_dev != iio_priv_to_dev(adc))
>> + return -EINVAL;
> I can't immediately spot why this could ever fail so we definitely
> need a comment here saying what it is protecting against!
You're right , it is over-protection, i will suppress it
Thanks
Arnaud
>
>> + adc->cb = NULL;
>> + adc->cb_priv = NULL;
>> +
>> + return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(stm32_dfsdm_release_buff_cb);
>> +
>> static int stm32_dfsdm_single_conv(struct iio_dev *indio_dev,
>> const struct iio_chan_spec *chan, int *res)
>> {
>> @@ -544,6 +915,67 @@ static irqreturn_t stm32_dfsdm_irq(int irq, void *arg)
>> return IRQ_HANDLED;
>> }
>>
>> +/*
>> + * Define external info for SPI Frequency and audio sampling rate that can be
>> + * configured by ASoC driver through consumer.h API
>> + */
>> +static const struct iio_chan_spec_ext_info dfsdm_adc_audio_ext_info[] = {
>> + /* filter oversampling: Post filter oversampling ratio */
>> + {
>> + .name = "audio_sampling_rate",
>> + .shared = IIO_SHARED_BY_TYPE,
>> + .read = dfsdm_adc_audio_get_rate,
>> + .write = dfsdm_adc_audio_set_rate,
>> + },
>> + /* data_right_bit_shift : Filter output data shifting */
>> + {
>> + .name = "spi_clk_freq",
>> + .shared = IIO_SHARED_BY_TYPE,
>> + .read = dfsdm_adc_audio_get_spiclk,
>> + .write = dfsdm_adc_audio_set_spiclk,
>> + },
>> + {},
>> +};
>> +
>> +static int stm32_dfsdm_dma_request(struct iio_dev *indio_dev)
>> +{
>> + struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
>> + struct dma_slave_config config;
>> + int ret;
>> +
>> + adc->dma_chan = dma_request_slave_channel(&indio_dev->dev, "rx");
>> + if (!adc->dma_chan)
>> + return -EINVAL;
>> +
>> + adc->rx_buf = dma_alloc_coherent(adc->dma_chan->device->dev,
>> + DFSDM_DMA_BUFFER_SIZE,
>> + &adc->dma_buf, GFP_KERNEL);
>> + if (!adc->rx_buf) {
>> + ret = -ENOMEM;
>> + goto err_release;
>> + }
>> +
>> + /* Configure DMA channel to read data register */
>> + memset(&config, 0, sizeof(config));
>> + config.src_addr = (dma_addr_t)adc->dfsdm->phys_base;
>> + config.src_addr += DFSDM_RDATAR(adc->fl_id);
>> + config.src_addr_width = DMA_SLAVE_BUSWIDTH_4_BYTES;
>> +
>> + ret = dmaengine_slave_config(adc->dma_chan, &config);
>> + if (ret)
>> + goto err_free;
>> +
>> + return 0;
>> +
>> +err_free:
>> + dma_free_coherent(adc->dma_chan->device->dev, DFSDM_DMA_BUFFER_SIZE,
>> + adc->rx_buf, adc->dma_buf);
>> +err_release:
>> + dma_release_channel(adc->dma_chan);
>> +
>> + return ret;
>> +}
>> +
>> static int stm32_dfsdm_adc_chan_init_one(struct iio_dev *indio_dev,
>> struct iio_chan_spec *ch)
>> {
>> @@ -564,7 +996,12 @@ static int stm32_dfsdm_adc_chan_init_one(struct iio_dev *indio_dev,
>> ch->info_mask_separate = BIT(IIO_CHAN_INFO_RAW);
>> ch->info_mask_shared_by_all = BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO);
>>
>> - ch->scan_type.sign = 'u';
>> + if (adc->dev_data->type == DFSDM_AUDIO) {
>> + ch->scan_type.sign = 's';
>> + ch->ext_info = dfsdm_adc_audio_ext_info;
>> + } else {
>> + ch->scan_type.sign = 'u';
>> + }
>> ch->scan_type.realbits = 24;
>> ch->scan_type.storagebits = 32;
>> adc->ch_id = ch->channel;
>> @@ -573,6 +1010,58 @@ static int stm32_dfsdm_adc_chan_init_one(struct iio_dev *indio_dev,
>> &adc->dfsdm->ch_list[ch->channel]);
>> }
>>
>> +static int stm32_dfsdm_audio_init(struct iio_dev *indio_dev)
>> +{
>> + struct iio_chan_spec *ch;
>> + struct stm32_dfsdm_adc *adc = iio_priv(indio_dev);
>> + int ret;
>> +
>> + ret = stm32_dfsdm_dma_request(indio_dev);
>> + if (ret) {
>> + dev_err(&indio_dev->dev, "DMA request failed\n");
>> + return ret;
>> + }
>> +
>> + indio_dev->modes |= INDIO_BUFFER_SOFTWARE;
>> +
>> + ret = iio_triggered_buffer_setup(indio_dev,
>> + &iio_pollfunc_store_time,
>> + NULL,
>> + &stm32_dfsdm_buffer_setup_ops);
>> + if (ret) {
>> + dev_err(&indio_dev->dev, "Buffer setup failed\n");
>> + goto err_dma_disable;
>> + }
>> +
>> + ch = devm_kzalloc(&indio_dev->dev, sizeof(*ch), GFP_KERNEL);
>> + if (!ch)
>> + return -ENOMEM;
>> +
>> + ch->scan_index = 0;
>> + ret = stm32_dfsdm_adc_chan_init_one(indio_dev, ch);
>> + if (ret < 0) {
>> + dev_err(&indio_dev->dev, "channels init failed\n");
>> + goto err_buffer_cleanup;
>> + }
>> +
>> + indio_dev->num_channels = 1;
>> + indio_dev->channels = ch;
>> +
>> + return 0;
>> +
>> +err_buffer_cleanup:
>> + iio_triggered_buffer_cleanup(indio_dev);
>> +
>> +err_dma_disable:
>> + if (adc->dma_chan) {
>> + dma_free_coherent(adc->dma_chan->device->dev,
>> + DFSDM_DMA_BUFFER_SIZE,
>> + adc->rx_buf, adc->dma_buf);
>> + dma_release_channel(adc->dma_chan);
>> + }
>> + return ret;
>> +}
>> +
>> static int stm32_dfsdm_adc_init(struct iio_dev *indio_dev)
>> {
>> struct iio_chan_spec *ch;
>> @@ -625,10 +1114,18 @@ static const struct stm32_dfsdm_dev_data stm32h7_dfsdm_adc_data = {
>> .init = stm32_dfsdm_adc_init,
>> };
>>
>> +static const struct stm32_dfsdm_dev_data stm32h7_dfsdm_audio_data = {
>> + .type = DFSDM_AUDIO,
>> + .init = stm32_dfsdm_audio_init,
>> +};
>> +
>> static const struct of_device_id stm32_dfsdm_adc_match[] = {
>> { .compatible = "st,stm32-dfsdm-adc",
>> .data = &stm32h7_dfsdm_adc_data,
>> },
>> + { .compatible = "st,stm32-dfsdm-dmic",
>> + .data = &stm32h7_dfsdm_audio_data,
>> + },
>> {}
>> };
>>
>> @@ -679,8 +1176,13 @@ static int stm32_dfsdm_adc_probe(struct platform_device *pdev)
>> name = devm_kzalloc(dev, sizeof("dfsdm-adc0"), GFP_KERNEL);
>> if (!name)
>> return -ENOMEM;
>> - iio->info = &stm32_dfsdm_info_adc;
>> - snprintf(name, sizeof("dfsdm-adc0"), "dfsdm-adc%d", adc->fl_id);
>> + if (dev_data->type == DFSDM_AUDIO) {
>> + iio->info = &stm32_dfsdm_info_audio;
>> + snprintf(name, sizeof("dfsdm-pdm0"), "dfsdm-pdm%d", adc->fl_id);
>> + } else {
>> + iio->info = &stm32_dfsdm_info_adc;
>> + snprintf(name, sizeof("dfsdm-adc0"), "dfsdm-adc%d", adc->fl_id);
>> + }
>> iio->name = name;
>>
>> /*
>> @@ -721,7 +1223,14 @@ static int stm32_dfsdm_adc_remove(struct platform_device *pdev)
>> struct iio_dev *indio_dev = iio_priv_to_dev(adc);
>>
>> iio_device_unregister(indio_dev);
>> -
>> + if (indio_dev->pollfunc)
>> + iio_triggered_buffer_cleanup(indio_dev);
>> + if (adc->dma_chan) {
>> + dma_free_coherent(adc->dma_chan->device->dev,
>> + DFSDM_DMA_BUFFER_SIZE,
>> + adc->rx_buf, adc->dma_buf);
>> + dma_release_channel(adc->dma_chan);
>> + }
>> return 0;
>> }
>>
>> diff --git a/include/linux/iio/adc/stm32-dfsdm-adc.h b/include/linux/iio/adc/stm32-dfsdm-adc.h
>> new file mode 100644
>> index 0000000..6885645
>> --- /dev/null
>> +++ b/include/linux/iio/adc/stm32-dfsdm-adc.h
>> @@ -0,0 +1,27 @@
>> +/*
>> + * This file discribe the STM32 DFSDM IIO driver API for audio part
>> + *
>> + * Copyright (C) 2017, STMicroelectronics - All Rights Reserved
>> + * Author(s): Arnaud Pouliquen <arnaud.pouliquen@st.com>.
>> + *
>> + * License terms: GPL V2.0.
>> + *
>> + * 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.
>> + */
>> +#ifndef STM32_DFSDM_ADC_H
>> +#define STM32_DFSDM_ADC_H
>> +
>> +int stm32_dfsdm_get_buff_cb(struct iio_dev *iio_dev,
>> + int (*cb)(const void *data, size_t size,
>> + void *private),
>> + void *private);
>> +int stm32_dfsdm_release_buff_cb(struct iio_dev *iio_dev);
>> +
>> +#endif
>
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply
* Re: [PATCH v4 08/12] IIO: ADC: add STM32 DFSDM sigma delta ADC support
From: Arnaud Pouliquen @ 2017-11-24 14:49 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Mark Rutland, devicetree@vger.kernel.org,
alsa-devel@alsa-project.org, Lars-Peter Clausen, Maxime Coquelin,
Liam Girdwood, linux-iio@vger.kernel.org, Mark Brown,
Takashi Iwai, Rob Herring, Peter Meerwald-Stadler, Hartmut Knaack,
linux-arm-kernel@lists.infradead.org, Alexandre TORGUE
In-Reply-To: <20171119142935.044a0764@archlinux>
On 11/19/2017 03:29 PM, Jonathan Cameron wrote:
> On Thu, 9 Nov 2017 11:12:30 +0100
> Arnaud Pouliquen <arnaud.pouliquen@st.com> wrote:
>
>> Add DFSDM driver to handle sigma delta ADC.
>>
>> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
>> ---
>> drivers/iio/adc/Kconfig | 13 +
>> drivers/iio/adc/Makefile | 1 +
>> drivers/iio/adc/stm32-dfsdm-adc.c | 741 ++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 755 insertions(+)
>> create mode 100644 drivers/iio/adc/stm32-dfsdm-adc.c
[...]
>> diff --git a/drivers/iio/adc/stm32-dfsdm-adc.c b/drivers/iio/adc/stm32-dfsdm-adc.c
>> new file mode 100644
>> index 0000000..f9419ab
>> --- /dev/null
>> +++ b/drivers/iio/adc/stm32-dfsdm-adc.c
>> @@ -0,0 +1,741 @@
[...]
>> +static int stm32_dfsdm_adc_remove(struct platform_device *pdev)
>> +{
>> + struct stm32_dfsdm_adc *adc = platform_get_drvdata(pdev);
>> + struct iio_dev *indio_dev = iio_priv_to_dev(adc);
>> +
>> + iio_device_unregister(indio_dev);
> Given that all we have here is device unregister, you could
> use the devm_iio_device_register call and drop the remove entirely.
> (of course you may add stuff here in later patches - I haven't
> looked yet ;)
Yes, the next patch makes devm_iio_device_register useless, so i don't
use it here.
Regards
Arnaud
>> +
>> + return 0;
>> +}
>> +
>> +static struct platform_driver stm32_dfsdm_adc_driver = {
>> + .driver = {
>> + .name = "stm32-dfsdm-adc",
>> + .of_match_table = stm32_dfsdm_adc_match,
>> + },
>> + .probe = stm32_dfsdm_adc_probe,
>> + .remove = stm32_dfsdm_adc_remove,
>> +
>> +};
>> +module_platform_driver(stm32_dfsdm_adc_driver);
>> +
>> +MODULE_DESCRIPTION("STM32 sigma delta ADC");
>> +MODULE_AUTHOR("Arnaud Pouliquen <arnaud.pouliquen@st.com>");
>> +MODULE_LICENSE("GPL v2");
>
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply
* Re: [PATCH v4 03/12] IIO: hw_consumer: add devm_iio_hw_consumer_alloc
From: Arnaud Pouliquen @ 2017-11-24 14:48 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Mark Rutland, devicetree@vger.kernel.org,
alsa-devel@alsa-project.org, Lars-Peter Clausen, Maxime Coquelin,
Liam Girdwood, linux-iio@vger.kernel.org, Mark Brown,
Takashi Iwai, Rob Herring, Peter Meerwald-Stadler, Hartmut Knaack,
linux-arm-kernel@lists.infradead.org, Alexandre TORGUE
In-Reply-To: <20171119123453.188da309@archlinux>
On 11/19/2017 01:34 PM, Jonathan Cameron wrote:
> On Thu, 9 Nov 2017 11:12:25 +0100
> Arnaud Pouliquen <arnaud.pouliquen@st.com> wrote:
>
>> Add devm_iio_hw_consumer_alloc function that calls iio_hw_consumer_free
>> when the device is unbound from the bus.
>>
>> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@st.com>
> Hmm.. I normally don't like devm for what is a single use case in
> a driver (for now) but I guess this is generic enough it will have
> additional users reasonably soon. Hence fine.
>
> Jonathan
>> ---
>> drivers/iio/buffer/industrialio-hw-consumer.c | 70 ++++++++++++++++++++++++++-
>> include/linux/iio/hw-consumer.h | 2 +
>> 2 files changed, 70 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/iio/buffer/industrialio-hw-consumer.c b/drivers/iio/buffer/industrialio-hw-consumer.c
>> index 7d4d800..e980a79 100644
>> --- a/drivers/iio/buffer/industrialio-hw-consumer.c
>> +++ b/drivers/iio/buffer/industrialio-hw-consumer.c
>> @@ -129,15 +129,81 @@ EXPORT_SYMBOL_GPL(iio_hw_consumer_alloc);
>> */
>> void iio_hw_consumer_free(struct iio_hw_consumer *hwc)
>> {
>> - struct hw_consumer_buffer *buf;
>> + struct hw_consumer_buffer *buf, *n;
>>
>> iio_channel_release_all(hwc->channels);
>> - list_for_each_entry(buf, &hwc->buffers, head)
>> + list_for_each_entry_safe(buf, n, &hwc->buffers, head)
>> iio_buffer_put(&buf->buffer);
>
> This looks like an unrelated fix. Push back into the
> original patch?
Yes, I missed to apply this fix directly in Lars's patch:
[01/12] iio: Add hardware consumer buffer support
Thanks
Arnaud
>
>> kfree(hwc);
>> }
>> EXPORT_SYMBOL_GPL(iio_hw_consumer_free);
>>
>> +static void devm_iio_hw_consumer_release(struct device *dev, void *res)
>> +{
>> + iio_hw_consumer_free(*(struct iio_hw_consumer **)res);
>> +}
>> +
>> +static int devm_iio_hw_consumer_match(struct device *dev, void *res, void *data)
>> +{
>> + struct iio_hw_consumer **r = res;
>> +
>> + if (!r || !*r) {
>> + WARN_ON(!r || !*r);
>> + return 0;
>> + }
>> + return *r == data;
>> +}
>> +
>> +/**
>> + * devm_iio_hw_consumer_alloc - Resource-managed iio_hw_consumer_alloc()
>> + * @dev: Pointer to consumer device.
>> + *
>> + * Managed iio_hw_consumer_alloc. iio_hw_consumer allocated with this function
>> + * is automatically freed on driver detach.
>> + *
>> + * If an iio_hw_consumer allocated with this function needs to be freed
>> + * separately, devm_iio_hw_consumer_free() must be used.
>> + *
>> + * returns pointer to allocated iio_hw_consumer on success, NULL on failure.
>> + */
>> +struct iio_hw_consumer *devm_iio_hw_consumer_alloc(struct device *dev)
>> +{
>> + struct iio_hw_consumer **ptr, *iio_hwc;
>> +
>> + ptr = devres_alloc(devm_iio_hw_consumer_release, sizeof(*ptr),
>> + GFP_KERNEL);
>> + if (!ptr)
>> + return NULL;
>> +
>> + iio_hwc = iio_hw_consumer_alloc(dev);
>> + if (IS_ERR(iio_hwc)) {
>> + devres_free(ptr);
>> + } else {
>> + *ptr = iio_hwc;
>> + devres_add(dev, ptr);
>> + }
>> +
>> + return iio_hwc;
>> +}
>> +EXPORT_SYMBOL_GPL(devm_iio_hw_consumer_alloc);
>> +
>> +/**
>> + * devm_iio_hw_consumer_free - Resource-managed iio_hw_consumer_free()
>> + * @dev: Pointer to consumer device.
>> + * @hwc: iio_hw_consumer to free.
>> + *
>> + * Free iio_hw_consumer allocated with devm_iio_hw_consumer_alloc().
>> + */
>> +void devm_iio_hw_consumer_free(struct device *dev, struct iio_hw_consumer *hwc)
>> +{
>> + int rc;
>> +
>> + rc = devres_release(dev, devm_iio_hw_consumer_release,
>> + devm_iio_hw_consumer_match, hwc);
>> + WARN_ON(rc);
>> +}
>> +EXPORT_SYMBOL_GPL(devm_iio_hw_consumer_free);
>> +
>> /**
>> * iio_hw_consumer_enable() - Enable IIO hardware consumer
>> * @hwc: iio_hw_consumer to enable.
>> diff --git a/include/linux/iio/hw-consumer.h b/include/linux/iio/hw-consumer.h
>> index f16791b..90ecfce 100644
>> --- a/include/linux/iio/hw-consumer.h
>> +++ b/include/linux/iio/hw-consumer.h
>> @@ -14,6 +14,8 @@ struct iio_hw_consumer;
>>
>> struct iio_hw_consumer *iio_hw_consumer_alloc(struct device *dev);
>> void iio_hw_consumer_free(struct iio_hw_consumer *hwc);
>> +struct iio_hw_consumer *devm_iio_hw_consumer_alloc(struct device *dev);
>> +void devm_iio_hw_consumer_free(struct device *dev, struct iio_hw_consumer *hwc);
>> int iio_hw_consumer_enable(struct iio_hw_consumer *hwc);
>> void iio_hw_consumer_disable(struct iio_hw_consumer *hwc);
>>
>
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply
* Re: [PATCH v7 11/13] slimbus: qcom: Add Qualcomm Slimbus controller driver
From: Srinivas Kandagatla @ 2017-11-24 14:40 UTC (permalink / raw)
To: Jonathan Neuschäfer, Charles Keepax
Cc: gregkh, broonie, alsa-devel, sdharia, bp, poeschel, treding,
andreas.noever, alan, mathieu.poirier, daniel, jkosina,
sharon.dvir1, joe, davem, james.hogan, michael.opdenacker,
robh+dt, pawel.moll, mark.rutland, devicetree, linux-kernel,
linux-arm-msm, vinod.koul, arnd
In-Reply-To: <20171123164212.655yliz3tmlpsjje@latitude>
Thanks for your review,
On 23/11/17 16:42, Jonathan Neuschäfer wrote:
> Hello Srinivas and Charles,
>
> On Thu, Nov 23, 2017 at 10:07:03AM +0000, Charles Keepax wrote:
>> On Wed, Nov 15, 2017 at 02:10:41PM +0000, srinivas.kandagatla@linaro.org wrote:
>>> From: Sagar Dharia <sdharia@codeaurora.org>
>>>
>>> This controller driver programs manager, interface, and framer
>>> devices for Qualcomm's slimbus HW block.
>>> Manager component currently implements logical address setting,
>>> and messaging interface.
>>> Interface device reports bus synchronization information, and framer
>>> device clocks the bus from the time it's woken up, until clock-pause
>>> is executed by the manager device.
>>>
>>> Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
>>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>>> ---
> [...]
>>> +static void qcom_slim_rxwq(struct work_struct *work)
>>> +{
>>> + u8 buf[SLIM_MSGQ_BUF_LEN];
>>> + u8 mc, mt, len;
>>> + int i, ret;
>>> + struct qcom_slim_ctrl *ctrl = container_of(work, struct qcom_slim_ctrl,
>>> + wd);
>>> +
>>> + while ((slim_get_current_rxbuf(ctrl, buf)) != -ENODATA) {
>>> + len = SLIM_HEADER_GET_RL(buf[0]);
>>> + mt = SLIM_HEADER_GET_MT(buf[0]);
>>> + mc = SLIM_HEADER_GET_MC(buf[1]);
>>> + if (mt == SLIM_MSG_MT_CORE &&
>>> + mc == SLIM_MSG_MC_REPORT_PRESENT) {
>>> + u8 laddr;
>>> + struct slim_eaddr ea;
>>> + u8 e_addr[6];
>>> +
>>> + for (i = 0; i < 6; i++)
>>> + e_addr[i] = buf[7-i];
>>> +
>>> + ea.manf_id = (u16)(e_addr[5] << 8) | e_addr[4];
>>> + ea.prod_code = (u16)(e_addr[3] << 8) | e_addr[2];
>>> + ea.dev_index = e_addr[1];
>>> + ea.instance = e_addr[0];
>>
>> If we are just bitshifting this out of the bytes does it really
>> make it much more clear to reverse the byte order first? Feels
>> like you might as well shift it out of buf directly.
>
> In any case, there is a predefined function to make this code a little
> nicer in <asm/byteorder.h>:
>
> le16_to_cpu(x): Converts the 16-bit little endian value x to
> CPU-endian
> le16_to_cpup(p): Converts the 16-bit little endian value pointed
> to by p to CPU-endian
>
> If you use le16_to_cpup, you need to cast your pointer to __le16 *:
>
> ea.manf_id = le16_to_cpup((__le16 *)&e_addr[4]);
>
It Looks like I can make use of these apis here, I will give this a go
to cleanup this part of the code.
thanks,
srini
^ permalink raw reply
* Re: [PATCH v7 11/13] slimbus: qcom: Add Qualcomm Slimbus controller driver
From: Srinivas Kandagatla @ 2017-11-24 14:39 UTC (permalink / raw)
To: Charles Keepax
Cc: gregkh, broonie, alsa-devel, sdharia, bp, poeschel, treding,
andreas.noever, alan, mathieu.poirier, daniel, jkosina,
sharon.dvir1, joe, davem, james.hogan, michael.opdenacker,
robh+dt, pawel.moll, mark.rutland, devicetree, linux-kernel,
linux-arm-msm, vinod.koul, arnd
In-Reply-To: <20171123100703.gqwcdm7qij63cuwz@localhost.localdomain>
Thanks for your review,
On 23/11/17 10:07, Charles Keepax wrote:
>> +static irqreturn_t qcom_slim_handle_rx_irq(struct qcom_slim_ctrl *ctrl,
>> + u32 stat)
>> +{
>> + u32 *rx_buf, pkt[10];
>> + bool q_rx = false;
>> + u8 la, *buf, mc, mt, len, *b = (u8 *)&pkt[0];
>> + u16 ele;
>> +
>
> This function feels pretty funky, we basically have rx_buf, pkt,
> b and buf all of which basically point to the same thing. Can we
> simplify it a little?
I will give that a try before I send next version.
>
>> + pkt[0] = readl_relaxed(ctrl->base + MGR_RX_MSG);
>> + mt = SLIM_HEADER_GET_MT(b[0]);
>> + len = SLIM_HEADER_GET_RL(b[0]);
>> + mc = SLIM_HEADER_GET_MC(b[1]);
>> +
>> + /*
...
>> +
>> + puc = (u8 *)pbuf;
>> + head = (u32 *)pbuf;
>> +
>> + if (txn->dt == SLIM_MSG_DEST_LOGICALADDR)
>> + *head = SLIM_MSG_ASM_FIRST_WORD(txn->rl, txn->mt, txn->mc, 0,
>> + la);
>> + else
>> + *head = SLIM_MSG_ASM_FIRST_WORD(txn->rl, txn->mt, txn->mc, 1,
>> + la);
>> +
>> + if (txn->dt == SLIM_MSG_DEST_LOGICALADDR)
>> + puc += 3;
>> + else
>> + puc += 2;
>
> Combine these two if statements, makes it much clearer the actions
> are related.
I agree!!
>
>> +
>> + if (txn->mt == SLIM_MSG_MT_CORE && slim_tid_txn(txn->mt, txn->mc))
>
> slim_tid_txn checks for SLIM_MSG_MT_CORE so the check here should
> be redundant.
>
Yep, will remove this in next version.
>> + *(puc++) = txn->tid;
>> +
>> + if ((txn->mt == SLIM_MSG_MT_CORE) &&
>> + ((txn->mc >= SLIM_MSG_MC_REQUEST_INFORMATION &&
>> + txn->mc <= SLIM_MSG_MC_REPORT_INFORMATION) ||
>> + (txn->mc >= SLIM_MSG_MC_REQUEST_VALUE &&
>> + txn->mc <= SLIM_MSG_MC_CHANGE_VALUE))) {
>> + *(puc++) = (txn->ec & 0xFF);
>> + *(puc++) = (txn->ec >> 8) & 0xFF;
>> + }
>
> As you already have slim_tid_txn, would it be worth adding
> something like slim_ec_txn?
I will give it a go and see how it looks like..
To state if an element code is
> required, feels like other controls will probably want to do a
> similar thing and would make the code a little more readable
> here.
>
>> +
>> + if (txn->msg && txn->msg->wbuf)
>> + memcpy(puc, txn->msg->wbuf, txn->msg->num_bytes);
>> +
>> + qcom_slim_queue_tx(ctrl, head, txn->rl, MGR_TX_MSG);
>> + timeout = wait_for_completion_timeout(&done, msecs_to_jiffies(ms));
>> +
>> + if (!timeout) {
>> + dev_err(ctrl->dev, "TX timed out:MC:0x%x,mt:0x%x", txn->mc,
>> + txn->mt);
>> + ret = -ETIMEDOUT;
>> + }
>> +
>> + return ret;
>> +
>> +}
>> +
>> +static void qcom_slim_rxwq(struct work_struct *work)
>> +{
>> + u8 buf[SLIM_MSGQ_BUF_LEN];
>> + u8 mc, mt, len;
>> + int i, ret;
>> + struct qcom_slim_ctrl *ctrl = container_of(work, struct qcom_slim_ctrl,
>> + wd);
>> +
>> + while ((slim_get_current_rxbuf(ctrl, buf)) != -ENODATA) {
>> + len = SLIM_HEADER_GET_RL(buf[0]);
>> + mt = SLIM_HEADER_GET_MT(buf[0]);
>> + mc = SLIM_HEADER_GET_MC(buf[1]);
>> + if (mt == SLIM_MSG_MT_CORE &&
>> + mc == SLIM_MSG_MC_REPORT_PRESENT) {
>> + u8 laddr;
>> + struct slim_eaddr ea;
>> + u8 e_addr[6];
>> +
>> + for (i = 0; i < 6; i++)
>> + e_addr[i] = buf[7-i];
>> +
>> + ea.manf_id = (u16)(e_addr[5] << 8) | e_addr[4];
>> + ea.prod_code = (u16)(e_addr[3] << 8) | e_addr[2];
>> + ea.dev_index = e_addr[1];
>> + ea.instance = e_addr[0];
>
> If we are just bitshifting this out of the bytes does it really
> make it much more clear to reverse the byte order first? Feels
> like you might as well shift it out of buf directly.
>
> Also we didn't bother to reverse the bytes for the element code
> above, so feels more consistent.
I will try Jonathan Neuschäfer Suggestion to simplify this area of code.
^ permalink raw reply
* Re: [PATCH v7 12/13] slimbus: qcom: Add runtime-pm support using clock-pause
From: Srinivas Kandagatla @ 2017-11-24 14:39 UTC (permalink / raw)
To: Charles Keepax
Cc: gregkh, broonie, alsa-devel, sdharia, bp, poeschel, treding,
andreas.noever, alan, mathieu.poirier, daniel, jkosina,
sharon.dvir1, joe, davem, james.hogan, michael.opdenacker,
robh+dt, pawel.moll, mark.rutland, devicetree, linux-kernel,
linux-arm-msm, vinod.koul, arnd
In-Reply-To: <20171123101749.ojiv6l52jjq6b55b@localhost.localdomain>
Thanks for the review,
On 23/11/17 10:17, Charles Keepax wrote:
> On Wed, Nov 15, 2017 at 02:10:42PM +0000, srinivas.kandagatla@linaro.org wrote:
>> From: Sagar Dharia <sdharia@codeaurora.org>
>>
>> Slimbus HW mandates that clock-pause sequence has to be executed
>> before disabling relevant interface and core clocks.
>> Runtime-PM's autosuspend feature is used here to enter/exit low
>> power mode for Qualcomm's Slimbus controller. Autosuspend feature
>> enables driver to avoid changing power-modes too frequently since
>> entering clock-pause is an expensive sequence
>>
>> Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
>> ---
>> +
>> +#ifdef CONFIG_PM_SLEEP
>> +static int qcom_slim_suspend(struct device *dev)
>> +{
>> + int ret = 0;
>> +
>> + if (!pm_runtime_enabled(dev) ||
>> + (!pm_runtime_suspended(dev))) {
>> + dev_dbg(dev, "system suspend");
>> + ret = qcom_slim_runtime_suspend(dev);
>> + }
>> +
>> + /*
>> + * If the clock pause failed due to active channels, there is
>> + * a possibility that some audio stream is active during suspend.
>> + * (e.g. modem usecase during suspend)
>> + * We dont want to return suspend failure in that case so that
>> + * display and relevant components can still go to suspend.
>> + * If there is some other error, then it should prevent
>> + * system level suspend
>> + */
>> + if (ret == -EISCONN)
>> + ret = 0;
>
> Who actually returns the EISCONN for this to catch? Or will that
> be added to slim_ctrl_clk_pause once support for the audio
> channels is added?
This looks like a leftover code, I will remove it in next version and we
can add it once related code is added.
>
> Thanks,
> Charles
>
>> +
>> + return ret;
>> +}
^ permalink raw reply
* Re: [PATCH] arm64: dts: Hi3660: Fix state id for 'CPU_NAP' state
From: Sudeep Holla @ 2017-11-24 14:39 UTC (permalink / raw)
To: Leo Yan
Cc: Sudeep Holla, Wei Xu, Mark Rutland, linux-arm-kernel,
linux-kernel, Rob Herring, devicetree, Daniel Lezcano,
Vincent Guittot
In-Reply-To: <20171124065623.GD13184@leoy-linaro>
On 24/11/17 06:56, Leo Yan wrote:
> Hi Sudeep,
>
> On Thu, Nov 23, 2017 at 02:03:51PM +0000, Sudeep Holla wrote:
>> Hi Daniel,
>>
>> Thanks a lot for pointing me to this and having some useful discussion
>> in private. That helped to dig a bit further on this.
>>
>> On 23/11/17 05:40, Leo Yan wrote:
>>> Thanks a lot for Vincent Guittot careful work to find bug for 'CPU_NAP'
>>> idle state. From ftrace log we can observe CA73 CPUs can be easily waken
>>> up from 'CPU_NAP' state but the 'waken up' CPUs doesn't handle anything
>>> and sleep again; so there have tons of trace events for CA73 CPUs
>>> entering and exiting idle state.
>>>
>>> On Hi3660 CA73 has retention state 'CPU_NAP' for CPU idle, this state we
>>> set its psci parameter as '0x0000001' and from this parameter it can
>>> calculate state id is 1. Unfortunately ARM trusted firmware (ARM-TF)
>>> takes 1 as a invalid value for state id, so the CPU cannot enter idle
>>> state and directly bail out to kernel.
>>>
>>> This commit changes psci parameter to '0x00000000' for state id = 0;
>>> this id is accepted by ARM trusted firmware and finally CPU can stay
>>> properly in 'CPU_NAP' state.
>>>
>>
>> I would like to conditionally NACK this patch. If we can't update the
>> ARM TF at all then, I will agree with this change reluctantly.
>
> Thanks for reviewing. Just like Daniel said, we need to figure out the
> right method for this. So suggestions are very welcome!
>
Sure, thanks for such a quick response and resolution :)
>> This looks like an artifact of copy paste in ARM TF port for this
>> platform. If you look as PSCI specification, CPU suspend parameter has
>> some recommendations and it's good to follow then unless you have strong
>> reasons not to.
>>
>> As Daniel pointed to me, this patch is required to satisfy TF
>> particularly [1]. Now that looks like copy pasted from Juno or FVP port
>> and if you look deeper, it's clearly under !ARM_RECOM_STATE_ID_ENC [2]
>> which was not copied IIUC :).
>
> Thanks for sharing pointers. It's shame that the copying is not
> correct for Hikey960 :)
>
Indeed.
> Come back to recommended state id, I reviewed Juno board defintion and
> I found it's not align with PSCI spec defintion, in ARM-TF Juno code
> defines state as below [1]:
>
Yes Juno is almost 4 years old now, so it may not be too good a
reference platform for latest and greatest platforms like hikey2 ;)
As I said, Juno predates the recommendation in the PSCI spec.
> #define ARM_LOCAL_STATE_RUN 0
> #define ARM_LOCAL_STATE_RET 1
> #define ARM_LOCAL_STATE_OFF 2
>
> In PSCI spec chapter "6.5 Recommended StateID Encoding" recommends power
> state id as below:
>
> 0: Run
> 1: Standby
> 2: Retention
> 3: Powerdown
>
> So could you confirm on Hikey960 we should follow PSCI definition for
> state id definition?
>
Yes, I don't see any reason not to, as this may become reference to some
other platform, it's good to keep it aligned so that copy paste happens
in a good sense for future platforms. :)
>> Juno's implementation is legacy as these recommendations were added
>> later in the specification while Juno is 3 year old platform now.
>>
>> Though strictly speaking it's not violation of the PSCI specification,
>> but I would rather get this fixed not before it's too late and copied to
>> the next generation of platforms. Since the firmware can be easily
>> upgraded that shouldn't be that difficult.
>
> If completely compliant with PSCI recommended state id, we need change
> both for ARM-TF and kernel for this. In ARM-TF, I have sent PR [2].
>
OK
> For the kernel patch, we should change state id as below. Please let me
> know if you have suggestion for this.
>
I would wait until ATF changes are merged before you patch DT in the kernel.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH v7 07/13] slimbus: Add support for 'clock-pause' feature
From: Srinivas Kandagatla @ 2017-11-24 14:39 UTC (permalink / raw)
To: Charles Keepax
Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
broonie-DgEjT+Ai2ygdnm+yROfE0A, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
sdharia-sgV2jX0FEOL9JmXXK+q4OQ, bp-l3A5Bk7waGM,
poeschel-Xtl8qvBWbHwb1SvskN2V4Q, treding-DDmLM1+adcrQT0dZR+AlfA,
andreas.noever-Re5JQEeQqe8AvxtiuMwx3w,
alan-VuQAYsv1563Yd54FQh9/CA,
mathieu.poirier-QSEj5FYQhm4dnm+yROfE0A, daniel-/w4YWyX8dFk,
jkosina-AlSwsSmVLrQ, sharon.dvir1-MQgwKvJRKlGYZoqfULhbRA,
joe-6d6DIl74uiNBDgjK7y7TUQ, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
james.hogan-1AXoQHu6uovQT0dZR+AlfA,
michael.opdenacker-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, pawel.moll-5wv7dgnIgG8,
mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
vinod.koul-ral2JQCrhuEAvxtiuMwx3w, arnd-r2nGTMty4D4
In-Reply-To: <20171123072800.z2pkmelom374zr63-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
Thanks for the Review,
On 23/11/17 07:28, Charles Keepax wrote:
> On Wed, Nov 15, 2017 at 02:10:37PM +0000, srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org wrote:
>> From: Sagar Dharia <sdharia-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>>
>> Per slimbus specification, a reconfiguration sequence known as
>> 'clock pause' needs to be broadcast over the bus while entering low-
>> power mode. Clock-pause is initiated by the controller driver.
>> To exit clock-pause, controller typically wakes up the framer device.
>> Since wakeup precedure is controller-specific, framework calls it via
>> controller's function pointer to invoke it.
>>
>> Signed-off-by: Sagar Dharia <sdharia-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> ---
>> +/**
>> + * struct slim_sched: Framework uses this structure internally for scheduling.
>
> Missing kernel doc for clkgear here.
Will add that in next version.
>
>> + * @clk_state: Controller's clock state from enum slim_clk_state
>> + * @pause_comp: Signals completion of clock pause sequence. This is useful when
>> + * client tries to call slimbus transaction when controller is entering
>> + * clock pause.
>> + * @m_reconf: This mutex is held until current reconfiguration (data channel
>> + * scheduling, message bandwidth reservation) is done. Message APIs can
>> + * use the bus concurrently when this mutex is held since elemental access
>> + * messages can be sent on the bus when reconfiguration is in progress.
>> + */
>> +struct slim_sched {
>> + int clkgear;
>> + enum slim_clk_state clk_state;
>> + struct completion pause_comp;
>> + struct mutex m_reconf;
>> +};
>
> Thanks,
> Charles
>
--
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/5] drm/panel: Add support for the EDT ETM0700G0BDH6
From: Fabio Estevam @ 2017-11-24 14:21 UTC (permalink / raw)
To: Türk, Jan
Cc: Rob Herring, Mark Rutland, Thierry Reding, David Airlie,
Russell King, Shawn Guo, Sascha Hauer, Fabio Estevam,
Andreas Färber, Kevin Hilman, Maxime Ripard,
Alexandre Belloni, Greg Kroah-Hartman, SZ Lin,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel,
DRI mailing list
In-Reply-To: <95F51F4B902CAC40AF459205F6322F01B7F903E17B-76KB/CMpcTeJqUQdFWzYuOuPKLVQfWtC@public.gmane.org>
Hi Jan,
On Thu, Nov 23, 2017 at 1:18 PM, Türk, Jan <Jan.Tuerk-BU0Y/NROKIiELgA04lAiVw@public.gmane.org> wrote:
> Hi Fabio,
>
> I've used git send-email and tested the patches by checkpatch.pl before without any problems.
> So it might have been touched by the mail server, so can you send me your checkpatch.pl log (directly)?
Take a look at your patch here: https://patchwork.kernel.org/patch/10072765/
Click in the "patch" link and download it. You will notice that all
tabs have been converted into spaces.
checkpatch will warn about it.
--
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/3] hwrng: exynos - add Samsung Exynos True RNG driver
From: Krzysztof Kozlowski @ 2017-11-24 14:13 UTC (permalink / raw)
To: Stephan Müller
Cc: Łukasz Stelmach, Rob Herring, Matt Mackall, Herbert Xu,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Marek Szyprowski,
Bartlomiej Zolnierkiewicz
In-Reply-To: <1733513.JRsPYiahIZ-jJGQKZiSfeo1haGO/jJMPxvVK+yQ3ZXh@public.gmane.org>
On Fri, Nov 24, 2017 at 2:05 PM, Stephan Müller <smueller-T9tCv8IpfcWELgA04lAiVw@public.gmane.org> wrote:
> Am Freitag, 24. November 2017, 13:09:06 CET schrieb Krzysztof Kozlowski:
>
> Hi Krzysztof,
>> >>
>> >> 1. I was rather thinking about extending existing exynos-rng.c [1] so
>> >> it would be using TRNG as seed for PRNG as this gives you much more
>> >> random data. Instead you developed totally separate driver which has
>> >> its own benefits - one can choose which interface he wants. Although
>> >> it is a little bit duplication.
>> >
>> > As far as I can tell, these are two different devices. However, PRNG
>> > shares hardware with the hash engine. Indeed there is a hardware to
>> > connect TRNG and PRNG, but, IMHO, it might be hard to model that
>> > dependency in kernel.
>>
>> It should be as simple as setting few more registers in SSS module
>> (actually maybe just enabling TRNG_SEED_START in PRNG). You do not
>> have to model it in a kernel like connecting some hw_rng entity to
>> cryptoai's rng_alg. See the jitterentropy-kcapi.c. I understand that
>> in that case existing exynos-rng.c could expose two different RNG
>> devices - one PRNG based on user's seed and second TRNG (actually
>> TRNG+PRNG).
>>
>> It does not seem difficult to model but the question is whether that
>> makes sense.
>
> The usage strategy for the PRNGs registered at the kernel crypto API is as
> follows:
>
> 1. crypto_rng_alloc
>
> 2. crypto_rng_reset
>
> 3. crypto_rng_generate
>
> If in step 2 you provide NULL as input, the kernel takes get_random_bytes as
> seed source. Step 2 is the mandatory.
>
> The Linux-RNG can be fed internally from the hw_random framework by the
> function hwrng_fillfn. This function is only used if the current_quality or
> default_quality values in the hw_random framework is set.
>
> For the TRNG, it seems to be not set per default, but could be set as either a
> boot argument or at runtime via /sys.
>
> If that variable is set and the TRNG is registered, it feeds random data into
> the Linux-RNG which in turn is used per default to seed a PRNG. In this case,
> no detour via user space is needed to push data from TRNG to the PRNG. Using
> that mechanism allows you to benefit from additional entropy the Linux-RNG
> collects elsewhere.
>>
>> > To me it seems easier to read TRNG (or
>> > /dev/random) and and write the result to PRNG manually (in software).
>>
>> Indeed this gives more flexibility to the user (choice of engine) but
>> first, it is slower, and second it reduces the quality of random
>> numbers (PRNG reseeds itself... but in this model cannot reseed from
>> TRNG).
>
> Given the reasons above, I would think that keeping the PRMG and TRNG separate
> as offered by the current patch seems reasonable. If configured correctly, the
> TRNG can seed the PRNG at any time (including boot time) without the need of
> user space.
Hi Stephan,
Thanks for explaining the details. This convinces me so I do not have
any objections against current approach of this second RNG driver for
Exynos.
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] ARM: dts: imx6qdl-nitrogen6x: Add SPI NOR partitions
From: Fabio Estevam @ 2017-11-24 13:44 UTC (permalink / raw)
To: Otavio Salvador
Cc: linux-arm-kernel@lists.infradead.org, Gary Bisson, Fabio Estevam,
devicetree@vger.kernel.org, Sascha Hauer, linux-kernel,
Rob Herring, Mark Rutland, Russell King, Shawn Guo
In-Reply-To: <20171124112151.2758-1-otavio@ossystems.com.br>
On Fri, Nov 24, 2017 at 9:21 AM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
> index 4bdf29169d2a..f8b267875e1c 100644
> --- a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi
> @@ -276,6 +276,23 @@
> compatible = "sst,sst25vf016b", "jedec,spi-nor";
> spi-max-frequency = <20000000>;
> reg = <0>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partition@0 {
> + label = "U-Boot";
What about calling it something more generic, like "bootloader"?
U-Boot is not the only bootloader that can run on this board.
You could also consider passing the 'read-only' property like it is
done in imx6sx-nitrogen6sx.dts.
> + reg = <0x0 0xc0000>;
> + };
> +
> + partition@c0000 {
> + label = "U-Boot Environment";
Maybe just 'env' and add 'read-only' property here as well.
^ permalink raw reply
* Re: [RFC PATCH 1/3] dt-bindings: pinctrl: sunxi: document new generic binding
From: Thierry Reding @ 2017-11-24 13:31 UTC (permalink / raw)
To: Andre Przywara
Cc: Linus Walleij, Maxime Ripard, Chen-Yu Tsai,
linux-gpio-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Linux ARM, Arnd Bergmann,
Icenowy Zheng,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
In-Reply-To: <20efcf8f-85a5-3cad-a84b-434ee5cad68e-5wv7dgnIgG8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 8321 bytes --]
On Fri, Nov 24, 2017 at 12:04:12PM +0000, Andre Przywara wrote:
> Hi,
>
> (adding linux-sunxi, which I forgot at the initial post).
>
> On 24/11/17 10:52, Thierry Reding wrote:
> > On Fri, Nov 24, 2017 at 11:19:52AM +0100, Linus Walleij wrote:
> >> On Mon, Nov 13, 2017 at 2:25 AM, Andre Przywara <andre.przywara-5wv7dgnIgG8@public.gmane.org> wrote:
> >>
> >>> So far all the Allwinner pinctrl drivers provided a table in the
> >>> kernel to describe all the pins and the link between the pinctrl functions
> >>> names (strings) and their respective mux values (register values).
> >>>
> >>> Extend the binding to put those mappings in the DT, so that any SoC can
> >>> describe its pinctrl and GPIO data fully there instead of relying on
> >>> tables.
> >>> This uses a generic compatible name, to be prepended with an SoC
> >>> specific name in the node.
> >
> > This seems backwards to me. I'm not sure if Rob has any hard rules on
> > this, but in the past I've seen a lot of drivers stick this kind of data
> > into drivers. I personally also prefer that approach because the data is
> > completely static and there's no way for any specific board to customize
> > it. So the tables are in fact implied completely by the SoC compatible
> > string.
>
> But this is just *data*, and I believe it is actually package specific.
> We need the DT to describe the relation between devices and pins anyway,
> it's just that we use arbitrary strings today instead of the actual
> register value. This is what the generic pinmux property fixes.
Register values don't belong in a device tree. And it's totally fine to
have data in the kernel, too. We do it all the time.
> > Moving all of this data into device tree has a number of disadvantages:
> >
> > * Existing boards already use the static tables in the driver, and the
> > device trees don't contain any data, so you can't get rid of any of
> > the existing tables because it would break ABI.
>
> Yes, my DeLorean is in the garage, so I can't really change this anymore
> ;-) But that doesn't mean we have to go on with this forever, I think.
ABI stability means that, yes, you have to keep maintaining the existing
tables forever, else old DTBs will stop working if you rip out the
static tables that drivers depend on.
> > * Moving the table into the DT doesn't actually solve anything because
> > the driver would have to validate the DT description to make sure it
> > contains valid data. And in order to validate DT content, the driver
> > would need a copy of the table anyway.
>
> I don't get what the driver would need to validate? We rely on DT
> information to be correct anyway, otherwise your board just won't work.
> If the DT is wrong, you have much bigger problems.
Given that DT is an ABI you should treat it the same way as other ABIs.
You can't rely on the DT being correct. Rather you have to make sure to
validate it before you hand the content to hardware. If you allow direct
register access to your hardware via DT and don't validate, it becomes
really easy for people to exploit it.
This is not the same as saying we need to be able to fully validate all
aspects of device tree. We can't, because some information simply does
not exist outside of DT. However, I think it's a big mistake to trust a
user to fully know about all intricacies of a pinmux and not make any
mistake when writing the device tree. What if one of the settings causes
the board to go up in flames?
> Actually we gain something, because we only commit information that can
> actually be tested. Right now we have a lot of information which is
> copied from the manual, and nobody knows if pin H24 on the A10 is really
> PATA-CS1 or not. Plus we have bugs when creating the table, plus
> copy&paste bugs. I found some while grep-ing for patterns - will send
> fixes ASAP.
That's a different matter. If you've got bugs in the tables, then go fix
the tables. However the assumption here is that you've done at least a
minimum of testing and your driver didn't cause your board to go up in
flames. When patches were posted, people had the opportunity to review
the tables for correctness. However, if you put all of the flexibility
into DT, you also put all of the risk there. People may just make some
stupid mistake and cause physical damage to their hardware.
> In the moment all the table gives us is a mapping between a *string* and
> the respective mux register value (per pin), plus the number of pins in
> each bank. This can *easily* be put in the DT and should belong there.
Why? This is data that is implied by the compatible string and static
per SoC. There is no way you can change the mapping in DT. What does
need to go into DT is the configuration of the pinmux, that is, what
function is used for each pin on a given board.
> Actually I believe that the current binding is not correct, because it
> makes those mux strings a part of the binding, though this is not
> documented anywhere. A developer cannot take the binding and write a
> working driver or even a DT without looking at the code.
> Plus we already changed those names in the past (for instance commit
> bc0f566a98c4), basically breaking compatibility.
If you haven't documented the strings your binding is not complete.
That's a bug and should be fixed. Also, it is occasionally acceptable to
break compatibility (it's technically only breaking if somebody notices)
and fixing bugs in bindings has in the past been one of the exceptions
where breaking ABI was specifically allowed.
However, the kind of breakage we're talking about here is total. If you
rip out the static tables from your driver, you don't have any data to
replace the missing information and none of the driver will work. This
is different from the driver erroring out trying to configure a pin for
the NAND function because it couldn't match the name.
Also, device tree bindings are not documentation for how to write a
driver. They are not a replacement for hardware documentation. Nobody
should be expected to be able to write an OS driver solely based on a
device tree binding. Device tree bindings are more of a configuration
interface specification for OS drivers.
> > I don't think you're going to do yourself any favours by pushing this. I
> > also don't see the commit description give any reason why you want to
> > move the table into device tree. Do you see any advantages in doing so?
>
> We stop adding tables with SoC specific *data* in the kernel *code*
> base. With being boolean Kconfig options, this gets added to every
> single-image kernel.
The kernel is full of data:
$ objdump -h build/arm64/vmlinux
[...]
1 .text 009c99c0 ffff000008081000 ffff000008081000 00011000 2**11
CONTENTS, ALLOC, LOAD, READONLY, CODE
2 .rodata 00403bf8 ffff000008a50000 ffff000008a50000 009e0000 2**12
CONTENTS, ALLOC, LOAD, DATA
[...]
So that's about 40% of the kernel image. Code really is no good without
data to process.
> More important: those tables help Linux, but other DT consumers (*BSD,
> U-Boot) have to replicate them, which is just wrong, IMHO.
Yeah, I've heard this before. To be honest, I think these tables are the
kind of data that you should generate, and once you do that it becomes
extremely cheap to add the data to other DT consumers.
And let's face it: the really difficult part of adding pinmux support is
to write the driver (or subsystem if you don't have one yet). Adding the
data is really the easy part.
> I believe the kernel is a nice collection of really good code for
> complicated file systems, high performance network protocols and
> sophisticated memory management, among others. It shouldn't be a dumping
> ground for arbitrary, very SoC specific information. Cf. LinusT 2011.
> DT is out there to fix this, so we should do so.
Every driver is very SoC specific information. There's never been an
objection to having SoC specific drivers in the kernel. And back at the
time the discussion was as much about the development process and code
structure than it was about board files.
The majority of the improvements over the years have been achieved by
moving drivers out of arch/arm and moving board files to DT. The goal
was never to get rid of all data.
Thierry
^ permalink raw reply
* [PATCH v4 6/6] arm/dts: Add nodes for flexcan devices present on LS1021A-Rev2 SoC
From: Pankaj Bansal @ 2017-11-24 13:22 UTC (permalink / raw)
To: wg-5Yr1BZd7O62+XT7JhA+gdA, mkl-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-can-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: V.Sethi-3arQi8VN3Tc, poonam.aggrwal-3arQi8VN3Tc, Pankaj Bansal,
Bhupesh Sharma, Sakar Arora
In-Reply-To: <1511529733-27942-1-git-send-email-pankaj.bansal-3arQi8VN3Tc@public.gmane.org>
This patch adds the device nodes for flexcan controller(s) present on
LS1021A-Rev2 SoC.
Signed-off-by: Pankaj Bansal <pankaj.bansal-3arQi8VN3Tc@public.gmane.org>
Signed-off-by: Bhupesh Sharma <bhupesh.sharma-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Signed-off-by: Sakar Arora <Sakar.Arora-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Reviewed-by: Zhengxiong Jin <Jason.Jin-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Reviewed-by: Poonam Aggrwal <poonam.aggrwal-3arQi8VN3Tc@public.gmane.org>
---
Changes in v4:
- Merged device tree changes and driver changes in one series
Changes in v3:
- No change.
Changes in v2:
- No change.
- Added one more patch in series.
arch/arm/boot/dts/ls1021a-qds.dts | 16 +++++++++++++
arch/arm/boot/dts/ls1021a-twr.dts | 16 +++++++++++++
arch/arm/boot/dts/ls1021a.dtsi | 36 +++++++++++++++++++++++++++++
3 files changed, 68 insertions(+)
diff --git a/arch/arm/boot/dts/ls1021a-qds.dts b/arch/arm/boot/dts/ls1021a-qds.dts
index 9408753..4f211e3 100644
--- a/arch/arm/boot/dts/ls1021a-qds.dts
+++ b/arch/arm/boot/dts/ls1021a-qds.dts
@@ -331,3 +331,19 @@
&uart1 {
status = "okay";
};
+
+&can0 {
+ status = "okay";
+};
+
+&can1 {
+ status = "okay";
+};
+
+&can2 {
+ status = "disabled";
+};
+
+&can3 {
+ status = "disabled";
+};
diff --git a/arch/arm/boot/dts/ls1021a-twr.dts b/arch/arm/boot/dts/ls1021a-twr.dts
index a8b148a..7202d9c 100644
--- a/arch/arm/boot/dts/ls1021a-twr.dts
+++ b/arch/arm/boot/dts/ls1021a-twr.dts
@@ -243,3 +243,19 @@
&uart1 {
status = "okay";
};
+
+&can0 {
+ status = "okay";
+};
+
+&can1 {
+ status = "okay";
+};
+
+&can2 {
+ status = "disabled";
+};
+
+&can3 {
+ status = "disabled";
+};
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index 9319e1f..7789031 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -730,5 +730,41 @@
<0000 0 0 3 &gic GIC_SPI 191 IRQ_TYPE_LEVEL_HIGH>,
<0000 0 0 4 &gic GIC_SPI 193 IRQ_TYPE_LEVEL_HIGH>;
};
+
+ can0: can@2a70000 {
+ compatible = "fsl,ls1021ar2-flexcan";
+ reg = <0x0 0x2a70000 0x0 0x1000>;
+ interrupts = <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clockgen 4 1>, <&clockgen 4 1>;
+ clock-names = "ipg", "per";
+ big-endian;
+ };
+
+ can1: can@2a80000 {
+ compatible = "fsl,ls1021ar2-flexcan";
+ reg = <0x0 0x2a80000 0x0 0x1000>;
+ interrupts = <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clockgen 4 1>, <&clockgen 4 1>;
+ clock-names = "ipg", "per";
+ big-endian;
+ };
+
+ can2: can@2a90000 {
+ compatible = "fsl,ls1021ar2-flexcan";
+ reg = <0x0 0x2a90000 0x0 0x1000>;
+ interrupts = <GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clockgen 4 1>, <&clockgen 4 1>;
+ clock-names = "ipg", "per";
+ big-endian;
+ };
+
+ can3: can@2aa0000 {
+ compatible = "fsl,ls1021ar2-flexcan";
+ reg = <0x0 0x2aa0000 0x0 0x1000>;
+ interrupts = <GIC_SPI 129 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clockgen 4 1>, <&clockgen 4 1>;
+ clock-names = "ipg", "per";
+ big-endian;
+ };
};
};
--
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
* [PATCH v4 5/6] arm: dts: Remove p1010-flexcan compatible from imx series dts
From: Pankaj Bansal @ 2017-11-24 13:22 UTC (permalink / raw)
To: wg, mkl, linux-can, robh+dt, mark.rutland, devicetree
Cc: V.Sethi, poonam.aggrwal, Pankaj Bansal
In-Reply-To: <1511529733-27942-1-git-send-email-pankaj.bansal@nxp.com>
The flexcan driver has been modified to check for big-endian dts
property for be read/write to flexcan registers/mb.
An exception to this rule is powerpc P1010RDB, which is always
big-endian, even if big-endian is not present in dts. This is
checked using p1010-flexcan compatible in dts.
Therefore, remove p1010-flexcan compatible from imx series dts,
as their flexcan core is little endian.
Signed-off-by: Pankaj Bansal <pankaj.bansal@nxp.com>
---
Changes in v4:
- Merged device tree changes and driver changes in one series
Changes in v3:
- No change.
Changes in v2:
- Add this patch in series.
arch/arm/boot/dts/imx25.dtsi | 4 ++--
arch/arm/boot/dts/imx28.dtsi | 4 ++--
arch/arm/boot/dts/imx35.dtsi | 4 ++--
arch/arm/boot/dts/imx53.dtsi | 4 ++--
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index 09ce8b8..fcaff1c 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -122,7 +122,7 @@
};
can1: can@43f88000 {
- compatible = "fsl,imx25-flexcan", "fsl,p1010-flexcan";
+ compatible = "fsl,imx25-flexcan";
reg = <0x43f88000 0x4000>;
interrupts = <43>;
clocks = <&clks 75>, <&clks 75>;
@@ -131,7 +131,7 @@
};
can2: can@43f8c000 {
- compatible = "fsl,imx25-flexcan", "fsl,p1010-flexcan";
+ compatible = "fsl,imx25-flexcan";
reg = <0x43f8c000 0x4000>;
interrupts = <44>;
clocks = <&clks 76>, <&clks 76>;
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 2f4ebe0..e52e05c 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -1038,7 +1038,7 @@
};
can0: can@80032000 {
- compatible = "fsl,imx28-flexcan", "fsl,p1010-flexcan";
+ compatible = "fsl,imx28-flexcan";
reg = <0x80032000 0x2000>;
interrupts = <8>;
clocks = <&clks 58>, <&clks 58>;
@@ -1047,7 +1047,7 @@
};
can1: can@80034000 {
- compatible = "fsl,imx28-flexcan", "fsl,p1010-flexcan";
+ compatible = "fsl,imx28-flexcan";
reg = <0x80034000 0x2000>;
interrupts = <9>;
clocks = <&clks 59>, <&clks 59>;
diff --git a/arch/arm/boot/dts/imx35.dtsi b/arch/arm/boot/dts/imx35.dtsi
index 6d5e6a6..1f0e220 100644
--- a/arch/arm/boot/dts/imx35.dtsi
+++ b/arch/arm/boot/dts/imx35.dtsi
@@ -303,7 +303,7 @@
};
can1: can@53fe4000 {
- compatible = "fsl,imx35-flexcan", "fsl,p1010-flexcan";
+ compatible = "fsl,imx35-flexcan";
reg = <0x53fe4000 0x1000>;
clocks = <&clks 33>, <&clks 33>;
clock-names = "ipg", "per";
@@ -312,7 +312,7 @@
};
can2: can@53fe8000 {
- compatible = "fsl,imx35-flexcan", "fsl,p1010-flexcan";
+ compatible = "fsl,imx35-flexcan";
reg = <0x53fe8000 0x1000>;
clocks = <&clks 34>, <&clks 34>;
clock-names = "ipg", "per";
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 8bf0d89..85573cf 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -545,7 +545,7 @@
};
can1: can@53fc8000 {
- compatible = "fsl,imx53-flexcan", "fsl,p1010-flexcan";
+ compatible = "fsl,imx53-flexcan";
reg = <0x53fc8000 0x4000>;
interrupts = <82>;
clocks = <&clks IMX5_CLK_CAN1_IPG_GATE>,
@@ -555,7 +555,7 @@
};
can2: can@53fcc000 {
- compatible = "fsl,imx53-flexcan", "fsl,p1010-flexcan";
+ compatible = "fsl,imx53-flexcan";
reg = <0x53fcc000 0x4000>;
interrupts = <83>;
clocks = <&clks IMX5_CLK_CAN2_IPG_GATE>,
--
2.7.4
^ permalink raw reply related
* [PATCH v4 4/6] powerpc: dts: P1010: Add endianness property to flexcan node
From: Pankaj Bansal @ 2017-11-24 13:22 UTC (permalink / raw)
To: wg, mkl, linux-can, robh+dt, mark.rutland, devicetree
Cc: V.Sethi, poonam.aggrwal, Pankaj Bansal
In-Reply-To: <1511529733-27942-1-git-send-email-pankaj.bansal@nxp.com>
The flexcan driver assumed that flexcan controller is big endian for
powerpc architecture and little endian for other architectures.
But this is not universally true. flexcan controller can be little or
big endian on any architecture.
Therefore the flexcan driver has been modified to check for "big-endian"
device tree property for controllers that are big endian.
consequently add the property to freescale P1010 SOC device tree.
Signed-off-by: Pankaj Bansal <pankaj.bansal@nxp.com>
Reviewed-by: Poonam Aggrwal <poonam.aggrwal@nxp.com>
---
Changes in v4:
- Merged device tree changes and driver changes in one series
Changes in v3:
- No change.
Changes in v2:
- No change.
- Added one more patch in series.
arch/powerpc/boot/dts/fsl/p1010si-post.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/boot/dts/fsl/p1010si-post.dtsi b/arch/powerpc/boot/dts/fsl/p1010si-post.dtsi
index af12ead..1b4aafc 100644
--- a/arch/powerpc/boot/dts/fsl/p1010si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/p1010si-post.dtsi
@@ -137,12 +137,14 @@
compatible = "fsl,p1010-flexcan";
reg = <0x1c000 0x1000>;
interrupts = <48 0x2 0 0>;
+ big-endian;
};
can1: can@1d000 {
compatible = "fsl,p1010-flexcan";
reg = <0x1d000 0x1000>;
interrupts = <61 0x2 0 0>;
+ big-endian;
};
L2: l2-cache-controller@20000 {
--
2.7.4
^ permalink raw reply related
* [PATCH v4 3/6] Documentation : can : flexcan : Add big-endian property to device tree
From: Pankaj Bansal @ 2017-11-24 13:22 UTC (permalink / raw)
To: wg-5Yr1BZd7O62+XT7JhA+gdA, mkl-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-can-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: V.Sethi-3arQi8VN3Tc, poonam.aggrwal-3arQi8VN3Tc, Pankaj Bansal
In-Reply-To: <1511529733-27942-1-git-send-email-pankaj.bansal-3arQi8VN3Tc@public.gmane.org>
The FlexCAN controller can be modelled as little or big endian depending
on SOC design. This device tree property identifies the controller
endianness and the driver reads/writes controller registers based on
that.
This is optional property. i.e. if this property is not present in
device tree node then controller is assumed to be little endian. if this
property is present then controller is assumed to be big endian.
Signed-off-by: Pankaj Bansal <pankaj.bansal-3arQi8VN3Tc@public.gmane.org>
Reviewed-by: Poonam Aggrwal <poonam.aggrwal-3arQi8VN3Tc@public.gmane.org>
---
Changes in v4:
- document the default behaviour in the bindings if the big-endian property
is missing.
- Merged device tree changes and driver changes in one series
Changes in v3:
- No change.
Changes in v2:
- No change.
- Added one more patch in series.
Documentation/devicetree/bindings/net/can/fsl-flexcan.txt | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
index 56d6cc3..bfc0c43 100644
--- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
+++ b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
@@ -18,6 +18,12 @@ Optional properties:
- xceiver-supply: Regulator that powers the CAN transceiver
+- big-endian: This means the registers of FlexCAN controller are big endian.
+ This is optional property.i.e. if this property is not present in
+ device tree node then controller is assumed to be little endian.
+ if this property is present then controller is assumed to be big
+ endian.
+
Example:
can@1c000 {
--
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
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