* Re: [PATCH V11 6/6] thermal: bcm2835: add thermal driver for bcm2835 SoC
From: Eduardo Valentin @ 2017-03-29 4:58 UTC (permalink / raw)
To: Stefan Wahren
Cc: Zhang Rui, kernel-TqfNSX0MhmxHKSADF0wUEw, Eric Anholt,
Rob Herring, Frank Rowand, Florian Fainelli,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1489356665-3175-7-git-send-email-stefan.wahren-eS4NqCHxEME@public.gmane.org>
On Sun, Mar 12, 2017 at 10:11:05PM +0000, Stefan Wahren wrote:
> Add basic thermal driver for bcm2835 SoC.
>
> This driver currently make sure that tsense HW block is set up
> correctly.
>
> Signed-off-by: Martin Sperl <kernel-TqfNSX0MhmxHKSADF0wUEw@public.gmane.org>
> Signed-off-by: Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>
> Acked-by: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
I see no issue with this driver at this point.
As I mentioned, the full series needs to go together. You either get an
Ack from OF maintainers, and I take the series, or you can add my
Acked-by: Eduardo Valentin <edubezval-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
after fixing the small comment from Nobuhiro.
> ---
> drivers/thermal/Kconfig | 8 +
> drivers/thermal/Makefile | 1 +
> drivers/thermal/bcm2835_thermal.c | 315 +++++++++++++++++++++++++++++++++++++
> 3 files changed, 324 insertions(+)
> create mode 100644 drivers/thermal/bcm2835_thermal.c
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 776b343..3bd2406 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -453,4 +453,12 @@ config ZX2967_THERMAL
> the primitive temperature sensor embedded in zx2967 SoCs.
> This sensor generates the real time die temperature.
>
> +config BCM2835_THERMAL
> + tristate "Thermal sensors on bcm2835 SoC"
> + depends on ARCH_BCM2835 || COMPILE_TEST
> + depends on HAS_IOMEM
> + depends on THERMAL_OF
> + help
> + Support for thermal sensors on Broadcom bcm2835 SoCs.
small suggestion here:
-If you are sending a new version fixing Nobuhiro comment, you could take
the opportunity to improve the driver Kconfig help description.
--
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 V11 2/6] thermal: of-thermal: Implement signed coefficient support
From: Eduardo Valentin @ 2017-03-29 4:54 UTC (permalink / raw)
To: Stefan Wahren
Cc: Zhang Rui, kernel-TqfNSX0MhmxHKSADF0wUEw, Eric Anholt,
Rob Herring, Frank Rowand, Florian Fainelli,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1489356665-3175-3-git-send-email-stefan.wahren-eS4NqCHxEME@public.gmane.org>
On Sun, Mar 12, 2017 at 10:11:01PM +0000, Stefan Wahren wrote:
> Use the new function of_property_read_s32_array() to prepare
> of-thermal for negative coefficients. These are used by
> the upcoming bcm2835_thermal driver.
>
> Signed-off-by: Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>
> ---
> drivers/thermal/of-thermal.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
> index d04ec3b..491d58a 100644
> --- a/drivers/thermal/of-thermal.c
> +++ b/drivers/thermal/of-thermal.c
> @@ -821,7 +821,8 @@ __init *thermal_of_build_thermal_zone(struct device_node *np)
> struct device_node *child = NULL, *gchild;
> struct __thermal_zone *tz;
> int ret, i;
> - u32 prop, coef[2];
> + u32 prop;
> + s32 coef[2];
>
> if (!np) {
> pr_err("no thermal zone np\n");
> @@ -851,7 +852,7 @@ __init *thermal_of_build_thermal_zone(struct device_node *np)
> * one sensor per thermal zone. Thus, we are considering
> * only the first two values as slope and offset.
> */
> - ret = of_property_read_u32_array(np, "coefficients", coef, 2);
> + ret = of_property_read_s32_array(np, "coefficients", coef, 2);
For the scope of the proposed change I see not problem with this patch.
However, this needs to go in after the of core change gets accepted.
Alternatively, I could take the full series if you get an Ack from OF
maintainers.
> if (ret == 0) {
> tz->slope = coef[0];
> tz->offset = coef[1];
> --
> 1.7.9.5
>
--
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: [RFC PATCH] of: Fix DMA configuration for non-DT masters
From: Oza Oza @ 2017-03-29 4:53 UTC (permalink / raw)
To: Robin Murphy
Cc: Linux IOMMU, devicetree-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <67d1f46172599be243405f4341665fd0ef9ab969.1490726288.git.robin.murphy-5wv7dgnIgG8@public.gmane.org>
On Wed, Mar 29, 2017 at 12:27 AM, Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org> wrote:
> For PCI masters not represented in DT, we pass the OF node of their
> associated host bridge to of_dma_configure(), such that they can inherit
> the appropriate DMA configuration from whatever is described there.
> Unfortunately, whilst this has worked for the "dma-coherent" property,
> it turns out to miss the case where the host bridge node has a non-empty
> "dma-ranges", since nobody is expecting the 'device' to be a bus itself.
>
> It transpires, though, that the de-facto interface since the prototype
> change in 1f5c69aa51f9 ("of: Move of_dma_configure() to device.c to help
> re-use") is very clear-cut: either the master_np argument is redundant
> with dev->of_node, or dev->of_node is NULL and master_np is the relevant
> parent bus. Let's ratify that behaviour, then teach the whole
> of_dma_configure() pipeline to cope with both cases properly.
>
> Signed-off-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
> ---
>
> This is what I'd consider the better fix - rather than adding yet more
> special cases - which will also make it simple to handle multiple
> "dma-ranges" entries with minimal further disruption. The callers now
> left passing dev->of_node as 'parent' are harmless, but look a bit silly
> and clearly want cleaning up - I'd be partial to renaming the existing
> function and having a single-argument wrapper for the 'normal' case, e.g.:
>
> static inline int of_dma_configure(struct device_node *dev)
> {
> return of_dma_configure_parent(dev, NULL);
> }
>
> Thoughts?
>
> Robin.
>
> drivers/iommu/of_iommu.c | 7 ++++---
> drivers/of/address.c | 37 +++++++++++++++++++++++++------------
> drivers/of/device.c | 12 +++++++-----
> include/linux/of_address.h | 7 ++++---
> include/linux/of_device.h | 4 ++--
> include/linux/of_iommu.h | 4 ++--
> 6 files changed, 44 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index 2683e9fc0dcf..35aff07bb5eb 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -138,21 +138,22 @@ static const struct iommu_ops
> }
>
> const struct iommu_ops *of_iommu_configure(struct device *dev,
> - struct device_node *master_np)
> + struct device_node *parent)
> {
> struct of_phandle_args iommu_spec;
> - struct device_node *np;
> + struct device_node *np, *master_np;
> const struct iommu_ops *ops = NULL;
> int idx = 0;
>
> if (dev_is_pci(dev))
> - return of_pci_iommu_configure(to_pci_dev(dev), master_np);
> + return of_pci_iommu_configure(to_pci_dev(dev), parent);
>
> /*
> * We don't currently walk up the tree looking for a parent IOMMU.
> * See the `Notes:' section of
> * Documentation/devicetree/bindings/iommu/iommu.txt
> */
> + master_np = dev->of_node ? dev->of_node : parent;
> while (!of_parse_phandle_with_args(master_np, "iommus",
> "#iommu-cells", idx,
> &iommu_spec)) {
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index 02b2903fe9d2..833bc17f5e55 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -808,6 +808,7 @@ EXPORT_SYMBOL(of_io_request_and_map);
> /**
> * of_dma_get_range - Get DMA range info
> * @np: device node to get DMA range info
> + * @parent: node of device's parent bus, if @np is NULL
> * @dma_addr: pointer to store initial DMA address of DMA range
> * @paddr: pointer to store initial CPU address of DMA range
> * @size: pointer to store size of DMA range
> @@ -822,36 +823,48 @@ EXPORT_SYMBOL(of_io_request_and_map);
> * It returns -ENODEV if "dma-ranges" property was not found
> * for this device in DT.
> */
> -int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *size)
> +int of_dma_get_range(struct device_node *np, struct device_node *parent,
> + u64 *dma_addr, u64 *paddr, u64 *size)
> {
> - struct device_node *node = of_node_get(np);
> + struct device_node *node;
> const __be32 *ranges = NULL;
> int len, naddr, nsize, pna;
> int ret = 0;
> u64 dmaaddr;
>
> - if (!node)
> - return -EINVAL;
> -
> - while (1) {
> + if (np) {
> + node = of_node_get(np);
> naddr = of_n_addr_cells(node);
> nsize = of_n_size_cells(node);
> node = of_get_next_parent(node);
> - if (!node)
> - break;
> + } else if (parent) {
> + node = of_node_get(parent);
> + np = parent;
> + if (of_property_read_u32(node, "#address-cells", &naddr))
> + naddr = of_n_addr_cells(node);
> + if (of_property_read_u32(node, "#size-cells", &nsize))
> + nsize = of_n_size_cells(node);
> + } else {
> + return -EINVAL;
> + }
>
> + while (node) {
> ranges = of_get_property(node, "dma-ranges", &len);
>
> - /* Ignore empty ranges, they imply no translation required */
> - if (ranges && len > 0)
> - break;
> -
> /*
> * At least empty ranges has to be defined for parent node if
> * DMA is supported
> */
> if (!ranges)
> break;
> +
> + /* Ignore empty ranges, they imply no translation required */
> + if (len > 0)
> + break;
> +
> + naddr = of_n_addr_cells(node);
> + nsize = of_n_size_cells(node);
> + node = of_get_next_parent(node);
> }
>
> if (!ranges) {
> diff --git a/drivers/of/device.c b/drivers/of/device.c
> index 9bb8518b28f2..57ec5324ed6c 100644
> --- a/drivers/of/device.c
> +++ b/drivers/of/device.c
> @@ -73,7 +73,8 @@ int of_device_add(struct platform_device *ofdev)
> /**
> * of_dma_configure - Setup DMA configuration
> * @dev: Device to apply DMA configuration
> - * @np: Pointer to OF node having DMA configuration
> + * @parent: OF node of device's parent bus, if @dev is not
> + * represented in DT (i.e. @dev->of_node is NULL)
> *
> * Try to get devices's DMA configuration from DT and update it
> * accordingly.
> @@ -82,13 +83,14 @@ int of_device_add(struct platform_device *ofdev)
> * can use a platform bus notifier and handle BUS_NOTIFY_ADD_DEVICE events
> * to fix up DMA configuration.
> */
> -void of_dma_configure(struct device *dev, struct device_node *np)
> +void of_dma_configure(struct device *dev, struct device_node *parent)
> {
> u64 dma_addr, paddr, size;
> int ret;
> bool coherent;
> unsigned long offset;
> const struct iommu_ops *iommu;
> + struct device_node *np = dev->of_node;
>
> /*
> * Set default coherent_dma_mask to 32 bit. Drivers are expected to
> @@ -104,7 +106,7 @@ void of_dma_configure(struct device *dev, struct device_node *np)
> if (!dev->dma_mask)
> dev->dma_mask = &dev->coherent_dma_mask;
>
> - ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
> + ret = of_dma_get_range(np, parent, &dma_addr, &paddr, &size);
> if (ret < 0) {
> dma_addr = offset = 0;
> size = dev->coherent_dma_mask + 1;
> @@ -132,11 +134,11 @@ void of_dma_configure(struct device *dev, struct device_node *np)
> dev->coherent_dma_mask = DMA_BIT_MASK(ilog2(dma_addr + size));
> *dev->dma_mask = dev->coherent_dma_mask;
>
> - coherent = of_dma_is_coherent(np);
> + coherent = of_dma_is_coherent(np ? np : parent);
> dev_dbg(dev, "device is%sdma coherent\n",
> coherent ? " " : " not ");
>
> - iommu = of_iommu_configure(dev, np);
> + iommu = of_iommu_configure(dev, parent);
> dev_dbg(dev, "device is%sbehind an iommu\n",
> iommu ? " " : " not ");
>
> diff --git a/include/linux/of_address.h b/include/linux/of_address.h
> index 37864734ca50..f1a507f3ae57 100644
> --- a/include/linux/of_address.h
> +++ b/include/linux/of_address.h
> @@ -52,8 +52,8 @@ extern int of_pci_range_parser_init(struct of_pci_range_parser *parser,
> extern struct of_pci_range *of_pci_range_parser_one(
> struct of_pci_range_parser *parser,
> struct of_pci_range *range);
> -extern int of_dma_get_range(struct device_node *np, u64 *dma_addr,
> - u64 *paddr, u64 *size);
> +extern int of_dma_get_range(struct device_node *np, struct device_node *parent,
> + u64 *dma_addr, u64 *paddr, u64 *size);
> extern bool of_dma_is_coherent(struct device_node *np);
> #else /* CONFIG_OF_ADDRESS */
> static inline void __iomem *of_io_request_and_map(struct device_node *device,
> @@ -95,7 +95,8 @@ static inline struct of_pci_range *of_pci_range_parser_one(
> return NULL;
> }
>
> -static inline int of_dma_get_range(struct device_node *np, u64 *dma_addr,
> +static inline int of_dma_get_range(struct device_node *np,
> + struct device_node *parent, u64 *dma_addr,
> u64 *paddr, u64 *size)
> {
> return -ENODEV;
> diff --git a/include/linux/of_device.h b/include/linux/of_device.h
> index c12dace043f3..bcd2b6fbeef3 100644
> --- a/include/linux/of_device.h
> +++ b/include/linux/of_device.h
> @@ -55,7 +55,7 @@ static inline struct device_node *of_cpu_device_node_get(int cpu)
> return of_node_get(cpu_dev->of_node);
> }
>
> -void of_dma_configure(struct device *dev, struct device_node *np);
> +void of_dma_configure(struct device *dev, struct device_node *parent);
> #else /* CONFIG_OF */
>
> static inline int of_driver_match_device(struct device *dev,
> @@ -103,7 +103,7 @@ static inline struct device_node *of_cpu_device_node_get(int cpu)
> {
> return NULL;
> }
> -static inline void of_dma_configure(struct device *dev, struct device_node *np)
> +static inline void of_dma_configure(struct device *dev, struct device_node *parent)
> {}
> #endif /* CONFIG_OF */
>
> diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
> index 13394ac83c66..c02b62e8e6ed 100644
> --- a/include/linux/of_iommu.h
> +++ b/include/linux/of_iommu.h
> @@ -12,7 +12,7 @@ extern int of_get_dma_window(struct device_node *dn, const char *prefix,
> size_t *size);
>
> extern const struct iommu_ops *of_iommu_configure(struct device *dev,
> - struct device_node *master_np);
> + struct device_node *parent);
>
> #else
>
> @@ -24,7 +24,7 @@ static inline int of_get_dma_window(struct device_node *dn, const char *prefix,
> }
>
> static inline const struct iommu_ops *of_iommu_configure(struct device *dev,
> - struct device_node *master_np)
> + struct device_node *parent)
> {
> return NULL;
> }
> --
> 2.11.0.dirty
>
pci and memory mapped device world is different. of course if you talk
from iommu perspective, all the master are same for IOMMU
but the original intention of the patch is to try to solve 2 problems.
please refer to https://lkml.org/lkml/2017/3/29/10
1) expose generic API for pci world clients to configure their
dma-ranges. right now there is none.
2) same API can be used by IOMMU to derive dma_mask.
while the current patch posted to handle dma-ranges for both memory
mapped and pci devices, which I think is overdoing.
besides we have different configuration of dma-ranges based on iommu
is enabled or not enabled.
#define PCIE_DMA_RANGES dma-ranges = <0x43000000 0x00 0x80000000 0x00
0x80000000 0x00 0x80000000 \
0x43000000 0x08 0x00000000 0x08
0x00000000 0x08 0x00000000 \
0x43000000 0x80 0x00000000 0x80
0x00000000 0x40 0x00000000>;
Not sure if this patch will consider above dma-ranges.
my suggestion is to leave existing of_dma_get_range as is, and have
new function for pci world as discussed in
please refer to https://lkml.org/lkml/2017/3/29/10
Regards,
Oza.
--
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 V11 2/6] thermal: of-thermal: Implement signed coefficient support
From: Eduardo Valentin @ 2017-03-29 4:52 UTC (permalink / raw)
To: Stefan Wahren
Cc: Zhang Rui, kernel-TqfNSX0MhmxHKSADF0wUEw, Eric Anholt,
Rob Herring, Frank Rowand, Florian Fainelli,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-pm-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1489356665-3175-3-git-send-email-stefan.wahren-eS4NqCHxEME@public.gmane.org>
Stefen,
On Sun, Mar 12, 2017 at 10:11:01PM +0000, Stefan Wahren wrote:
> Use the new function of_property_read_s32_array() to prepare
> of-thermal for negative coefficients. These are used by
> the upcoming bcm2835_thermal driver.
>
> Signed-off-by: Stefan Wahren <stefan.wahren-eS4NqCHxEME@public.gmane.org>
Once done with the comment pointed by Frank, you can add my
Reviewed-by: Eduardo Valentin <edubezval-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> drivers/thermal/of-thermal.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
> index d04ec3b..491d58a 100644
> --- a/drivers/thermal/of-thermal.c
> +++ b/drivers/thermal/of-thermal.c
> @@ -821,7 +821,8 @@ __init *thermal_of_build_thermal_zone(struct device_node *np)
> struct device_node *child = NULL, *gchild;
> struct __thermal_zone *tz;
> int ret, i;
> - u32 prop, coef[2];
> + u32 prop;
> + s32 coef[2];
>
> if (!np) {
> pr_err("no thermal zone np\n");
> @@ -851,7 +852,7 @@ __init *thermal_of_build_thermal_zone(struct device_node *np)
> * one sensor per thermal zone. Thus, we are considering
> * only the first two values as slope and offset.
> */
> - ret = of_property_read_u32_array(np, "coefficients", coef, 2);
> + ret = of_property_read_s32_array(np, "coefficients", coef, 2);
> if (ret == 0) {
> tz->slope = coef[0];
> tz->offset = coef[1];
> --
> 1.7.9.5
>
--
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: [RFC PATCH 1/3] of/pci: dma-ranges to account highest possible host bridge dma_mask
From: Oza Oza @ 2017-03-29 4:43 UTC (permalink / raw)
To: Robin Murphy
Cc: Rob Herring, Joerg Roedel, Linux IOMMU,
linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w@public.gmane.org
In-Reply-To: <de6bfedf-62aa-98e4-dae5-7862ab3ba754-5wv7dgnIgG8@public.gmane.org>
On Tue, Mar 28, 2017 at 7:59 PM, Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org> wrote:
> On 28/03/17 06:27, Oza Oza wrote:
>> On Mon, Mar 27, 2017 at 8:16 PM, Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>>> On Sat, Mar 25, 2017 at 12:31 AM, Oza Pawandeep <oza.oza-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
>>>> it is possible that PCI device supports 64-bit DMA addressing,
>>>> and thus it's driver sets device's dma_mask to DMA_BIT_MASK(64),
>>>> however PCI host bridge may have limitations on the inbound
>>>> transaction addressing. As an example, consider NVME SSD device
>>>> connected to iproc-PCIe controller.
>>>>
>>>> Currently, the IOMMU DMA ops only considers PCI device dma_mask
>>>> when allocating an IOVA. This is particularly problematic on
>>>> ARM/ARM64 SOCs where the IOMMU (i.e. SMMU) translates IOVA to
>>>> PA for in-bound transactions only after PCI Host has forwarded
>>>> these transactions on SOC IO bus. This means on such ARM/ARM64
>>>> SOCs the IOVA of in-bound transactions has to honor the addressing
>>>> restrictions of the PCI Host.
>>>>
>>>> current pcie frmework and of framework integration assumes dma-ranges
>>>> in a way where memory-mapped devices define their dma-ranges.
>>>> dma-ranges: (child-bus-address, parent-bus-address, length).
>>>>
>>>> but iproc based SOCs and even Rcar based SOCs has PCI world dma-ranges.
>>>> dma-ranges = <0x43000000 0x00 0x00 0x00 0x00 0x80 0x00>;
>>>
>>> If you implement a common function, then I expect to see other users
>>> converted to use it. There's also PCI hosts in arch/powerpc that parse
>>> dma-ranges.
>>
>> the common function should be similar to what
>> of_pci_get_host_bridge_resources is doing right now.
>> it parses ranges property right now.
>>
>> the new function would look look following.
>>
>> of_pci_get_dma_ranges(struct device_node *dev, struct list_head *resources)
>> where resources would return the dma-ranges.
>>
>> but right now if you see the patch, of_dma_configure calls the new
>> function, which actually returns the largest possible size.
>> so this new function has to be generic in a way where other PCI hosts
>> can use it. but certainly iproc(Broadcom SOC) , rcar based SOCs can
>> use it for sure.
>>
>> although having powerpc using it; is a separate exercise, since I do
>> not have any access to other PCI hosts such as powerpc. but we can
>> workout with them on thsi forum if required.
>>
>> so overall, of_pci_get_dma_ranges has to serve following 2 purposes.
>>
>> 1) it has to return largest possible size to of_dma_configure to
>> generate largest possible dma_mask.
>>
>> 2) it also has to return resources (dma-ranges) parsed, to the users.
>>
>> so to address above needs
>>
>> of_pci_get_dma_ranges(struct device_node *dev, struct list_head
>> *resources, u64 *size)
>>
>> dev -> device node.
>> resources -> dma-ranges in allocated list.
>> size -> highest possible size to generate possible dma_mask for
>> of_dma_configure.
>>
>> let em know how this sounds.
>
> Note that the point of passing PCI host bridges into of_dma_configure()
> in the first place was to avoid having some separate PCI-specific path
> for DMA configuration. I worry that introducing bus-specific dma-ranges
> parsing largely defeats that, since we end up with the worst of both
> worlds; effectively-duplicated code, and/or a load of extra complexity
> to then attempt to reconverge the divergent paths (there really
> shouldn't be any need to allocate a list of anything). Given that
> of_translate_dma_address() is already bus-agnostic, it hardly seems
> justifiable for its caller not to be so as well, especially when it
> mostly just comes down to getting the right #address-cells value.
>
> The patch below is actually enough to make typical cases work, but is
> vile, so I'm not seriously considering it (hence I've not bothered
> making IOMMU configuration handle all circumstances). What it has served
> to do, though, is give me a clear idea of how to properly sort out the
> not-quite-right device/parent assumptions between of_dma_configure() and
> of_dma_get_range() rather than bodging around them any further - stay tuned.
>
> Robin.
>
> ----->8-----
> From: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
> Subject: [PATCH] of/pci: Use child node for DMA configuration
>
> of_dma_configure() expects to be passed an OF node representing the
> device being configured - for PCI devices we currently pass the node of
> the appropriate host controller, which sort of works for inherited
> properties which may appear at any level, like "dma-coherent", but falls
> apart for properties which actually care about specific device-parent
> relationships, like "dma-ranges".
>
> Solve this by attempting to find a suitable child node if the PCI
> hierarchy is actually represented in DT, and if not then faking one up
> as a last resort, to make all of DMA configuration work as expected.
>
> Signed-off-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
> ---
> drivers/iommu/of_iommu.c | 3 ++-
> drivers/pci/of.c | 24 ++++++++++++++++++++++++
> drivers/pci/probe.c | 14 +++++++++++++-
> include/linux/pci.h | 3 +++
> 4 files changed, 42 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index 2683e9fc0dcf..35c97b945c15 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -146,7 +146,8 @@ const struct iommu_ops *of_iommu_configure(struct
> device *dev,
> int idx = 0;
>
> if (dev_is_pci(dev))
> - return of_pci_iommu_configure(to_pci_dev(dev), master_np);
> + return of_pci_iommu_configure(to_pci_dev(dev),
> + of_get_next_parent(master_np));
>
> /*
> * We don't currently walk up the tree looking for a parent IOMMU.
> diff --git a/drivers/pci/of.c b/drivers/pci/of.c
> index e112da11630e..96eece1c423d 100644
> --- a/drivers/pci/of.c
> +++ b/drivers/pci/of.c
> @@ -88,3 +88,27 @@ struct irq_domain
> *pci_host_bridge_of_msi_domain(struct pci_bus *bus)
> return NULL;
> #endif
> }
> +
> +struct device_node *pci_dev_get_dma_of_node(struct pci_dev *dev)
> +{
> + struct device_node *np;
> + struct pci_bus *bus = dev->bus;
> +
> + /* Is the device itself actually described in the DT? */
> + np = of_node_get(dev->dev.of_node);
> + if (np)
> + return np;
> +
> + /* Or is some intermediate bridge? That would do... */
> + for (bus = dev->bus; bus->parent; bus = bus->parent) {
> + np = of_node_get(bus->bridge->of_node);
> + if (np)
> + return np;
> + }
> +
> + /* Failing that, any child of the same host bridge? */
> + if (bus->bridge->parent)
> + np = of_get_next_child(bus->bridge->parent->of_node, NULL);
> +
> + return np;
> +}
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index dfc9a2794141..4f7ade64aa3e 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -1906,7 +1906,19 @@ static void pci_dma_configure(struct pci_dev *dev)
>
> if (IS_ENABLED(CONFIG_OF) &&
> bridge->parent && bridge->parent->of_node) {
> - of_dma_configure(&dev->dev, bridge->parent->of_node);
> + struct device_node *np, tmp = {0};
> +
> + np = pci_dev_get_dma_of_node(dev);
> + if (!np) {
> + np = &tmp;
> + of_node_set_flag(np, OF_DETACHED);
> + of_node_init(np);
> + tmp.parent = bridge->parent->of_node;
> + }
> +
> + of_dma_configure(&dev->dev, np);
> + if (np != &tmp)
> + of_node_put(np);
> } else if (has_acpi_companion(bridge)) {
> struct acpi_device *adev = to_acpi_device_node(bridge->fwnode);
> enum dev_dma_attr attr = acpi_get_dma_attr(adev);
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index eb3da1a04e6c..94ecd1817f58 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -2086,6 +2086,7 @@ void pci_release_of_node(struct pci_dev *dev);
> void pci_set_bus_of_node(struct pci_bus *bus);
> void pci_release_bus_of_node(struct pci_bus *bus);
> struct irq_domain *pci_host_bridge_of_msi_domain(struct pci_bus *bus);
> +struct device_node *pci_dev_get_dma_of_node(struct pci_dev *dev);
>
> /* Arch may override this (weak) */
> struct device_node *pcibios_get_phb_of_node(struct pci_bus *bus);
> @@ -2110,6 +2111,8 @@ static inline struct device_node *
> pci_device_to_OF_node(const struct pci_dev *pdev) { return NULL; }
> static inline struct irq_domain *
> pci_host_bridge_of_msi_domain(struct pci_bus *bus) { return NULL; }
> +static inline struct device_node *
> +pci_dev_get_dma_of_node(struct pci_dev *dev) { return NULL; }
> #endif /* CONFIG_OF */
>
> #ifdef CONFIG_ACPI
>
pci and memory mapped device world is different. of course if you talk
from iommu perspective, all the master are same for IOMMU
but the original intention of the patch is to try to solve 2 problems.
1) expose generic API for pci world clients to configure their
dma-ranges. right now there is none.
2) same API can be used by IOMMU to derive dma_mask.
the implementation tries to handle dma-ranges for both memory mapped
and pci devices, which I think is overkill.
besides we have different configuration of dma-ranges based on iommu
is enabled or not enabled.
#define PCIE_DMA_RANGES dma-ranges = <0x43000000 0x00 0x80000000 0x00
0x80000000 0x00 0x80000000 \
0x43000000 0x08 0x00000000 0x08
0x00000000 0x08 0x00000000 \
0x43000000 0x80 0x00000000 0x80
0x00000000 0x40 0x00000000>;
the of_dma_get_range is written with respect to traditional memory
ranges, they were not meant for pci dma-ranges.
Regards,
Oza.
--
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 v4 2/3] mailbox: Add iProc mailbox controller driver
From: Jassi Brar @ 2017-03-29 4:36 UTC (permalink / raw)
To: Jonathan Richardson
Cc: Rob Herring, Mark Rutland, Ray Jui, Scott Branden, Jon Mason,
Russell King, Vikram Prakash, Devicetree List,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
BCM Kernel Feedback
In-Reply-To: <0e8ac72a-6b2f-171d-41e7-7a6cefc4c7c4-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On Tue, Mar 28, 2017 at 11:00 PM, Jonathan Richardson
<jonathan.richardson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
> On 17-03-15 10:30 AM, Jassi Brar wrote:
>> The right way to do is have a 'server/owner' client that accepts
>> requests from various clients and serially queue them to mailbox. That
>> way you can keep the controller driver free from quirks (like max wait
>> time of 30us) of your present platform.
>
> Do you mean 1 mailbox client with one mailbox channel that all the mbox client drivers share?
> I thought this would work when I suggested it previously but the client callbacks are necessary
> in all txdone modes. Client drivers that send the messages need the callbacks
>
That's a legit requirement.
> and this is only possible with multiple mbox clients.
>
That is incorrect.
It is trivial to support callbacks to end clients from your common
code... just ask for callback along with the message to be submitted
to mailbox api.
> And a channel can only have 1 mbox client. Clients in multiple drivers need the callbacks to either know when to start polling, or be notified when the transaction is complete. It would be nice if multiple clients could use the same channel.
>
We had to choose from shared vs exclusive access to channels... latter
was chosen because there are ways to still support former.
--
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: vf610-zii-dev-rev-b: change switch2 label
From: Shawn Guo @ 2017-03-29 3:49 UTC (permalink / raw)
To: Vivien Didelot
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
kernel-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/, Florian Fainelli,
Andrew Lunn
In-Reply-To: <20170328192426.13798-1-vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/@public.gmane.org>
On Tue, Mar 28, 2017 at 03:24:26PM -0400, Vivien Didelot wrote:
> Rename the switch2@0 label of the switch2 node to switch@0 to respect
> the general unit@address DTS rule, and be consistent with the other
> switch nodes of the DTS file.
>
> Signed-off-by: Vivien Didelot <vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/@public.gmane.org>
Applied, thanks.
--
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: imx6qp-nitrogen6_som2: add Quad Plus variant of the SOM
From: Shawn Guo @ 2017-03-29 3:44 UTC (permalink / raw)
To: Gary Bisson
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, robh+dt-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <20170327160601.12871-1-gary.bisson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
On Mon, Mar 27, 2017 at 06:06:01PM +0200, Gary Bisson wrote:
> https://boundarydevices.com/product/nit6x-som-v2/
>
> Signed-off-by: Gary Bisson <gary.bisson-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
Please post to LAKML.
Shawn
> ---
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/imx6qp-nitrogen6_som2.dts | 55 +++++++++++++++++++++++++++++
> 2 files changed, 56 insertions(+)
> create mode 100644 arch/arm/boot/dts/imx6qp-nitrogen6_som2.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 011808490fed..6190afe94371 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -426,6 +426,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
> imx6q-wandboard.dtb \
> imx6q-wandboard-revb1.dtb \
> imx6qp-nitrogen6_max.dtb \
> + imx6qp-nitrogen6_som2.dtb \
> imx6qp-sabreauto.dtb \
> imx6qp-sabresd.dtb
> dtb-$(CONFIG_SOC_IMX6SL) += \
> diff --git a/arch/arm/boot/dts/imx6qp-nitrogen6_som2.dts b/arch/arm/boot/dts/imx6qp-nitrogen6_som2.dts
> new file mode 100644
> index 000000000000..011726c836cd
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6qp-nitrogen6_som2.dts
> @@ -0,0 +1,55 @@
> +/*
> + * Copyright 2017 Boundary Devices, Inc.
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include "imx6qp.dtsi"
> +#include "imx6qdl-nitrogen6_som2.dtsi"
> +
> +/ {
> + model = "Boundary Devices i.MX6 Quad Plus Nitrogen6_SOM2 Board";
> + compatible = "boundary,imx6qp-nitrogen6_som2", "fsl,imx6qp";
> +};
> +
> +&sata {
> + status = "okay";
> +};
> --
> 2.11.0
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 00/15] ARM: dts: i.MX6: Add lcdif/sound nodes on Engicam SOMs
From: Shawn Guo @ 2017-03-29 3:40 UTC (permalink / raw)
To: Jagan Teki
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Sascha Hauer, Fabio Estevam,
Matteo Lisi, Michael Trimarchi, Jagan Teki
In-Reply-To: <1490372330-5611-1-git-send-email-jagan-oRp2ZoJdM/RWk0Htik3J/w@public.gmane.org>
On Fri, Mar 24, 2017 at 09:48:35PM +0530, Jagan Teki wrote:
> Jagan Teki (15):
> ARM: dts: imx6ul-geam: Add backlight support for lcdif
> ARM: dts: imx6ul-isiot: Add backlight support for lcdif
> ARM: dts: imx6ul-isiot: Add imx6ul-isiot-common.dtsi
> ARM: dts: imx6ul-isiot: Add i2c nodes
> ARM: dts: imx6ul-isiot-common: Add touchscreen node
> ARM: dts: imx6ul-[geam|isiot]: Add sai2 node
Applied above ones.
Shawn
> ARM: dts: imx6ul-isiot: Add Sound card with codec node
> ARM: dts: imx6ul-geam: Add Sound card with codec node
> ARM: dts: imx6qdl-icore: Add Sound card with codec node
> ARM: dts: imx6dl-icore-rqs: Add sgtl5000 codec node
> ARM: dts: imx6qdl-icore-rqs: Replace codec 'lable: node@addr'
> ARM: dts: imx6dl-icore: Add LVDS support
> ARM: dts: imx6dl-icore: Add touchscreen node
> ARM: dts: imx6qdl-icore-rqs: Add CAN nodes
> ARM: dts: imx6ul-isiot: Add FEC node support
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 10/15] ARM: dts: imx6dl-icore-rqs: Add sgtl5000 codec node
From: Shawn Guo @ 2017-03-29 3:29 UTC (permalink / raw)
To: Jagan Teki
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Sascha Hauer, Fabio Estevam,
Matteo Lisi, Michael Trimarchi, Jagan Teki
In-Reply-To: <1490372330-5611-11-git-send-email-jagan-oRp2ZoJdM/RWk0Htik3J/w@public.gmane.org>
On Fri, Mar 24, 2017 at 09:48:45PM +0530, Jagan Teki wrote:
> From: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
>
> - Moved sound card node on imx6qdl-icore-rqs.dtsi
> - Added codec node in imx6dl-icore-rqs from imx6q-icore-rqs
>
> Cc: Shawn Guo <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Matteo Lisi <matteo.lisi-4s7YQHO/iPVBDgjK7y7TUQ@public.gmane.org>
> Cc: Michael Trimarchi <michael-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
> Signed-off-by: Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
> ---
> Changes for v2:
> - Newly added patch
>
> arch/arm/boot/dts/imx6dl-icore-rqs.dts | 11 +++++++++++
> arch/arm/boot/dts/imx6q-icore-rqs.dts | 13 -------------
> arch/arm/boot/dts/imx6qdl-icore-rqs.dtsi | 13 +++++++++++++
> 3 files changed, 24 insertions(+), 13 deletions(-)
>
> diff --git a/arch/arm/boot/dts/imx6dl-icore-rqs.dts b/arch/arm/boot/dts/imx6dl-icore-rqs.dts
> index cf42c2f..5b4c14c 100644
> --- a/arch/arm/boot/dts/imx6dl-icore-rqs.dts
> +++ b/arch/arm/boot/dts/imx6dl-icore-rqs.dts
> @@ -49,3 +49,14 @@
> model = "Engicam i.CoreM6 DualLite/Solo RQS Starter Kit";
> compatible = "engicam,imx6-icore-rqs", "fsl,imx6dl";
> };
> +
> +&i2c3 {
> + codec: sgtl5000@0a {
Why adding something that the following patch will change right away?
Shawn
> + compatible = "fsl,sgtl5000";
> + reg = <0x0a>;
> + clocks = <&clks IMX6QDL_CLK_CKO>;
> + VDDA-supply = <®_2p5v>;
> + VDDIO-supply = <®_3p3v>;
> + VDDD-supply = <®_1p8v>;
> + };
> +};
> diff --git a/arch/arm/boot/dts/imx6q-icore-rqs.dts b/arch/arm/boot/dts/imx6q-icore-rqs.dts
> index e451b4c..441a28e5 100644
> --- a/arch/arm/boot/dts/imx6q-icore-rqs.dts
> +++ b/arch/arm/boot/dts/imx6q-icore-rqs.dts
> @@ -47,19 +47,6 @@
> / {
> model = "Engicam i.CoreM6 Quad/Dual RQS Starter Kit";
> compatible = "engicam,imx6-icore-rqs", "fsl,imx6q";
> -
> - sound {
> - compatible = "fsl,imx-audio-sgtl5000";
> - model = "imx-audio-sgtl5000";
> - ssi-controller = <&ssi1>;
> - audio-codec = <&codec>;
> - audio-routing =
> - "MIC_IN", "Mic Jack",
> - "Mic Jack", "Mic Bias",
> - "Headphone Jack", "HP_OUT";
> - mux-int-port = <1>;
> - mux-ext-port = <4>;
> - };
> };
>
> &i2c3 {
> diff --git a/arch/arm/boot/dts/imx6qdl-icore-rqs.dtsi b/arch/arm/boot/dts/imx6qdl-icore-rqs.dtsi
> index 5fab5be..4032d38 100644
> --- a/arch/arm/boot/dts/imx6qdl-icore-rqs.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-icore-rqs.dtsi
> @@ -118,6 +118,19 @@
> clocks = <&clks IMX6QDL_CLK_LVDS2_GATE>;
> clock-names = "refclk";
> };
> +
> + sound {
> + compatible = "fsl,imx-audio-sgtl5000";
> + model = "imx-audio-sgtl5000";
> + ssi-controller = <&ssi1>;
> + audio-codec = <&codec>;
> + audio-routing =
> + "MIC_IN", "Mic Jack",
> + "Mic Jack", "Mic Bias",
> + "Headphone Jack", "HP_OUT";
> + mux-int-port = <1>;
> + mux-ext-port = <4>;
> + };
> };
>
> &clks {
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 07/15] ARM: dts: imx6ul-isiot: Add Sound card with codec node
From: Shawn Guo @ 2017-03-29 3:27 UTC (permalink / raw)
To: Jagan Teki
Cc: linux-arm-kernel, devicetree, linux-kernel, Sascha Hauer,
Fabio Estevam, Matteo Lisi, Michael Trimarchi, Jagan Teki
In-Reply-To: <1490372330-5611-8-git-send-email-jagan@openedev.com>
On Fri, Mar 24, 2017 at 09:48:42PM +0530, Jagan Teki wrote:
> From: Jagan Teki <jagan@amarulasolutions.com>
>
> Add support for Sound card and related codec(via i2c1) nodes
> on Engicam Is.IoT MX6UL variant module boards.
>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Matteo Lisi <matteo.lisi@engicam.com>
> Cc: Michael Trimarchi <michael@amarulasolutions.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
<snip>
> diff --git a/arch/arm/boot/dts/imx6ul-isiot.dtsi b/arch/arm/boot/dts/imx6ul-isiot.dtsi
> index ea30380..9648de9 100644
> --- a/arch/arm/boot/dts/imx6ul-isiot.dtsi
> +++ b/arch/arm/boot/dts/imx6ul-isiot.dtsi
> @@ -69,6 +69,35 @@
> 100>;
> default-brightness-level = <100>;
> };
> +
> + reg_1p8v: regulator-1p8v {
> + compatible = "regulator-fixed";
> + regulator-name = "1P8V";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + reg_3p3v: regulator-3p3v {
> + compatible = "regulator-fixed";
> + regulator-name = "3P3V";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + sound {
> + compatible = "fsl,imx-audio-sgtl5000";
> + model = "imx6ul-isiot-sgtl5000";
> + cpu-dai = <&sai2>;
> + audio-codec = <&sgtl5000>;
> + audio-routing =
> + "MIC_IN", "Mic Jack",
> + "Mic Jack", "Mic Bias",
> + "Headphone Jack", "HP_OUT";
> + };
Can you consider to use simple-audio-card bindings instead?
Shawn
> };
>
> &i2c1 {
> --
> 1.9.1
>
^ permalink raw reply
* Re: [PATCH v3 1/5] dt-bindings: Document STM32 IWDG bindings
From: Guenter Roeck @ 2017-03-29 3:15 UTC (permalink / raw)
To: Yannick Fertre, Wim Van Sebroeck, Rob Herring, Alexandre TORGUE,
Benjamin Gaignard, Maxime Coquelin
Cc: linux-watchdog-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Philippe Cornu,
Gabriel FERNANDEZ, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1490195083-25117-2-git-send-email-yannick.fertre-qxv4g6HH51o@public.gmane.org>
On 03/22/2017 08:04 AM, Yannick Fertre wrote:
> From: Yannick Fertre <yfertre.stm32-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> This adds documentation of device tree bindings for the STM32 IWDG
> (Independent WatchDoG).
>
> Change-Id: Idadacc806d00205fe9af2e8606af229b4b760558
Please drop.
> Signed-off-by: Yannick Fertre <yannick.fertre-qxv4g6HH51o@public.gmane.org>
> ---
> .../devicetree/bindings/watchdog/st,stm32-iwdg.txt | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.txt
>
> diff --git a/Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.txt b/Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.txt
> new file mode 100644
> index 0000000..036b040
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.txt
> @@ -0,0 +1,15 @@
> +STM32 Independent WatchDoG (IWDG)
> +---------------------------------
> +
> +Required properties:
> +- compatible: "st,stm32-iwdg"
> +- reg: physical base address and length of the registers set for the device
> +- clocks: must contain a single entry describing the clock input
> +
> +Example:
> +
> +iwdg@40003000 {
> + compatible = "st,stm32-iwdg";
> + reg = <0x40003000 0x400>;
> + clocks = <&clk_lsi>;
> +};
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 2/5] drivers: watchdog: Add STM32 IWDG driver
From: Guenter Roeck @ 2017-03-29 3:15 UTC (permalink / raw)
To: Yannick Fertre, Wim Van Sebroeck, Rob Herring, Alexandre TORGUE,
Benjamin Gaignard, Maxime Coquelin
Cc: linux-watchdog-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Philippe Cornu,
Gabriel FERNANDEZ, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1490195083-25117-3-git-send-email-yannick.fertre-qxv4g6HH51o@public.gmane.org>
On 03/22/2017 08:04 AM, Yannick Fertre wrote:
> This patch adds IWDG (Independent WatchDoG) support for STM32 platform.
>
> Change-Id: Iab218745fc25566f12558fae7f52e2f8c21db74e
No gerrit tags, please.
> Signed-off-by: Yannick FERTRE <yannick.fertre-qxv4g6HH51o@public.gmane.org>
> ---
> drivers/watchdog/Kconfig | 11 ++
> drivers/watchdog/Makefile | 1 +
> drivers/watchdog/stm32_iwdg.c | 289 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 301 insertions(+)
> create mode 100644 drivers/watchdog/stm32_iwdg.c
>
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 52a70ee..d9745a5 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -744,6 +744,17 @@ config ZX2967_WATCHDOG
> To compile this driver as a module, choose M here: the
> module will be called zx2967_wdt.
>
> +config STM32_WATCHDOG
> + tristate "STM32 Independent WatchDoG (IWDG) support"
> + depends on ARCH_STM32
> + select WATCHDOG_CORE
> + default y
> + help
> + Say Y here to include Watchdog timer support.
... for <pick your text>.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called stm32_iwdg.
> +
> # AVR32 Architecture
>
> config AT32AP700X_WDT
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index a2126e2..a35e423 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -84,6 +84,7 @@ obj-$(CONFIG_ATLAS7_WATCHDOG) += atlas7_wdt.o
> obj-$(CONFIG_RENESAS_WDT) += renesas_wdt.o
> obj-$(CONFIG_ASPEED_WATCHDOG) += aspeed_wdt.o
> obj-$(CONFIG_ZX2967_WATCHDOG) += zx2967_wdt.o
> +obj-$(CONFIG_STM32_WATCHDOG) += stm32_iwdg.o
>
> # AVR32 Architecture
> obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
> diff --git a/drivers/watchdog/stm32_iwdg.c b/drivers/watchdog/stm32_iwdg.c
> new file mode 100644
> index 0000000..507dfc4
> --- /dev/null
> +++ b/drivers/watchdog/stm32_iwdg.c
> @@ -0,0 +1,289 @@
> +/*
> + * Driver for STM32 Independent Watchdog
> + *
> + * Copyright (C) Yannick Fertre 2017
> + * Author: Yannick Fertre <yannick.fertre-qxv4g6HH51o@public.gmane.org>
> + *
> + * This driver is based on tegra_wdt.c
> + *
> + * License terms: GNU General Public License (GPL), version 2
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/watchdog.h>
> +
> +/* minimum watchdog trigger timeout, in seconds */
> +#define MIN_WDT_TIMEOUT 1
> +
> +/* IWDG registers */
> +#define IWDG_KR 0x00 /* Key register */
> +#define IWDG_PR 0x04 /* Prescaler Register */
> +#define IWDG_RLR 0x08 /* ReLoad Register */
> +#define IWDG_SR 0x0C /* Status Register */
> +#define IWDG_WINR 0x10 /* Windows Register */
> +
> +/* IWDG_KR register bit mask */
> +#define KR_KEY_RELOAD 0xAAAA /* reload counter enable */
> +#define KR_KEY_ENABLE 0xCCCC /* peripheral enable */
> +#define KR_KEY_EWA 0x5555 /* write access enable */
> +#define KR_KEY_DWA 0x0000 /* write access disable */
> +
> +/* IWDG_PR register bit values */
> +#define PR_4 0x00 /* prescaler set to 4 */
> +#define PR_8 0x01 /* prescaler set to 8 */
> +#define PR_16 0x02 /* prescaler set to 16 */
> +#define PR_32 0x03 /* prescaler set to 32 */
> +#define PR_64 0x04 /* prescaler set to 64 */
> +#define PR_128 0x05 /* prescaler set to 128 */
> +#define PR_256 0x06 /* prescaler set to 256 */
> +
> +/* IWDG_RLR register values */
> +#define RLR_MAX 0xFFF /* max value supported by reload register */
> +
> +/* IWDG_SR register bit mask */
> +#define FLAG_PVU BIT(0) /* Watchdog prescaler value update */
> +#define FLAG_RVU BIT(1) /* Watchdog counter reload value update */
> +
> +/* set timeout to 100000 us */
> +#define TIMEOUT_US 100000
> +#define SLEEP_US 1000
> +
> +struct stm32_iwdg {
> + struct watchdog_device wdd;
> + struct device *dev;
> + void __iomem *regs;
> + struct clk *clk;
> + unsigned int rate;
> +};
> +
> +static int heartbeat = MIN_WDT_TIMEOUT;
> +module_param(heartbeat, int, 0x0);
> +MODULE_PARM_DESC(heartbeat,
> + "Watchdog heartbeats in seconds. (default = "
> + __MODULE_STRING(WDT_HEARTBEAT) ")");
> +
> +static inline u32 reg_read(void __iomem *base, u32 reg)
> +{
> + return readl_relaxed(base + reg);
> +}
> +
> +static inline void reg_write(void __iomem *base, u32 reg, u32 val)
> +{
> + writel_relaxed(val, base + reg);
> +}
> +
> +static int stm32_iwdg_start(struct watchdog_device *wdd)
> +{
> + struct stm32_iwdg *wdt = watchdog_get_drvdata(wdd);
> + u32 val = FLAG_PVU | FLAG_RVU;
> + u32 reload;
> + int ret;
> +
> + dev_dbg(wdt->dev, "%s\n", __func__);
> +
> + /* prescaler fixed to 256 */
> + reload = (wdd->timeout * wdt->rate) / 256;
> + if (reload > RLR_MAX + 1) {
> + dev_err(wdt->dev,
> + "Watchdog doesn't support reload value: %d\n", reload);
> + return -EINVAL;
> + }
This should not happen if min_timeout and max_timeout are set properly.
> +
> + /* enable watchdog */
> + reg_write(wdt->regs, IWDG_KR, KR_KEY_ENABLE);
> +
> + /* set prescaler & reload registers */
> + reg_write(wdt->regs, IWDG_KR, KR_KEY_EWA);
> + reg_write(wdt->regs, IWDG_PR, PR_256); /* prescaler fix to 256 */
> + reg_write(wdt->regs, IWDG_RLR, reload - 1);
> +
> + /* wait for the registers to be updated (max 100ms) */
> + ret = readl_relaxed_poll_timeout(wdt->regs + IWDG_SR, val,
> + !(val & (FLAG_PVU | FLAG_RVU)),
> + SLEEP_US, TIMEOUT_US);
> + if (ret) {
> + dev_err(wdt->dev,
> + "Fail to set prescaler or reload registers\n");
> + return -EINVAL;
Any reason for overriding the return value ?
> + }
> +
> + /* reload watchdog */
> + reg_write(wdt->regs, IWDG_KR, KR_KEY_RELOAD);
> +
> + return 0;
> +}
> +
> +static int stm32_iwdg_stop(struct watchdog_device *wdd)
> +{
> + struct stm32_iwdg *wdt = watchdog_get_drvdata(wdd);
> +
> + if (watchdog_active(wdd)) {
> + dev_err(wdt->dev,
> + "Watchdog can't be stopped once started(no way out)\n");
> + return -EPERM;
The infrastructure takes care of this. Don't provide a stop function, and provide
the maximum hardware timeout.
> + }
> +
> + return 0;
> +}
> +
> +static int stm32_iwdg_ping(struct watchdog_device *wdd)
> +{
> + struct stm32_iwdg *wdt = watchdog_get_drvdata(wdd);
> +
> + dev_dbg(wdt->dev, "%s\n", __func__);
> +
> + reg_write(wdt->regs, IWDG_KR, KR_KEY_RELOAD);
> +
> + return 0;
> +}
> +
> +static int stm32_iwdg_set_timeout(struct watchdog_device *wdd,
> + unsigned int timeout)
> +{
> + struct stm32_iwdg *wdt = watchdog_get_drvdata(wdd);
> +
> + dev_dbg(wdt->dev, "%s timeout: %d sec\n", __func__, timeout);
> +
> + wdd->timeout = timeout;
> +
> + if (watchdog_active(wdd))
> + return stm32_iwdg_start(wdd);
> +
> + return 0;
> +}
> +
> +static const struct watchdog_info stm32_iwdg_info = {
> + .options = WDIOF_SETTIMEOUT |
> + WDIOF_MAGICCLOSE |
> + WDIOF_KEEPALIVEPING,
> + .identity = "STM32 Independent Watchdog",
> +};
> +
> +static struct watchdog_ops stm32_iwdg_ops = {
> + .owner = THIS_MODULE,
> + .start = stm32_iwdg_start,
> + .stop = stm32_iwdg_stop,
> + .ping = stm32_iwdg_ping,
> + .set_timeout = stm32_iwdg_set_timeout,
> +};
> +
> +static int stm32_iwdg_probe(struct platform_device *pdev)
> +{
> + struct watchdog_device *wdd;
> + struct stm32_iwdg *wdt;
> + struct resource *res;
> + void __iomem *regs;
> + struct clk *clk;
> + int max_wdt_timeout;
> + int ret;
> +
> + /* This is the timer base. */
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + regs = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(regs)) {
> + dev_err(&pdev->dev, "Could not get resource\n");
> + return PTR_ERR(regs);
> + }
> +
> + clk = devm_clk_get(&pdev->dev, NULL);
> + if (IS_ERR(clk)) {
> + dev_err(&pdev->dev, "Unable to get clock\n");
> + return PTR_ERR(clk);
> + }
> +
> + ret = clk_prepare_enable(clk);
> + if (ret) {
> + dev_err(&pdev->dev, "Unable to prepare clock %p\n", clk);
> + return ret;
> + }
> +
> + /*
> + * Allocate our watchdog driver data, which has the
> + * struct watchdog_device nested within it.
> + */
> + wdt = devm_kzalloc(&pdev->dev, sizeof(*wdt), GFP_KERNEL);
> + if (!wdt) {
> + ret = -ENOMEM;
> + goto err;
> + }
> +
> + /* Initialize struct stm32_iwdg. */
> + wdt->regs = regs;
> + wdt->dev = &pdev->dev;
> + wdt->clk = clk;
> + /*
> + * iwdg is clocked by its own dedicated low-speed clock (LSI)
> + * at 32khz.
> + */
> + wdt->rate = 32 * 1024;
Why not clk_get_rate() ?
> +
> + /* get max timeout & set heartbeat */
> + max_wdt_timeout = ((RLR_MAX + 1) * 256) / wdt->rate;
> + heartbeat = max_wdt_timeout;
What is the value of overwriting this variable ? Why don't you just use max_wdt_timeout,
and what is the point of making heartbeat configurable if you overwrite it anyway ?
I would suggest to use watchdog_init_timeout() to set optional non-default
timeout values, especially since this also enables getting the timeout value from
devicetree.
> +
> + /* Initialize struct watchdog_device. */
> + wdd = &wdt->wdd;
> + wdd->timeout = heartbeat;
> + wdd->info = &stm32_iwdg_info;
> + wdd->ops = &stm32_iwdg_ops;
> + wdd->min_timeout = MIN_WDT_TIMEOUT;
> + wdd->max_timeout = max_wdt_timeout;
You might want to consider setting max_hw_heartbeat_ms instead and drop the stop function.
> + watchdog_set_drvdata(wdd, wdt);
> + watchdog_set_nowayout(wdd, true);
> +
> + ret = watchdog_register_device(wdd);
> + if (ret) {
> + dev_err(&pdev->dev,
> + "failed to register watchdog device\n");
> + goto err;
> + }
> +
> + platform_set_drvdata(pdev, wdt);
> +
> + dev_info(&pdev->dev,
> + "initialized (heartbeat = %d sec)\n", heartbeat);
> + return 0;
> +
> +err:
> + clk_disable_unprepare(clk);
> + return ret;
> +}
> +
> +static int stm32_iwdg_remove(struct platform_device *pdev)
> +{
> + struct stm32_iwdg *wdt = platform_get_drvdata(pdev);
> +
> + watchdog_unregister_device(&wdt->wdd);
> + clk_disable_unprepare(wdt->clk);
> +
> + dev_info(&pdev->dev, "removed watchdog device\n");
Is this message really useful ? I think it is just noise.
> + return 0;
> +}
> +
> +static const struct of_device_id stm32_iwdg_of_match[] = {
> + { .compatible = "st,stm32-iwdg" },
> + { /* end node */ }
> +};
> +MODULE_DEVICE_TABLE(of, stm32_iwdg_of_match);
> +
> +static struct platform_driver stm32_iwdg_driver = {
> + .probe = stm32_iwdg_probe,
> + .remove = stm32_iwdg_remove,
> + .driver = {
> + .name = "iwdg",
> + .of_match_table = stm32_iwdg_of_match,
> + },
> +};
> +module_platform_driver(stm32_iwdg_driver);
> +
> +MODULE_AUTHOR("Yannick Fertre <yannick.fertre-qxv4g6HH51o@public.gmane.org>");
> +MODULE_DESCRIPTION("STMicroelectronics STM32 Independent Watchdog Driver");
> +MODULE_LICENSE("GPL v2");
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 6/9] coresight: add support for CPU debug module
From: Leo Yan @ 2017-03-29 3:07 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: Jonathan Corbet, Rob Herring, Mark Rutland, Wei Xu,
Catalin Marinas, Will Deacon, Andy Gross, David Brown,
Michael Turquette, Stephen Boyd, Mathieu Poirier, Guodong Xu,
John Stultz, linux-doc, linux-kernel, devicetree,
linux-arm-kernel, linux-arm-msm, linux-soc, linux-clk, mike.leach,
sudeep.holla
In-Reply-To: <31be033f-514e-e48a-3ba2-a5c5cd477548@arm.com>
Hi Suzuki,
On Mon, Mar 27, 2017 at 05:34:57PM +0100, Suzuki K Poulose wrote:
> On 25/03/17 18:23, Leo Yan wrote:
[...]
> Leo,
>
> Thanks a lot for the quick rework. I don't fully understand (yet!) why we need the
> idle_constraint. I will leave it for Sudeep to comment on it, as he is the expert
> in that area. Some minor comments below.
Thanks a lot for quick reviewing :)
> >Signed-off-by: Leo Yan <leo.yan@linaro.org>
> >---
> > drivers/hwtracing/coresight/Kconfig | 11 +
> > drivers/hwtracing/coresight/Makefile | 1 +
> > drivers/hwtracing/coresight/coresight-cpu-debug.c | 704 ++++++++++++++++++++++
> > 3 files changed, 716 insertions(+)
> > create mode 100644 drivers/hwtracing/coresight/coresight-cpu-debug.c
> >
> >diff --git a/drivers/hwtracing/coresight/Kconfig b/drivers/hwtracing/coresight/Kconfig
> >index 130cb21..18d7931 100644
> >--- a/drivers/hwtracing/coresight/Kconfig
> >+++ b/drivers/hwtracing/coresight/Kconfig
> >@@ -89,4 +89,15 @@ config CORESIGHT_STM
> > logging useful software events or data coming from various entities
> > in the system, possibly running different OSs
> >
> >+config CORESIGHT_CPU_DEBUG
> >+ tristate "CoreSight CPU Debug driver"
> >+ depends on ARM || ARM64
> >+ depends on DEBUG_FS
> >+ help
> >+ This driver provides support for coresight debugging module. This
> >+ is primarily used to dump sample-based profiling registers when
> >+ system triggers panic, the driver will parse context registers so
> >+ can quickly get to know program counter (PC), secure state,
> >+ exception level, etc.
>
> May be we should mention/warn the user about the possible caveats of using
> this feature to help him make a better decision ? And / Or we should add a documentation
> for it. We have collected some real good information over the discussions and
> it is a good idea to capture it somewhere.
Sure, I will add a documentation for this.
[...]
> >+static struct pm_qos_request debug_qos_req;
> >+static int idle_constraint = PM_QOS_DEFAULT_VALUE;
> >+module_param(idle_constraint, int, 0600);
> >+MODULE_PARM_DESC(idle_constraint, "Latency requirement in microseconds for CPU "
> >+ "idle states (default is -1, which means have no limiation "
> >+ "to CPU idle states; 0 means disabling all idle states; user "
> >+ "can choose other platform dependent values so can disable "
> >+ "specific idle states for the platform)");
>
> Correct me if I am wrong,
>
> All we want to do is disable the CPUIdle explicitly if the user knows that this
> could be a problem to use CPU debug on his platform. So, in effect, we should
> only be using idle_constraint = 0 or -1.
>
> In which case, we could make it easier for the user to tell us, either
>
> 0 - Don't do anything with CPUIdle (default)
> 1 - Disable CPUIdle for me as I know the platform has issues with CPU debug and CPUidle.
The reason for not using bool flag is: usually SoC may have many idle
states, so if user wants to partially enable some states then can set
the latency to constraint.
But of course, we can change this to binary value as you suggested,
this means turn on of turn off all states. The only one reason to use
latency value is it is more friendly for hardware design, e.g. some
platforms can enable partial states to save power and avoid overheat
after using this driver.
If you guys think this is a bit over design, I will follow up your
suggestion. I also have some replying in Mathieu's reviewing, please
help review as well.
> than explaining the miscrosecond latency etc and make the appropriate calls underneath.
> something like (not necessarily the same name) :
>
> module_param(broken_with_cpuidle, bool, 0600);
> MODULE_PARAM_DESC(broken_with_cpuidle, "Specifies whether the CPU debug has issues with CPUIdle on"
> " the platform. Non-zero value implies CPUIdle has to be"
> " explicitly disabled.",);
[...]
> >+ /*
> >+ * Unfortunately the CPU cannot be powered up, so return
> >+ * back and later has no permission to access other
> >+ * registers. For this case, should set 'idle_constraint'
> >+ * to ensure CPU power domain is enabled!
> >+ */
> >+ if (!(drvdata->edprsr & EDPRSR_PU)) {
> >+ pr_err("%s: power up request for CPU%d failed\n",
> >+ __func__, drvdata->cpu);
> >+ goto out;
> >+ }
> >+
> >+out_powered_up:
> >+ debug_os_unlock(drvdata);
>
> Question: Do we need a matching debug_os_lock() once we are done ?
I have checked ARM ARMv8, but there have no detailed description for
this. I refered coresight-etmv4 code and Mike's pseudo code, ther have
no debug_os_lock() related operations.
Mike, Mathieu, could you also help confirm this?
[...]
> >+static void debug_init_arch_data(void *info)
> >+{
> >+ struct debug_drvdata *drvdata = info;
> >+ u32 mode, pcsr_offset;
> >+
> >+ CS_UNLOCK(drvdata->base);
> >+
> >+ debug_os_unlock(drvdata);
> >+
> >+ /* Read device info */
> >+ drvdata->eddevid = readl_relaxed(drvdata->base + EDDEVID);
> >+ drvdata->eddevid1 = readl_relaxed(drvdata->base + EDDEVID1);
>
> As mentioned above, both of these registers are only need at init time to
> figure out the flags we set here. So we could remove them.
>
> >+
> >+ CS_LOCK(drvdata->base);
> >+
> >+ /* Parse implementation feature */
> >+ mode = drvdata->eddevid & EDDEVID_PCSAMPLE_MODE;
> >+ pcsr_offset = drvdata->eddevid1 & EDDEVID1_PCSR_OFFSET_MASK;
>
>
> >+
> >+ if (mode == EDDEVID_IMPL_NONE) {
> >+ drvdata->edpcsr_present = false;
> >+ drvdata->edcidsr_present = false;
> >+ drvdata->edvidsr_present = false;
> >+ } else if (mode == EDDEVID_IMPL_EDPCSR) {
> >+ drvdata->edpcsr_present = true;
> >+ drvdata->edcidsr_present = false;
> >+ drvdata->edvidsr_present = false;
> >+ } else if (mode == EDDEVID_IMPL_EDPCSR_EDCIDSR) {
> >+ if (!IS_ENABLED(CONFIG_64BIT) &&
> >+ (pcsr_offset == EDDEVID1_PCSR_NO_OFFSET_DIS_AARCH32))
> >+ drvdata->edpcsr_present = false;
> >+ else
> >+ drvdata->edpcsr_present = true;
>
> Sorry, I forgot why we do this check only in this mode. Shouldn't this be
> common to all modes (of course which implies PCSR is present) ?
No. PCSROffset is defined differently in ARMv7 and ARMv8; So finally we
simplize PCSROffset value :
0000 - Sample offset applies based on the instruction state (indicated by PCSR[0])
0001 - No offset applies.
0010 - No offset applies, but do not use in AArch32 mode!
So we need handle the corner case is when CPU runs AArch32 mode and
PCSRoffset = 'b0010. Other cases the pcsr should be present.
[...]
Other suggestions are good for me, will take them in next version.
Thanks,
Leo Yan
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: ls1012a: add crypto node
From: Shawn Guo @ 2017-03-29 3:04 UTC (permalink / raw)
To: Horia Geantă
Cc: Rob Herring, Mark Rutland, devicetree, Herbert Xu, Harninder Rai,
Catalin Marinas, Bhaskar Upadhaya, Will Deacon, Dan Douglass,
linux-crypto, David S. Miller, linux-arm-kernel
In-Reply-To: <20170328114619.16568-1-horia.geanta@nxp.com>
On Tue, Mar 28, 2017 at 02:46:19PM +0300, Horia Geantă wrote:
> LS1012A has a SEC v5.4 security engine.
>
> Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v3 0/5] STM32 Independant watchdog
From: Guenter Roeck @ 2017-03-29 3:00 UTC (permalink / raw)
To: Yannick Fertre, Wim Van Sebroeck, Rob Herring, Alexandre TORGUE,
Benjamin Gaignard, Maxime Coquelin
Cc: linux-watchdog-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Philippe Cornu,
Gabriel FERNANDEZ, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1490195083-25117-1-git-send-email-yannick.fertre-qxv4g6HH51o@public.gmane.org>
Subject: s/Independant/Independent/
On 03/22/2017 08:04 AM, Yannick Fertre wrote:
> Version 3:
> - Update typo into bindings file
> - Reorder node in devicetree (ordering by address)
> - Remove unecessary lines in commits
>
> Version 2:
> - Add commit messages
>
> Version 1:
> - Initial commit
>
> The purpose of this set of patches is to add a new watchdog driver for
> stm32f429.
> This driver was developed and tested on evaluation board stm32429i.
>
> Yannick Fertre (5):
> dt-bindings: Document STM32 IWDG bindings
> drivers: watchdog: Add STM32 IWDG driver
> ARM: dts: stm32: Add watchdog support for STM32F429 SoC
> ARM: dts: stm32: Add watchdog support for STM32F429 eval board
> ARM: configs: Add watchdog support in STM32 defconfig
>
> .../devicetree/bindings/watchdog/st,stm32-iwdg.txt | 15 ++
> arch/arm/boot/dts/stm32429i-eval.dts | 4 +
> arch/arm/boot/dts/stm32f429.dtsi | 9 +-
> arch/arm/configs/stm32_defconfig | 1 +
> drivers/watchdog/Kconfig | 11 +
> drivers/watchdog/Makefile | 1 +
> drivers/watchdog/stm32_iwdg.c | 289 +++++++++++++++++++++
> 7 files changed, 329 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.txt
> create mode 100644 drivers/watchdog/stm32_iwdg.c
>
--
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] auxdisplay: hd44780: Fix DT properties to include units of measurement
From: Rob Herring @ 2017-03-29 2:34 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Greg Kroah-Hartman, Willy Tarreau, Miguel Ojeda Sandonis,
Mark Rutland, Ksenija Stanojevic, Arnd Bergmann,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1490275537-3769-1-git-send-email-geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
On Thu, Mar 23, 2017 at 02:25:37PM +0100, Geert Uytterhoeven wrote:
> DT properties specifying physical properties should contain appropriate
> suffices indicating the units of measurement.
>
> Hence amend the HD44780 DT bindings to add "chars" suffixes to the
> "display-height" and "display-width" properties, and update the driver
> to parse them.
>
> Fixes: dd9502a9e9156dd8 ("dt-bindings: auxdisplay: Add bindings for Hitachi HD44780")
> Fixes: d47d88361feea2ce ("auxdisplay: Add HD44780 Character LCD support")
> Signed-off-by: Geert Uytterhoeven <geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
> ---
> Against char-misc-next
>
> Documentation/devicetree/bindings/auxdisplay/hit,hd44780.txt | 11 ++++++-----
> drivers/auxdisplay/hd44780.c | 5 +++--
> 2 files changed, 9 insertions(+), 7 deletions(-)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v5 1/2] Documentation: dt-bindings: Document bindings for Aspeed ADC
From: Joel Stanley @ 2017-03-29 2:33 UTC (permalink / raw)
To: Rick Altherr
Cc: OpenBMC Maillist, Linux Kernel Mailing List,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA, Hartmut Knaack, Rob Herring,
Lars-Peter Clausen, Mark Rutland, Jonathan Cameron,
Peter Meerwald-Stadler
In-Reply-To: <20170328215259.31622-1-raltherr-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
On Wed, Mar 29, 2017 at 8:22 AM, Rick Altherr <raltherr-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:
> Signed-off-by: Rick Altherr <raltherr-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
> ---
Acked-by: Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>
>
> Changes in v5: None
> Changes in v4: None
> Changes in v3:
> - Consistently write hex contstants with lowercase letters
> - Drop model numbers from description as same IP is used in every generation
>
> Changes in v2:
> - Rewritten as an IIO ADC device
>
> .../devicetree/bindings/iio/adc/aspeed_adc.txt | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/aspeed_adc.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/aspeed_adc.txt b/Documentation/devicetree/bindings/iio/adc/aspeed_adc.txt
> new file mode 100644
> index 000000000000..674e133b7cd7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/aspeed_adc.txt
> @@ -0,0 +1,20 @@
> +Aspeed ADC
> +
> +This device is a 10-bit converter for 16 voltage channels. All inputs are
> +single ended.
> +
> +Required properties:
> +- compatible: Should be "aspeed,ast2400-adc" or "aspeed,ast2500-adc"
> +- reg: memory window mapping address and length
> +- clocks: Input clock used to derive the sample clock. Expected to be the
> + SoC's APB clock.
> +- #io-channel-cells: Must be set to <1> to indicate channels are selected
> + by index.
> +
> +Example:
> + adc@1e6e9000 {
> + compatible = "aspeed,ast2400-adc";
> + reg = <0x1e6e9000 0xb0>;
> + clocks = <&clk_apb>;
> + #io-channel-cells = <1>;
> + };
> --
> 2.12.2.564.g063fe858b8-goog
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/7] dt-bindings: pinctrl: Add RZ/A1 bindings doc
From: Linus Walleij @ 2017-03-29 2:30 UTC (permalink / raw)
To: jacopo
Cc: Geert Uytterhoeven, Jacopo Mondi, Geert Uytterhoeven,
Laurent Pinchart, Chris Brandt, Rob Herring, Mark Rutland,
Russell King, Linux-Renesas, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <b9eaac8a63dced229bb152ba412e8ec1@jmondi.org>
On Tue, Mar 28, 2017 at 4:38 PM, <jacopo@jmondi.org> wrote:
>> The fact that historically all the early adopters of pinctrl in device
>> tree
>> have these funky custom bindings is unfortunate but just something
>> that we need to live with.
>>
>
> To avoid any confusion, please bear with me and clarify this once and for
> all,
> since I'm not certain I fully got you here.
>
> Are you suggesting:
>
> 1) Use "pins" property with the currently implemented ABI (which slightly
> differs
> from the standard documented one as explained above. Not sure it is fine
> overriding
> it or not)
Correction: you should be using the property "pinmux", because you
are setting group and function at the same time.
See for example:
include/dt-bindings/pinctrl/mt65xx.h
And how that is used in:
arch/arm/boot/dts/mt2701-pinfunc.h
arch/arm/boot/dts/mt2701-evb.dts
The docs are here:
Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt
I'm sorry that "pinmux" is not part of the generic documentation, it'd be
great if you would like to add it with a patch.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 2/2] DT: leds: Add Qualcomm Light Pulse Generator binding
From: Rob Herring @ 2017-03-29 2:26 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Richard Purdie, Jacek Anaszewski, Pavel Machek, Mark Rutland,
linux-leds-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170323055435.29197-2-bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On Wed, Mar 22, 2017 at 10:54:35PM -0700, Bjorn Andersson wrote:
> This adds the binding document describing the three hardware blocks
> related to the Light Pulse Generator found in a wide range of Qualcomm
> PMICs.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> .../devicetree/bindings/leds/leds-qcom-lpg.txt | 194 +++++++++++++++++++++
> 1 file changed, 194 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/leds/leds-qcom-lpg.txt
>
> diff --git a/Documentation/devicetree/bindings/leds/leds-qcom-lpg.txt b/Documentation/devicetree/bindings/leds/leds-qcom-lpg.txt
> new file mode 100644
> index 000000000000..fb9edd89119d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/leds-qcom-lpg.txt
> @@ -0,0 +1,194 @@
> +Binding for Qualcomm Light Pulse Generator
> +
> +The Qualcomm Light Pulse Generator consists of three different hardware blocks;
> +a ramp generator with lookup table, the light pulse generator and a three
> +channel current sink. These blocks are found in a wide range of Qualcomm PMICs.
> +Each of these are described individually below.
> +
> += Lookup Table (LUT)
> +
> +- compatible:
> + Usage: required
> + Value type: <stringlist>
> + Definition: must be "qcom,spmi-lpg-lut"
> +
> +- reg:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: base address of the LUT block
> +
> +- qcom,lut-size:
> + Usage: required
> + Value type: <u32>
> + Definition: number of elements available in the lookup table
> +
> += Light Pulse Generator (LPG)
> +The Light Pulse Generator can operate either as a standard PWM controller or in
> +a more advanced lookup-table based mode. These are described separately below.
> +
> +- compatible:
> + Usage: required
> + Value type: <stringlist>
> + Definition: must be "qcom,spmi-lpg"
> +
> +- reg:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: base address of the LPG block
> +
> +== PWM mode
> +
> +- #pwm-cells:
> + Usage: required
> + Value type: <u32>
> + Definition: must be 1
> +
> +== Lookup-table mode
> +
> +- cell-index:
This is a standard though not used property name. Perhaps "reg" or a
vendor property instead.
> + Usage: required, when referencing a LUT
> + Value type: <u32>
> + Definition: id of the LPG, used to associate the LPG with a particular
> + ramp generator in the LUT block
> +
> +- default-state:
> + Usage: optional
> + Value type: <string>
> + Definition: default state, as defined in common.txt
> +
> +- label:
> + Usage: optional
> + Value type: <string>
> + Definition: label of the LED, as defined in common.txt
> +
> +- linux,default-trigger:
> + Usage: optional
> + Value type: <string>
> + Definition: default trigger, as defined in common.txt
> +
> +- qcom,tri-led:
> + Usage: optional
> + Value type: <prop-encoded-array>
> + Definition: a phandle of a TRILED node and a single u32 denoting which
> + output channel to control
> +
> +- qcom,lut:
> + Usage: optional
> + Value type: <prop-encoded-array>
> + Definition: phandle of a LUT node
> +
> +- qcom,dtest:
> + Usage: optional
> + Value type: <prop-encoded-array>
> + Definition: configures the output into an internal test line of the
> + pmic. A first u32 defines which test line to use and the
> + second cell configures how the value should be outputed
> + (available lines and configuration differs between PMICs)
> +
> +- qcom,pattern:
> + Usage: optional
> + Value type: <u16-list>
> + Definition: list of 16 bit duty cycle values to make up the pattern to
> + be programmed into the LUT. Values should be in the range
> + [0,512).
> +
> +- qcom,pattern-length-ms:
> + Usage: optional
> + Value type: <u32>
> + Definition: duration, in milliseconds, of the ramp generator running
> + one pass over the defined pattern
> +
> +- qcom,pattern-pause-lo-ms:
> + Usage: optional
> + Value type: <u32>
> + Definition: duration, in milliseconds, for the ramp generator to pause
> + before iterating over the pattern
> +
> +- qcom,pattern-pause-hi-ms:
> + Usage: optional
> + Value type: <u32>
> + Definition: duration, in milliseconds, for the ramp generator to pause
> + after iterating over the pattern
> +
> +- qcom,pattern-ping-pong:
> + Usage: optional
> + Value type: <boolean>
> + Definition: denotes that the ramp generator should reverse direction
> + when reaching the end of the pattern, instead of wrapping
> + to the beginning
> +
> +- qcom,pattern-oneshot:
> + Usage: optional
> + Value type: <boolean>
> + Definition: denotes that the ramp generator should stop after a single
> + pass over the pattern
> +
> +- qcom,pattern-reverse:
> + Usage: optional
> + Value type: <boolean>
> + Definition: denotes that the ramp generator should operate backwards
> + over the pattern
The pattern related properties should be common if we put them in DT
which I think is debatable.
> +
> += LED Current Sink (TRILED)
> +
> +- compatible:
> + Usage: required
> + Value type: <stringlist>
> + Definition: must be "qcom,spmi-tri-led"
> +
> +- reg:
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: base address of the TRILED block
> +
> +- qcom,power-source:
> + Usage: required
> + Value type: <u32>
> + Definition: power-source used to drive the output, as defined in the
> + datasheet
> +
> += EXAMPLE:
> +The following example defines a single output of the PMI8994, sinking current
> +into a LED in a natural pulsating pattern:
> +
> +&spmi_bus {
> + pmic@3 {
> + compatible = "qcom,pmi8994", "qcom,spmi-pmic";
typo.
> + reg = <0x3 SPMI_USID>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + pmi8994_lpg_lut: lpg-lut@b000 {
> + compatible = "qcom,spmi-lpg-lut";
> + reg = <0xb000>;
> +
> + qcom,lut-size = <24>;
> + };
> +
> + lpg@b200 {
> + compatible = "qcom,spmi-lpg";
> + reg = <0xb200>;
> +
> + cell-index = <2>;
> +
> + label = "lpg:green:user0";
> +
> + qcom,tri-led = <&pmi8994_tri_led 1>;
> + qcom,lut = <&pmi8994_lpg_lut>;
> +
> + qcom,pattern = /bits/ 16 <9 20 42 86 158 256 353
> + 425 469 491 502 507>;
> + qcom,pattern-length-ms = <1337>;
> + qcom,pattern-ping-pong;
> +
> + default-state = "on";
> + };
> +
> + pmi8994_tri_led: tri-led@d000 {
It may make more sense to make the LED(s) and their properties a sub
node of this. You could always use the PWM binding to link back to the
LPG. The pattern/LUT is really just a queue of PWM settings. That's not
all that different than a PWM based audio buzzer. There was a DMA based
PWM binding the other day for audio.
Rob
> + compatible = "qcom,spmi-tri-led";
> + reg = <0xd000>;
> +
> + qcom,power-source = <1>;
> + };
> + };
> +};
> --
> 2.12.0
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 5/7] pinctrl: aramda-37xx: Add irqchip support
From: Linus Walleij @ 2017-03-29 2:18 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Nadav Haklai, Victor Gu, Marcin Wojtas, Wilson Ding, Hua Jing,
Neta Zur Hershkovits
In-Reply-To: <87mvc5a3hh.fsf-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Tue, Mar 28, 2017 at 4:19 PM, Gregory CLEMENT
<gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> On mar., mars 28 2017, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> What you're doing is mocking around with core irqchip semantics.
>> Is ->mask really supposed to be played around with from the outsid
>> like this?
>
> According to the documentation mask is a "precomputed bitmask for
> accessing the chip registers" and it is exactly the way it is used in
> this driver.
>
> Moreover, currently ->mask is only used by the generic irqchip framework
> and not by the core of the irqchip subsystem. So the mask initialization
> is not done from the oustide but at the same level as the generic
> irqchip which is not used here.
OK excellent, sorry for my ignorance. We should rather point to your driver
as a good example of how to do this. Care to add some few lines of comment
as to what is going on for others that need to do the same?
Actually it would even be good to have something in
Documentation/gpio/driver.txt
>> It has irq_create_mapping(gpiochip->irqdomain, offset); that get
>> called for every IRQ, and that will eventually call irq_of_parse_and_map()
>> if the IRQs are defined in the device tree. (IIRC)
>
> When I followed the functions called I never find a call to
> irq_of_parse_and_map(), the closer things related to device tree I found
> was:
> "virq = irq_domain_alloc_descs(-1, 1, hwirq, of_node_to_nid(of_node),
> NULL);"
> http://elixir.free-electrons.com/source/kernel/irq/irqdomain.c?v=4.11-rc4#L507
I don't know if I'm rambling or what. I'm pretty sure it gets called, maybe
even earlier, like when the DT is parsed for the platform. We have so many
drivers not seemingly needing this, but if your driver needs it, all others
may need to be fixed too.
Can you put a print in irq_of_parse_and_map() and see what happens?
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] leds: Add driver for Qualcomm LPG
From: Rob Herring @ 2017-03-29 2:17 UTC (permalink / raw)
To: Pavel Machek
Cc: Bjorn Andersson, Richard Purdie, Jacek Anaszewski,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-leds-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170323203749.GB8563@amd>
On Thu, Mar 23, 2017 at 09:37:49PM +0100, Pavel Machek wrote:
> Hi!
>
> > The Light Pulse Generator (LPG) is a PWM-block found in a wide range of
> > PMICs from Qualcomm. It can operate on fixed parameters or based on a
> > lookup-table, altering the duty cycle over time - which provides the
> > means for e.g. hardware assisted transitions of LED brightness.
>
> Ok, this is not first hardware that supports something like this. We
> have similar hardware that can do blinking on Nokia N900 -- please
> take a look at leds-lp55*.c
And perhaps some alignment on the bindings too if the N900 has bindings.
> And it would be really good to provide hardware abstraction. We really
> don't want to have different userspace for LPG and for N900 and for
I'm interested in what this looks like as several AOSP platforms do
tri-color LEDs with custom sysfs extensions.
Do any of the Dragonboards have tri-color LEDs?
Rob
--
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] ipmi: bt-bmc: Add ast2500 compatible string
From: Corey Minyard @ 2017-03-29 2:16 UTC (permalink / raw)
To: Rob Herring, Joel Stanley
Cc: openipmi-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Cédric Le Goater,
Andrew Jeffery, Mark Rutland
In-Reply-To: <20170329012224.jeil7uxvi2iefzvh@rob-hp-laptop>
On 03/28/2017 08:22 PM, Rob Herring wrote:
> On Thu, Mar 23, 2017 at 12:31:12AM +1030, Joel Stanley wrote:
>> The ast2500 SoCs contain the same IPMI BT device.
>>
>> Signed-off-by: Joel Stanley <joel-U3u1mxZcP9KHXe+LvDLADg@public.gmane.org>
>> ---
>> Documentation/devicetree/bindings/ipmi/aspeed,ast2400-ibt-bmc.txt | 4 +++-
>> drivers/char/ipmi/bt-bmc.c | 1 +
>> 2 files changed, 4 insertions(+), 1 deletion(-)
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
This is in the IPMI tree for the next kernel.
Thanks all,
-corey
--
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] doc,dts - add XRA1403 DTS binding documentation
From: Linus Walleij @ 2017-03-29 2:09 UTC (permalink / raw)
To: Nandor Han
Cc: Alexandre Courbot, Rob Herring, Mark Rutland,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <39ba92bacf48da957f8f85d5cb11d3254fe3d68f.1490595641.git.nandor.han-JJi787mZWgc@public.gmane.org>
On Mon, Mar 27, 2017 at 8:23 AM, Nandor Han <nandor.han-JJi787mZWgc@public.gmane.org> wrote:
> Add the XRA1403 DTS binding documentation.
>
> Signed-off-by: Nandor Han <nandor.han-JJi787mZWgc@public.gmane.org>
There is no big problem with this but:
> +The XRA1403 is an 16-bit GPIO expander with an SPI interface. Features available:
> + - Individually programmable inputs:
> + - Internal pull-up resistors
> + - Polarity inversion
> + - Individual interrupt enable
> + - Rising edge and/or Falling edge interrupt
> + - Input filter
Since you mention that it has interrupts maybe you want to add bindings
for the cascaded interrupt and the interrupt-controller; keyword etc
already now.
We just document what the hardware can do, we don't have to do all
of it in the first Linux driver submission.
Yours,
Linus Walleij
--
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/3] gpio - Add EXAR XRA1403 SPI GPIO expander driver
From: Linus Walleij @ 2017-03-29 2:07 UTC (permalink / raw)
To: Nandor Han
Cc: Alexandre Courbot, Rob Herring, Mark Rutland,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Semi Malinen
In-Reply-To: <6bf04ba1761f0692cb461558f0c8836f0d1f7ad8.1490595641.git.nandor.han-JJi787mZWgc@public.gmane.org>
On Mon, Mar 27, 2017 at 8:23 AM, Nandor Han <nandor.han-JJi787mZWgc@public.gmane.org> wrote:
> This is a simple driver that provides a /sys/class/gpio
> interface for controlling and configuring the GPIO lines.
Use the gpio tools in tools/gpio, use the characcter device.
Do not use sysfs. Change this to reference the tools.
> It does not provide support for chip select or interrupts.
>
> Signed-off-by: Nandor Han <nandor.han-JJi787mZWgc@public.gmane.org>
> Signed-off-by: Semi Malinen <semi.malinen-JJi787mZWgc@public.gmane.org>
(...)
> +exar Exar Corporation
Send this as a separate patch to the DT bindings maintainer
(Rob Herring.)
> +static int xra1403_get_byte(struct xra1403 *xra, unsigned int addr)
> +{
> + return spi_w8r8(xra->spi, XRA_READ | (addr << 1));
> +}
> +
> +static int xra1403_get_bit(struct xra1403 *xra, unsigned int addr,
> + unsigned int bit)
> +{
> + int ret;
> +
> + ret = xra1403_get_byte(xra, addr + (bit > 7));
> + if (ret < 0)
> + return ret;
> +
> + return !!(ret & BIT(bit % 8));
> +}
This looks like it can use regmap-spi right off, do you agree?
git grep devm_regmap_init_spi
should give you some examples of how to use it.
If it's not off-the shelf regmap drivers like
drivers/iio/pressure/mpl115_spi.c
give examples of how to make more elaborate custom
SPI transfers with regmap.
> +static int xra1403_set_bit(struct xra1403 *xra, unsigned int addr,
> + unsigned int bit, int value)
> +{
> + int ret;
> + u8 mask;
> + u8 tx[2];
> +
> + addr += bit > 7;
> +
> + mutex_lock(&xra->lock);
> +
> + ret = xra1403_get_byte(xra, addr);
> + if (ret < 0)
> + goto out_unlock;
> +
> + mask = BIT(bit % 8);
> + if (value)
> + value = ret | mask;
> + else
> + value = ret & ~mask;
> +
> + if (value != ret) {
> + tx[0] = addr << 1;
> + tx[1] = value;
> + ret = spi_write(xra->spi, tx, sizeof(tx));
> + } else {
> + ret = 0;
> + }
> +
> +out_unlock:
> + mutex_unlock(&xra->lock);
> +
> + return ret;
> +}
Classical mask-and-set implementation right?
With regmap this becomes simply regmap_update_bits(map, addr, mask, set)
> +static int xra1403_probe(struct spi_device *spi)
> +{
> + struct xra1403 *xra;
> + struct gpio_desc *reset_gpio;
> +
> + xra = devm_kzalloc(&spi->dev, sizeof(*xra), GFP_KERNEL);
> + if (!xra)
> + return -ENOMEM;
> +
> + /* bring the chip out of reset */
> + reset_gpio = gpiod_get_optional(&spi->dev, "reset", GPIOD_OUT_LOW);
> + if (IS_ERR(reset_gpio))
> + dev_warn(&spi->dev, "could not get reset-gpios\n");
> + else if (reset_gpio)
> + gpiod_put(reset_gpio);
I don't think you should put it, other than in the remove()
function and in that case you need to have it in the
state container.
> + mutex_init(&xra->lock);
> +
> + xra->chip.direction_input = xra1403_direction_input;
> + xra->chip.direction_output = xra1403_direction_output;
Please implement .get_direction(). This is very nice to have.
> +static int xra1403_remove(struct spi_device *spi)
> +{
> + struct xra1403 *xra = spi_get_drvdata(spi);
> +
> + gpiochip_remove(&xra->chip);
Use devm_gpiochip_add_data() and this remove is not
needed at all.
> +static int __init xra1403_init(void)
> +{
> + return spi_register_driver(&xra1403_driver);
> +}
> +
> +/*
> + * register after spi postcore initcall and before
> + * subsys initcalls that may rely on these GPIOs
> + */
> +subsys_initcall(xra1403_init);
> +
> +static void __exit xra1403_exit(void)
> +{
> + spi_unregister_driver(&xra1403_driver);
> +}
> +module_exit(xra1403_exit);
This seems like tricksy. Just module_spi_driver()
should be fine don't you think?
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox