* [PATCH v2] dma: Add Xilinx AXI Video Direct Memory Access Engine driver support
From: Andy Gross @ 2014-01-31 17:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E2698B.6070001@metafoo.de>
On Fri, Jan 24, 2014 at 02:24:27PM +0100, Lars-Peter Clausen wrote:
> On 01/24/2014 12:16 PM, Srikanth Thokala wrote:
> > Hi Lars,
> >
> > On Thu, Jan 23, 2014 at 4:55 PM, Lars-Peter Clausen <lars@metafoo.de> wrote:
> >> On 01/22/2014 05:52 PM, Srikanth Thokala wrote:
> >> [...]
> >>> +/**
> >>> + * xilinx_vdma_device_control - Configure DMA channel of the device
> >>> + * @dchan: DMA Channel pointer
> >>> + * @cmd: DMA control command
> >>> + * @arg: Channel configuration
> >>> + *
> >>> + * Return: '0' on success and failure value on error
> >>> + */
> >>> +static int xilinx_vdma_device_control(struct dma_chan *dchan,
> >>> + enum dma_ctrl_cmd cmd, unsigned long arg)
> >>> +{
> >>> + struct xilinx_vdma_chan *chan = to_xilinx_chan(dchan);
> >>> +
> >>> + switch (cmd) {
> >>> + case DMA_TERMINATE_ALL:
> >>> + xilinx_vdma_terminate_all(chan);
> >>> + return 0;
> >>> + case DMA_SLAVE_CONFIG:
> >>> + return xilinx_vdma_slave_config(chan,
> >>> + (struct xilinx_vdma_config *)arg);
> >>
> >> You really shouldn't be overloading the generic API with your own semantics.
> >> DMA_SLAVE_CONFIG should take a dma_slave_config and nothing else.
> >
> > Ok. The driver needs few additional configuration from the slave
> > device like Vertical
> > Size, Horizontal Size, Stride etc., for the DMA transfers, in that case do you
> > suggest me to define a separate dma_ctrl_cmd like the one FSLDMA_EXTERNAL_START
> > defined for Freescale drivers?
>
> In my opinion it is not a good idea to have driver implement a generic API,
> but at the same time let the driver have custom semantics for those API
> calls. It's a bit like having a gpio driver that expects 23 and 42 as the
> values passed to gpio_set_value instead of 0 and 1. It completely defeats
> the purpose of a generic API, namely that you are able to write generic code
> that makes use of the API without having to know about which implementation
> API it is talking to. The dmaengine framework provides the
> dmaengine_prep_interleaved_dma() function to setup two dimensional
> transfers, e.g. take a look at sirf-dma.c or imx-dma.c.
>
The comments in the include/linux/dmaengine.h state that if you have
non-generic, non-fixed configuration then you can just create your own
structure and embed the dma_slave_config. Using the container_of you can get
back your structure.
I agree that we should always use the generic structure if possible, but
sometimes there are some non-standard things that you have to do for your
hardware. I am currently in a bind for adding some quirky features that are
required by peripherals who want to use the QCOM DMA devices.
If the context field in prep_slave_sg and prep_dma_cyclic was exposed to
everyone, that would allow an easy way to pass in hardware specific
configuration without bastardizing the slave_config. I noticed that rapidio is
the only consumer of that field and that they have their own prep function.
If we are not going to allow people to do their own slave_config when they need
to, then we need to remove the comments from the include file and expose the
context to the dmaengine_prep_slave_sg and dmaengine_prep_dma_cyclic.
--
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH] ARM: zynq: Reserve not DMAable space in front of the kernel
From: Rob Herring @ 2014-01-31 17:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <780bb8c8fd752eeace2fd2fbe1d8ed8572dc0d76.1391170073.git.michal.simek@xilinx.com>
On Fri, Jan 31, 2014 at 6:08 AM, Michal Simek <michal.simek@xilinx.com> wrote:
> Reserve space from 0x0 - __pa(swapper_pg_dir),
> if kernel is loaded from 0, which is not DMAable.
> It is causing problem with MMC driver and others
> which want to add dma buffers to this space.
>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> ---
>
> Jason: I don't think it is worth to bring 0x8000 magic
> value and count minimum from it and phys_addr of swapper_pg_dir.
> Full 512k of memory shouldn't be used by DMA.
>
> ---
> arch/arm/mach-zynq/common.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
The existing DT reserved range can't be used for this purpose?
Rob
>
> diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
> index 1db2a5ca..8c09a83 100644
> --- a/arch/arm/mach-zynq/common.c
> +++ b/arch/arm/mach-zynq/common.c
> @@ -25,6 +25,7 @@
> #include <linux/of_irq.h>
> #include <linux/of_platform.h>
> #include <linux/of.h>
> +#include <linux/memblock.h>
> #include <linux/irqchip.h>
> #include <linux/irqchip/arm-gic.h>
>
> @@ -41,6 +42,18 @@
>
> void __iomem *zynq_scu_base;
>
> +/**
> + * zynq_memory_init - Initialize special memory
> + *
> + * We need to stop things allocating the low memory as DMA can't work in
> + * the 1st 512K of memory.
> + */
> +static void __init zynq_memory_init(void)
> +{
> + if (!__pa(PAGE_OFFSET))
> + memblock_reserve(__pa(PAGE_OFFSET), __pa(swapper_pg_dir));
> +}
> +
> static struct platform_device zynq_cpuidle_device = {
> .name = "cpuidle-zynq",
> };
> @@ -117,5 +130,6 @@ DT_MACHINE_START(XILINX_EP107, "Xilinx Zynq Platform")
> .init_machine = zynq_init_machine,
> .init_time = zynq_timer_init,
> .dt_compat = zynq_dt_match,
> + .reserve = zynq_memory_init,
> .restart = zynq_system_reset,
> MACHINE_END
> --
> 1.8.2.3
>
^ permalink raw reply
* [PATCH 07/10] watchdog: xilinx: Fix OF binding
From: Rob Herring @ 2014-01-31 17:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <26d172891694e4041e73b7dae85a1848adf38034.1391177880.git.michal.simek@xilinx.com>
On Fri, Jan 31, 2014 at 8:18 AM, Michal Simek <michal.simek@xilinx.com> wrote:
> Use of_property_read_u32 functions to clean OF probing.
The subject is a bit misleading as this doesn't really fix anything.
>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> ---
>
> drivers/watchdog/of_xilinx_wdt.c | 25 ++++++++++---------------
> 1 file changed, 10 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/watchdog/of_xilinx_wdt.c b/drivers/watchdog/of_xilinx_wdt.c
> index c229cc4..475440a6 100644
> --- a/drivers/watchdog/of_xilinx_wdt.c
> +++ b/drivers/watchdog/of_xilinx_wdt.c
> @@ -147,8 +147,7 @@ static u32 xwdt_selftest(struct xwdt_device *xdev)
> static int xwdt_probe(struct platform_device *pdev)
> {
> int rc;
> - u32 *tmptr;
> - u32 *pfreq;
> + u32 pfreq, enable_once;
> struct resource *res;
> struct xwdt_device *xdev;
> bool no_timeout = false;
> @@ -168,28 +167,24 @@ static int xwdt_probe(struct platform_device *pdev)
> if (IS_ERR(xdev->base))
> return PTR_ERR(xdev->base);
>
> - pfreq = (u32 *)of_get_property(pdev->dev.of_node,
> - "clock-frequency", NULL);
> -
> - if (pfreq == NULL) {
> + rc = of_property_read_u32(pdev->dev.of_node, "clock-frequency", &pfreq);
> + if (rc) {
> dev_warn(&pdev->dev,
> "The watchdog clock frequency cannot be obtained\n");
> no_timeout = true;
You can kill this...
> }
>
> - tmptr = (u32 *)of_get_property(pdev->dev.of_node,
> - "xlnx,wdt-interval", NULL);
> - if (tmptr == NULL) {
> + rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-interval",
> + &xdev->wdt_interval);
> + if (rc) {
> dev_warn(&pdev->dev,
> "Parameter \"xlnx,wdt-interval\" not found\n");
> no_timeout = true;
and this...
> - } else {
> - xdev->wdt_interval = *tmptr;
> }
>
> - tmptr = (u32 *)of_get_property(pdev->dev.of_node,
> - "xlnx,wdt-enable-once", NULL);
> - if (tmptr == NULL) {
> + rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-enable-once",
> + &enable_once);
> + if (!rc && enable_once) {
> dev_warn(&pdev->dev,
> "Parameter \"xlnx,wdt-enable-once\" not found\n");
> watchdog_set_nowayout(xilinx_wdt_wdd, true);
> @@ -201,7 +196,7 @@ static int xwdt_probe(struct platform_device *pdev)
> */
> if (!no_timeout)
and use "if (pfreq && xdev->wdt_interval)" if you initialize pfreq to 0.
> xilinx_wdt_wdd->timeout = 2 * ((1 << xdev->wdt_interval) /
> - *pfreq);
> + pfreq);
Is the wdog really usable if the timeout properties are missing? Seems
like you should fail to probe rather than warn.
Rob
^ permalink raw reply
* [PATCH v5 00/20] Armada 370/XP watchdog support
From: Willy Tarreau @ 2014-01-31 17:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140129181949.GB27143@localhost>
On Wed, Jan 29, 2014 at 03:19:50PM -0300, Ezequiel Garcia wrote:
> On Mon, Jan 27, 2014 at 12:27:00PM -0300, Ezequiel Garcia wrote:
> > A new round, mostly fixing some minor nitpicks.
> >
>
> If anyone wants to give this a test, here's a public branch:
>
> https://github.com/MISL-EBU-System-SW/mainline-public/tree/wdt_for_v3.14_v5
Tested-By: Willy Tarreau <w@1wt.eu>
Works like a charm on the mirabox, I've long been missing a hardware
watchdog to save me from unplugging the power cord after some hangs
during development.
Thanks,
Willy
^ permalink raw reply
* [PATCH] arm: dma-mapping: Add support to extend DMA IOMMU mappings
From: Andreas Herrmann @ 2014-01-31 17:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140130084413.GC13543@alberich>
Instead of using just one bitmap to keep track of IO virtual addresses
(handed out for IOMMU use) introduce an array of bitmaps. This allows
us to extend existing mappings when running out of iova space in the
initial mapping etc.
If there is not enough space in the mapping to service an IO virtual
address allocation request, __alloc_iova() tries to extend the mapping
-- by allocating another bitmap -- and makes another allocation
attempt using the freshly allocated bitmap.
This allows arm iommu drivers to start with a decent initial size when
an dma_iommu_mapping is created and still to avoid running out of IO
virtual addresses for the mapping.
A new parameter is introduced for arm_iommu_create_mapping:
int extensions
Specifies how often the initial mapping of size bytes can be
extended by another address range of size bytes. Thus if
extensions = 0 is passed the mapping won't be extended at
all.
Adapt existing calls to arm_iommu_create_mapping in exynos_drm_iommu.c
and shmobile-iommu.c such that they do not make use of the extension
feature.
Adapt existing call to arm_iommu_create_mapping in arm-smmu.c such
that the extension feature will be used. (The resulting maximum
mapping size is 4GB.)
Tests were done on Calxeda ECX-2000 with smmu for sata and xgmac.
I've used SZ_512K for the size of the mapping and 31 for the
extensions parameter.
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Hiroshi Doyu <hdoyu@nvidia.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Andreas Herrmann <herrmann.der.user@googlemail.com>
Signed-off-by: Andreas Herrmann <andreas.herrmann@calxeda.com>
---
arch/arm/include/asm/dma-iommu.h | 12 ++-
arch/arm/mm/dma-mapping.c | 135 ++++++++++++++++++++++++-----
drivers/gpu/drm/exynos/exynos_drm_iommu.c | 4 +-
drivers/iommu/arm-smmu.c | 2 +-
drivers/iommu/shmobile-iommu.c | 2 +-
5 files changed, 126 insertions(+), 29 deletions(-)
Hi Marek, Will,
Here is a 2nd attempt to implement this feature. This time using
an array of bitmaps. The initial size for the mapping will be used
to extend the mapping if running out of unused IO addresses.
Comments welcome.
Regards,
Andreas
diff --git a/arch/arm/include/asm/dma-iommu.h b/arch/arm/include/asm/dma-iommu.h
index a8c56ac..e12c6c2 100644
--- a/arch/arm/include/asm/dma-iommu.h
+++ b/arch/arm/include/asm/dma-iommu.h
@@ -13,8 +13,12 @@ struct dma_iommu_mapping {
/* iommu specific data */
struct iommu_domain *domain;
- void *bitmap;
- size_t bits;
+ unsigned long **bitmaps; /* array of bitmaps */
+ unsigned int nr_bitmaps; /* nr of elements in array */
+ unsigned int extensions;
+ size_t bitmap_size; /* size of a sinble bitmap */
+ size_t bits; /* per bitmap */
+ unsigned int size; /* per bitmap */
unsigned int order;
dma_addr_t base;
@@ -23,8 +27,8 @@ struct dma_iommu_mapping {
};
struct dma_iommu_mapping *
-arm_iommu_create_mapping(struct bus_type *bus, dma_addr_t base, size_t size,
- int order);
+arm_iommu_create_mapping(struct bus_type *bus, dma_addr_t base, size_t size,
+ int order, int extensions);
void arm_iommu_release_mapping(struct dma_iommu_mapping *mapping);
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index f61a570..bd9cd22 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1069,6 +1069,8 @@ fs_initcall(dma_debug_do_init);
/* IOMMU */
+static int extend_iommu_mapping(struct dma_iommu_mapping *mapping);
+
static inline dma_addr_t __alloc_iova(struct dma_iommu_mapping *mapping,
size_t size)
{
@@ -1076,6 +1078,8 @@ static inline dma_addr_t __alloc_iova(struct dma_iommu_mapping *mapping,
unsigned int align = 0;
unsigned int count, start;
unsigned long flags;
+ dma_addr_t iova;
+ int i;
if (order > CONFIG_ARM_DMA_IOMMU_ALIGNMENT)
order = CONFIG_ARM_DMA_IOMMU_ALIGNMENT;
@@ -1087,30 +1091,78 @@ static inline dma_addr_t __alloc_iova(struct dma_iommu_mapping *mapping,
align = (1 << (order - mapping->order)) - 1;
spin_lock_irqsave(&mapping->lock, flags);
- start = bitmap_find_next_zero_area(mapping->bitmap, mapping->bits, 0,
- count, align);
- if (start > mapping->bits) {
- spin_unlock_irqrestore(&mapping->lock, flags);
- return DMA_ERROR_CODE;
+ for (i = 0; i < mapping->nr_bitmaps; i++) {
+ start = bitmap_find_next_zero_area(mapping->bitmaps[i],
+ mapping->bits, 0, count, align);
+
+ if (start > mapping->bits)
+ continue;
+
+ bitmap_set(mapping->bitmaps[i], start, count);
+ break;
}
- bitmap_set(mapping->bitmap, start, count);
+ /*
+ * No unused range found. Try to extend the existing mapping
+ * and perform a second attempt to reserve an IO virtual
+ * address range of size bytes.
+ */
+ if (i == mapping->nr_bitmaps) {
+ if (extend_iommu_mapping(mapping)) {
+ spin_unlock_irqrestore(&mapping->lock, flags);
+ return DMA_ERROR_CODE;
+ }
+ pr_err("extended iommu mapping\n");
+ start = bitmap_find_next_zero_area(mapping->bitmaps[i],
+ mapping->bits, 0, count, align);
+
+ if (start > mapping->bits) {
+ spin_unlock_irqrestore(&mapping->lock, flags);
+ return DMA_ERROR_CODE;
+ }
+
+ bitmap_set(mapping->bitmaps[i], start, count);
+ }
spin_unlock_irqrestore(&mapping->lock, flags);
- return mapping->base + (start << (mapping->order + PAGE_SHIFT));
+ iova = mapping->base + (mapping->size * i);
+ iova += start << (mapping->order + PAGE_SHIFT);
+
+ return iova;
}
static inline void __free_iova(struct dma_iommu_mapping *mapping,
dma_addr_t addr, size_t size)
{
- unsigned int start = (addr - mapping->base) >>
- (mapping->order + PAGE_SHIFT);
- unsigned int count = ((size >> PAGE_SHIFT) +
- (1 << mapping->order) - 1) >> mapping->order;
+ unsigned int start, count;
unsigned long flags;
+ dma_addr_t bitmap_base;
+ u32 bitmap_index;
+
+ if (!size)
+ return;
+
+ bitmap_index = (u32) (addr - mapping->base) / (u32) mapping->size;
+ BUG_ON(addr < mapping->base || bitmap_index > mapping->extensions);
+
+ bitmap_base = mapping->base + mapping->size * bitmap_index;
+
+ start = (addr - bitmap_base) >> (mapping->order + PAGE_SHIFT);
+
+ if (addr + size > bitmap_base + mapping->size) {
+ /*
+ * The address range to be freed reaches into the iova
+ * range of the next bitmap. This should not happen as
+ * we don't allow this in __alloc_iova (at the
+ * moment).
+ */
+ BUG();
+ } else
+ count = ((size >> PAGE_SHIFT) +
+ (1 << mapping->order) - 1) >> mapping->order;
spin_lock_irqsave(&mapping->lock, flags);
- bitmap_clear(mapping->bitmap, start, count);
+ bitmap_clear(mapping->bitmaps[bitmap_index], start, count);
spin_unlock_irqrestore(&mapping->lock, flags);
}
@@ -1875,22 +1927,30 @@ struct dma_map_ops iommu_coherent_ops = {
* arm_iommu_create_mapping
* @bus: pointer to the bus holding the client device (for IOMMU calls)
* @base: start address of the valid IO address space
- * @size: size of the valid IO address space
+ * @size: (initial) size of the valid IO address space
* @order: accuracy of the IO addresses allocations
+ * @extensions: specifies how many times it's allowed to extend the initial
+ * mapping (0 - no extension at all, 1 - mapping can be extended
+ * once, 2 - mapping can be extended twice, etc.)
*
* Creates a mapping structure which holds information about used/unused
* IO address ranges, which is required to perform memory allocation and
* mapping with IOMMU aware functions.
*
+ * If a positive extensions parameter is passed the mapping will be
+ * extended (by size bytes) when the mapping runs out of unused IO
+ * addresses. Thus the maximum size of the mapping is
+ *
+ * size * (1 + extensions)
+ *
* The client device need to be attached to the mapping with
* arm_iommu_attach_device function.
*/
struct dma_iommu_mapping *
arm_iommu_create_mapping(struct bus_type *bus, dma_addr_t base, size_t size,
- int order)
+ int order, int extensions)
{
unsigned int count = size >> (PAGE_SHIFT + order);
- unsigned int bitmap_size = BITS_TO_LONGS(count) * sizeof(long);
struct dma_iommu_mapping *mapping;
int err = -ENOMEM;
@@ -1901,23 +1961,35 @@ arm_iommu_create_mapping(struct bus_type *bus, dma_addr_t base, size_t size,
if (!mapping)
goto err;
- mapping->bitmap = kzalloc(bitmap_size, GFP_KERNEL);
- if (!mapping->bitmap)
+ mapping->bitmap_size = BITS_TO_LONGS(count) * sizeof(long);
+ mapping->bitmaps = kzalloc((extensions + 1) * sizeof(unsigned long *),
+ GFP_KERNEL);
+ if (!mapping->bitmaps)
goto err2;
+ mapping->bitmaps[0] = kzalloc(mapping->bitmap_size, GFP_KERNEL);
+ if (!mapping->bitmaps[0])
+ goto err3;
+
+ mapping->nr_bitmaps = 1;
+ mapping->extensions = extensions;
mapping->base = base;
- mapping->bits = BITS_PER_BYTE * bitmap_size;
+ mapping->size = size;
mapping->order = order;
+ mapping->bits = BITS_PER_BYTE * mapping->bitmap_size;
+
spin_lock_init(&mapping->lock);
mapping->domain = iommu_domain_alloc(bus);
if (!mapping->domain)
- goto err3;
+ goto err4;
kref_init(&mapping->kref);
return mapping;
+err4:
+ kfree(mapping->bitmaps[0]);
err3:
- kfree(mapping->bitmap);
+ kfree(mapping->bitmaps);
err2:
kfree(mapping);
err:
@@ -1927,14 +1999,35 @@ EXPORT_SYMBOL_GPL(arm_iommu_create_mapping);
static void release_iommu_mapping(struct kref *kref)
{
+ int i;
struct dma_iommu_mapping *mapping =
container_of(kref, struct dma_iommu_mapping, kref);
iommu_domain_free(mapping->domain);
- kfree(mapping->bitmap);
+ for (i = 0; i < mapping->nr_bitmaps; i++)
+ kfree(mapping->bitmaps[i]);
+ kfree(mapping->bitmaps);
kfree(mapping);
}
+static int extend_iommu_mapping(struct dma_iommu_mapping *mapping)
+{
+ int next_bitmap;
+
+ if (mapping->nr_bitmaps > mapping->extensions)
+ return -EINVAL;
+
+ next_bitmap = mapping->nr_bitmaps;
+ mapping->bitmaps[next_bitmap] = kzalloc(mapping->bitmap_size,
+ GFP_ATOMIC);
+ if (!mapping->bitmaps[next_bitmap])
+ return -ENOMEM;
+
+ mapping->nr_bitmaps++;
+
+ return 0;
+}
+
void arm_iommu_release_mapping(struct dma_iommu_mapping *mapping)
{
if (mapping)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_iommu.c b/drivers/gpu/drm/exynos/exynos_drm_iommu.c
index fb8db03..cc8389e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_iommu.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_iommu.c
@@ -40,8 +40,8 @@ int drm_create_iommu_mapping(struct drm_device *drm_dev)
priv->da_space_order = EXYNOS_DEV_ADDR_ORDER;
mapping = arm_iommu_create_mapping(&platform_bus_type, priv->da_start,
- priv->da_space_size,
- priv->da_space_order);
+ priv->da_space_size,
+ priv->da_space_order, 0);
if (IS_ERR(mapping))
return PTR_ERR(mapping);
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index bee88c8..67b3364 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1694,7 +1694,7 @@ static int arm_smmu_group_notifier(struct notifier_block *nb,
break;
mapping = arm_iommu_create_mapping(&platform_bus_type,
- 0, SZ_128M, 0);
+ 0, SZ_128M, 0, 31);
if (IS_ERR(mapping)) {
ret = PTR_ERR(mapping);
dev_info(dev, "arm_iommu_create_mapping failed\n");
diff --git a/drivers/iommu/shmobile-iommu.c b/drivers/iommu/shmobile-iommu.c
index d572863..2540b7e 100644
--- a/drivers/iommu/shmobile-iommu.c
+++ b/drivers/iommu/shmobile-iommu.c
@@ -343,7 +343,7 @@ static int shmobile_iommu_add_device(struct device *dev)
mapping = archdata->iommu_mapping;
if (!mapping) {
mapping = arm_iommu_create_mapping(&platform_bus_type, 0,
- L1_LEN << 20, 0);
+ L1_LEN << 20, 0, 0);
if (IS_ERR(mapping))
return PTR_ERR(mapping);
archdata->iommu_mapping = mapping;
--
1.7.9.5
^ permalink raw reply related
* Extending OPP bindings
From: Rob Herring @ 2014-01-31 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140131124620.GC2616@e102568-lin.cambridge.arm.com>
On Fri, Jan 31, 2014 at 6:46 AM, Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
> Hi Nishanth,
>
> On Fri, Jan 31, 2014 at 12:43:54AM +0000, Nishanth Menon wrote:
>> Hi Sudeep,
>>
>> On 01/30/2014 07:43 AM, Sudeep Holla wrote:
>>
>> >
>> > I am looking into a couple shortcomings in the current OPP bindings and
>> > how to address them. Feel free to add to the list if you think of any more
>> > issues that needs to be addressed or if and how any problem mentioned below
>> > can be handled with the existing bindings.
>> >
>> > 1. indexing: currently there are no indices in the operating-points.
>> indexing is based on frequency which is why the accessors use
>> frequency to pull out the OPP data.
>>
>> indexing is a horrible idea - on platforms where OPP may be disabled
>> or enabled for various reasons(see arch/arm/mach-imx/mach-imx6q.c,
>> arch/arm/mach-omap2/board-omap3beagle.c etc) - the indexing you see in
>> dts is just a myth that may not exist once the nodes are loaded and
>> operated upon depending on SoC variations (example efuse describing
>> which OPPs can be used and which not).
>
> I do not understand why. As long as a mapping from DT to data structures
> in the kernel is done at boot, I can see how by indexing device nodes
> can refer to specific OPPs. If they are disabled, amen, as long as we
> can point at specific operating points that should be ok.
>
> Indexing does not mean that the index in the DT is the same as the one
> allocated by the OS. Indexing is there to point at specific OPPs from
> different DT nodes, a good example are clock bindings and that's exactly
> how they work.
That is not a good comparison. With clocks, you are describing which
physical signal coming out of a hardware block much like interrupts.
Granted the h/w is not typically documented that way for clocks
although the numbering could correspond to register bit locations as
interrupt numbers do. With OPP indexes, they are a totally made up
software construct.
Perhaps OPPs should be nodes so new fields can be added easily and
then you have a phandle for each OPP.
>
> Can you provide me with an example where the indexing would go wrong
> please ?
Putting s/w indexes into DT. Using cell-index for uarts to define
their tty number was one example.
> Certainly relying on implicit ordering is not great either, actually I
> would say that it is broken.
>
>> That said, the original OPP[1][2] series discussion started by trying
>> to kill indexing precisely for the same reason.. once you have it - it
>> becomes just crazy to deal with.
>
> I could not find any "index killing" :) discussion in there, but I will
> keep reading.
>
>> > It's assumed that the list is either in ascending or descending
>> > order of frequency but not explicit in the binding document.
>> > There are arch/arm/boot/dts/* files with opps in both styles.
>> it should not matter -> opp library should do an insertion sort and
>> organize it in ascending order once all the data is inserted. (line
>> 449ish in opp.c)
>
> That's OS details and they must not be mandated by the bindings.
> We cannot rely on word of mouth for things to work, I do not like
> implicit rules, so the bindings should speficy the ordering or better
> a way to reference OPPs.
>
>> if you see issues with the insertion sort not functioning, it is a bug
>> and should be easy to track down and fix.
>
> Problem is not the insertion sort, problem is that DT bindings do not
> define a way to refer to a specific OPP, unless we do that implicitly
> and again, I rest my case, that is broken.
>
>> > Few other bindings like thermal defines bindings like
>> > cooling-{min,max}-state assuming some order which is broken IMO.
>> Now that you bring it up, I missed it :(.. yeah, I might have
>> preferred it to be min frequency and max_frequency - I agree it is
>> probably broken. I'd let Eduardo comment more about it.
>>
>> >
>> > One such use-case that came up recently[0] is the c-state latencies
>> > which could be different for each OPP. It would be good if the
>> > latencies are specified with the indices to OPP table to avoid
>> > inconsistency between the bindings.
>>
>> You can define C states based on frequencies as well - which really
>> makes sense - since that sounds really like our constraint (say
>> valid-at-frequency "xyz"
>
> I do not think that's generic enough, I do not like the idea of looking
> up frequencies (eg a C-state target_residency does not depend on the
> frequency only - ie voltage and other factors play a role, it really
> depends on an operating point- looking it up by frequency is misleading IMO).
It seems we are trying to fit a square peg into a round hole here.
Rob
^ permalink raw reply
* Why are imprecise external aborts masked on recent kernel while booting ?
From: Russell King - ARM Linux @ 2014-01-31 17:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EBC86D.1010509@st.com>
On Fri, Jan 31, 2014 at 04:59:41PM +0100, Fabrice Gasnier wrote:
> Is it a desired change in recent kernels ?
I think it was an unnoticed behavioural change.
> Is it possible to unmask imprecise data aborts earlier in the boot
> process (e.g. before PCIe bus enumeration, when drivers are being probed)
> ?
How about this patch?
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index 172ee18ff124..b0ff06f49cd0 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -900,6 +900,15 @@ void __init early_trap_init(void *vectors_base)
flush_icache_range(vectors, vectors + PAGE_SIZE * 2);
modify_domain(DOMAIN_USER, DOMAIN_CLIENT);
+
+ /* Enable imprecise aborts */
+ asm volatile(
+ "mrs %0, cpsr\n"
+ " bic %0, %0, %1\n"
+ " msr cpsr_c, %0"
+ : "=&r" (i)
+ : "r" (PSR_A_BIT));
+
#else /* ifndef CONFIG_CPU_V7M */
/*
* on V7-M there is no need to copy the vector table to a dedicated
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply related
* [PATCH] usb: dwc3: keystone: switch to use runtime pm
From: Felipe Balbi @ 2014-01-31 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EBC650.50305@ti.com>
On Fri, Jan 31, 2014 at 10:50:40AM -0500, Santosh Shilimkar wrote:
> On Friday 31 January 2014 10:47 AM, Felipe Balbi wrote:
> > On Fri, Jan 31, 2014 at 10:43:21AM -0500, Santosh Shilimkar wrote:
> >> On Friday 31 January 2014 10:19 AM, Felipe Balbi wrote:
> >>> Hi,
> >>>
> >>> On Fri, Jan 31, 2014 at 03:20:26PM +0200, Grygorii Strashko wrote:
> >>>> The Keystone PM management layer has been implemented using PM bus for
> >>>> power management clocks. As result, most of Keystone drivers don't need
> >>>> to manage clocks directly. They just need to enable runtime PM and use it
> >>>> to handle their PM state and clocks.
> >>>>
> >>>> Hence, remove clock management code and switch to use runtime PM.
> >>>>
> >>>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> >>>
> >>> quite a few weeks back I sent a series enabling runtime pm for all glue
> >>> layers. I'll use that version instead, sorry.
> >>>
> >> That should be fine but you need to drop clk_*() related code
> >> from that patch. I assume you will send refresh version of it then.
> >
> > why ? it makes no difference if you enable twice and disable twice.
> >
> Sure but why do you want to have the clock node handling code in drivers
> if it is not needed. Isn't that better ?
It might, but then way that I wanted to see it is so that I can make
assumptions about the device state. From a driver perspective, what I
would love to see is the ability to assume that when my probe gets
called the device is already enabled. So if you can make sure that
clk_enable() happens before my probe and that you call
pm_runtime_set_active() before my probe too, then I can more than
hapilly remove clk_* calls from the driver ;-)
either that or maintain the driver like so:
probe()
{
...
clk_get(dev, "fck");
clk_prepare(clk);
clk_enable(clk);
pm_runtime_set_active(dev);
pm_runtime_enable(dev);
pm_runtime_get_sync(dev);
...
}
runtime_suspend()
{
clk_disable(dev);
}
runtime_resume()
{
clk_enable(dev);
}
note that because of pm_runtime_set_active() that first
pm_runtime_get_sync() in probe() will simply increase the reference
counter without calling my ->runtime_resume() callback, which is exactly
what we want, as that would completely avoid situations of bad context
being restored because of that initial pm_runtime_get_sync().
Then, we can even make pm_runtime completely async easily, because
clk_prepare() was called only on probe() (or before it, for that
matter).
Bottomline is, if you can guarantee me that clk_get(), clk_prepare(),
clk_enable() and pm_runtime_set_active() will be called properly before
my probe, i'll be more than happy to comply with your request above as
that will greatly simplify my driver.
Just make, also, that if this clock is shared between dwc3-keystone
wrapper and dwc3 core, you clk_get() on both driver's probe.
cheers
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140131/e709d095/attachment.sig>
^ permalink raw reply
* [PATCH v2 08/11] of: Increase MAX_PHANDLE_ARGS
From: Rob Herring @ 2014-01-31 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140130174546.GF13543@alberich>
On Thu, Jan 30, 2014 at 11:45 AM, Andreas Herrmann
<andreas.herrmann@calxeda.com> wrote:
> On Wed, Jan 29, 2014 at 12:26:35PM -0500, Suravee Suthikulanit wrote:
>> On 1/29/2014 11:16 AM, Andreas Herrmann wrote:
>> > On Wed, Jan 29, 2014 at 11:59:12AM -0500, Suravee Suthikulanit wrote:
>> >> On 1/29/2014 10:57 AM, Rob Herring wrote:
>> >>>>> diff --git a/include/linux/of.h b/include/linux/of.h
>> >>>>>>> index 276c546..24e1b28 100644
>> >>>>>>> --- a/include/linux/of.h
>> >>>>>>> +++ b/include/linux/of.h
>> >>>>>>> @@ -67,7 +67,7 @@ struct device_node {
>> >>>>>>> #endif
>> >>>>>>> };
>> >>>>>>>
>> >>>>>>> -#define MAX_PHANDLE_ARGS 8
>> >>>>>>> +#define MAX_PHANDLE_ARGS 16
>> >>>>>
>> >>>>>
>> >>>>> Since the MMU-500 specify "Number of SMRs" upto 128 registers, shouldn't
>> >>>>> this be changed to be able to support 128 StreamIDs as well? Although I am
>> >>>>> not sure if this would be too big to have on the stack per Rob's comment in
>> >>>>> the previous patch set.
>> >>> Do you actually need 128 now? If not, then we can deal with that when
>> >>> we get there. There are lots of things in spec's that are not actually
>> >>> implemented or supported.
>> >>
>> >> Actually, we are using 32 on the AMD system. So, do you think we can set
>> >> this to 32 instead?
>> >
>> > I think that's ok.
>> >
>> > But are we really talking about number of SMRs or number of StreamIDs
>> > per master device here? Ie. are you just having 32 SMRs for an SMMU on
>> > your AMD system or do you have master devices which have 32 StreamIDs?
>> >
>> > If it's just number of SMRs we don't need to modify this macro.
>
>> I am referring to the case where each mmu-master can have upto 32 streamID.
>
> Rob,
>
> Do you agree on increasing MAX_PHANDLE_ARGS to 32?
Yes, but more than that will require a closer look. Please get this
into next early in the cycle.
> Or should this be done when someone (e.g. Suravee) submits a DTS
> update with an SMMU node description containing more than 16 stream
> IDs for a master device?
Well, I am inclined to not care having seen no upstream activity for
AMD's platform.
Rob
^ permalink raw reply
* [PATCH 3/3] spi: switch to devm_spi_alloc_master
From: Stephen Warren @ 2014-01-31 16:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391163792-21819-4-git-send-email-maxime.ripard@free-electrons.com>
On 01/31/2014 03:23 AM, Maxime Ripard wrote:
> Make the existing users of devm_spi_register_master use the
> devm_spi_alloc_master function to avoid leaking memory.
> diff --git a/drivers/spi/spi-tegra114.c b/drivers/spi/spi-tegra114.c
> @@ -1087,14 +1085,13 @@ static int tegra_spi_probe(struct platform_device *pdev)
> if (ret < 0) {
> dev_err(&pdev->dev, "Failed to register ISR for IRQ %d\n",
> tspi->irq);
> - goto exit_free_master;
> + return ret;
> }
>
> tspi->clk = devm_clk_get(&pdev->dev, "spi");
> if (IS_ERR(tspi->clk)) {
> dev_err(&pdev->dev, "can not get clock\n");
> - ret = PTR_ERR(tspi->clk);
> - goto exit_free_irq;
> + return PTR_ERR(tspi->clk);
> }
>
> tspi->max_buf_size = SPI_FIFO_DEPTH << 2;
> @@ -1152,8 +1149,6 @@ exit_rx_dma_free:
> tegra_spi_deinit_dma_param(tspi, true);
> exit_free_irq:
> free_irq(spi_irq, tspi);
> -exit_free_master:
> - spi_master_put(master);
> return ret;
Doesn't that s/goto exit_free_irq/return/ leak spi_irq? It's only OK to
replace goto free_master with a direct return.
The other two Tegra drivers don't seem to have this problem.
^ permalink raw reply
* recommended action for bootloaders regarding modifying device-tree nodes
From: Jason Cooper @ 2014-01-31 16:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJ+vNU2zis+1DUCzmegUFw+Z6XATBEPJ+yqMsttp4ENcckHUYA@mail.gmail.com>
On Thu, Jan 30, 2014 at 08:39:00PM -0800, Tim Harvey wrote:
> On Thu, Jan 30, 2014 at 12:45 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> > Hi Tim,
> >
> > On Thu, Jan 30, 2014 at 01:11:18AM -0800, Tim Harvey wrote:
> >> My approach has been to define a per-baseboard device-tree in Linux
> >> for a 'fully loaded' board, then remove nodes which the EEPROM claims
> >> are not present in the bootloader before it passes the DTB to the
> >> kernel. I do this by defining aliases in the device-tree for the
> >> peripherals that are 'optional' so that the bootloader itself does not
> >> need to know the details about how the device is connected.
> >
> > This is more of a process question: Is there any information captured
> > in your EEPROM that can't be represented in the dtb? iow, at the point
> > when you write the EEPROM, why not write the dtb to it as configured?
> >
> > You could have pre-configured dtsi fragments for each config option, and
> > then dynamically create the board dts from the order.
> >
> > I only ask because it would solve the problem below. However, there's a
> > lot more to changing a manufacturing process than meets the eye. :)
> >
>
> our eeprom config section is only 40 bytes. It contains a SKU string,
> mac addrs, and some bitwise fields for the various optional components
> that we can subload.
Ok.
> >> Is it more appropriate for the bootloader to 'remove' nodes for
> >> devices that are not physically present or should I be setting their
> >> status property to 'disabled' instead? I'm not clear if either option
> >> really has any pros or cons.
> >
> > That depends on how you have it structured. Is it a valid dtb?
> > Meaning, do you have four nodes all at the same register address?
> > Perhaps you could provide an example dts?
>
> yes its a valid dtb - it is just the superset of everything the
> baseboard (ie schematic design) can support.
>
> A good example is a custom SKU of a baseboard with ethernet subloaded.
> If the EEPROM says there is no ethernet mac or phy, I would want to
> remove or disable the ethernet node from the devicetree.
>
> Another example would be a node for 'gpio-pps' (GPIO based
> pulse-per-second) support. A baseboard design that has a GPS with its
> PPS signal tied to a GPIO would define this in the device-tree, but if
> the EEPROM says the GPS isn't loaded, I would want to remove or
> disable the gps-pps node.
I think JasonG's approach is the way to go (inserting nops). But it's a
matter of preference as long as the output is a valid dtb.
on a side note: Do you still have to tie your dtb to a version of the
kernel?
thx,
Jason.
^ permalink raw reply
* [PATCH v2 3/5] spi: sunxi: Add Allwinner A31 SPI controller driver
From: Mark Brown @ 2014-01-31 16:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140131081147.GC2950@lukather>
On Fri, Jan 31, 2014 at 09:11:47AM +0100, Maxime Ripard wrote:
> Wouldn't it be better if it was suspended by default, and just waken
> up whenever the framework needs it?
The aim should be to come out of probe in that state if runtime PM is
enabled but don't do it with these hacks, do it by idling the device
at the end of probe for example. Apart from anything else this code
just looks ugly.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140131/2482bece/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: dts: k2hk-evm: rename clock node to clocks
From: Grygorii Strashko @ 2014-01-31 16:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EBB4F6.3050202@ti.com>
On 01/31/2014 04:36 PM, Santosh Shilimkar wrote:
> On Friday 31 January 2014 08:31 AM, Grygorii Strashko wrote:
>> Fix type in clock(s) node name: "clock"-->"clocks".
>>
> s/type/typo ;-)
>
>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
>> ---
> No need to resend, I will fix it up while applying it
Thanks
>
>> arch/arm/boot/dts/k2hk-evm.dts | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/k2hk-evm.dts b/arch/arm/boot/dts/k2hk-evm.dts
>> index eaefdfe..c02c3a8 100644
>> --- a/arch/arm/boot/dts/k2hk-evm.dts
>> +++ b/arch/arm/boot/dts/k2hk-evm.dts
>> @@ -15,7 +15,7 @@
>> compatible = "ti,keystone-evm";
>>
>> soc {
>> - clock {
>> + clocks {
>> refclksys: refclksys {
>> #clock-cells = <0>;
>> compatible = "fixed-clock";
>>
>
^ permalink raw reply
* Why are imprecise external aborts masked on recent kernel while booting ?
From: Fabrice Gasnier @ 2014-01-31 15:59 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
I'm working on a PCIe driver that uses an "imprecise external abort"
handler to detect when a port is behind a switch.
This mechanism is used when enumerating PCIe bus upon kernel boot.
In prior kernel (3.4), I noticed it's possible to use an abort handler
registered by using hook_fault_code(16+6, ...);
These aborts are detected and the relevant handler is called as long as
it is registered, when probing the bus.
In more recent kernel (3.10), abort handler is no longer triggered
during kernel boot. At PCIe bus enumeration, imprecise aborts are not
enabled. It seems unmasked later when starting userland init process
(e.g. when CPSR.A bit on arm is cleared). Aborts are deferred until then.
I found another thread that looks like similar :
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/208641.html
I looked for where imprecise aborts were enabled on 3.4. I found out
that it was enabled when the first schedule() happens. More precisely in
kernel_thread_helper() when doing: "msr cpsr_c, r7".
There has been changes beetween 3.6 or 3.7, like in commit
9e14f828ee4a7a4a98703e380d180717a579fb35 (and others) that i believe
changes the behavior of unmasking CPSR.A bit. kernel_thread_helper has
been removed in that patch.
Is it a desired change in recent kernels ?
Is it possible to unmask imprecise data aborts earlier in the boot
process (e.g. before PCIe bus enumeration, when drivers are being probed) ?
Best regards,
Fabrice
^ permalink raw reply
* [PATCH] usb: dwc3: keystone: switch to use runtime pm
From: Santosh Shilimkar @ 2014-01-31 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140131154721.GD20736@saruman.home>
On Friday 31 January 2014 10:47 AM, Felipe Balbi wrote:
> On Fri, Jan 31, 2014 at 10:43:21AM -0500, Santosh Shilimkar wrote:
>> On Friday 31 January 2014 10:19 AM, Felipe Balbi wrote:
>>> Hi,
>>>
>>> On Fri, Jan 31, 2014 at 03:20:26PM +0200, Grygorii Strashko wrote:
>>>> The Keystone PM management layer has been implemented using PM bus for
>>>> power management clocks. As result, most of Keystone drivers don't need
>>>> to manage clocks directly. They just need to enable runtime PM and use it
>>>> to handle their PM state and clocks.
>>>>
>>>> Hence, remove clock management code and switch to use runtime PM.
>>>>
>>>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
>>>
>>> quite a few weeks back I sent a series enabling runtime pm for all glue
>>> layers. I'll use that version instead, sorry.
>>>
>> That should be fine but you need to drop clk_*() related code
>> from that patch. I assume you will send refresh version of it then.
>
> why ? it makes no difference if you enable twice and disable twice.
>
Sure but why do you want to have the clock node handling code in drivers
if it is not needed. Isn't that better ?
^ permalink raw reply
* [PATCH] usb: dwc3: keystone: switch to use runtime pm
From: Felipe Balbi @ 2014-01-31 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EBC499.2070302@ti.com>
On Fri, Jan 31, 2014 at 10:43:21AM -0500, Santosh Shilimkar wrote:
> On Friday 31 January 2014 10:19 AM, Felipe Balbi wrote:
> > Hi,
> >
> > On Fri, Jan 31, 2014 at 03:20:26PM +0200, Grygorii Strashko wrote:
> >> The Keystone PM management layer has been implemented using PM bus for
> >> power management clocks. As result, most of Keystone drivers don't need
> >> to manage clocks directly. They just need to enable runtime PM and use it
> >> to handle their PM state and clocks.
> >>
> >> Hence, remove clock management code and switch to use runtime PM.
> >>
> >> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> >
> > quite a few weeks back I sent a series enabling runtime pm for all glue
> > layers. I'll use that version instead, sorry.
> >
> That should be fine but you need to drop clk_*() related code
> from that patch. I assume you will send refresh version of it then.
why ? it makes no difference if you enable twice and disable twice.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140131/a181155d/attachment-0001.sig>
^ permalink raw reply
* Extending OPP bindings
From: Mark Brown @ 2014-01-31 15:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140131124620.GC2616@e102568-lin.cambridge.arm.com>
On Fri, Jan 31, 2014 at 12:46:20PM +0000, Lorenzo Pieralisi wrote:
> Indexing does not mean that the index in the DT is the same as the one
> allocated by the OS. Indexing is there to point at specific OPPs from
> different DT nodes, a good example are clock bindings and that's exactly
> how they work.
> Can you provide me with an example where the indexing would go wrong
> please ?
This does depend on what you mean by indexing but if you're talking
about having bindings where you have things that refer to the nth
element in an array in that form then it can become hard to read the
resulting DT and the potential for errors is increased. Changes to the
original table need to take into account all the references to the table
and (especially if the number of entries gets large) it can be prone to
miscounting when checking references.
With OPPs this might happen if new operating points are characterised or
some are removed, for example due to new SoC variants or binning.
> Certainly relying on implicit ordering is not great either, actually I
> would say that it is broken.
Yes, that too - some sort of explict reference does help.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140131/69f7af5f/attachment.sig>
^ permalink raw reply
* [PATCH] usb: dwc3: keystone: switch to use runtime pm
From: Santosh Shilimkar @ 2014-01-31 15:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140131151955.GB20736@saruman.home>
On Friday 31 January 2014 10:19 AM, Felipe Balbi wrote:
> Hi,
>
> On Fri, Jan 31, 2014 at 03:20:26PM +0200, Grygorii Strashko wrote:
>> The Keystone PM management layer has been implemented using PM bus for
>> power management clocks. As result, most of Keystone drivers don't need
>> to manage clocks directly. They just need to enable runtime PM and use it
>> to handle their PM state and clocks.
>>
>> Hence, remove clock management code and switch to use runtime PM.
>>
>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
>
> quite a few weeks back I sent a series enabling runtime pm for all glue
> layers. I'll use that version instead, sorry.
>
That should be fine but you need to drop clk_*() related code
from that patch. I assume you will send refresh version of it then.
Regards,
Santosh
^ permalink raw reply
* [PATCH V3 6/8] SPEAr13xx: Fixup: Move SPEAr1340 SATA platform code to phy driver
From: Arnd Bergmann @ 2014-01-31 15:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140131041204.GC2618@pratyush-vbox>
On Friday 31 January 2014, Pratyush Anand wrote:
> On Thu, Jan 30, 2014 at 09:21:00PM +0800, Arnd Bergmann wrote:
> > On Thursday 30 January 2014, Mohit Kumar wrote:
> > >
> > > diff --git a/Documentation/devicetree/bindings/phy/spear13xx-miphy.txt b/Documentation/devicetree/bindings/phy/spear13xx-miphy.txt
> > > new file mode 100644
> > > index 0000000..208b37d
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/phy/spear13xx-miphy.txt
> > > @@ -0,0 +1,8 @@
> > > +Required properties:
> > > +- compatible : should be "st,spear1340-sata-pcie-phy".
> >
> > Just for confirmation: This phy is by design only capable of driving
> > sata or pcie, but nothing else if reused in a different SoC, right?
> >
> > If the phy is actually more generic than that, I'd suggest changing
> > the name, otherwise it's ok.
>
> OK, we will give a generic name as it can be used for sata/pcie/usb3.0.
> Although, phy register definition may vary from version to version,
> but that can be managed,as and when support of new soc is added.
It probably doesn't hurt to already define a list of possible
modes in the binding that you already know about. That way, you
don't have to update the binding in sync with the driver if you
add another mode, such as USB.
Arnd
^ permalink raw reply
* [PATCH v2] pwm: add CSR SiRFSoC PWM driver
From: Arnd Bergmann @ 2014-01-31 15:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGsJ_4xFKytv=Mj9eVwGY7RjyUy2W=iSXvnULKyBETYVzMVbOg@mail.gmail.com>
On Friday 31 January 2014, Barry Song wrote:
> >
> > Is SRC_OSC_RATE the rate of spwm->clk? If so, it would be nice to just call
> > clk_get_rate() here, in case you ever have a chip with a different rate.
> >
>
> SRC_OSC_RATE is the fixed frequency of crystal oscillator, but
> spwm->clk comes from the IO bus. the design is a little strange, pwm
> channels don't use the clock of PWM controller to generate
> period/duty, but use other sources.
How about modeling that other source as a fixed-rate clock in DT
then?
Arnd
^ permalink raw reply
* [PATCH] usb: dwc3: keystone: switch to use runtime pm
From: Felipe Balbi @ 2014-01-31 15:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391174426-13773-1-git-send-email-grygorii.strashko@ti.com>
Hi,
On Fri, Jan 31, 2014 at 03:20:26PM +0200, Grygorii Strashko wrote:
> The Keystone PM management layer has been implemented using PM bus for
> power management clocks. As result, most of Keystone drivers don't need
> to manage clocks directly. They just need to enable runtime PM and use it
> to handle their PM state and clocks.
>
> Hence, remove clock management code and switch to use runtime PM.
>
> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
quite a few weeks back I sent a series enabling runtime pm for all glue
layers. I'll use that version instead, sorry.
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140131/53f35523/attachment.sig>
^ permalink raw reply
* [PATCH v4] arm: remove !CPU_V6 and !GENERIC_ATOMIC64 build dependencies for XEN
From: Stefano Stabellini @ 2014-01-31 15:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140121180750.GO30706@mudshark.cambridge.arm.com>
On Tue, 21 Jan 2014, Will Deacon wrote:
> On Tue, Jan 21, 2014 at 01:44:24PM +0000, Stefano Stabellini wrote:
> > Remove !GENERIC_ATOMIC64 build dependency:
> > - introduce xen_atomic64_xchg
> > - use it to implement xchg_xen_ulong
> >
> > Remove !CPU_V6 build dependency:
> > - introduce __cmpxchg8 and __cmpxchg16, compiled even ifdef
> > CONFIG_CPU_V6
> > - implement sync_cmpxchg using __cmpxchg8 and __cmpxchg16
> >
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > CC: arnd at arndb.de
> > CC: linux at arm.linux.org.uk
> > CC: will.deacon at arm.com
> > CC: catalin.marinas at arm.com
> > CC: linux-arm-kernel at lists.infradead.org
> > CC: linux-kernel at vger.kernel.org
> > CC: xen-devel at lists.xenproject.org
>
> Reviewed-by: Will Deacon <will.deacon@arm.com>
>
> Cheers Stefano,
Do you think it is acceptable to have this in 3.14?
Maybe we should aim at 3.15?
^ permalink raw reply
* [PATCH v4] ARM/serial: at91: switch atmel serial to use gpiolib
From: Richard Genoud @ 2014-01-31 15:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZNe0L+yZnqrY51Oeg+k5NHXebJAiqxi+p5Scy-BQ2+1w@mail.gmail.com>
On 13/01/2014 14:39, Linus Walleij wrote:
> On Thu, Nov 7, 2013 at 10:25 AM, Linus Walleij <linus.walleij@linaro.org> wrote:
>
>> This passes the errata fix using a GPIO to control the RTS pin
>> on one of the AT91 chips to use gpiolib instead of the
>> AT91-specific interfaces. Also remove the reliance on
>> compile-time #defines and the cpu_* check and rely on the
>> platform passing down the proper GPIO pin through platform
>> data.
>>
>> This is a prerequisite for getting rid of the local GPIO
>> implementation in the AT91 platform and move toward
>> multiplatform.
>>
>> The patch also adds device tree support for getting the
>> RTS GPIO pin from the device tree on DT boot paths.
>>
>> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>> Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>> ---
>> ChangeLog v3->v4:
>
> ARM SoC folks, if you're not taking this in through the <timex.h> removal
> series then please ACK this patch so I can take it through the GPIO
> tree instead (unless you want to apply this single patch, which would
> be even better, you have Greg's ACK in this thread).
>
I can't find this patch in linux-next, did I missed something ?
^ permalink raw reply
* ALKML rejecting my mails
From: Guennadi Liakhovetski @ 2014-01-31 14:55 UTC (permalink / raw)
To: linux-arm-kernel
Hi Russell,
thanks for offering to have a look at my mail. 2 days ago sending to ALKML
worked just fine for me, but not any longer.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* [PATCH v2] clk: keystone: gate: fix clk_init_data initialization
From: Santosh Shilimkar @ 2014-01-31 14:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391104991-15000-1-git-send-email-ivan.khoronzhuk@ti.com>
On Thursday 30 January 2014 01:03 PM, Ivan Khoronzhuk wrote:
> The clk_init_data struct is allocated in the stack. All members of
> this struct should be initialized before using otherwise it will
> lead to unpredictable situation as it can contain garbage.
>
> Ultimately the clk->flag field contains garbage. In my case it leads
> that flag CLK_IGNORE_UNUSED is set for most of clocks. As result a
> bunch of unused clocks cannot be disabled.
>
> So initialize flags in this structure too.
>
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
> ---
> Based on
> git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git
> keystone/master
>
> v1..v2:
> - updated commit description only
>
Thanks for the update.
> drivers/clk/keystone/gate.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/clk/keystone/gate.c b/drivers/clk/keystone/gate.c
> index 17a5983..86f1e36 100644
> --- a/drivers/clk/keystone/gate.c
> +++ b/drivers/clk/keystone/gate.c
> @@ -179,6 +179,7 @@ static struct clk *clk_register_psc(struct device *dev,
>
> init.name = name;
> init.ops = &clk_psc_ops;
> + init.flags = 0;
> init.parent_names = (parent_name ? &parent_name : NULL);
> init.num_parents = (parent_name ? 1 : 0);
>
>
^ 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